More Than Random: Achieving Systematic ASIL D ISO 26262 Compliance For Automotive SoCs

Automakers are upgrading vehicle autonomy levels from Level2 Advanced Driving Assistance Systems (ADAS) to Level 2+ and Level 3 and evolving to full Highly Automated Driving (HAD) Level 4 and Level 5 with new safety critical applications. The new applications such as automatic emergency braking, lane keep aid, traffic sign recognition, surround view, drowsiness monitoring, and others improve safety for the vehicle and occupants. To ensure vehicle hardware and software for the new applications meet safety standards, the entire hardware/software supply chain, including the complex semiconductor system-on-chip (SoC) used in the evolving Electrical and Electronic (E/E) systems, must meet the ISO 26262 standard for vehicle functional safety. It is essential that the latest SoC processors implementing the ADAS functions use automotive grade IP that meets specific ISO 26262 Automotive Safety Integrity Levels (ASIL) and meets the ISO 26262 functional safety (FuSa) development flows for the safety critical SoCs.

Standard V-Model Development Process for Safety Critical Automotive Products

Figure 1: Automotive Product Development Model

Figure 1 shows the standard V-model development process widely utilized to develop products in the automotive industry. The standard V-model development process shown in purple should be used for all automotive product development. According to ISO 26262, for products that are safety critical, additional development steps shown in green are required to supplement the standard definition, implementation, and verification/validation activities.

Creating a Safety Culture for Safety Critical Product Development
The safety critical development activities need the development team to implement a safety culture applied to each step of the development process. Defining and applying a safety culture for safety critical product development includes the assignment of an independent FuSa organizational manager with independent authority over the product development team. The safety oversight and development activities include the documented definition and adherence to a Safety Plan and the definition/documentation of Safety Requirements. The safety plan and safety specification include the functional HW/software Safety Mechanisms such as ECC, parity checking, dual-core lockstep, and other functionality, which are implemented by the design team following the requirements in the Safety Concept specification. Designing the hardware/software safety mechanisms into automotive IP products for safety critical SoCs requires the IP products to be assessed and validated to meet ASIL ISO 26262 safety requirements, including the ASIL levels.

It is industry best practice for semiconductor SoCs, and the IP products which make up those SoCs, to implement safety mechanisms into the design of the products. Hardware/software metrics determine the impact of the safety mechanisms on identifying and correcting possible faults in the IP. The metrics are analyzed during the verification and validation phase of the SoC development process and require assessment, simulation, and fault injection to determine whether the product meets the target ASIL levels set in the Safety Requirements specification.

Functional Safety Assessment of ASIL Random Faults
A random fault analysis is required to meet full compliance with the ISO 26262:2018 standard. The ASIL random fault analysis is an assessment that focuses on Part 5, clause 8 (product development at the hardware level) of the ISO 26262:2018 safety standard. During this assessment, only hardware safety analysis for the safety critical IP product is addressed, and the deliverables/work products from the design and assessment include Failure Modes, Effects, and Diagnostic Analysis (FMEDA) and the safety manual. As part of the random fault analysis, ISO 26262 defines key results for Single Point Fault Metric (SPFM) and the Latent Fault Metric (LFM) rates to meet specific ASIL levels.

Reaching these metrics as a goal involves the Design Failure Mode Effect Analysis (DFMEA) of the design. The DFMEA is a qualitative analysis that captures the failure modes in the design and their effects on the element at the level of IP.

Best Practice: Functional Safety Assessment of ASIL D Systematic Faults
In addition to the hardware/software safety development, including the functional safety assessment of the random faults for those hardware/software safety mechanisms, automotive industry best practices also call for a safety assessment for the systematic development process for all safety critical products. The systematic development process addresses all development phases for the product, such as the planning phase, development phase, verification/validation phase, assessment and product release, and ongoing maintenance and product monitoring. The holistic development of safety critical products for all these development phases requires the FuSa safety management team and product development team to perform multiple steps and reviews, including ongoing monitoring, to ensure the ISO 26262 systematic development process (Figure 2) is followed.

Figure 2: ISO 26262 ASIL D systematic development process.

Although the ISO 26262 FuSa systematic development process showcased in Figure 2 is defined in the ISO 26262 standard and is required for full product compliance, a development team may decide to comply with the ASIL random hardware/software fault assessment only or comply with both the ASIL random hardware/software fault and ASIL D systematic fault assessment. It is industry best practice to target the ASIL D systematic safety level for the ASIL systematic fault assessment.

Quality Management System for Random & Systematic Fault Assessments
For products compliant with both ASIL random hardware/software fault and ASIL D systematic fault assessment, the development team needs to ensure all aspects of the development go through stringent procedures with multiple checks and balances. The procedures include numerous iterations of the review and approval process followed by an internal audit and optional third=party independent inspection/audit. It’s not only required to perform and document the reviews and approvals. It is necessary to record and prove the reviews and approvals have occurred. To ensure all steps have been performed, documented, and reviewed, an automotive industry state-of-the-art Quality Management System (QMS) is necessary to track and show the development has been performed. The QMS system includes complete requirements tracking from requirements setting to execution and confirmation.

During the ASIL D systematic development process, the first step is the Planning Phase which includes every work product for the product being defined and tracked. The development phase will require the completion of most of the work products/deliverables. But multiple work products are generated during the verification/validation phase and the assessment and product release phases. In each development phase, confirmation review reports, functional safety audit reports, and functional safety assessment reports are created and independently tracked in the QMS system. The ASIL D systematic development process shown in Figure 2 generally results in over 80 safety work products/deliverables.

Synopsys Automotive IP: Compliant to ISO 26262 ASIL Random and ASIL D Systematic for Safety Critical Automotive Applications
Synopsys automotive-grade IP is implemented using a FuSa-compliant ASIL D systematic development flow for ISO 26262 targeting both ASIL B and ASIL D random hardware fault safety levels, helping designers accelerate their ISO 26262 SoC-level functional safety assessments and reach target ASILs.

In addition to defining and adhering to a FuSa-compliant ASIL D systematic development process, it is valuable to independently confirm the ASIL D systematic development flow. To ensure that the Synopsys-defined ISO 26262 FuSa development process is compliant with the ISO 26262 standard, we utilize SGS TUV Saar to assess the development flow. As the certificate in Figure 3 shows, the generic development process instituted by Synopsys is shown to be compliant with the industry standard.

Figure 3: SGS TUV Saar Certificate for Synopsys Generic Process according to ISO 26262:2018

Highlighting the importance to the automotive IP industry, Synopsys recently upgraded the PCI Express Controller IP, the MIPI CSI-2 Host and Device Controller IP, and Synopsys 10Gb Ethernet Controller IP, supporting full ASIL random and ASIL D systematic compliance. Synopsys is the first IP supplier to offer full ISO 26262 compliance for these mission critical interface protocols which are widely used in ADAS domain modules, zonal ECUs, and central compute processing for L3, L4, and L5 autonomy vehicles. The Synopsys interface IP products supporting full ASIL random and ASIL D systematic compliance join the existing Synopsys ARC® processors in full ASIL compliance to the ISO 26262 standard. Synopsys’ automotive-grade interface IP and processor IP offer the highest levels of safety to accelerate safety critical SoCs designs for the new automotive platform architectures.

Summary
Designers are leveraging automotive-grade IP when designing safety critical SoCs for evolving E/E vehicle systems. New automotive applications have increased the need for semiconductor SoC functionality, bandwidth, and power requirements. Synopsys ARC processors and mission critical interface IP such as PCI Express, MIPI, and Ethernet with TSN features are compliant with the ASIL random and ASIL D systematic ISO 26262 functional safety standard, providing the functionality and performance for safety-critical applications.

Synopsys’ ASIL D systematic compliant IP portfolio is developed and assessed specifically for random hardware faults and ASIL D systematic, accelerating SoC-level functional safety certification. For more information, click here.

This article was first published as part of Synopsys IP Technical Bulletin: https://www.synopsys.com/designware-ip/technical-bulletin/asild-systematic-iso26262-compliance.html