DesignWare Technical Bulletin

Ethernet with TSN in ADAS Applications

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.

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. 

Reaching Automotive Safety Integrity Levels

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:

• Definition: Requirements must be defined, quality objectives determined and a deployment plan set in place
• Implementation: Quality teams are formed to control the implementation process and collect test data
• Analysis: Discrepancies must be analyzed and effective counter measures must be proposed
• Standardization: Process is summarized and standardized while continuous improvements are made

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.

Ethernet IP Certification Process

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.

Creating 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:

1. When making assumptions about the proper functionality of the IP, safety goal violations, outlined in Table 1, must be identified to determine the proper function of the IP. Safety goal violations can be created in a single point fault with one error or multi-point fault with multiple errors or no fault (called “safe”).

        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.

        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.

Validation of the FMEDA Report

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. 

DesignWare Ethernet QoS Controller IP

Certified Ethernet IP is integrated into automotive SoCs for reliable networking, enabling data streaming in a safe environment. Synopsys’ DesignWare Ethernet QoS Controller IP has gone through the same vigorous safety and reliability process that an automotive SoC must go through. Synopsys 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 Synopsys' 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 Synopsys 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 DesignWare Ethernet QoS Controller IP enables you to accelerate your design schedules and qualification of your SoCs.