Today, luxury vehicle models can already contain up to 150 million lines of software code, which are often spread across several hundred electronic control units and a constantly growing number of cameras, radar and lidar sensors.
Connected mobility, driver assistance systems, autonomous driving, e-mobility and shared mobility - the current mobility megatrends - are changing customer expectations and are all based on software. Original Equipment Manufacturers (OEMs) and suppliers are therefore forced to increasingly deal with it.
The enabler for the "software-defined vehicle" will be a primary operating system that is flexible enough to cover all important systems in the vehicle. And ideally, the software modules will be developed on a common code basis in the future and thus form an industry standard.
The fact that the associated challenge is extremely great is now being clearly demonstrated to car manufacturers and Tier 1 suppliers, both in Europe and in the USA and Asia. Many OEMs are chasing after the goals they have set themselves to complete their own operating system.
The “we do everything ourselves” approach has long since developed deep cracks, even among its biggest advocates. The openness to cooperation between car manufacturers and the software suppliers, which are rapidly gaining in importance, is greater than ever.
Not least because the idea that the company's own structures and processes are hardly suitable for developing software-defined vehicles to series maturity in the short time necessary is gaining ground in the minds of car managers.
Because hardware-centric vehicle architectures with functions developed in isolation still prevail. At least the change to a software-centric architecture that is open and consistent has begun.
With it, the functions in the entire vehicle communicate directly with one another, so that costly and difficult-to-maintain gateways between the vehicle domains are no longer required. Here, software defines the functions that are updated over-the-air (OTA).
But the vehicle software architecture is still lagging behind the hardware architecture. Today, car manufacturers combine disjointed software components to create their own platforms.
Software-driven companies such as Aurora, Cruise and Waymo, the often troubled new-kids-on-the-block of the mobility world, show that there is another way. They have developed vertically integrated products that are very precisely tailored to a special application: the robotaxi.
These companies do not focus on independently marketable components such as software stacks or sensors. That makes them only of limited interest as a cooperation partner for classic car manufacturers. Because they need software for their upcoming vehicles that is horizontally integrated.
Meta operating systems are required. They form the intermediate layer between the hardware and that software. The path to this goal is clearly mapped out. The E/E architecture is moving from a complex system architecture with simple software to a simple system architecture with complex software. If done incorrectly, this results in challenges such as exploding software complexity, but also diverse cyber security risks.
Correct implementation, on the other hand, enables the introduction of modern software development, clean and scalable software architecture, cross-domain consistency and development tooling. Other plus points are controllable security risks, the possibility of OTA updates and a digital ecosystem.
The smartphone world can serve as an analogy. Because the market for operating systems follows the winner-takes-all principle, in which the industrial segment plays no role. Therefore, the auto industry can learn a lot from the experience of the mobile phone industry.
In 2007, smartphones brought about a separation of basic software from hardware, making the phone a software-defined device. It became a general-purpose platform on which manufacturers could build operating systems or OS systems and push OTA updates.
Ultimately, the radical reorientation of technology led to exponential growth in the smartphone market and in computing power. The winners were Apple's iOS and Android.
The secret of success behind Android's dominance today is its open architecture combined with a software development kit (SDK). It can be customized to meet the needs of different brands. This saves development costs and offers a huge application ecosystem (in the App Store) that no single system provider (except Apple) can achieve alone.
Now the question arises why a common operating system with developer SDK is relevant or even necessary for mobility platforms. It would be conceivable for each manufacturer to develop its own system.
However, the value of a digital ecosystem results primarily from its size. It is what software developers and suppliers always focus on. However, proprietary systems of individual OEMs will hardly develop the critical mass that makes them interesting for the relevant software community.
In fact, there are already standards for such ecosystems, and there are currently more than enough other initiatives that want to offer additional solutions. Their success is in doubt for a number of reasons.
The standards that have been available for years have not proven themselves in practice. Developer efficiency is not high enough, and many users have long since started deviating from the previously agreed rules. So it is hardly possible to speak of a standard anymore.
The new initiatives, on the other hand, are too late in shaping their software ecosystem to be able to give serious support to those OEMs who want to start series production with their software-defined models in two years' time.
After all, not only does the software have to be written and tested, it also has to get a security certification. At my company Apex.AI, we worked together with TÜV-NORD for a year and a half on the certification of Apex.OS. The new initiatives don't have that time, and the OEMs don't have it either.
The automobile manufacturers are therefore faced with the decision of developing their own OS system or taking over a product from a supplier. Obviously, the time and resources required speak against developing your own OS.
The actual decision, which is better to be made today than tomorrow, is therefore whether to join the Android model and thus a common and open basic software layer or continue to develop your own system on the way to the software-defined vehicle - and thus the Fate of Nokia follows.
The author is CEO of the start-up Apex.AI.
