Most worldwide OEMs replace the existing solutions consisting of multiple separated ECUs by putting into production or designing vehicle architectures, where most software functions will be concentrated on fewer, very powerful, “domain controllers”. The Cockpit Controller is one such domain controller.
OpenSynergy offers the precise technology to enable this combination of different functions on a single System-on-Chip (SoC). Customers can integrate and run multi-purpose operating systems, such as Linux and Android along with real-time OS or AUTOSAR-compliant software, on OpenSynergy’s COQOS Hypervisor SDK.
The Cockpit Controller is an integrated automotive ECU that centralizes the visual interaction between the driver and the car. It drives several displays, typically the Instrument Cluster Display positioned in front of the driver and the Infotainment Display in the center stack, and sometimes also additional displays such as a Head-Up Display, projecting critical information to the driver, or displays for passengers in the front or in the back of the car. The Cockpit Controller integrates many very different functions that are implemented in software: from entertainment and infotainment applications to driver information systems providing safety critical information from various vehicle systems to the driver. Future cars might even replace rear-view mirrors with digital solutions, further increasing the number of displays in the car and innovative placements of the displays.
Silicon vendors have been providing powerful SoCs that integrate enough computing power to build a Cockpit Controller. These SoCs can run many applications, from different domains such as Infotainment and Driver Information concurrently, and contain powerful co-processors such as Graphic Processor Units (GPUs) that can drive a large number of pixels on multiple displays.
Integration leads to much more efficient communication paths. In case the Head Unit needs to send a video stream to the separate ECU driving the Instrument Cluster Display, this requires complex coding and decoding on both sides to serialize the data over Ethernet or specific busses. On an integrated Cockpit Controller, very efficient “shared memory” can be used.
HMI designers want to have flexibility in changing the layout of the Instrument Cluster display depending on the vehicle situation and the driver’s preference. In some cases, the dials showing the vehicle speed must move to the side to blend in a 3D-rendered map from the navigation system. In other cases, the dials are in full focus and only a small space is reserved for turn-by-turn navigation. This is technologically challenging on the Cockpit Controller as the same hardware pipeline is used by both functional domains.
The applications in the different domains require different application programming interfaces and development environments: Android, Linux, Alibaba, FireOS, AGL in the Infotainment Domain. Some OEMs might even want to allow the user to download their preferred “apps” from selected app stores and run them on the in-vehicle Infotainment, providing a more open experience.
When it comes to safety, the extremely complex Android framework is not suitable at all.
In the Driver Information Domain some OEMs will use Linux, others want to use specific embedded or real-time operating systems, to integrate legacy applications.
In addition, to interact with the vehicle busses and other ECUs, many OEMs want to use classic AUTOSAR. In case the Cockpit Controller needs to execute local driver assistance applications, adaptive AUTOSAR is a good choice
If a safety goal of a vehicle function is given a specific ASIL level, this does not imply that all hardware or software affecting this function needs to be developed up to the same ASIL level! It all depends on how the safety goal is realized by decomposing it into safety requirements on hardware or software components that might only need to fulfill a lower ASIL level.
An automotive example are the “tell-tales” that need to be rendered by the Instrument Cluster Domain. Tell-tales are warning signs that alert the driver of a malfunction in the car (e.g. a problem detected in the braking) or a dangerous driving situation (e.g. coming from a driver assistance system). In case the Instrument Cluster function is informed (through data coming from the vehicle network) that a tell-tale must be rendered (“tell-tale must be shown”), the relevant display must show the tell-tale within a certain period of time (“tell-tale is shown”). As a safe state, it is sufficient to make sure that the driver is made aware that his Instrument Cluster is not working correctly.
In the architecture of OpenSynergy’s reference platform, Linux renders the entire Instrument Cluster Display. An IC-Guard, located in a separate VM instructs the Linux VM to render the Instrument Cluster and verifies that this has been done correctly. In case tell-tales are not displayed, the IC Guard immediately puts the Cockpit Controller in a safe state, and initiates recovery actions, such as restarting one VM or the entire Cockpit Controller. TÜV SÜD has confirmed that this concept satisfies the safety requirements up to ISO 26262 ASIL-B.
Over-the-air software updates and device management are a must in all new vehicle systems. Software updates can fix bugs related to functionality, safety, or security or add new functionality during the lifetime of the vehicle. Device management makes it possible to unlock features or collect information on the health of the systems.
On an integrated device such as the Cockpit Controller, it is important that the architecture supports modular software updates provided by the separation mechanism of the hypervisor.
Many functions in the Infotainment Domain are “connected” by nature: they will stream media from local smart devices or from the cloud, download “points of interest”, traffic and weather data, and run automotive-specific online services such as geofencing or battery management. The Cockpit Controller acts as a gateway to manage or update other ECUs in the car or to provide connectivity to other ECUs or smart devices.
As a result, the Cockpit Controller architecture can integrate functions with different security levels. Even if a complex software function with a broad interface to the outside world and a large attack surface is affected by a security breach, secondary firewalls make it hard for attackers to access more critical functions.
OpenSynergy has already implemented the Safe Cockpit Controller in a large number of cars with several global automotive OEMs.