Automotive Safety Island: Test, Safety, Security, ISO 26262

I first fell in love with electric vehicles back in 1978 as an Electrical Engineering student, studying at the University of Minnesota. What caught my fancy was a small advertisement listed in the back of Popular Mechanics magazine to build your own electric vehicle by replacing the gas engine of a Honda with an electric motor, so I bought the plans and showed them to my dad’s machinist friend. He quickly informed me that the cost to machine the parts for this one of a kind EV would cost more than a new car, so I waited decades for the auto industry to start designing affordable EVs.

Modern automobiles are oft described as “data centers on wheels”, and I believe it’s true, because the typical 2021 Ford auto can have 25-35 ECUs (Electronic Control Unit), while a luxury BMW 7 series contains 60-65 ECUs. With the growth of Advanced Driver-Assist Systems (ADAS) also comes the need to design for functional safety by following ISO 26262, plus defending against cyber security hacking is another design requirement. This is a true systems-level challenge, so no surprise that systems companies like Siemens are talking about this topic in a recent White Paper, Automotive Safety Island. Their approach to meet these challenges is a “safety island”, where a scalable system using an embedded CPU and software control is used.

The audio and entertainment system inside of a car can have an Automotive Safety Integrity Level (ASIL) that is low, like level A, while self-steering would fall under the highest integrity, so level D. IP subsystems get designed for the automotive market with one of these four ASIL levels in mind.

Safety Island

The promise of a safety island is to manage and control the safety content inside an SoC by:

• Signaling failures
• Enabling recovery
• Adapting to future needs

Preventing any harm from the failure of a safety-critical system is what functional safety is all about. Adding logic inside a chip to detect random hardware faults that are either latent or transient is part of diagnostics coverage, while meeting the desired level of ASIL. These added functional safety blocks are shown in grey for an automotive SoC:

The safety mechanisms used for an IP within an SoC depend on the type of IP, and engineers trade off coverage, test time, silicon area and the amount of disruption to normal operation:

Connecting all of these safety mechanisms together can be done readily with the Tessent MissionMode architecture, where SiB is Segment insertion Bit, and FSM stands for Finite State Machine.

With the addition of a Safety CPU, the MissionMode controller becomes a safety island:

When adding this safety island, it is separated from the rest of the design: logically, physically, power.

Memory BIST

Memory Built In Self-Test (BIST) can test any memory instance, so the question is when to run these tests. With non-destructive Memory BIST, the BIST engine only does bursts of testing, while the SoC is functionally operating. The safety CPU is the brains that decides when to do these bursts, based on system activity.

Beyond Just Test

BIST is managed through the IJTAG interface, and it tests for structural defects in the silicon. Another type of IP that can be added is called Embedded Analytics, and that has monitoring and data collection for an entire SoC for a higher level of safety checking, even aware of cyber security activity. Here’s the idea of Embedded Analytics for an automotive SoC, where the safety island is connected to the message infrastructure:

Along with the Embedded Analytics there is an Embedded SDK, a software library that runs on an embedded safety manager inside your SoC, and it configures and controls the Embedded Analytics monitors (shown above in grey boxes).

Summary

Automobiles have become incredibly complex systems, which present many challenges to design teams about test, safety and security. By designing new automotive SoCs to meet these challenges, and using the approach of on-chip monitors and analytics with a safety island, it’s possible to meet your ASIL levels in a software-driven flow.

Read the complete 9-page White Paper here from Siemens.

Related Blogs

• Safety Architecture Verification, ISO 26262
• Observation Scan Solves ISO 26262 In-System Test Issues
• Siemens EDA wants to help you engineer a smarter future faster
• Automotive SoCs Need Reset Domain Crossing Checks
• Siemens PAVE360 Stepping Up to Digital Twins