This is the third part of a series on mastering the design and verification of next generation automotive systems and concentrates on achieving functional safety.
Using the same demonstrator, this article will consider the functional safety within the terms of those areas covered the ISO 26262 standard, as shown in Figure 1.
At the heart of the process described is a workflow that should reduces systematic and random faults to a standard-compliant level. It has three main stages.
- Safety analysis – calculating safety vulnerabilities and identifying ways to resolve them.
- Design for safety – inserting safety mechanisms and performing initial verification.
- Safety verification – generating, selecting, inserting, simulating, analyzing and verifying the removal of faults across a design so that standard compliance can be documented and certified.
Figure 2 shows how various design and verification activities around functional safety for an automotive design will typically be located within a traditional high-level synthesis flow (HLS).
The underlying assumptions used for the Tiny YOLO demonstrator in an automotive context are shown in Figure 3. The main objective is to demonstrate that by using this workflow this CNN, as earlier refined, can be further enhanced for compliance with ASIL-B, the second lowest safety integrity level defined within ISO 26262.
The Failure Mode Effects and Diagnostic Analysis (FMEDA) required within ISO 26262 involves the generation of estimated (analytical) and proven (verified) metrics.
A key step during analysis is to compute the failures-in-time (FIT) metric. FIA is based on a standard formula (Figure 4). Here specifically, it is carried out on each sub-block and filter within the nine-stage Tiny YOLO architecture. The results are rolled up to give a FIT number for the entire design, addressing permanent and transient issues.
These metrics help to provide a better safety-led understanding of the results in RTL after HLS synthesis. To that end, while a total Tiny YOLO FIT rating has been produced, more granular component data within that can help to identify which design instances should first be addressed by the addition of new safety mechanism (Figure 5).
The next step is then to evaluate the diagnostic coverage achievable for those mechanisms so that it also informs any safety-led additions made to the design. In Figure 6, for example, the application of safety mechanisms to memory is considered.
Design for safety
Given the range of safety mechanisms available, the guidance provided during the earlier FIT-based analysis is important. Pulling together a design’s basic requirements for power, performance and area, its use model and its target safety level is complex, even for a comparatively lower level target such as ASIL-B.
As seen above, memory protection has been recommended as a valuable step, so error correcting code is now applied to the Tiny YOLO design to protect it against transient issues (Figure 7).
Other parts of the earlier analysis suggested that a mix of register parity and duplication mechanisms would also help the design hit its funcational safety target. That kind insertion can be performed automatically at the sub-block level.
The Tiny YOLO example has been analyzed and safety mechanisms have been inserted. The next step is to carry out a fault campaign that verifies the results in the context of the original analysis and subsequent design optimizations.
Part One of this series cited how Toyota CEO Akio Toyoda said that some 14.2km of effective test would be needed to verify a fully autonomous vehicle for functional safety and other performance metrics at the system level. But even at the silicon (or, here, CNN) levels, tens of thousands of faults need to be executed on a design to verify that it contains appropriate systematic and random functional safety protections.
The overall fault campaign flow that used for the Tiny YOLO demonstrator is shown in Figure 8. It begins with optimization steps, both at the stimulus level and at the fault list level.
Strategies for stimulus optimization (Figure 9) and fault list optimization (Figure 10) are shown separately below.
Techniques such as concurrent fault simulation and intelligent injection can deliver still further efficiencies at this stage when run through a campaign manager that parallelizes and distributes tasks as appropriate (Figure 11).
The result of this workflow should be full and efficient fault classification and verification ready for addition to the FMEDA for the design. The team can thus report compliance with the functional safety ASIL-B requirements of ISO 26262.
This functional safety workflow leverages extensive automation and uses a range of tools from Mentor, a Siemens business. The article and the demonstrator within it are based on a tutorial by three of the company’s technical staff, David Aerne, Jacob Wiltgen and Richard Pugh (it will be presented in full at the forthcoming DVCon Europe and can also be found in proceedings from DV Con United States, earlier this year)
A breakdown of the tools used – as well as those that can be used at the lifecycle management level for functional safety projects – is shown in Figure 12.
The fourth and final part of this series moves on from the comparatively discreet implementation described here to consider the system-of-systems challenges facing next generation transportation, with specific reference to how emulation can be used at that level.