Professional Articles

The automotive industry and its suppliers are preparing cars for the Internet of Things. In the process, they are using a system architecture that supports better integration of functions and their connectivity to the outside. Using what it calls Interior Domain Integration, Continental Automotive (Figure 1) is developing this type of integrated platform for connected vehicles. The new system is based on a hypervisor that enables applications to be arranged in a new way.

Figure 1: An automotive supplier is developing an integrated platform for connected vehicles that prioritizes the overall security of the automobile system while allowing for the integration of automotive and consumer electronics and infotainment.

Learning from other Industries

In the 1990s, the aviation industry revolutionized aircraft electronics with Integrated Modular Avionics (IMA). This approach combined individual control units on a central platform for the first time in the Boeing 777 and Airbus A380 in order to save size, weight and power.

Today, automotive electronics face challenges similar to those aviation encountered. Here, too, it is important to separate the rapidly expanding number of devices that usually have small, low-power processors from their isolated hardware and to represent their functions in software. As many as 120 processors per vehicle and 100 million lines of software code are to be combined on a powerful central processing unit. And we are only now witnessing the dawn of “intelligent” cars. A constant flow of new multimedia applications, safety functions and assistance systems are emerging all the time, which can be dynamically installed from app stores in the workshop or even by users themselves. The mobile communications industry is also pushing its way into automotive electronics and tapping into new business models such as Car-to-Go and insurance premiums based on usage and driving habits.

Interior Domain Integration

Continental Automotive is developing Interior Domain Integration as a central platform for a variety of functions. The Interior Domain Integration central platform that Continental is developing relies on the PikeOS hypervisor from SYSGO. Combining GENIVI, AUTOSAR, Android and POSIX applications on a single powerful ARM multicore hardware unit, this central platform links automotive electronics with consumer electronics and infotainment. This creates more space for additional applications, increases design flexibility and opens up opportunities for additional after-sales services and long-term business models over the life cycle of the vehicle.

Employing such a platform also solves the associated security problems by separating the applications in the system architecture according to their security properties: untrustworthy Android applications run on the other side of the firewall, on a separate Core 4. Trusted but non-security-relevant GENIVI applications run behind the firewall, on Core 2 and 3. Both the trusted and security-relevant POSIX and AUTOSAR applications use Core 1, as Figure 2 shows.

Figure 2: Interior Domain Integration separates the applications on the hypervisor according to the secure/insecure as well as trusted/untrusted criteria and runs them on different cores.

System Architecture for a heterogeneous Software Landscape

PikeOS hypervisor features support the pooling of a heterogeneous software landscape consisting of existing as well as new applications according to their respective safety and security relevance. First, by means of partitioning, containers are set up for the instances of different guest operating systems with their respective applications (Figure 3). Interior Domain Integration requires that the containers be separated from one another so that they cannot interfere with each other.

Figure 3: Shown is an example of PikeOS system architecture for automotive electronics with partitions for heterogeneous software applications on a centralized platform.

Ensuring Functional Safety in Vehicles

The adoption of ISO 26262 in 2011 was essentially an automobile-specific version of IEC 61508 to standardize the functional safety of automotive electronics. Safety risks are classified separately for each application according to the ISO 26262 standard. A distinction is made here between QM (no risk) and ASIL A through D (low to high risk). The software of each application is then certified separately according to the risk determined by independent agencies.

Because all Interior Domain Integration applications are placed in separate containers on one platform, it’s the job of the separation kernel in PikeOS to ensure that this separation actually works. The kernel’s task is to create an environment that, from the perspective of the individual application, does not differ from a physically separated system. Time and space partitioning ensures that each application is autonomous and does not “see” the other applications. It uses only the hardware resources explicitly assigned to it by the separation kernel. These include memory areas, resources and application sets at precisely specified times. The inter-partition communication controls the flow of information with other applications by way of fixed channels and limits communication to known and accepted instances.

The integrated platform from Continental can host multiple applications, which are classified according to functional safety levels: non-critical (unsafe) to highly critical (safe). The PikeOS separation kernel separates these from each other so that they do not see and interfere with one another. All applications are certified according to their individual criticality. PikeOS itself must comply with these safety criteria as well. The heterogeneous overall system therefore meets the functional safety requirements defined in ISO 26262. If, for example, a non-critical multimedia system running on Android causes an error and crashes, this will not interfere with a high-priority, critical assistance system. Instead, the critical assistance system continues running normally.

Overcoming Vulnerabilities via Security Rules

The more entertainment and infotainment electronics find their way into the vehicle, the more vulnerable the integrated platform is to malicious attacks and deliberate manipulation. For this reason, it is important to define IT security rules for applications in cars, and the underlying system software must support these rules.

For this purpose, the Multiple Independent Levels of Security (MILS) concept, which originated in military applications, has been around for a long time. MILS organizes systems into three horizontal levels with different rights and levels of trustworthiness.

The lowest level is formed by the hardware with other platform and security modules. Level 2 contains the separation kernel, which controls all communication in the system and allocates computation time and memory access to the various applications. Only the separation kernel has hardware access privileges (kernel mode) and is considered trustworthy in terms of security (trusted). All other modules of the system software on the second level are also considered trusted, but do not have hardware access privileges. This methodology helps configure, organize and monitor the functionality of the entire system. All applications are assigned to the third level, are considered not trustworthy (untrusted) and run in user mode.

The PikeOS hypervisor supports a system architecture for Interior Domain Integration, allowing a combination of heterogeneous software applications in separate containers on a single platform. The separation kernel in PikeOS enables a strict separation of applications. It provides safety and security features that ensure the overall security of the automobile system and allows for the integration of automotive and consumer electronics and infotainment.

More information at www.sysgo.com/pikeos