Why Mixed-Criticality Is the Future of Automotive Architectures
The term “mixed-criticality” often comes up in discussions around the software-defined vehicle (SDV) or in-vehicle software architectures. What is it and why does it matter?
Defining Mixed-Criticality
Mixed-criticality essentially means one chip is running two pieces of software that require disparate safety levels. An example would be a single chip that controls both radio volume and electric steering controls. A failure of audio controls is annoying — while a failure of steering controls is dangerous, possibly even life-threatening.
For a more precise definition, we can look at the basics of functional safety within the car.
Automakers use ISO 26262 as the standard for creating functionally safe software within vehicles. Part of the ISO 26262 standard is a risk classification system that defines software by Automotive Safety Integrity Level (ASIL) and measures several factors. These include different degrees of severity, exposure, and the controllability of software failures within a vehicle. Four ASIL levels – A through D – range from low- to high-risk classifications. A fifth level, Quality Management or “QM,” represents when standard quality processes are sufficient with no risk reduction needed.
| Level |
Description |
Example |
| QM (Quality Management) |
No safety relevance (standard quality processes are sufficient) |
Radio volume suddenly increases |
| ASIL A |
Low risk, reduction is necessary |
Brake light stops working |
| ASIL B |
Medium risk, reduction is necessary |
Headlights stop working |
| ASIL C |
Medium-high risk, reduction is necessary |
Adaptive cruise inadvertently applies brakes |
| ASIL D |
High risk, reduction is necessary |
Electric steering fails |
Table 1 – ISO 26262 ASIL levels measure different degrees of severity, exposure, and controllability in vehicle software failures.
In the table above, we list technical examples of functions and criticality levels. Examples of mixed-criticality, where software classified at one ASIL level is running alongside software classified at a different level on the same processor, might include the following:
- A digital instrument cluster that shows both turn speed (ASIL A) and album art (QM)
- An infotainment system that shows navigation (QM) and rear-view camera (ASIL B)
- An engine controller that provides both adaptive cruise control (ASIL B) and semi-autonomous modes (ASIL D)
Why Software-Defined Vehicles Need Mixed-Criticality
Four main automotive design trends are increasing the propensity to create mixed-criticality systems in the vehicle:
ECU consolidation
There is a continuing need to absorb the functionality of multiple engine control units (ECU) into either domain controllers or high-performance compute (HPC) platforms. This trend frequently combines modules with different safety levels.
Reducing certification work
By constraining more stringent ASIL levels to the smallest possible piece of code, mixed-criticality reduces the amount of work that the engineering team must do to certify – but it also introduces a situation where different parts of the software may require different ASIL levels.
Functional safety decomposition
Like redundant jet engines on a plane, functional safety decomposition is a technique that allows software components with redundant functionality to work together to reduce the occurrence of failure – and increase the overall software’s ASIL level. These components may share the same ASIL safety level (and therefore are not technically “mixed”), however, the same software solutions used to handle mixed-criticality apply equally well to this scenario, regardless of the individual ASIL levels.
Software-defined vehicles
Perhaps most important is the desire to make the vehicle flexible, changeable, and updateable. Many features and options can be delivered through software to accomplish these goals but the complexity that accompanies the SDV also introduces mixed-safety requirements. This is one of the most important factors driving the adoption of mixed-criticality. Since SDVs are designed to accomplish all upgrades and fixes via software — without altering hardware once the car leaves the factory — they must often use mixed-criticality to safely incorporate new functionality.
How Mixed-Criticality Simplifies Automotive Architecture
It might seem that mixed-criticality introduces more problems than it solves. Why not avoid complexity and just certify each module software at the most stringent ASIL level necessary to guarantee proper performance?
This is often impossible. Some software — due to either how it’s created, the hardware it relies on, or the functions it performs — cannot be certified at a higher safety level. As an example, web browser technology cannot be safety certified for several reasons (one being dynamic memory allocation), yet a browser may be needed to display an in-vehicle manual. If the same infotainment system used to display that documentation also needs access to a backup camera, then the entire system would be uncertifiable without resorting to mixed-criticality.
It can also take significantly longer, and be more expensive, to certify at a higher ASIL level. For example, while ASIL A does not require a functional safety audit, ASIL B and higher levels do. And while ASIL C can be audited by a person within the same company that designed the module, ASIL D requires use of a separate, independent company to perform the audit. The higher the ASIL level, the greater the costs for engineering processes, development time, and contractor assistance.
Mixing Criticality: Hypervisors and Foresight
Technical solutions such as functional-safety-certified hypervisors can help alleviate the impact of using mixed-criticality systems. These software solutions use the hardware capability of modern system-on-a-chip (SoC) architectures to partition the software into different, isolated spaces. A hypervisor-based design assumes that the software within each distinct space is at a single ASIL level, yet the system as a whole may contain software with multiple ASIL designations, each contained in its own protected, “virtualized” space.
Including a functionally safe hypervisor from the onset of a project helps system architects create a “clean” design. It also allows them to structure a more streamlined safety process that can reduce overall complication with ISO 26262 compliance.
Using a hypervisor to implement mixed-criticality should be considered at the beginning of software planning. Because it forms the bottom-most structural component of the software stack, it is typically difficult to “bolt-on” to an existing design. Also, by trying to add a hypervisor late in the game, engineering staff and product software can miss out on much of the benefit that would have otherwise been realized.
The Future is Mixed
Whether it’s combining advanced driver assistance systems (ADAS) with convenience, or infotainment with safety, a mixed-criticality environment allows us to unite the use of consumer-grade operating systems (OS) and applications with safety-certified OSs and features. The factors that are driving mixed-criticality are on the rise — increasing in both pace and scope.
This is why we see mixed-criticality being used throughout the vehicle, creating a new software paradigm for today, and for the future. To learn more about mixed-criticality, read the BlackBerry® QNX® whitepaper, Beyond the Edge - The Evolution and Future of the Software-Defined Vehicle, which shows how mixed-criticality fits into the software-defined vehicle and related trends driving modern vehicle software architectures.
About Randy Martin
Randy Martin is a Product Manager at BlackBerry.
