Software-Based Self-Test Library for Functional Safety Assurance

By: Hossam Raafat- Mohamed Fayad- Nour Ali- Yasmine Ismail — Si-Vision

Introduction

Ensuring the reliability of modern processors requires multiple layers of testing across the product lifecycle. Pre-fabrication testing verifies the correctness of the design before silicon is manufactured, preventing costly design flaws. However, it cannot reveal manufacturing defects, since no physical chip yet exists. Post-fabrication testing addresses this gap by validating the fabricated device and screening out defects introduced during production. Still, it cannot anticipate the faults that arise under prolonged stress and field conditions. In-field testing is therefore critical, as it detects the faults that might arise due to aging, wear-out, or unexpected environmental conditions, to prevent hazardous failures.

This is where Software Test Libraries (STL) play a vital role. Unlike pre-fab and post-fab methods, STL operates directly on the deployed hardware, continuously monitoring processor health during real operation. Every testing phase has its own distinct role, and none can replace another; together, they form a layered defense, with STL acting as the last line of protection against in-field faults. As a configurable, lightweight software safety mechanism, STL offers periodic runtime diagnostics that contribute directly to system-level fault detection and functional safety goals. This makes STL an essential element in safety-critical domains such as automotive, industrial, and medical systems, ensuring compliance with the functional safety standards.

Problem Statement

Two of the most well-known automotive safety crises were the Toyota unintended acceleration incidents (2000s–2010s) and the General Motors (GM) ignition switch defect (2000s–2014). Toyota vehicles were reported to accelerate without driver input, leading to hundreds of crashes and dozens of fatalities; the company faced recalls and paid over $1 billion in settlements. GM’s ignition switch defect caused engines to shut off suddenly, disabling steering, braking assist, and airbags, resulting in at least 124 confirmed deaths, hundreds of injuries, and billions in costs. These tragedies highlight how a single fault can cascade into life-threatening situations. That’s why modern automotive development follows strict standards like ISO 26262 (Automotive Functional Safety) to minimize risks. For example, if the root cause had been an error in memory, buses, data cache, or internal CPU units that were responsible for reading a critical sensor data or calculating high accuracy value. Even though the processor operates correctly and passes digital verification in the lab, faults can still occur during real-world operation due to different environmental conditions. For example, high temperatures in a car engine bay or electromagnetic interference can cause failures that were not detected during laboratory testing. In such cases, STL can identify these faults at an early stage — potentially preventing the dangerous consequences.

How STL works

The following simple diagram shows a small defect which could lead to hundreds of injuries, and billions in costs if it is used in a safety critical application:

• The first AND gate is fault-free and going to calculate the result correctly.
• The second gate is faulty; its second input is stuck at 0.
• The second gate will produce incorrect output, potentially causing significant runtime issues.

How to detect this fault? Consider a scenario where the Arithmetic Logic Unit (ALU) operates with predefined runtime inputs. The output is then validated against an expected value. If the ALU is faulty, its output will deviate from the anticipated results. This mechanism effectively detects hardware faults within the ALU. This is the operational principle of the STL.

Safety Metrics Overview

There are two safety metrics that evaluate STL and determine that it is assessed for its ability to detect faults.

• ASIL (Automotive Safety Integrity Level) is a risk classification for functional safety in road vehicles, defined by Severity, Exposure, and Controllability of hazardous events. It determines the required safety measures to reduce risk to acceptable levels.
• SPFM (Single Point Fault Metric) is a measure in ISO 26262 that indicates how effectively a safety mechanism detects or controls single faults.

The following table shows the relation between different ASIL levels and SPFM according to ISO26262:

STL Implementation Considerations

STL provides a scalable framework for runtime infield diagnostics in safety-critical systems, but integration into embedded applications faces challenges from hardware diversity, real-time constraints, and compliance with standards such as ISO 26262.

ISO 26262 Compliance

To achieve compliance with ISO 26262, the STL must be developed and implemented under defined software constraints that ensure both functional safety and process integrity. The implementation shall avoid unsafe constructs, prohibit non-deterministic services such as dynamic memory allocation, and ensure deterministic behavior across all execution paths. From a process perspective, the STL shall adhere to established safe coding guidelines such as MISRA-C, and undergo verification activities, including unit testing, integration testing, and structural code coverage up to Modified Condition/Decision Coverage (MC/DC). In addition, full bidirectional traceability must be maintained between requirements, design, implementation, and verification, ensuring that the STL’s role as a safety mechanism is clearly justified and its SPFM is demonstrably achieved.

Performance vs. Coverage

Embedded environments impose strict memory and performance limits, while a major trade-off exists between maximizing diagnostic coverage and minimizing execution time and memory footprint, where greater signal observability improves SPFM and increases runtime overhead, memory footprint, and stack depth.

To address this, STL uses short, focused test scenarios that stimulate a broad range of behaviors within limited cycles and memory, ensuring efficient coverage without resource consumption.

Application Hardware Context Preserving

Running STL alongside live applications requires preserving the system state. Tests on registers, memory, or control settings demand precise save and restore within a critical section to avoid corruption for live application. Multicore systems add complexity with shared caches and peripherals, requiring careful cache handling to prevent data loss or performance issues. Dedicated memory regions may be allocated to keep STL non-intrusive.

Handling Compiler Interference

Compiler optimizations may alter test behavior through code elimination, instruction reordering, or control-flow modifications. STL may mitigate this using inline assembly, attributes, or pragmas to enforce deterministic execution and preserve test integrity.

Ensuring Deterministic and Safe Execution of STL

The STL must identify hardware faults within a bounded time frame. According to ISO 26262, the effectiveness of a safety mechanism is determined by its Fault Detection Time Interval (FDTI), which specifies the maximum time between the occurrence of a fault and its detection. This interval must always be shorter than or equal to the system’s Fault Tolerant Time Interval (FTTI), which defines the maximum time a fault may remain latent before potentially leading to a hazardous event. Consequently, STL must be executed periodically and within strict timing constraints to ensure that all targeted faults are detected before the expiration of the FTTI. In addition, the STL must incorporate safe termination strategies, meaning that if a diagnostic routine fails to complete within its expected time or encounters an unexpected condition, the system transitions into a controlled safe state rather than continuing operation in an undefined or hazardous manner. Such safe termination can be realized, for example, through a watchdog timer, which forces the system into a predefined recovery or shutdown state if the STL overruns or becomes unresponsive. Together, time-critical detection and safe termination guarantee that STL execution remains both deterministic and compliant with safety requirements.

STL vs HW Safety Mechanisms:

The following table provides a comparison between STL and some other hardware safety mechanisms. While both approaches contribute to system reliability, they address different aspects of fault detection.

Conclusion

Software-based Test Library (STL) is a crucial and effective functional safety mechanism for complex systems-on-chip (SoCs), particularly in the automotive industry. It’s a highly reliable method for detecting faults in HW. STL’s main advantages are its high test coverage and minimal performance impact, all while complying with important safety standards like ISO 26262. As a software-based system, STL needs to be certified to ASIL-D, the highest level of automotive safety integrity. Its effectiveness is further enhanced when used alongside other complementary safety measures, such as watchdog timers and Error-Correcting Code (ECC).

About The Author

Hossam Raafat, Mohamed Fayad, Nour Ali and Yasmine Ismail — Embedded SW Engineers at Si-Vision

(https://www.linkedin.com/company/si-vision/). Si-Vision is a leading provider of innovative IC solutions, specializing in cutting-edge technologies that drive advancements in the semiconductor industry. With a strong focus on research and development, Si-Vision has established itself as a trusted partner for companies seeking high-performance IC designs tailored to their specific needs. Our team of experts combines technical expertise with a deep understanding of market trends to deliver customized solutions that meet the evolving demands of the semiconductor market.

References

Philip Koopman, “A Case Study of Toyota Unintended Acceleration and Software Safety” (Presentation / Slides, 2014). Functional Safety of Automotive Software, in Automotive Software Architectures (Springer, 2017) by Staron & Johannessen. ISO 26262: Road vehicles — Functional safety (ISO standard for automotive electronics).