DEPENDABLE PROCESSOR DESIGN

Transcription

1 DEPENDABLE PROCESSOR DESIGN Matteo Carminati Politecnico di Milano - October 31st, 2012 Partially inspired by P. Harrod (ARM) presentation at the Test Spring School Annecy (France)

2 OUTLINE What? Problem Statement Preliminary Definitions Where? Interested Fields Standards Why? Pursued Objectives State of the Art How? Innovative Solutions 2

3 PROBLEM STATEMENT Guarantee a system to: Match specifications Fulfill requirements Meet constraints Provide real-time response What even when faults occur! We want the system to be dependable. 3

4 DEPENDABILITY RELIABILITY AVAILABILITY SAFETY INTEGRITY It is that property of a computer system such that reliance can justifiably be placed on the service it delivers. J.C. Laprie [6] Dependability is an abstraction comprising a plethora of quantities. What MAINTAINABILITY TESTABILITY 4

5 DEPENDABILITY RELIABILITY AVAILABILITY SAFETY INTEGRITY Probability that the system will operate correctly in a specified operating environment up until time t. R(t) = P(not failed during [0, t]) What MAINTAINABILITY TESTABILITY 5

6 DEPENDABILITY RELIABILITY AVAILABILITY SAFETY INTEGRITY Probability that the system will be operational at time t. A(t) = P(not failed at time t) What MAINTAINABILITY TESTABILITY 6

7 DEPENDABILITY RELIABILITY AVAILABILITY SAFETY INTEGRITY The absence of undesired and unplanned event that results in a specific level of loss (i.e. accident). What MAINTAINABILITY TESTABILITY 7

8 DEPENDABILITY RELIABILITY AVAILABILITY SAFETY INTEGRITY The absence of improper system state alterations. What MAINTAINABILITY TESTABILITY 8

9 DEPENDABILITY RELIABILITY AVAILABILITY SAFETY INTEGRITY Probability that the system can be repaired until time t. M(t) = P(repaired during [0, t]) What MAINTAINABILITY TESTABILITY 9

10 DEPENDABILITY RELIABILITY AVAILABILITY SAFETY INTEGRITY The ability to test for certain attributes within a system. Related to maintainability: importance of minimizing time required to identify and locate specific problems What MAINTAINABILITY TESTABILITY 10

11 These quantities have different, sometimes contradictory, goals: their trade-off is to be maximized while designing a new electronic system. What ROBUSTNESS Ability of a system to continue functioning despite the presence of faults, even if the system performance may be altered (always in a safe way), until the faults are corrected. FUNCTIONAL SAFETY Absence of unreasonable risk due to hazards caused by malfunctioning behavior of electronic systems. 11

12 WHAT IS A FAULT? FAULT ERROR FAILURE a defect within the system a deviation from the required operation the system fails to perform its required function Fault Error Detection What Fault Free Latency Repair Recovery Fault Free Outage t 12

13 FAULT TAXONOMY FAULT RANDOM SYSTEMATIC HW HW SW What PERMANENT (hard): shorts, stuck-at, stuck-open INTERMITTENT TRANSIENT (soft): SEE, SBU, MBU, SET 13

14 WHAT IS AN ACCIDENT? Fault Error Failure Fault Error Failure state of the system that in certain environmental situations may lead to an accident What Fault Error Failure Hazard Accident 14

15 SIL - IEC SAFETY INTEGRITY LEVEL The relative level of risk reduction provided by a safety function. Safe Failure Fraction Ratio between the sum of safe hazards plus detected dangerous hazards and the sum of safe hazards plus all dangerous hazards. SFF Hardware Fault Tolerance A HFT on N means that N+1 faults could cause a loss of the safety function. HFT What <60% >60% && <90% >90% && <99% >99% - SIL 1 SIL 2 SIL 3 SIL 1 SIL 2 SIL 3 SIL 4 SIL 2 SIL 3 SIL 4 SIL 4 From [1]. 15

16 FAULT-RELATED PROPERTIES Fault Ignore The fault does not require to be detected nor mitigated. Fault Detection The result can be incorrect, but the fault must be identified. Fault Tolerance The fault is to be mitigated and the provided result correct. What Fault Diagnosis The result must be correct and the faulty unit is to be identified. 16

17 CRITICAL SYSTEMS MISSION Aerospace Railway SAFETY Where Nuclear power stations Medical devices Automotive BUSINESS Account management Transaction systems 17

18 CRITICAL SYSTEMS MISSION Aerospace - DO-178B/DO-254 Railway - EN SAFETY STANDARDS Where Nuclear power stations - IEC Medical devices - IEC Automotive - ISO BUSINESS Account management Transaction systems 18

19 ISO 26262: FOCUS Driver assistant, lane departure Passenger safety air bags Electric/hybrid energy system Where Engine management, power train From [1]. Breaking: ABS, anti-skid,... 19

20 ISO 26262: FOCUS REQUIREMENTS Architecture compliance Measures to achieve system safety in case of random HW failures. Where Process compliance Guidelines for designing processes and HW/SW architectures to avoid systematic failures. 20

21 ISO 26262: FOCUS ASIL AUTOMOTIVE SAFETY INTEGRITY LEVEL IEC ISO Application Example SIL 4 SIL 3 - ASIL D ASIL C Railway signal control Brake-by-wire, EPS,... Battery management Where SIL 2 SIL 1 ASIL B ASIL A Automotive dashboard Rear lights Ex: ASIL D means >99% faults must be detected and the probability of violation of safety goal due to HW random failures shall be less than 10 FIT (1 FIT = 1 failure in1 billion of hours) 21

22 ISO 26262: FOCUS HOW TO ACHIEVE THE ASIL Setting up functional safety management Defining safety goal Where Improving the process Avoid systematic failures Improving the product Detect/tolerate HW random failures Avoid/detect dependent failures 22

23 NON-CRITICAL SYSTEMS Domestic appliance Entertainment devices Where Distribution networks Wellness 23

24 NON-CRITICAL SYSTEMS Domestic appliance Dependability Entertainment devices Where Distribution networks Wellness Performance TRADE-OFF Power 24

25 GOALS Design dependable processors to: Reduce the number hazards and accidents Increase system safety Why Meet standards 25

26 STATE OF THE ART ARCHITECTURAL APPROACH A 1oo1 Rs = Ra A B 2oo2 Rs = 1 - (1 - Ra) x (1 - Rb) Why A B 1oo2 Rs = Ra x Rb A B C VOTING 2oo3 Rs = 1 - (1 - RaRb) x (1 - RbRc) x (1 - RaRc) 26

27 STATE OF THE ART DIVERSITY different solutions satisfying the same requirement with the aim of independence - ISO A B A Ch Reduces HW systematic failures Why Prevents, reduces, or detects common cause failures replacing the need for complex measures 27

28 DUAL CORE LOCK-STEP Homogeneous Redundancy CPU master SW COMP CPU checker Achieves ASIL D Example Freescale MPC5746M Why High diagnostic coverage Negligible SW overhead Significant HW overhead Significant power consumption increase Susceptible to common-cause and HW systematic failures Poor diagnostic info and availability 28

29 CHALLENGE & RESPONSE SW cross-exchange between 2 independent units SW1 CPU main SW2 CPU secondary Achieves ASIL C serial interface Why Common-cause failures detection HW/SW systematic failures detection Significant HW and power consumption increase Significant SW and performance overhead Poor transient fault coverage, reusability, and availability Slow error detection latency 29

30 E-GAS CONCEPT SW diversified redundancy with 2 independent units SW1 CPU SW2 Achieves ASIL B main MISR Why Low HW overhead SW systematic failures detection Significant SW and performance overhead Poor transient fault coverage, reusability, and availability Susceptible to common-cause failures Slow error detection latency 30

31 HARDENED BY-DESIGN Each processor functional units is independently hardened hardened CPU Example LEON3 FT SW Why Low HW overhead Low performance overhead Optimized solution Significant design overhead Need to know processor internal description Very low reusability, very specific solution 31

32 TIGHTLY COUPLED 2 CORE Asymmetric Redundancy SW CPU master CPU interface checker optimized supervisor Achieves ASIL D How Low HW and power consumption overhead Negligible SW overhead Common-cause and HW systematic failures detection Fast error detection latency, good availability Very detailed analysis required CPU interface needed 32

33 YOGITECH S FAULT-ROBUST SW CPU master CPU interface main supervisor robust net remote supervisors How From [4]. The supervisor is designed exploiting a white-box approach Meets IEC and ISO requirements One main supervisor for the CPU and a set of remote supervisors, one for each specific region of the system Hardware-centric approach 33

34 MAIN SUPERVISOR system control unit CPU interface main supervisor System Control Unit CPU Checking Unit robust net CPU interface CPU sniffer Data sup. Data addr. sup. Instruct. exec. sup. Mode sup. CPU checking unit How The CPU Checking Unit checks the instructions execution, the program flow, and the data processing The CPU sniffer collects, compacts, codes, and buffers signals from the CPU and forwards them to the supervisors Each supervisor is composed by: a data-path, a sequencer and a checker The System Control Unit decides if the system is in a wrong state and performs necessary actions 34

35 REMOTE SUPERVISORS How robust net remote supervisors Memory Supervisors Peripheral Supervisors Bus Supervisors Custom Supervisors The memory supervisor provides the possibility to store ECC codes and to share it with multiple memories Peripheral supervisors implement a hardware verification component The bus supervisors monitor sources and sinks of the bus and perform data integrity checks 35

36 METHODOLOGY FLOW Safety Requirements Specification supported by automatic tools DESIGN Failure Modes and Effects Analysis Fault Injection How SFF/DC reports Safe Failure Fraction - SFF Diagnostic Coverage - DC 36

37 RESULTS How PHILIPS SJA2510 FlexRay microcontroller <30% HW overhead for CPU protection <10% HW overhead for memory protection A greater level of optimization can be reached if the configuration is more application specific From [4]. 37

38 CONCLUSIONS OLD TREND HW is unreliable by definition HW is stupid: in case of failure it cannot tell what is going on HW/SW redundancy is the only way to guarantee the availability of safety-critical systems NEW TREND Design-for-Uncertainty must become a new paradigm FMEA till the gate level should become a de facto standard New architectures should embed methods to detect and control errors The proposed platform-based solution aims at reducing of HW and SW costs needed to implement fault robust MCUs in adherence with IEC SIL3. This is achieved by implementing an optimized HW CPU fault detection, by providing dedicated HW to replace, support or supplement SW tests and by distributing robustness to the whole SoC. The proposed approach is scalable, flexible, portable and reusable by design. 38

39 BIBLIOGRAPHY 1. P. Harrod, Dependable Processor Design - TSS presentation, C. Bolchini, Dependable Systems - Course slides, M. Bellotti, R. Mariani, How future automotive functional safety requirements will impact microprocessors design - Microelectronics Reliability, R. Mariani, P. Fuhrmann, B. Vittorelli, Fault-robust microcontrollers for automotive applications, IEEE International On-Line Testing Symposium (IOLTS), M. Baleani, A. Ferrari, L. Mangeruca, A. Sangiovanni-Vincentelli, M. Peri, S. Pezzini, Fault-Tolerant Platforms for Automotive Safety-Critical Applications, International Conference on Compilers, Architectures, and Synthesis for Embedded Systems (CASES), J.C. Laprie, Dependable Computing: Concepts, Limits, Challenges, IEEE International Symposium on Fault-Tolerant Computing,