Implementing safety mechanisms to detect and indicate fault occurrence.
By Nidhi Bhasin, Shivakumar Chonnad, Vladimir Litovtchenko, and Sowjanya Syamala
The prevalence and complexity of electronics and software (EE systems) in automotive applications are increasing with every new generation of car. The critical functions within the system on a chip (SoC) involve hardware and software that perform automotive-related signal communication at high data rates to and from the components off-chip. Every SoC includes general purpose IOs (GPIOs) on its periphery which facilitate the communication between on-chip logic and the off-chip components.
For automotive SoCs, GPIO IP blocks are typically developed as Safety Element out of Context (SEooC) and delivered with a set of Assumptions of Use (AoUs). Any risk due to failure of the EE components within the SoC due to systematic failures, random failures, and dependent failures between the hardware and/or software components can potentially involve the GPIO cells as well. It is thus important that the GPIO blocks are treated as a safety related logic. In this role, GPIOs need safety analysis to mitigate any faults before the result of fault occurrence causes a system-wide failure.
The integrity level of any safety related logic must include GPIO cells. Standards like ISO 26262 have provided a framework of risk classification by defining Automotive Safety Integrity Levels (ASILs). Designers meet their system ASIL requirements through analysis within work products like Failure Modes Effects and Diagnostics Analysis (FMEDA). FMEDA captures the details of various failure modes, its effects, its distribution, the associated suitable safety mechanisms, and the diagnostic coverage of safety mechanisms. FMEDA verifies Technical Safety Concept (TSC) for completeness and correctness and eventually evaluates the safety related metrics to arrive at the final, evaluated ASIL.
To mitigate the risk of random hardware faults, designers identify suitable safety mechanisms as part of the TSC. The safety mechanisms are designed to detect, indicate, and/or correct the faults. The measure of effectiveness of these safety mechanisms is defined as its Diagnostic Coverage (DC), which is an important parameter in the evaluation of the metrics that decide the ASIL for GPIO cells. Within the scope of an FMEDA of any SoC, the GPIO cells are typically considered as safety related logic elements.
During the safety concept development of the SoC, the TSC of safety-related GPIO cells is integrated into the next higher level of the SoC. Similarly, SoC FMEDA analysis also includes a section for GPIO checks. Work products of the GPIO cells, like the safety manual, provide details of the GPIO safety mechanisms. Along with the AoU, the safety manual is a reference to the system integrator.
Typical safety related logic consists of several on-chip parts or sub-parts interacting with each other and with an external interface through GPIO cells. GPIOs can be configured to function in a Receive (Rx) mode, Transmit (Tx) mode, or bi-directional mode based on the context of usage. The figure below illustrates the Tx and Rx buffers along with their enable controls.
Fig. 1: GPIO IP with internal safety mechanisms of ESD protection.
Though faults are inevitable in any safety related logic, safety measures such as safety mechanisms can be implemented for detection, indication and optional correction of these faults. Safety mechanisms are necessary to ensure that safety requirements are met to mitigate the random hardware and systematic faults that could occur any time during the entire cycle of operation. The details of relevant safety mechanisms are captured in safety related documentation or work products like safety manuals. In case of GPIO IP, safety mechanisms can either be implemented internally or external to the GPIO cells.
When a safety mechanism that can detect and indicate fault occurrence is implemented within the IP, it is referenced as an internal safety mechanism. ISO 26262 recommends a few safety mechanisms that can be implemented internally to the GPIOs, such as resistive pull-up/pull-down, voltage clamp, and power on reset.
ISO 26262 describes several work products, i.e., tasks and documents that can be produced as part of the safety activities. A couple of key work products that illustrate the safety metrics are the FMEDA and safety manual, but there are other work products involved as part of a full compliance functional safety assessment. For IO cells, the FMEDA can be performed for various types of cells within the library. The diagnostic information within the GPIO’s FMEDA can be used for creating the FMEDA at the next level of the SoC. It will, however, need an analysis to check suitability and application of safety mechanisms at the higher level since an SoC can internally implement some of the external safety mechanisms of the GPIO. The safety manual work product primarily captures key information like top-level safety requirements, context of application use, and description of the safety mechanisms and references for the DC of the GPIO. These details support a system integrator to infer the expected use model of exercising the safety mechanisms. The work product also captures the various AoUs which the SoC integrator refers to, to validate that the assumptions are reasonable without any impact to the safety goals at product level. A design failure mode and effects analysis (DFMEA) of the GPIO library suite is conducted by safety engineers to analyze systematic fault occurrence. The systematic failure causes are enunciated along with the suitable avoidance and prevention techniques. Based on the ratings of the severity, occurrence, and detection, the risk priority numbers (RPN) are evaluated for each systematic failure mode. For RPNs beyond a threshold value, suitable recommendation of actions to be taken at the part/sub-part or at system level are provided in the DFMEA analysis report for the SoC integrators. These deliverables allow SoC designers to minimize safety risks due to the GPIO cells while following the recommendations and actions.
Automotive-ready GPIO IP teams develop work products that are reviewed by qualified functional safety members with the required level of independence within the organization. The objectivity of the assessment can further be extended to qualified and independent external third-party assessors, thus insuring the highest and required level of independence as required by the ISO 26262 standard.
A GPIO library’s automotive functional safety package is typically delivered by an IP vendor with key automotive work products like FMEDA reports and safety manuals to facilitate safety integration into an SoC. The safety manuals describe the safety measures and particular safety mechanisms that detect random hardware faults and how the occurrences of those faults shall be handled at the system level. The SoC integrator can validate assumptions described in the safety manual in the context of the target SoC. The DFMEA report provides the system integrator with the required actions they need to undertake at the system level for prevention and avoidance of systematic failures. The details in such safety documentation contribute to the calculations of metrics in achieving the ASIL of the random hardware faults at the SoC level. Synopsys DesignWare GPIO IP for functional safety accelerates SoC development by providing the essential safety related documentation and work products to help designers reach their SoC’s safety and ASIL requirements.
This article is an excerpt from the Synopsys white paper: GPIOs: Critical IP for Automotive Functional Safety Applications.
Nidhi Bhasin is a staff design engineer, GPIO+, at Synopsys.
Shivakumar Chonnad is a principal engineer, Quality and Functional Safety, at Synopsys.
Vladimir Litovtchenko is director for Quality and Functional Safety at Synopsys.
Sowjanya Syamala is a staff design engineer, GPIO+, at Synopsys.
 |
 |
 |
 |
 |
 |
 |
 |
 |
Leave a Reply