Open Car.OS and the software-defined vehicle

The days of the hardware-defined vehicle are numbered, as automakers turn to software to deliver more complex features and functions. And underpinning this transition is the automotive equivalent of the operating system (OS) that powers the smartphones in our pockets.

For so long, vehicle desirability and differentiation have been judged by function- and feature-specific hardware, from engine power and torque to in-vehicle infotainment and driver comfort features.

But as model cycles give way to software releases, welcome to the era of the software-defined vehicle, and the car operating system (Car.OS).

By switching their focus from hardware to software, automakers, suppliers, and app developers can not only maintain, but also improve their offerings over a vehicle’s lifetime.

Despite the transition to software, hardware will still be required to deliver that functionality; currently hardware systems are supported by electronic control units (ECU), typically one per vehicle function, and they're usually outsourced, creating further complexity.

What's required is an end-to-end software architecture, and hardware that enables customisation, upgrades, and new features. A software-defined vehicle is nothing if it can't be updated, and updates are pointless if they can't be delivered over-the-air (OTA) and over the lifetime of the vehicle.

For automakers and suppliers, this creates opportunities and challenges which can be supported and overcome with a Car.OS.

In an industry so closed and secretive, the software that effectively drives the vehicles is considered competitive and proprietary. Yet much of the underlying code is common, creating the perfect opportunity for “co-opetition” on an open OS which enables multiple stakeholders to co-operate on development and compete on delivery.

The software-defined vehicle

In traditional, hardware-defined vehicle manufacturing, software is developed to control function-specific hardware. In the software-defined vehicle, the reverse is true, with automotive innovation driven out of software functionality.

Software applications that add value, like ADAS or infotainment, require computational power and hardware, which in turn need to be orchestrated by an integration platform. And between the hardware and the integration platform sits the middleware, also known as the Car.OS.

We’re all familiar with the concept of an operating system—even without understanding how it works, we know it enables our smartphone’s features, apps, and functions to operate seamlessly, regardless of handset brand, model, or carrier. The OS is frequently updated with minimal inconvenience to the user, improving the phone’s performance and often introducing all-new features and functions. As the automotive industry makes the leap to the software-defined vehicle, there’s a growing need to support this transition with a Car.OS.

What is a Car.OS?

Perhaps surprisingly, there's no common definition of Car.OS, although there are several interpretations, from platform software for the different vehicle domains, to solutions that cover everything, including infotainment and connectivity, body, chassis, and ADAS.

 

A modern vehicle is a highly complex system and must be considered as a whole. The underlying car software therefore needs to orchestrate all vehicle functions and ensure the highest level of safety and security.

 

Currently, each domain has its own technical development and its own software solution; the ideal Car.OS would therefore provide a bridge across the different vehicle domains. Automotive complexity is such that while this is feasible, it’s likely to be a superset of compatible software modules.

Current offerings range from off-the-shelf software such as AUTOSAR Classic and AUTOSAR Adaptive, to operating systems like QNX, platforms like Linux, and TTTech Auto’s own automated driving platform, MotionWise.

Car.OS and next-generation ECU strategy

Car.OS can also address the challenges caused by the multitude of function-specific ECUs. A high-end car today could have upwards of a hundred different ECUs, each developed and tested independently. Not surprisingly, the automotive industry has for several years sought to cut the number of ECUs to at most four or five core domains.

The key vehicle domains are ADAS, chassis control, powertrain, body, infotainment, and the connected gateway that enables security and over the air (OTA) updates. And as the automotive industry transitions from the internal combustion engine (ICE) to electrification, e-propulsion and chassis will converge. Different domains require different software capabilities, and an operating system that can support these five or six vehicle domains.

Unlike domain-specific ECUs, zonal ECUs control functions in their proximity within the vehicle layout, such as the front end, or the engine bay.

And it’s in the ECU architecture where Car.OS could play an important role. A Car.OS would be a generic, single solution platform supporting domain or zonal architecture, with development done just once, instead of once for each ECU. Thus, it speeds up the integration process and makes the interaction between the ECUs more robust.

A place for the super ECU?

In recent years, automakers have even considered using just one super ECU. There are clear benefits to reducing the number of ECUs.

However, more than one central ECU is required for systems reliability, safety, and security. Ideally, three or four high-performance ECUs will perform computation while mechatronic systems or smart I/O’s provide digital interfaces. It is obvious that high-performance ECUs require much higher computational performance as well as communication bandwidth.

Ultimately, these high-performance ECUs have a much higher need for a software platform that helps to orchestrate all execution and communication.

Car.OS requirements

In addition, it is important to reflect on the fact that a car’s functionality is very diverse in terms of safety, security, and performance requirements: infotainment, connected gateways, ADAS, and automated driving and chassis control systems have widely differing requirements. While infotainment users expect fast updates and user experience improvements, the same user expects ultimate safety from braking, steering, and ADAS/AD systems. This cannot be packed in a single Car.OS but rather in a version that handles the highest safety requirements and addresses the flexible needs for infotainment. However, it is critical that both software versions are fully compatible mechanisms to interact with each other and ease integration. This includes communication, diagnostics, sharing a common time base, and a vehicle state.

A difficult start

Unlike some of the new OEMs, which have already established their own in-vehicle operating systems, the legacy automakers have yet to develop a generic vehicle OS. And for various reasons, the German OEMs have been unable to agree on a Car.OS approach and are pursuing their own solutions. Some, notably premium manufacturers, are trying to develop their own Car.OS by combining partially developed in-house building blocks with third-party software.

Onboard or offboard?

Clearly, the need for high power computing lies at the heart of a successful Car.OS strategy, but what’s the best approach: embedded, or in the cloud?

 

Car.OS must be safe & secure, hard real-time performant, upgradeable and cloud enabled

 

Some of the leading players see Car.OS as a mix of embedded and cloud-based, but consider this: driving across the Austrian-German border, for example, you lose cell phone connectivity. There’s no handover between Austrian and German carriers without calls being disrupted. Similarly, there’s no seamless interaction between cloud connectivity and embedded software—and safety-relevant vehicle functions need a solid embedded software solution.

So there are several use cases for cloud-based computation, but the safety core needs to stay on board. For example, level 4 driving with remote support is possible, but remote support can only improve functionality and not touch core safety features.

How vehicle functions benefit from Car.OS

Explore the concept of Car.OS and it’s difficult to find areas of the vehicle that would not benefit. Of particular interest to Car.OS developers are domains such as ADAS, infotainment, propulsion, electrification, and longer term, Level 4 and 5 automation.

A Car.OS, combined with component-based software architecture concepts, provides the basis for an efficient OTA update concept. Decoupling the software from the hardware release cycle brings many opportunities for OEMs to market new functionalities without the need to get the cars to a garage to update ECUs. Thus they can offer unique services that might not have been ready when the vehicle was built and sold.

How automakers benefit from Car.OS

The benefits of a Car.OS are manyfold, and include accelerated software development and shorter project times, software independence, OTA updates, upgrades and configurations, and the addition of vehicle functions and infotainment services. The most important benefits are faster and more robust integration cycles.

Just as the Android smartphone operating system provides an interface to thousands of apps, regardless of hardware, a Car.OS could transform the automotive experience.

Open Car.OS

As we’ve seen, OEMs are developing their own OS. So where does the open Car.OS fit in?

That’s down to automakers being forward-thinking and open-minded. Put simply, a vehicle OS is a non-competitive area, and an open Car.OS would be just that: open for any OEM to collaborate, adding their requirements to an open platform, with all stakeholders profiting from the end result, and delivering their own branded product. Air conditioning, in-vehicle lighting, or window and door openers—these non-competitive functions can be easily standardised and supported with a software platform. The end-user will simply expect it to be robust, reliable, and secure—and to work.

In a Car.OS, everyone who collaborates would enjoy increased efficiency and accelerated development, and avoid costly, time-consuming duplication. And if it’s managed by a neutral software company, OEMs will also be able to avoid the complexities of vendor lock-in.

There are precedents in automotive for open-source platforms, such as in infotainment where much of the software stack is common, enabling collaborative development and competitive delivery. It sounds simple: cooperate on the specification and compete on the implementation—but it would require major changes in the mindset of the OEMs as well as the Tier 1s.

Is it achievable? Yes.

Will it be easy? Not necessarily. Today the different OEMs cannot even agree on a common approach to a future vehicle operating system.

For now, the automotive industry has accepted that software has a value and a price. Perhaps in time, industry stakeholders will agree on an open standard, to which many parties contribute – and from which all parties benefit.

 

 

Stay informed about the most recent technological findings in the automotive industry – visit us at www.tttech-auto.com and follow us on LinkedIn for more on this exciting topic.