This article appeared in Electronic Design and has been published here with permission.
What you’ll learn:
- What are software test libraries?
- The key role of diagnostic coverage in characterizing safety-mechanism effectiveness.
- How to approach target values.
The magic behind today’s astonishing automotive systems rests on something that’s also a complex design challenge—functional safety. In a 2020 survey, 41% of Arm ecosystem respondents identified functional safety as the biggest challenge in achieving mass deployment of level 4 autonomous vehicles.
It would be one thing if functional safety was confined to a few bleeding-edge automotive designs, but it’s increasingly not the case. Conforming to safety standards is vital to solving the problems of deploying safety efficiently and consistently across the supply chain at varying levels of complexity and for many automotive applications.
As a rule of thumb, the higher the criticality and the less control the driver has over the application, the higher the inherent risk and associated Automotive Safety Integrity Level (ASIL). The industry-standard ISO 26262 defines four ASIL levels, from lowest integrity level to highest: ASIL A, ASIL B, ASIL C, and ASIL D.
For safety applications in which the driver typically has more control over the vehicle, such as lane monitoring and adaptive headlight systems, or the consequences of a malfunction aren’t severe, the integrity requirements tend to be lower (e.g., ASIL B). This is where a lot of automotive system design is focused today.
Much of the discussion around functional safety focuses on hardware design and architectures, but software plays an increasingly important role. Indeed, more and more automotive designs will leverage software-defined concepts as hardware performance and efficiency continues to improve.
Key to the capability of accommodating such diverse software concepts is a reliable middleware or low-level software containing software test libraries (STLs). These are sets of tests that can be run at startup or during operation of a system to check that the underlying hardware is executing correctly.
Let’s take a short tour of STLs and methodologies leveraging them to enable safety-relevant designs in automobiles.
Defining and Addressing Safety Requirements
STLs are used in testing for permanent hardware faults within the functional logic of the hardware and it can be developed as a software safety element out of context (SW SEooC) by the IC or IP suppliers. These components are developed without considering a particular target vehicle and based on assumptions of use.
When developing an STL, designers must consider systematic faults and random hardware faults (RHWF) occurring in one or more of the elements. For random hardware faults, ISO 26262 and other functional-safety standards define several hardware architectural metrics with recommended target values for each defined integrity level.
These targets for the hardware architectural metrics must be achieved to confirm, with reasonable confidence and in a quantitative manner, that a safety-related system can cope with random hardware permanent faults without causing a system malfunction that leads to a hazardous situation. We’ve read examples ranging from electric scooters suddenly braking without warning because of a software glitch, to an ADAS system neglecting to identify a bicyclist in the roadway, causing a collision.
Assessing Diagnostic Coverage
One metric used to characterize the effectiveness of safety mechanisms to detect and control faults is diagnostic coverage (DC). This metric is the percentage of failure rate of the hardware element or the failure modes that are detected and controlled by a safety mechanism. The DC of a safety mechanism directly affects the hardware architectural metrics. Four steps are involved in STL development:
- Exploration (safety-related areas of the CPU that have maximum impact on the metrics).
- Test writing to generate pseudo-random tests.
- Fault simulation to validate the quality of the tests.
- Sign-off (running the full set of tests on the entire CPU, to demonstrate that the target coverage is achieved).
At the end of the STL development, the fulfillment of the scope definition is verified, and the actual DC of the STL is measured or evaluated.
Bump in the (Design) Road
This sounds reasonably straightforward; however, there’s a wrinkle: The hardware architectural metrics’ target values are defined at the system level, and they must be achieved for the entire hardware of a system. ISO 26262 provides little guidance on how to approach target values if you’re developing just an IC or IP core that’s only part of the overall system. Designers must specify their targets for the IC or IP core.
In designing a safety mechanism for the safety portion of an IP core or an IC, designers need to consider, among other things, what hardware blocks the safety mechanism should cover and whether the mechanism should cover all or just certain failure modes. Based on the software-defined concept, these blocks and failure modes may vary, even if the same hardware is used.
If using STLs as a safety mechanism, designers can break them apart and only apply the portion of the STLs testing the blocks and failure modes that are relevant for the specific applications. Compared to other hardware-based solutions, STLs improve flexibility and efficiency of the system, ensuring a maximized scheduling capacity for the system to perform its function with higher performance overall.
Conclusion
With a global journey to enable autonomous electric vehicles, the race is on to design systems that deliver low-power, high-performance solutions. But that race can’t be won without considering functional safety and adhering to applicable standards and methodologies, such as ISO 26262. The devil, as they say, is in the details, and often there’s confusion and misunderstanding surrounding the application of such standards. This whitepaper helps clear that up and details steps designers should take in considering and implementing STLs for safety-relevant designs.