The probability of systematic and random faults in electronic systems is increasing due to growing complexity, sensitivity to soft-errors, internal coupling effects and external disturbances. If we define robustness as the ability to continue mission reliably despite the existence of faults, we can conclude that modern electronic systems are increasingly less robust.

Nowadays, deep-sub micron technologies and multi-CPU systems are used in high-volume applications where safety is a key factor. For example, in the automotive industry, electronic systems are involved in airbags, active brakes, engine control and future x-by-wire cars. The same goes for biomedics and aerospace. But it is not only a matter of safety: availability also becomes relevant for high-demanding and very high-volume applications such as modern communications systems.

In such a scenario, the need for tools, methodologies and architectures is more important than ever to manage robustness and related costs.

IEC61508 is a set of international norms for the functional safety of electrical/electronic/programmable electronic safety-related systems.
It introduces a deterministic approach to evaluate the robustness of a given Equipment Under Control or EUC. It also rules the documentation to be delivered with the safety system concerning the implementation and the validation flow of both HW and SW.

The table summarizes which Safety Integrity Level (SIL) can be claimed by a system based on its Safe Failure Fraction (SFF): the higher the HFT, the higher the availability. Annexes of IEC61508 deliver precise guidelines in terms of faults and failure modes to be considered for each system component (CPU, bus, internal/external communications, memories and so on) and include the recommended diagnostic techniques, graded according to their effectiveness with respect to the target SIL.

Notified bodies such as TÜV-SÜD assess the compliance of systems to IEC61508.

--


• Automotive systems mainly concern the white boxes.
• SIL 2 is the minimum level: an example of systems requiring SIL2 is the Anti-Braking Systems or abs.
• SIL3 is the requirement for active safety systems such x-by-wire, active brake or stability control.
• SIL4 isn’t considered achievable for single chip solutions and in general it is not considered necessary
for automotive systems.

State-of-the art solutions for high reliability systems make use of one or more of the following approaches.

At software level
It is based on sw redundancy, as for instance n-Version Programming and recovery block.
Many drawbacks - Performance degradation, sw overhead, higher detection latency, strong application dependency and higher effort to achieve iec61508 compliance for each application.

At system level
It is based on mcu redundancy. In this case a certain number of mcus, typically two or three depending if fault-tolerance is required, are used in the same system, with comparators or with mutual check.
Many drawbacks - High cost at system level for hw overhead, packaging and pcb, system dependency.

At MCU level
It is based on CPU redundancy. It can be either symmetric, with comparators or with mutual checks; or asymmetric, where a smaller CPU or watchdogs.
Many drawbacks - Symmetric solutions (such as lock-step or dual core architectures) lack the diversity required by iec61508 and the overheads (gate count, performance and power) rapidly grow beyond practicality in the attempt to apply these concepts to high-performance cores. Asymmetric solutions are mainly based on watchdogs that suffer from low diagnostic coverage and thus require a complex SW infrastructure to overcome this limitation. Therefore, they are mainly used for low SIL systems.

At gate level
It can be used logic redundancy for instance using concurrent checkers in alu, or modifying the pipeline with ecc codes.
Many drawbacks - Specific cpu redesign, performance overhead (timing), diagnostic mixed with safety function (not recommended by iec61508).

At transistor level
It can be used a particular process or layout techniques to harden the technology against errors, such for instance to design srams with dram architecture to make them less prone to soft errors.
Many drawbacks - Specific to certain types of faults, very high cost and overheads.

YOGITECH's faultRobust technology is based on a design and validation methodology. It makes use of a library of HW fRIPs (called fault supervisors) that can be passives (detecting) but also actives (correcting errors or failures). These IPs are not intrusive and they don’t require any modification of the logic circuit that they supervise. The library includes fault supervisors for CPU fRCPU, for Busses/Interconnects fRBUS, for Memory sub-systems fRMEM and for Peripherals fRPERI. It will also include a library of SW fRIPs and a tool suite to handle the HW-SW integration flow.

YOGITECH's faultRobust technology offers the advantages of asymmetric solutions (low-cost and diversity) while maintaining the highest diagnostic coverage to permit the implementation of SIL2 and SIL3 systems. When higher availability is required, faultRobust technology can be used in combination with dual or multiprocessor cores.

The IEC61508 norm for functional safety of electronic safety-related systems introduces a deterministic approach to evaluate the robustness of a given Equipment Under Control or EUC since it also rules the documentation to be delivered with the safety system concerning the implementation and the validation flow of both HW and SW. For system sub-components such ASICs or IPs, to follow this norm means a complex analysis and evaluation procedure.

The starting point of faultRobust technology is the definition of the Safety Requirements Specification (SRS) with the safety or robustness targets to be fulfilled by the EUC.
The Failure Mode and Effects Analysis (FMEA) is the foundation of the validation procedure. Particular attention is paid to failure modes specified in IEC61508-2. Diagnostic Coverage (DC) and Safe Failure Fractions (SFF) are computed: in this way it is possible to precisely position the component or sub-system under analysis in the SIL table of IEC61508-2.

As required by the IEC, faultRobust technology uses fault injection at all the different stages of the validation procedure: to validate the FMEA, to assess the safe failure fraction of the EUC including diagnostic, and at the end of the implementation stage. With an automatic flow, the FMEA results are used for fault list generation and at the end of fault injection campaign the results assess and improve the quality of the FMEA.

Single-CPU
The simplest architecture with faultRobust technology is a single-CPU asymmetric solution, where a standard CPU-based microcontroller is complemented by a set of supervisors such as the fRCPU, some instances of the fRMEM e.g. for system sram and tightly-coupled memories, a set of fRBUS for internal interconnects and a set of fRPERI to cover the peripherals.
The choice of which peripheral should be covered is driven by the SRS and FMEA. This solution keeps the gate-count costs for the diagnostic below 30% of the protected logic; it has a very low beta factor and it can be configured to achieve the level of robustness required either for a SIL2 or a SIL3 system.

Dual-CPU
faultRobust is also suitable for multiprocessors architectures and it can be used to implement or complement lock-step or mutual redundant solutions. The two CPUs share an fRCPU that includes two CPU checking units. The System Control Unit acts like the comparator of a dual-core approach, while the CPU Checking Units guarantee enough clues for the System Control Unit to determine which of the two CPUs is faulty in case of a mismatch, thus increasing the diagnostic capability of the system, keeping a very low beta factor thanks to the diversity of the diagnostic logic, allowing higher availability and a better fault-degradation path with respect to state-of-the-art dual core architectures.

Multi-IC
At system level, the combined use of fRIPs and fRNET allows the construction of hierchical robust systems: each MCU or sensor is made more robust using fRIPs while safety-relevant information is exchanged through an off-chip implementation of fRNET.

Embedded memories (Volatile and Non Volatile Memories) are the most critical blocks concerning permanent and transient faults such soft-errors. Fault detection in memories is typically addressed by using Error Detection and Correction Codes (EDC or ECC), but several limitation are inherently embedded in EDC/ECC being used as a standalone approach.

Standard EDC/ECC itself is not allowing SIL3 compliance for a memory sub-system composed by the memory array, the memory controller and the protection circuitry; EDC/ECC has a meaningful impact in terms of area and timing overhead; for large memories, multiple faults cause protection degradation; from a system point of view, EDC/ECC is not a solution for faults caused by unintentional or forbidden accesses.

fRMEM is an IP providing on top of EDC/ECC a set of proprietary techniques to fulfil the limitations of a pure EDC/ECC based solution. fRMEM is available for SRAM connected to the system bus, for Tightly Coupled Memories, caches and for non volatile memories (Flashes, NAND Flashes and EEPROM). fRMEM is also designed to allow interoperability with external Built-In-Self-Test or Built-In-Self Repair modules. fRMEM is certified by TÜV SÜD: it fulfils the safety integrity level SIL3 in accordance with IEC 61508, the international norm for safety critical electronics.

--

fRMethodology is a systematic procedure offered by YOGITECH to address IEC 61508 requirements.
Starting with the Safety Requirements Specification (SRS), a Failure Mode and Effect Analysis (FMEA) is performed, extracting information with proprietary tools from the RTL of the target design. Precise reports about Diagnostic Coverage (DC) and Safe Failure Fractions (SFF) are delivered.

fRMethodology uses fault injection at all the different stages of the validation procedure: to validate the FMEA, to assess the safe failure fraction of the EUC including diagnostic, and at the end of the implementation stage. It can be used at block/IP, sub-system and system level.