University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Hardware/Software Codesign of Embedded Systems Validation Voicu Groza School of Information Technology and Engineering

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Validation – Simulation and test pattern generation (TPG)

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Introduction (1) Definition: Validation is the process of checking whether or not a certain (possibly partial) design is appropriate for its purpose, meets all constraints and will perform as expected. Definition: Validation with mathematical rigor is called (formal) verification.

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Introduction (2) Ideally: Formally verified tools transforming specifications into implementations („correctness by construction“). In practice: Non-verified tools and manual design steps  validation of each and every design required Unfortunately has to be done at intermediate steps and not just for the final design  Major effort required.

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Simulations  Simulations try to imitate the behavior of the real system on a (typically digital) computer.  Simulation of the functional behavior requires executable models.  Simulations can be performed at various levels.  Some non-functional properties (e.g. temperatures, EMC) can also be simulated.

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Examples of thermal simulations (1) Source: NL_JUN_2001/Campi/Jun_Campi_2001.html Encapsulated cryptographic coprocessor:

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Examples of thermal simulations (2) Source: applications/app141/hot_chip.pdf Microprocessor

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS EMC simulation Source: ~etienne/emccourse/what_for.html Red: high emission Validation of EMC properties often done at the end of the design phase. Example: car engine controller

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Example of thermal measurement Infrared image of sample PCB Thermal signature is the thermal response of DUT when a vector test or a sequence of vector tests is applied to DUT.

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Simulations Limitations  Typically slower than the actual design.  Violations of timing constraints likely if simulator is connected to the actual environment  Simulations in the real environment may be dangerous  There may be huge amounts of data and it may be impossible to simulate enough data in the available time.  Most actual systems are too complex to allow simulating all possible cases (inputs). Simulations can help finding errors in designs, but they cannot guarantee the absence of errors.

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Rapid prototyping/Emulation  Prototype: Embedded system that can be generated quickly and behaves very similar to the final product.  May be larger, more power consuming and have other properties that can be accepted in the validation phase  Can be built, for example, using FPGAs.  Prototype: Embedded system that can be generated quickly and behaves very similar to the final product.  May be larger, more power consuming and have other properties that can be accepted in the validation phase  Can be built, for example, using FPGAs. Example: Canadian Microelectronics Corporation

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS More recent commercial emulators [ ] AP1000 Development Board for Larger Virtex-II Pro Devices The AP1000 family of boards support Xilinx Virtex-II Pro devices (in FF1704 package): XC2VP70 with two IBM PPC405 cores, and XC2VP100 with two IBM PPC405 cores.

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Test: Goals 1.Production test 2.Is there any way of using test patterns for production test already during the design*? 3.Test for failures after delivery to customer

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Test: Scope Testing includes  the application of test patterns to the inputs of the device under test (DUT) and  the observation of the results. More precisely, testing requires the following steps: 1.test pattern generation, 2.test pattern application, 3.response observation, and 4.result comparison.

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Test pattern generation Test pattern generation typically  considers certain fault models and  generates patterns that enable a distinction between the faulty and the fault-free case.  Examples:  Boolean differences  D-Algorithm

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Fault models  stuck-at fault model (net permanently connected to ground or V dd )  stuck-open faults: for CMOS, open transistors can behave like memories  delay faults: circuit is functionally correct, but the delay is not. Hardware fault models include: /rassp_43/sld022.htm

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Simple example Could we check for a stuck at one error at a (s-a-1( a )) ? Solution (just guessing):  f='1' if there is an error  a='0', b='0' in order to have f='0' if there is no error  g='1' in order to propagate error  c='1' in order to have g='1' (or set d='1')  e='1' in order to propagate error  i='1' if there is no error & i='0' if there is /1 0  /0 0 error no error

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Variable D Getting rid of 0/1 notation:  Definition: This is adequate for modeling a single error. Multiple errors would require several variables. This is adequate for modeling a single error. Multiple errors would require several variables.

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Modeling gates with primitive cubes Definition: Let a function f and its complement be represented by implicants. Each entry in a table of implicants and outputs is called a primitive cube (pc). Example: 2-input NAND gate fault-freewith fault A B C Primitive cube

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Primitive D-cubes of a fault (pdcf's) are cubes which model a condition under which a fault does show up. Input values generate an output of D (resp. D ) if they are contained in cubes  1 and  0 (resp.  0 and  1 ). Hence, we define the intersection of cubes as follows: X  '0' = '0', X  '1'='1', '1'  '0' =  (empty), with X: don't care Modeling faulty gates with D-cubes of a fault fault freewith fault pc pdcf ° Primitive D-cubes of a fault (pdcf's) are cubes which model a condition under which a fault does show up. Input values generate an output ofD(resp.D) if they are contained in cubes  1 and  0 (resp.  0 and  1 ). Hence, we define the intersection of cubes as follows: X  '0' = '0', X  '1'='1', '1'  '0' =  (empty), with X: don't care Primitive D-cubes of a fault (pdcf's) are cubes which model a condition under which a fault does show up. Input values generate an output ofD(resp.D) if they are contained in cubes  1 and  0 (resp.  0 and  1 ). Hence, we define the intersection of cubes as follows: X  '0' = '0', X  '1'='1', '1'  '0' =  (empty), with X: don't care

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Modeling propagation with propagation cubes (1) Propagation D-cubes are cubes that model requirements for propagating errors to the output. An error D ( ) at input r gets propagated to the output as f=D ( ) iff r='0' implies f='0' and r='1' implies f='1' (non-inverting) An error D ( ) at input r gets propagated to the output as f= ( D ) iff r='0' implies f='1' and r='1' implies f='0' (inverting). Hence, consider intersection of  1 and  0 while ignoring input r.

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Modeling propagation with propagation cubes (2) Hence, consider intersection of  1 and  0 while ignoring input r. Example: 2-input NAND gate fault freewith fault pc pdcf

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS D-Algorithm 1.Select D-cube for the error under consideration. 2.Implication: Imply signals whose value results unambiguously from the preceding selection. Based on the intersection between the "test cube" (set of known signals) and primitive cubes of gates reached by the test cube. Return to last step if intersection is empty (backtracking). 3.D-drive: D-frontier = all gates whose outputs are unspecified and whose inputs carry a value of D or D. Select gate  D-frontier. Propagate signal to output by intersecting test cube with pdcf of that gate. Return to last step if no non-empty intersection exists. 4.Iterate steps 2 and 3 until some signal has reached output 5.Line justification: Unspecified inputs will be adjusted by intersecting the test cube and primitive cubes of the gates. Backtracking if required.

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Example Primitive cubes for NAND Propagation D-cubes for NAND Pdcfs for NAND fault free with fault Typ. Runtime: O((# of gates)²) 1 pattern per error

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Fault coverage A certain set of test patterns will not always detect all faults that are possible within a fault model  For actual designs, the coverage should be at least in the order of 98 to 99%

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Generation of Self-Test Program Generation - Key concept - RF(0) := "11...1"; MEM(0) := "11...1"; IF MEM(0) - R(0) <>"00...0" THEN Error; ALU MEMRF a b = 0 ? PC stuck-at-0? mux

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Test Program Generation (2) Programs running on the processors to be tested Well-known concept mainframes) Very poor tool support Mostly ad-hoc process: Initial ad-hoc program; Extended until sufficient coverage achieved; Extended if undetected errors are reported by field service Programs running on the processors to be tested Well-known concept mainframes) Very poor tool support Mostly ad-hoc process: Initial ad-hoc program; Extended until sufficient coverage achieved; Extended if undetected errors are reported by field service

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Self-Test Programs generated by Retargetable Test Compiler RT- Netlist ternal nodes ternal nodes program [Bieker, 1995] binary code Retargetable Test Program Compiler stimuli

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Fault simulation (1) Coverage can be computed with fault simulation:  faults  fault model: check if distinction between faulty and the fault-free case can be made: Simulate fault-free system;  faults  fault model DO  test patterns DO Simulate faulty system; Can the fault be observed for  1 pattern? Faults are called redundant if they do not affect the observable behavior of the system, Fault simulation checks whether mechanisms for improving fault tolerance actually help.

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Fault simulation (2) High computational requirements. Parallel fault-simulation at the gate level: Each bit in a word represents a different input pattern. E.g.: 32 input patterns simulated at the same time.   Each bit corresponds to one test pattern Operators correspond to gate-level structure

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Summary Validation is the process of checking whether or not a certain (possibly partial) design is appropriate for its purpose, meets all constraints and will perform as expected. Techniques  Simulation (used at various steps)  Test TPG (D-Algorithm, generation of assembly prog.,..) Application of test patterns Checking the results Fault simulation for computing coverage  Emulation

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Validation - Design for testability (DFT) and fault injection -

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Testing finite state machines Difficult to check states and transitions A/f B/c C/d E/d For example, verifying the transition from 2 to 3 requires  Getting into state 2  Application of A  Check if output is f  Check if we have actually reached 3 Simplified with scan design: For example, verifying the transition from 2 to 3 requires  Getting into state 2  Application of A  Check if output is f  Check if we have actually reached 3 Simplified with scan design:

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Scan design

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Scan design: usage Verifying a transition requires Shifting-in the „old state“ Application of the input pattern Checking if output is correct Shifting-out the new state and comparing it. Essentially reduced to testing combinatorial logic Verifying a transition requires Shifting-in the „old state“ Application of the input pattern Checking if output is correct Shifting-out the new state and comparing it. Essentially reduced to testing combinatorial logic

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS JTAG (Boundary scan) (1) JTAG defines a 4..5-wire serial interface to access complex ICs.. Any compatible IC contains shift registers & FSM to execute the JTAG functions. TDI: test data in; stored in instruction register or in one of the data registers. TDO: test data out TCK: clock TMS: controls the state of the test access port (TAP). Optional TRST* is reset signal. Source: com/brochure.php

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS IEEE Std Boundary-Scan Testing

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Boundary- Scan Register PinDescriptionFunction TDITest data input Serial input pin for instructions as well as test and programming data. Data is shifted in on the rising edge of TCK. TDO Test data output Serial data output pin for instructions as well as test and programming data. Data is shifted out on the falling edge of TCK. The pin is tri-stated if data is not being shifted out of the device. TMS Test mode select Input pin that provides the control signal to determine the transitions of the TAP controller state machine. Transitions within the state machine occur at the rising edge of TCK. Therefore, TMS must be set up before the rising edge of TCK. TMS is evaluated on the rising edge of TCK. TCKTest clock inputThe clock input to the BST circuitry. Some operations occur at the rising edge, while others occur at the falling edge.

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Boundary-scan cell Boundary-Scan Testing Altera MAX 7000 User I/O BSC with IEEE Std BST Circuitry

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS JTAG (Boundary scan) (2) Defines method for setting up a scan chain on a PCB Source: com/brochure.php

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Limitations of a single serial scan chain For chips with a large number of flop-flops, serial shifts can take a quite long time. Hence, it becomes necessary to provide several scan chains.  Trying to avoid serial shifts by generating test patterns internally and by also storing the results internally.  Compaction of circuit response in a signature. Shifting the entire result out becomes obsolete, we just shift out the signature.

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Signature analysis Response of circuit to sequence of test patterns compacted in a signature. Only this signature is compared to the golden reference. In order to exploit an n-bit signature register as good as possible, we try to use all values possible for that registers. In practice, we use shift-registers with linear feedback: n-bit shift registerXOR Response of circuit to sequence of test vectors Signature Using proper feedback bits, all values possible for the register can be generated.

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Example: 4-bit signature generator XOR All 16 possible signatures are generated! Source: P.K.Lala: Fault tolerant & fault testable hardware design, Prentice Hall,

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Aliasing for signatures Consider aliasing for some current pattern  An n-bit signature generator can generate 2 n signatures.  For an m-bit input sequence, the best that we can get is to evenly map 2 (m-n) patterns to the same signature.  Hence, there are 2 (m-n) -1 sequences that map to the same signature as the pattern currently considered.  In total, there are 2 m -1 sequences different from the current one. 

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Replacing serially shifted test pattern by pseudo random test patterns Shifting in test patterns can be avoided if we generate (more or less) all possible test patterns internally with a pseudo- random test pattern generator. DUTPseudo- random test pattern generator Signature analysis register Effect of pseudo random numbers on coverage to be analyzed. Signature analysis register shifted-out at the end of the test. Effect of pseudo random numbers on coverage to be analyzed. Signature analysis register shifted-out at the end of the test. Compare with reference

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Pseudo random test pattern generation XOR n -1 patterns generated! Superior to counters if not all patterns are used. 2 n -1 patterns generated! Superior to counters if not all patterns are used. Linear feedback shift register (LFSR)

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Combining signature analysis with pseudo- random test patterns: Built-in logic block observer (BILBO) Uses parallel inputs to compress circuit response Könemann & Mucha

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Built-in logic block observer (BILBO) Modes of operation

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Typical application Compressed response shifted out of Bilbo-2 & compared to known „golden“ reference response. Roles of Bilbo-1 and 2 swapped for testing DUT-1 DUT-1 Bilbo-1 (generates pseudo-random test patterns) Bilbo-2 (compresses response) DUT-2

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Fault injection Fault simulation may be too time-consuming  If real systems are available, faults can be injected. Two types of fault injection: 1.local faults within the system, and 2.faults in the environment (behaviors which do not correspond to the specification). For example, we can check how the system behaves if it is operated outside the specified temperature or radiation ranges.

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Physical fault injection Hardware fault injection requires major effort, but generates precise information about the behavior of the real system. 3 techniques compared in the PDCS project on the MARS hardware [Kopetz]: Injection TechniqueHeavy-ionPin-levelEMI Controllability, spaceLowHighLow Controllability, timeNoneHigh/mediumLow FlexibilityLowMediumHigh ReproducibilityMediumHighLow Physical reachabilityHighMedium Timing measurementMediumhighLow

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS MARS hardware nodes Communi- cation Unit (68070 processor) Application Unit (68070 processor) FIFOFIFO FIFOFIFO Bus Guar- dian Replicated bus 2 asynchronous communication ports (RS 232) Bus guardian protects against "babbling idiots"

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Implemented error detection mechanisms 1.Hardware: standard mechanism for CPU: Illegal instruction & illegal address traps; Special mechanisms: bus guardian, FIFO overflow, power supply monitor 2.System software: compiler generated run- time assertions, timing checks to check WCET of RT-tasks 3.Application software: double execution, triple execution (two dynamic, one static in- between), end-to-end CRC

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Experimental setup Software: typical cyclic real-time application Result of comparison Application unit error data Communic. unit error data Fault injector Comparator Data generator

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Results According to experiments reported by Kopetz: 1.With all error-detection mechanisms enabled, no fail-silence violation was observed in any of the experiments. 2.End-to-end error detection mechanisms and double execution of tasks were needed for all 3 fault injection methods if a coverage of > 99% were to be achieved. 3.For heavy-ion radiation, triple execution was needed. 4.The bus guardian unit was needed in all 3 experiments if a coverage of > 99% was required.

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Software fault injection Errors are injected into the memories. Advantages:  Predictability: it is possible to reproduce every injected fault in time and space.  Reachability: possible to reach storage locations within chips instead of just pins.  Less effort than physical fault injection: no modified hardware. Same quality of results?

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Results  Software fault injection with bit-flips in the data is comparable to hardware fault injection  Application software error detection is higher for software-implemented fault injection. Most hardware-injected faults do not propagate to the application level.  If application level error detection is turned of, software fault injection generates a higher number of coverage violations than EMI or pin level injections for single task execution.  Software fault injection comparable to EMI and pin level injections. However, heavy-ion radiation is more stressful.

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Risk- and dependability analysis „10 -9“ : For many systems, probability of a catastrophe has to be less than per hour  one case per 100,000 systems for 10,000 hours. FIT: failure-in-time unit for failure rate (=1/MTTF  1/MTBF); 1 FIT: rate of failures per hour Damages are resulting from hazards. For every damage there is a severity and a probability. Several techniques for analyzing risks. Example : metal Pentium 4

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Actual failure rates Example: failure rates less than 100 FIT for the first 20 years of life at TriQuint (GaAs) [ Target: Failures rates of systems ≤ 1FIT (Failure in Time) Reality: Failures rates of circuits ≤ 100 FIT  redundancy is required to make a system more reliable than its components Different devices

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Fault tree Analysis (FTA)  FTA is a top-down method of analyzing risks. Analysis starts with possible damage, tries to come up with possible scenarios that lead to that damage.  FTA typically uses a graphical representation of possible damages, including symbols for AND- and OR-gates.  OR-gates are used if a single event could result in a hazard.  AND-gates are used when several events or conditions are required for that hazard to exist.

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Example

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Limitations The simple AND- and OR-gates cannot model all situations. For example, their modeling power is exceeded if shared resources of some limited amount (like energy or storage locations) exist. Markov models may have to be used to cover such cases.

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Failure mode and effect analysis (FMEA)  FMEA starts at the components and tries to estimate their reliability. The first step is to create a table containing components, possible faults, probability of faults and consequences on the system behavior.  Using this information, the reliability of the system is computed from the reliability of its parts (corresponding to a bottom-up analysis).

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Safety cases Both approaches may be used in “safety cases”. In such cases, an independent authority has to be convinced that certain technical equipment is indeed safe. One of the commonly requested properties of technical systems is that no single failing component should potentially cause a catastrophe.

University of Ottawa, SITE, 2008 VOICU GROZA - HARDWARE/SOFTWARE CODESIGN OF EMBEDDED SYSTEMS Summary  Design for Test (DFT)  Scan path  Signature analysis, pseudo random patterns, BILBO  Boundary scan  Fault injection  Physical fault injection  Software fault injection  Risk- and dependability analysis  FTA  FMEA