This article also appears in
Subscribe now »

One kind of software-defined vehicle architecture as represented by AUTOSAR, the global partnership of companies in the automotive and software industries collaborating to develop and establish a standardized software framework and vehicle E/E system open architecture. (AUTOSAR/Elektrobit)

Defining the software of ‘software-defined’ vehicles

Elektrobit CEO discusses the landscape of automotive software development and explains why a lot of software doesn’t necessarily have to be all that transformational.

The phrase “software-defined vehicle” has embedded in the vehicle-development lexicon as the catchall for a new era of digitally driven products. But there is persistent disagreement about even the phrase’s definition, much less the engineering scope required to transition from the industry’s hardware-intensive history to a software-driven environment.

Leading into SAE’s WCX 2023 conference earlier this year, SAE Media spoke with Maria Anhalt, CEO at Elektrobit, the 35-year-old developer of software products and services for the auto industry that is an independently operated but wholly owned subsidiary of global supplier Continental. Elektrobit had just announced that Jaguar Land Rover would contract for the company’s software platform and Automotive OS (operating system) to build JLR’s next-generation electrical architecture. And in early August Elektrobit added a collaboration with NXP in which Elektrobit’s software for developing automotive ECUs will support NXP’s S32G3-series vehicle network processors.

Anhalt discussed the definition of “software-defined vehicles,” the confusion over what automotive “operating systems” really encompass and why the bulk of automotive software actually is “non-differentiating.”

SAE media: There is a lot of maneuvering in this space with operating systems (OSs) and who's really going to be in charge of that. You clearly want to be involved in the development of vehicle OSs, but some automakers say they want to do it themselves. Help us understand this landscape.

Ahalt: I'll start with who we are: Elektrobit is a pure-play company ─ systems and software ─ we don't do hardware. We do have hardware engineers, however.

The software-defined vehicle starts from the software and the systems side ─ and I'll explain it in a bit. Being a software company, we earn money with commercial software: software products and software services. What's the difference? A software product is something that solves a problem that is a pattern, you buy it again and again. Think of Microsoft Office, something that you purchase a perpetual license, software as a product, software as a service, and multiple customers can use it, this is the product. Obviously, these products are not differentiating for the end user. For the people who are providing it, it's differentiating, but who is buying it, it's not differentiating.

A software service is — and this is where the automotive industry is coming from — there is an OEM, there is a car maker who comes and says, ‘Hey, I need A, B, C, D, here's my book of requirements, 400 pages, you write it for me.’ This is a service. You write software for somebody, this is differentiating for them, the IP is with the person or the company who orders it; we write the software. This is the difference between a product and services. We do both.

SAE Media: A service then, a customer comes to you essentially with an RFQ to say, ‘Can you do this for us?’

Anhalt: Yes, we do products and we do services. This is one of our co-differentiating principles; there are companies thates. There are a lot of companies that do primarily services.

When you sit in a modern vehicle, there is a ton of software inside. We have done investigation and studies and interviews with carmakers and we estimate that approximately 60 percent of the software that is in the car is something that you're not seeing — you as an end user. You're not seeing and you're not experiencing it. I had a discussion with McKinsey last year and they were saying that they estimate 75 [percent]. Whether it's 60 percent or 75 percent or 68 percent, it doesn't matter a lot.

A lot of software is essential. It's important, but it's not something that the end user, the end customer, is seeing. We refer to this as non-differentiating, meaning it's non-differentiating for the carmaker, it's non-differentiating for the end user. But for us it's differentiating, around 40 percent is differentiating. Think of the software where the ‘trademark’ is visible: entertainment, the cockpit, automated-driving functions, where you sit in a BMW or in a Tesla and you don't even see the logo, but you know it's a different car. These are differentiating aspects.

SAE Media: Separating the differentiating from the non-differentiating helps everyone in the value chain, then?Anhalt: If we position our product for the non-differentiating piece, then this is how we help customers run faster, provide a higher quality of service and save money. Because if you do not need to reinvent the wheel again and again and can base your development on software that is well-established, that is used by multiple other players, tested for many other corner cases, it's foundational.

Our foundational software is where we excel and we provide products, we also provide the maintenance, the upgrade ability and everything because this is how we help the customer run faster, provide faster innovation, increase the quality of the service and everything. An example of this is the [Jaguar Land Rover collaboration] — we have more customers that are basing their development on our software, but this is one famous customer that is publicly speaking about this non-differentiating [component of vehicle software].

Differentiating is where we do something for the user experience so visible that is differentiating, and this is an example for us. You've seen probably seen Afeela, the Sony-Honda mobility [vehicle concept]. This is something for the differentiated piece — our whole piece of this work that we have done for Sony is on the software platform as well, but we also did the end-to-end, we did the system-level design, we did the displays, we did the hardware requirements, we did the software platform, the architecture, the implementation and we did the whole cockpit. Now what you experience in the cockpit, all these displays, L-swipe display, this feeling, the different experience in the car, this is differentiating.

SAE Media: Where does an automotive operating system fit into all this?

Anhalt: When we say automotive OS — I studied computer science, so the operating system per se is something that you don't see, it's in the vehicle. But when OEMs speak about automotive OS, it's not an OS in the computer-science terminology, this is why it's so confusing.

When Volkswagen CARIAD, for example, speaks about automotive OS, they mean the entire vertical stack. You have hardware, then you have some software that is very hardware-specific, then we have the more standard operating system like Linux, the things like this. Then you'll have the hypervisors, then you'll have the middleware, then you have the platform services, then you have the abstraction layer with the software-defined kit, and then you have the functions. When CARIAD says ‘Volkswagen OS,’ they mean the entire vertical stack. When Daimler or Mercedes-Benz talks about the ‘MBOS,’ for them it's also a vertical stack.

SAE Media: When an automaker refers to OS, they are talking about something that would be everything from software that governs the body controller or the engine-management system, all the way to the screen in the cabin?

Anhalt: Yeah, without the hardware, exactly.

When I became the CEO of Elektrobit in January 2021, I was thinking, ‘Shall I use the same terminology?’ I had a torn heart — it's not true if you're a computer scientist, it's very confusing, but if your customers are using that terminology… You cannot implement everything. On one hand, it's just not possible, but what we believe is that there must be a lot of standardization for the non-differentiating pieces that are repeatable that everyone needs, and we must work across the ecosystem to have more and more people reuse these pieces — and differentiate with the functions.

SAE Media: Why is that? Is it a time savings? Is it a money savings? Is it both?

Anhalt: It’s all of those? Because right now, this is part of the problem with this ‘spaghetti code.’ Of course, there's complexity and of course there's safety and everything. But the OEMs have been doing development, "This is the hardware, this is how it works."

With every SOP, with every new product line, they start to develop from scratch every time, and this is why cost is going up; it takes more time, then the quality is low. If we start building software like for the phones — I have an older Samsung phone and I still can upgrade it, it's still an Android, and it's only possible with that, the hardware is decoupled from the software. You can always upgrade it. There is the iPhone, you can upgrade it quite often with a new operating system and the hardware is the same.

SAE Media: Part of the disconnect for some people watching the industry is that the automakers have talked for some time about how many software engineers they're hiring. Do you think that's a mistake, that they should let you do that, and then they can go on about the business of developing a car?

Anhalt: Yes and no. We believe that a carmaker could do everything on their own, but it is very expensive and very slow, and probably there is one or two – max — carmakers in the world who will have the financial power and endurance to go this way. Carmakers have a lot of innovation, they're great companies, but they're not software companies, and there is not even enough talent. We do not have so many software engineers in the world to do everything.

I truly believe that OEMs must acquire software expertise, they must have software engineers in-house. However, team up and leverage the products, the software that already exists, build it in — do not reinvent it again —vv and invest the software capabilities into differentiating features, functions that are relevant for the brand.

SAE Media: ‘Software-defined’ has quickly become a catchphrase – everyone in almost every corner of the industry uses the term. Where do you begin to really define software-defined?

Anhalt: For me, the Sony [Afeela] car is one of the very first true software-defined cars; what Tesla is doing is a software-defined car.

SAE Media: You view Teslas, then, as software-defined vehicles?

Anhalt: Tesla started as a software company; Tesla is a software company that happens to produce cars. They differentiate with software, not with the hardware. They do EVs, but differentiate with the software. They learn with the software, they update with it, their business model is based on the software.

When Sony did the Afeela car, they started with a software, software-defined. We worked together to define a concept for user and experience, everything user-experience from the use case, how you will [interact] with the displays for the cockpit. We know how to do software in the car, Sony knows how to do behavioral studies, how to do user-experience with the gadgets. From there, we define the requirements for the hardware, we define the requirements for the platform, for the architecture — we implement this.

Continue reading »