As the self-driving car matures, safety will take center stage. Consumers will choose models that achieve high safety ratings, and manufacturers will need to use software that is safe and reliable. This demand leads to regulatory and competitive pressures to certify automotive systems to the ISO 26262 functional safety standard. Due to the increasing complexity of the overall software system, the OEM must rely on a large software supply chain to deliver the required functionality. As this complexity rises, certified commercial off-the-shelf (COTS) software provides a cost effective way to integrate pre-certified subsystems into the final product.
SAE International defines six levels of automation, with Level 0 being “no automation.” At Level 1, a system might provide safety features like automatic emergency braking to help the driver regain control faster than what would otherwise be possible. At Level 2, several primary control functions may work together to alleviate the driver of some aspects of driving (for example, adaptive cruise control could work in tandem with lane centering to provide traffic jam assistance). However, the driver is still responsible for the vehicle’s ongoing operation. At Level 3, during certain traffic or environmental conditions, the driver may be able to cede all safety-critical functions to the car’s software. The driver must remain available for occasional control but with a sufficiently comfortable transition time. Finally, at Levels 4 and 5, the vehicle performs all safety-critical driving functions for an entire trip—with or without a driver.
BOM Pressures
The challenge is to implement these highly advanced, computer- and network-intensive systems without increasing Bill of Materials (BOM) costs. As part of this effort, a multitude of Advanced Driver Assistance System (ADAS) functions, previously implemented on discrete modules, are being integrated onto a single platform. With the shift towards platform designs for infotainment systems, automakers want a common ADAS platform upon which they can deploy various ADAS capabilities that can enable differentiation across vehicle classes. For example, the same software platform that supports autonomous emergency braking and lane-keeping assistance in high-end models should also be able to support lane departure warnings and traffic sign recognition in lower end models with modest power requirements and lower BOM costs.
To meet the above requirements, a software platform needs to have these major characteristics in real-time: security, reliability, an ability to effectively isolate software, and safety certification.
Predictable Response Times
The software has to respond to events in a timely and deterministic manner. Even the lowest level of automation cited above (i.e., automatic emergency braking) requires that information be analyzed in milliseconds. As the level of automation increases (i.e., collision detection and avoidance), the response times must remain predictable. They must also be guaranteed during worst case scenarios when the system will be the most heavily loaded.
The operating system (OS) architecture contributes significantly here. In a real-time microkernel OS, such as QNX Neutrino, the kernel is responsible for only a few key operations (mainly scheduling, interrupt management, interprocess communications, and memory management) and can be tested in isolation. Because the kernel is one small component, it doesn’t need to be rebuilt for each system and can be certified once. Simpler to test means simpler to certify.
Security and Reliability
As ADAS and automated driving systems become increasingly connected, security will be key. The OS must provide an architecture and mechanisms to prevent and contain attacks. This goes hand-in-hand with reliability, a result of correct operation and availability. The availability of a system is a function of two values: Mean Time Between Failure (MTBF) and Mean Time To Repair (MTTR). There are two ways to increase availability: increase the MTBF (make the product fail less often) and/or decrease the MTTR (when the product fails, it recovers quickly).
Using a distributed microkernel OS helps with both aspects. Because individual software components operate in isolation (i.e., they’re not part of a large, monolithic kernel), the overall system MTBF is increased so that any component that fails takes out itself and not the whole system. Further, by providing hot standby modules that can take over operations when the current module fails, system architects can reduce MTTR.
Freedom From Interference
As CPUs become more powerful, architects can realize significant cost savings by integrating multiple discrete subsystems onto a single system on chip (SoC). Today’s SoCs feature multi-core CPUs with the power to run many different applications. By aggregating subsystems, this approach reduces direct and incidental costs. A single SoC takes less power, is smaller, and uses less wiring than discrete subsystems. However, a technical challenge is getting the individual subsystems to work and play well together. If any one of the subsystems is classed as a critical or safety-related subsystem, then the manufacturer must ensure that none of the other subsystems will interfere with it.
This “freedom from interference” requirement is mandated by the safety certification. Simply put, the non safety-related systems cannot interfere with the safety-related systems under any condition. That being said, certifying all the software on an SoC is overkill. The QNX OS microkernel provides the separation needed to ensure freedom from interference for safety critical systems.
If the architecture makes use of multiple operating systems, a type 1 hypervisor offers a cost effective solution, creating “virtual machines” on top of real hardware and giving guest operating systems the illusion that they’re running on their own machine. The type 1 hypervisor allows mixed-criticality software to run on the same physical SoC and guarantees freedom from interference of the differing criticality levels so that they do not (and cannot) interfere with each other’s operation.
Certification
Finally, the overall system needs to be certified. Using COTS components that are ISO 26262 certified reduces the development and certification time and cost. Components can include the OS, hypervisor, device drivers, sensor fusion stacks, protocol stacks, middleware, and so on. Certified COTS components can be used as part of an overall certified product and are allowed by the 26262 standard. ECN