The German mega-supplier Continental is competing with traditional rivals such as Bosch, as well as non-automotive companies such as Google, to lead the software transformation in the modern automobile. Directing the charge at Continental is Michael Huelsewies, head of architecture and software activities and acting chief technology officer. Huelsewies joined Continental in July 2020 from the Chinese startup Byton, where he headed the global electric/electronics integration team based in San Francisco. Before joining Byton in 2018, he spent most of his career at Delphi/Aptiv, becoming director of global engineering at Aptiv in 2017. Huelsewies discussed the challenges ahead in an interview with Automotive News Europe Correspondent Nick Gibbs.
What does the software-defined vehicle mean for the auto industry?
Electrification and connectivity are enabling a whole new way of defining the product and user experience. Continuous evolution of a car’s digital life cycle is going to become a standard requirement if you’re going to survive and operate in that mobility space. Having the cars always connected means the features will be defined mainly by the software rather than all the mechanical stuff that we had in the past. You start thinking of the car like a computer. How to define these products and how to make sure that we maximize the opportunity from that transformation is what we are very heavily discussing on a daily basis at the moment.
What are your customers asking for?
We need to help them find the sweet spot of how to best shape a scalable platform and the architecture around that to provide connectivity. We also know how to organize and deliver business streams. We need to figure out how to define standards going forward.
What’s a good example from other tech businesses that have defined those standards?
It’s similar to what the mobile phone industry went through 10 or 15 years ago. Back then they had a dozen different systems. Now it boils down to iOS and Android. Or personal computers in the 1980s. IBM PC came in and set a standard platform so you could actually standardize interfaces and hardware platforms and start building your own ecosystem.
Name: Michael Huelsewies
Title: Continental senior vice president, head of architecture and software
Age: 48
Main challenge: Persuading automakers and other players in the automotive software world to collaborate on a standard operating system.
Are automakers in agreement on a common goal?
Everybody has a different understanding of what a standardized operating system really is. Almost every automaker claims to be working on an operating system, but it’s not really comparing apples to apples. We understand, from the hardware all the way up through the middleware and the applications, what makes an operating system. We have a [wholly owned subsidiary] company -- Elektrobit -- that actually is in the middle of that. We see ourselves in a position to shape that future with our customers and partners.
You want to create the equivalent of IBM’s operating system standard, but for automotive computing?
Why not, with partners? I think the point is IBM eventually also did define this platform. It was open, it was free to license, it was free to use for others. And it was explicitly also inviting other players to adapt it and work together. Now, will it be like an IBM standard in the sense that it was set up, or are there other ways to collaborate and create common IP [intellectual property]? For example, we are talking with some our peers on a vertical level, bringing some automakers together, bringing some cloud players together and really working on defining an open standard. We would be more than glad to lead it. We have made the first step with AWS [Amazon Web Services] with a partnership that defines the Continental Automotive Edge, or CAEdge platform, which is a framework that enables exactly that integrated, cloud-connected full-life cycle experience.
If an automaker is looking outside to develop software allowing seamless connectivity, why wouldn’t they go to somebody who is already playing in the world of mobile devices?
We have an understanding of the industry itself. An automobile is obviously not a mobile phone. There are requirements around reliability, robustness, safety and security. We understand the automotive ecosystem and we bring our software expertise into it. Maybe we’re not as visible as Google, but we do have 40,000 engineers, of which 17,000 are software and IT engineers, across Continental.
That number rather eclipses VW with their planned 5,000 software engineers for the Cariad division.
The quantity of software engineers isn't necessarily a measure for how good you are at something, but it does show that there are different layers that require software. In every sensor there is an abstraction layer to translate the message of the sensor into something that can be understood by the vehicle system software. Then there is another abstraction layer, which is enabling third-party applications to connect to the car. And we need to also understand where is the sweet spot for each player. An automaker will differentiate through design, through the user experience. It will not necessarily differentiate through what great API [application programming interface] it has under the hood. And from the hardware side, they of course will differentiate by how comprehensive their basic operating systems are, as well as the hypervisor [software that oversees ‘virtual machine’ software] etc. that enables them. Then there’s the middleware layer.
So, of these different layers, which ones do you want to play in?
We see ourselves playing a key role in the nondifferentiating areas, as well as in the applications, where we are confident that we can provide a best-in-class solution. At some point, we want the opportunity to populate our own applications, basically so users can choose: Do I want to use the built-in weather app or use a different one, because I like the UI [user interface] more?
Does that mean Continental could have an app store?
Yes, it can be us, or it can be the automaker. That's also part of the necessity to create an open platform and to have the ability to deploy these assets in as simply as possible.
Everybody looks to Tesla on this. What have they achieved and where can you learn from it and improve on it?
Tesla has right from the start basically defined their products as driven by the user experience, the features and the software that enables it. So, the car must be always connected. I need to be able to deploy features basically every other day if I want to do that. That of course drives requirements of the hardware and software that led [Tesla], because of the lack of availability of other solutions, to develop proprietary systems.
Is speed also crucial?
Yes, another real differentiator for us is the ability to orchestrate and integrate all these different subsets and applications, and enable customers to get integrated, validated -- ideally, already-in-the-cloud-validated -- software into the car quickly. We need to slash the development times and the time from having an idea or finding a bug and fixing it to below a day. That's our vision. And that's what Tesla had in mind from the beginning when they designed that system. This is the software-driven mindset.
How much did Tesla actually do themselves? Is it possible to go completely on your own?
If you look at the first Tesla Model S, there were a lot of legacy parts from existing suppliers. But that was a necessary evil on the way to going to a further level of vertical integration. And that's kind of what we see now in the mindset of most other automakers. Of course, Tesla had no legacy to deal with, so you can do it from scratch and use the best practices that come from the computer and mobile world.
How do you integrate legacy technology with best practices from the computer and mobile world?
We can do this paradigm shift together with the automakers, to gradually develop an architecture and develop features and functions in a way that are really identified by the software. A translation layer will also have to cope with legacy sensors and domains that are still there and will be there for a while. This is part of the challenge of defining that future architecture. Tesla went that way as well. They started with using an external purchased system, then developing the software on their own, and starting from the real base layer all the way into the application. And now we see they are developing their own microchips, because it’s optimized to the algorithms and to the software that enables the desired functionality.
Where have people gone in the past? And what were the lessons learned from those earlier software developments?
Up to now, pretty much every new feature or function was an add-on system. Each came with its own control unit, embedded software and logic. And that led to an inflation of control units, as people had great ideas and automakers came in with solutions. The more of these control units you had coming into these distributed systems, the more complexity and hardware you brought into the vehicle, which at some point became almost unmanageable.
So in the future, you'll need fewer chips because there will be a sort of a big brain. Is that correct?
That’s definitely an upside when centralizing computing power. Eventually when you have 100-plus electronic control units and each of them has to talk to each other, you need to make up that connection and basically hard-code it in the firmware. It makes it super inflexible. It makes it error prone. And still, once the product is out on the road, you can't really change it. That doesn't work in the long run. Now cars are getting connected and the computing power is getting bigger as well. We’re on a migration path where you need to look for platforms that you can basically build on. That means centralizing the computing power into fewer but more powerful high-performance computers.
How can automakers be persuaded that it's OK to share to create a standard platform?
That’s something you perceive in the messaging of the automakers, but we are already in a dialogue with automakers which isn't so obvious. We are working to find these sweet spots to create a platform that really wouldn't matter if it's the automaker or Continental or any other company providing that platform service, because it's not of particular value add. The value add is that it accelerates the development times so automakers can continuously deliver appreciating features and functionalities to their customers.
So attitudes are changing within the automakers?
A habit that has been proliferated over the last couple of decades in the automotive industry is that you do everything yourself and don't partner. But we see that loosening up step-by-step and the willingness to cooperate is opening up. As an engineer you just need one platform, and that's it. But realistically, we probably will see some level of competition, and some may have sufficient scale in order to have their own ecosystem. But the more join the party, the better it will be for all of us for the sake of innovation.
There are open platforms already.
There is Autosar [standardized software framework] but that is pretty limited to certain elements. Android Auto is not a platform that covers the whole ecosystem; it’s what we call the domain extension, basically that supports a certain amount, while Autosar is more in the middle layer. And nevertheless, yes, there are some areas where we do collaborate already. But to have the ability to deploy applications similarly to what we see in the Android world or iOS wireless world, if you really want to get there one day, we need to have one standardized platform.
Are you meeting regularly with stakeholders to develop a platform?
We still need to bring everybody to one table with the right mindset. Let's forget about legacy, let's forget about kingdom building. We don’t need those on the table. We need those who really understand the implications of what we're after, then find common ground where we can then collaborate and work in a quick way -- that is, failing and learning fast to establish such a platform.
VW Group CEO Herbert Diess has said that up to 80 percent of differentiation between brands in the future will be software. If you have a common platform, how do you get that differentiation?
The differentiating part is not part of the platform. The platform enables development and deployment of those differentiating functions. More than half of the software content in a software-defined car is not going to be differentiated. It's going to be basically what's under the hood. So putting the effort into the differentiating, I completely understand. And by the way, we at Continental also want to play that differentiation space.
