Cloud native EDA tools & pre-optimized hardware platforms
By: John Swanson, Product Line Manager, 草榴社区
Today’s sophisticated automotive electronic systems provide convenience, safety, and comfort. With the increase of data traffic, a reliable network, like Ethernet, is needed to manage the data stream between these electronic devices securely. Automotive system-on-chip (SoC) designers must meet stringent requirements for safety and reliability as defined in the ISO 26262 standard to achieve Automotive Safety Integrity Level (ASIL) targets. Furthermore, the IP - such as Ethernet - that is integrated into the SoC must also meet the same safety and reliability requirements. This article describes the ISO 26262 certification process for DesignWare? Ethernet Quality-of-Service (QoS) IP and how the certified IP helps designers reach their automotive SoC’s ASIL targets.
Automobiles are shifting from traditional hydro-mechanical to electro-mechanical systems. Automotive electronics offer new safety and convenience options, such as collision avoidance, automatic parking, and other Advanced Driver Assistance Systems (ADAS) that require time sensitive networking (TSN). With these changes, quality and reliability requirements have become even more stringent. Figure 1 shows examples of a few ADAS applications where Ethernet might be used.
Figure 1: Examples of safety-critical ADAS applications
Ethernet was first used for onboard diagnostics and software updates; now, in today’s connected automobile, the trend is towards active information and warning systems like driver assistance control units, in-vehicle sensor systems as well as vehicle video cameras. Enabling multiple sensors to communicate and function reliably is complex and requires real-time networking, so designers are integrating Ethernet IP with TSN into their SoCs. To meet the requirements of ISO 26262 and reach their ASIL targets, designers are leveraging Ethernet IP that is declared ASIL ready.
ASIL is defined by, and a key component of, the ISO 26262 Functional Safety standard. It is used to define the safety requirements necessary to be in line with the ISO 26262 standard. ASIL certification designates completed risk analysis including severity, exposure and controllability of an operational scenario. There are four different types of ASILs defined by the standard: ASIL A (lowest integrity requirements), ASIL B, ASIL C and ASIL D (highest integrity requirements). Let’s illustrate the different levels in a simple example: a driver can stop the car when a cruise control system fails to decelerate — ASIL A applies in this situation where the requirement to meet the standard isn’t as strict. But in a self-driving car, a wrong decision by the electronic steering or incorrect deployment of the airbag can be deadly so more stringent requirements of ASIL C or D apply.
To adhere to the standard and meet their targeted ASILs, automotive SoC designers must go through a heavily documented process:
The process isn't a one-time framework, but is repeated until all requirements are met, tested, and both the SoC and Ethernet IP are ASIL certified.
With the help of accredited testing authorities active in standard bodies, like SGS-T?V Saar, automotive IP solutions are put through the rigorous process of ISO 26262 certification for ASIL qualification.
Documentation is critical and required as part of the certification process. There are two types of documentation – generic and IP-specific. Generic documents include change management plan, change request, configuration management plan, documentation guidelines, documentation management plan, evidence of field monitoring, product management process, production operation service and decommissioning requirements, and safety process rules. IP-specific documents, required by ISO 26262 Safety Enhancement Package (SEP), show the Failure Modes Effects and Diagnostics Analysis (FMEDA), hardware safety requirements specification, safety plan, safety manual, and verification plan. For the purpose of this article, we will mainly focus on the FMEDA report.
In the FMEDA report for the IP core, there are two main sections: the fault rating which is a function of the target library and I/Os associated with the block, and the more functional- or application-centric section. Designers may use the IP in a range of systems such as infotainment system, ADAS or networking, but in the case where the end application is unknown, the ISO 26262 standard defines a “Safety Element out of Context” (SEooC). This allows an IP or subsystem to be certified out of context of the end application. So some assumptions about the proper functionality of the IP need to be made and used to create the possible safety goal violations. To achieve this, the following steps must be taken:
Table 1: Examples of Ethernet safety goal violations
2. The details like terms, references, abbreviations, definitions, as well as inputs for failure rates based on the target technology are listed in a template.
3. Since the Ethernet IP block is too large to analyze, it is broken down into several block subsets – Media Access Control (MAC), memory controller, Direct Memory Access (DMA), AMBA interface – for simpler testing. However, even at this level, the Ethernet IP block is too large and needs to be broken down further for a closer look inside each block. Ultimately, the Ethernet IP is broken down into 36 different blocks.
4. Each block is then mapped into a template which includes names of blocks, descriptions, locations, etc.
5. Synthesis results are then mapped into the template to calculate the failure rate for each of the 36 blocks based on the International Electrotechnical Commission (IEC) TR 62380 standard.
6. Each of the 36 blocks has associated group of signals for clocking, programming, etc., which are broken down into different categories like clock and rest, programming controls, packet data controls, packet data and packet status. The signals are analyzed using a percentage approach based on the number of signals. The percentage approach is used because the area/gate count is relatively small and the Ethernet design is a datapath-centric design, meaning the data flows through the design in a predictable manor and thus the number of I/O signals is more of a contributing factor than the slight area differences. The percentage approach is approved by the SGS-T?V, which is critical in the certification process.
7. Each sub-block is tested using the safety goal violations as a guide to determine if a violation can occur. This manual step enables us to look through the circuits, run analysis and simulation, analyze the blocks that failed, etc. The possible failures are then documented.
8. The safety goal violations are then mapped across the faults in the template. Across each block, one of three error conditions must be applied – single point fault, multi-point fault, safe – and in any case where there is error, an associated diagnostic test is created. For example, the designer may create a diagnostic test to understand the number of cycles required to assess a failure. Table 2 shows this section of the template for fault analysis.
Table 2: Example of fault analysis for each block as part of the overall FMEDA report
9. The diagnostics are developed to correct a safety goal violation. When an error is detected, a reset needs to occur. The time it takes, out of context, is for example 1 ms. It is a function of the end application if this delay, plus any other associated system delay can meet the application’s requirements.
The above manual process is repeated until the safety goal violations meet the requirements of the target application. Now, the entire process needs to be validated.
The FMEDA report is validated by tools that can automatically insert artificial faults, run verification and help to track and detect faults. Such tools can remove faults that do not change the design due to dead logic or redundant code. They also help prioritize fault injection so the top-tier faults that create the biggest problems are exposed quickly. When a fault isn’t detected, the tool drops the related faults that may point to some weakness which will have to be addressed.
Certified Ethernet IP is integrated into automotive SoCs for reliable networking, enabling data streaming in a safe environment. 草榴社区’ Ethernet QoS Controller IP has gone through the same vigorous safety and reliability process that an automotive SoC must go through. 草榴社区 adheres to the requirements dictated by ISO 26262 to certify the Ethernet IP by breaking down the IP into manageable blocks, creating safety goal violations, executing diagnostics for testing the violations, and validating the entire process in an integrated verification infrastructure. The entire process is documented and made available in the automotive SoC certification documentation.
In a recent announcement, Wolfgang Ruf, head of Functional Safety for Semiconductor at SGS-T?V Saar, an accredited testing authority active in standard bodies, stated “SGS-T?V Saar's certificate for 草榴社区' Ethernet QoS Controller IP is based on extensive testing of validation processes related to the functional safety of electronic vehicle components in accordance with the ISO standard 26262, chapter 5.9.” Mr. Ruf also stated, “Product certifications according to ISO 26262 gives companies like 草榴社区 the assurance that their prototypes and hardware and software solutions meet the stringent safety-critical requirements of the automotive industry.”
Find out how the ASIL B ready 草榴社区 Ethernet QoS Controller IP enables you to accelerate your design schedules and qualification of your SoCs.