What Is ISO 26262 And Functional Safety?
Functional safety (FuSa) is the absence of unreasonable risk due to hazards caused by the malfunctioning behaviour of electronic systems. In other words, this means that in the presence of a fault, a functionally safe system will remain in a safe system state or switch over to a safe system state.
The definition of hazardous behaviour and the safe state is critical to defining the scope of functional safety: in some applications, it’s acceptable to simply stop operating, or else a degraded mode of operation can be defined.
Introducing ISO 26262
In the automotive domain, functional safety of electronic systems became increasingly important during the rapid growth in the number and complexity and authority of dedicated electronic control units in the last 30 years. Now it’s possible that your car may have 100 million lines of code and 100 distributed electronic controllers governing everything from the engine (or drive motor) to steering to electric windows and cabin climate control.
To manage the complexity and define common expectations for functional safety, automotive manufacturers and suppliers collaborated to define a standard approach which was first published in 2011 by the International Standards Organisation (ISO) as ISO 26262:2011.
The automotive architecture is changing towards zone controllers or centralised processing, and functional safety requirements are changing again as vehicles perform with greater autonomy. Even though ISO 26262 is not required in law it is very often specified by OEMs and system integrators to reach a common understanding with their suppliers on the functional safety expectations for product development.
Whereas the first edition of ISO 26262 was limited to passenger vehicles up to 3500kg, the second edition (ISO 26262:2018) included consideration of trucks, buses and motorcycles, and specific enhancements for semiconductor products, among other improvements.
ISO 26262 describes four Automotive Safety Integrity Levels (ASIL) ranging from A to D, with the latter the most stringent. Different functions within a vehicle system require different levels of safety integrity according to the risk of harm. To satisfy ASIL D, greater robustness and reliability is required of the hardware architecture (expressed via the metrics Single-Point Fault Metric (SPFM) and Latent Fault Metric (LFM)) and greater rigour is required during development, including independent technical confirmation via functional safety audit and functional safety assessment.
How do you create functionally safe IP?
Automotive projects at Imagination are managed according to a strictly defined safety element out-of-context (SEooC) lifecycle, or in accordance with any Development Interface Agreement specified by the customer in case of distributed development. Dedicated functional safety engineers track the progress and quality of all safety-related engineering work with reference to Imagination’s quality management system (QMS).
From the product perspective, the sufficiency and robustness of the IP is determined via failure mode analysis involving a set of bespoke tools, developed in-house at Imagination. Each product is examined to determine failure modes and effects and to model the effectiveness of installed safety mechanisms, e.g., error-correcting codes in memory. Typically, this analysis addresses the potential for non-safety-related failure modes and violation of the product safety requirements, so that Imagination can adapt to new safety requirements more quickly.
Imagination cannot control the actual reliability of the implemented hardware, and the target lifetime or mission profile may vary from one application to the next. For these reasons, Imagination does not specify the probabilistic metric for random hardware failures (PMHF) metric, only single-point fault metric (SPFM) and latent fault metric (LFM).
The objective of functional safety is the mitigation of unacceptable risk of physical injury or damage – either directly or indirectly – through the proper implementation of one or more safety mechanisms. These safety mechanisms and their assumed effectiveness are then thoroughly verified in register-transfer level (RTL) simulation, emulation and in a field-programmable gate array (FPGA) implementation.
In the context of a vehicle, functional safety is intrinsically end-to-end in scope, as it incorporates the safe function of multiple components or subsystems as part of the safe function of the entire vehicle. This is particularly the case when integrating commercial off-the-shelf components, such as a graphics processing unit (GPU) or neural network accelerator (NNA) into a larger system. External dependencies or assumptions by Imagination are explicitly documented in the safety user manual to facilitate early planning and rapid development by our customers.
Imagination has been supplying IP into the automotive arena for over a decade. We work in partnership with an automotive engineering and development consultancy that can perform an “I3” independent functional safety audit and assessment for ASIL D, or upon request, for ASIL B. In 2020 our dedication to the development of functionally safe products via our quality management system was recognised with a statement of conformance by our external auditor. Imagination has also delivered a safety-critical GPU driver, while our IMG BXT GPU is an ASIL B design that delivers high performance with a comprehensive safety case aligned to ISO 26262.
Related Articles
When Will Autonomous Cars Be Available?
Production-Ready Autonomous Vehicles
What Are The Six Levels Of Autonomous Driving Technology?
Related Posts
Imagination achieves ISO 26262 statement of conformance
Related News
Imagination receives ISO 26262 statement of process conformance from HORIBA MIRA
