1、How future automotive functional safety requirements will impactmicroprocessors designM. Bellottia,*, R. MarianibaEngineering & Design Electrical Electronics Department, Fiat Group Automobiles, Torino, ItalybYOGITECH SPA, via Lenin 132/p 56017 San Martino Ulmiano, Pisa, Italya r t i c l ei n f oArti
2、cle history:Received 7 July 2010Accepted 13 July 2010Available online 3 August 2010a b s t r a c tSafety is one of the key issues of future automobile development. Car maker as well as suppliers need toprove that, despite increasing complexity, their electronic systems will deliver the required func
3、tionalitysafely and reliably. Future development and integration of these functionalities will even strengthen theneed of safe system development processes and the possibility to provide evidence that all reasonablesafety objectives are satisfied. Obviously with the trend of increasing complexity, t
4、here are increasingrisks from systematic failures and random hardware faults that could impact negatively on vehicle safety.Safety relevant systems (such as advanced driving assistance and vehicle dynamic control units) requiremicrocontrollers able to guarantee safety and availability with an accept
5、able cost. Safety must beachieved with respect to both systematic and hardware random faults, including soft-errors and com-mon-cause failures. To provide availability, efficient and fast fault detection mechanisms shall be com-bined with infrastructures able to collect error events with enough deta
6、ils to allow reactions by theremaining hardware and the operating system. Costs shall be minimized by introducing as much robust-ness as needed and not more: this shall be done by avoiding unnecessary redundancies and reducing atthe minimum the impact on system performances, therefore maximizing the
7、 usage of the availableresources. This paper will give a short introduction on main concept of functional safety and ISO/DIS26262, underlining the impact of such requirements on microprocessors and microcontrollers design.Some examples will be given on current approaches used to answer ISO/DIS 26262
8、 requirements.? 2010 Elsevier Ltd. All rights reserved.1. IntroductionToday, many safety relevant types of equipment require micro-controllers (MCU). Currently the average number of MCUs per vehi-cle is about 25 and this number is expected to increase in thefollowing decade. For example, automotive
9、MCUs are expected tosee revenuesof $3.1 billionfor 2009,accountingfor 21%of the auto-motive semiconductor market. By 2014 it is expected that automo-tive MCUs will generate revenues of almost $4.8 billion, withrevenuegrowinginlinewiththeoverallautomotivesemiconductorsmarket 1. System complexityraise
10、s also safety questionsconcern-ing their impact of the vehicle and its occupants. As a consequence,safety relevant systems need to be properly designed, consideringthe fact the system and his internal resources are involved in safetyfunctionalities and non-safety relevant functionalities.Many MCU pr
11、oducers (see for example 24) are developingcomponents able to face new safety requirements, specifying,designing and analyzing their components in accordance withfunctional safety norms like IEC 61508 5 and ISO/DIS 26262 6.These MCUs deliver cost effective solution; some MCUs are basedon a hardware
12、architecture that reduces both effort of safety mech-anisms and their detection latency; others with dual-core lock-stepimplementation simplifying software development by removingredundant safety system requirements. Such solutions provideautomatic hardware diagnostics and safety features to meet th
13、ehighest requirements of ISO/DIS 26262 automotive safety integritylevel: ASIL D.2. ISO/DIS 26262 in generalThe car manufacturer has the basic obligation to place on themarket only safe products (as reported in 85/374 EEC and 2001/95 EC in Europe, US Tread Act). Actually there is no legal require-men
14、t for certification of compliance of automotive E/E systemswith ISO/DIS 26262; it is a voluntary adherence (state of art). Theneed of adoption of such new safety standards is mainly due tothe fact that car makers as well as suppliers need to prove that, de-spite increasing complexity, their electron
15、ic systems will deliverthe required functionality safely and reliably. This standard gives0026-2714/$ - see front matter ? 2010 Elsevier Ltd. All rights reserved.doi:10.1016/j.microrel.2010.07.041* Corresponding author. Tel.: +39 011 0038863; fax: +39 011 0033609.E-mail address: esref2010_author01un
16、icas.it (M. Bellotti).Microelectronics Reliability 50 (2010) 13201326Contents lists available at ScienceDirectMicroelectronics Reliabilityjournal homepage: to perform a Functional Safety Assessment and providesautomotive-specific analysis methods to identify the automotivesafety integrity level (ASI
17、L = specifies the items necessary safetyrequirements for achieving an acceptable residual risk). Car makersas well as suppliers can adopt this new standard also because givesclear rules for a Safety Oriented” Design; it asses hazards and risksof a system during the concept phase” or during early des
18、ignphases; it also includes requirements on manufacturer/supplierrelation and distributed development process for safety relevantsystems; it requires a detailed scheduling of the design activitieswith well defined work products for each system lifecycle stageand finally states the rules of standardi
19、zed safety elements reuseand placing fundamentals on standardization concept application.One of the first phases described by this standard is the hazardanalysis and risk assessment which objective is to identify and cat-egorize the hazards of the item and formulate the safety goals re-lated to the
20、prevention or mitigation of these hazards, in order toavoid unreasonable risk.An ASIL defined as one of four levels to specify the items orelements necessary requirements of ISO/DIS 26262 and safetymeasures for avoiding an unreasonable residual risk with D repre-senting the most stringent and A the
21、least stringent level shall bedetermined for each hazardous event using the estimation param-eters severity (S), probability of exposure (E) and controllability (C)in accordance with Table 1. In addition to these four ASILs, the classQM (Quality Management) denotes no requirement in accordancewith I
22、SO/DIS 26262.The ASIL/hazard classification scheme comprises the determi-nation of the severity (S), the exposure (E) and the controllability(C) associated with the considered hazard of the item. For a givenhazard, this classification will result in one or more combinationsof S, E, and C classes. As
23、 such, each combination represents an esti-mate of potential harm in a particular driving situation, with theseverity determined by the potential harm and the exposure deter-mined by the situation. The controllability rates how easy or diffi-cult it is for the driver or other road traffic participan
24、t to avoid theconsidered accident type in the considered situation.The ASIL determined for the hazardous event shall be assignedto the corresponding safety goal.To comply with the safety goals, the functional safety conceptspecifies the basic safety mechanisms and safety measures in theform of funct
25、ional safety requirements. The functional safetyrequirements are allocated to elements in the system architecture.To specify safety mechanisms the functional safety concept ad-dresses the following: Fault detection and failure mitigation. Transitioning to a safe state. Fault tolerance mechanisms, wh
26、ere a fault does not leaddirectly to the violation of the safety goals and which maintainsthe system in a safe state (with or without degradation); and Fault detection and driver warning in order to reduce the riskexposure time to an acceptable interval (repair request, stoprequest). Arbitration log
27、ic to select the most appropriate control requestfrom multiple requests generated simultaneously by differentfunctions.The structure and distribution of the safety requirements withinthe corresponding parts of ISO/DIS 26262 are illustrated in Fig. 1.The technical safety requirements are allocated to
28、 hardwareand software. The requirements that are allocated to both are fur-ther partitioned to yield hardware only safety requirements. Thehardware safety requirements are further detailed and considerdesign constraints and the impact of these constraints on the hard-ware. Hardware design includes h
29、ardware architectural design andhardware detailed design. Hardware architectural design repre-sents all hardware components and their interactions with one an-other. Hardware detailed design is at the level of electricalschematics representing the interconnections between hardwareparts composing the
30、 hardware components. In order to develop asingle hardware design both hardware safety requirements as wellas all non-safety requirements have to be fulfilled. Hence, safetyand non-safety requirements are handled within one developmentprocess. Finally a safety analysis of hardware architectural and
31、de-tailed design to determine effects and causes of faults shall be ap-plied using deductive or inductive methods such as Failure Modeand Effects Analysis (FMEA) or Fault Tree Analysis (FTA).3. ISO/DIS 26262 and MCU designFig. 2 gives an abstract view of an Electronic Control Unit (ECU),including a
32、MCU plus a set of digital and analogue drivers to con-trol/readactuators/sensors,businterfaces,relaysandclockgeneration.The MCU typically includes a vital” core (including the CPU,the memories, the inner busses and the key registers such as oper-ating system timers, configuration registers) plus the
33、 peripheralsneeded to control the digital and analogue drivers and the businterface.3.1. ISO/DIS 26262 MCU failure classesFrom ISO/DIS 26262 point of view, failures of the MCU can bedivided in two main classes:? HW random failure: failure that may occur unpredictably duringthe lifetime of a hardware
34、 element and that follows a probabil-ity distribution. In an MCU, they can be caused by permanentfaults (e.g. stuck-at faults), transient faults (e.g. single-event-upset), intermittent faults (e.g. time dependent variability).? Systematic failure: failure of an element or item that is caused ina det
35、erministic way during development, manufacturing, ormaintenance. For example: MCU design bugs, unverified cornercases, timing weaknesses, underestimated couplings effects, sil-icon defects escaped from production test, etc.Dependent failures are an important sub-case: they are failureswhose probabil
36、ity of simultaneous or successive occurrence can-not be expressed as the simple product of the unconditional prob-abilities of each of them. In particular, common-cause failures(CCF, failure of two or more elements of an item resulting from asingle specific event or root cause) are very important fo
37、r MCUs be-Table 1ASIL determination.C1C2C3S1E1QMQMQME2QMQMQME3QMQMAE4QMABS2E1QMQMQME2QMQMAE3QMABE4ABCS3E1QMQMAE2QMABE3ABCE4BCDM. Bellotti, R. Mariani/Microelectronics Reliability 50 (2010) 132013261321cause physical faults can easily cause those kinds of failures insidethe same silicon. The dependen
38、t failures can be either random (e.g.a change in the temperature affecting all the integrated circuit, or ahot-spot) or systematic (e.g. a mistake during timing analysis ofthe MCU leading to simultaneous failures in the MCU modules).According ISO/DIS 26262, hardware random failures can be fur-ther d
39、ivided using the model given in Fig. 3.A single point fault is a fault in an element which is not coveredby a safety mechanism and where the fault leads directly to theviolation of a safety goal.A residual fault is a portion of a fault which by itself leads to theviolation of a safety goal, occurrin
40、g in a hardware element, wherethat portion of the fault is not covered by existing safetymechanisms.Fig. 1. Structure of the safety requirements.Fig. 2. Abstract view of a MCU.1322M. Bellotti, R. Mariani/Microelectronics Reliability 50 (2010) 13201326A multiple point fault is one fault of several in
41、dependent faultsthat in combination, leads to a multiple point failure (either per-ceived, detected or latent). In particular, a latent fault is a multiplepoint fault whose presence is not detected by a safety mechanismnor perceived by the driver.The intention of the identification of multiple point
42、 faults is notto require a systematic analysis of every possible combination of 2or more hardware faults but at least to consider combinations thatderives from the safety concept (for instance the combination of 2faults where one fault affects a safety-related element and anotherfault affects the co
43、rresponding safety mechanism intended toachieve or maintain a safe state).A safe fault is a fault whose occurrence will not significantly in-crease the probability of violation of a safety goal.3.1.1. Requirements on failure classesIn relation with the previous defined failures, the ISO/DIS 26262def
44、ines the following requirements:? HW random failuress Requirements for HW architectural metrics (single pointfaults metric and latent faults metric).s Requirements for probability of violation of the safety goal.? Dependent failuress Qualitative requirements for dependent failures.? Systematic failu
45、ress Requirements for avoidance of systematic failures duringMCU design, development and production.3.2. ISO/DIS 26262 HW architectural metrics and probability ofviolation of the safety goalThe aim of HW architectural relative” metrics is to be objec-tively assessable: metrics are verifiable, unambi
46、guous, reproduc-ibleandpreciseenoughtodifferentiatebetweendifferentarchitectures. They support evaluation of the final design (the pre-cise calculations are done with the detailed hardware design) andin particular they reveal whether or not the coverage of the safetymechanisms, to control hardware f
47、aults in the architecture is suf-ficient. Moreover, being computed as ratio between failure rates,they are robust concerning uncertainty of hardware failures rates.The most important HW architectural metric is the SinglePoint Fault” metric (SPF metric). This metric reflects the robustnessof the item
48、 to single point faults either by coverage from safetymechanisms or by design (primarily safe faults). A high single pointfaults metric implies that the proportion of single point faults andresidual faults in the hardware is low. The definition is given by thefollowing equation:SPFault metric 1 ?PSa
49、fety related HW elementskSPF kRFPSafety related HW elementskPSafety related HW elementskMPF kSPSafety related HW elementsk1where kSPF, failure rate associated to hardware element single pointfaults; kRF, failure rate associated to hardware element residualfaults; kMPF, failure rate associated to hardware element multiplepoint faults; kS, failure rate associated to hardware element safefaults; with k = kSPF+ kRF+ kMPF+ kS.For ASILD, this metric shall be 99%. A similar metric is definedfor latent faults with the aim to emphasize the robustness of theitem to latent faults either by coverage of f
