Part 1 of this feature dealt with the nature of faults and measures of robustness for automotive electronics applications leading to the "car-on-a- chip."
The fRCPU IP of the faultRobust technology serves as the fault supervisor of a CPU sub-system. This suite is not a replication of the CPU since it is architecturally and functionally diverse and, because of that, it strongly reduces the Beta Factor [The probability of common cause failures that could become a limiting factor especially when multiple, functionally-equal channels are implemented in the same silicon.] as required by the IEC 61508 standard. Being hardware-centric (i.e. most of the diagnostics are in hardware), alarms are generated independently from the application and there is not any performance impact on CPU. The fRCPU covers only what is really relevant to reach Safety Integrity Level 3 (SIL3), allowing the minimum hardware overhead (and power consumption), and minimum connection requirements and complexity.
As shown below, the fRCPU for protecting CPU subsystems is composed of:
A CPU Sniffer Unit collecting, "compating," and coding signals from the CPU boundary
A Shadow Processing Unit executing the same flow as the CPU, including a register bank to store a shadow value of CPU main registers
A management unit to generate data/addresses
The fRCPU compares its results with those read from the CPU with a set of independent checkers supervising the different CPU ports. A Coverage Monitor Unit (CMU) provides run-time information on the current safe failure fraction (SFF) with respect to "conditions of use", that is in relation to FMEA assumptions. The CMU acts as a "checker of the checker," flagging unexpected software scenarios (such infinite loops), and allows dynamic coverage, pre-integration analysis on application profiles.
The technology is completed by a faultRobust System Control Unit (fRSCU) collecting and synchronizes all the alarms coming from fRCPU and from the other "remote" fault supervisors, such as fRMEM. Based on this information, fRSCU decides if the system (CPU and peripherals) is in a wrong state and, based on architectural safety requirements, performs actions such as flagging the operating system, forcing some fail-safe hardware configuration, and so on. The fRSCU is highly configurable by the user.
The other "remote" supervisors are:
Bus supervisors (fRBUS), consisting of a set of blocks (decoders, arbiters, checkers) monitoring sources and sinks of the bus interconnect
Peripheral supervisors (fRPERI), implementing a "hardware verification component," i.e. a block where a subset of the protocol checks and assertions used to verify a given interface have been translated into hardware constructs
The fRCPU, fRMEM, fRBUS, and fRPERI communicate with the fRSCU through a dedicated on-chip robust interconnect (fRNET) guaranteeing that information is transferred without errors between the different diagnostic units. The fRNET ensures that safety-related information travels in a separate channel with respect to mission data.
While this approach is hardware-centric (the major role is played by the hardware supervisors), in order to provide the best tradeoff between costs and benefits, faultRobust technology foresees a set of software fRIPsvery compact software Built-in Self-Tests (BISTs) making use of hardware resources guaranteed by the hardware fRIPs.
Join our online Radio Show on Friday 11th July starting at 2:00pm Eastern, when EETimes editor of all things fun and interesting, Max Maxfield, and embedded systems expert, Jack Ganssle, will debate as to just what is, and is not, and embedded system.