Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
3 Safety Assurance Processes for Automotive Electronics The automotive industry is customer-driven, and each original equip- ment manufacturer (OEM) designs its new vehicles and their features to meet customer demands for various attributes such as comfort, styling, fuel economy, safety, and reliability. All product design and development decisions are also influenced by anticipated product development, man- ufacturing, and warranty costs and by the need to comply with federal emissions, fuel economy, and safety standards. Beyond these generaliza- tions, the specifics of product development differ by automotive manu- facturer. Each OEM and supplier views its product development processes as proprietary, giving it a competitive advantage by facilitating innova- tion, enabling smoother integration of procured components, managing costs, and increasing product reliability. Despite the many differences in their product development practices, OEMs share similar philosophies on how to ensure the reliable perfor- mance of their products. For the most part, they follow processes during product design, engineering, and manufacturing intended to ensure that products perform as expected up to defined failure probabilities, and performance is verified through testing and analysis. As preparation for the possible failure of critical components, all manufacturers have estab- lished failure monitoring and diagnosis systems that are likewise tested. When a failure is detected, these systems are designed to implement pre- defined strategies to minimize the harm. For example, they may notify the driver through a malfunction dashboard light, shut off the failed 71
72 || The Safety Promise and Challenge of Automotive Electronics system if it is nonessential, or command a reduction in engine power to avoid stranding the motorist and to enable the vehicle to âlimp homeâ for repair. Only certain safety-critical features, such as brakes, which must remain operational at all times, consist of independent redundant systems.1 The Federal Motor Vehicle Safety Standards (FMVSSs) administered by the National Highway Traffic Safety Administration (NHTSA) require that vehicles have certain safety features and characteristics, such as brakes, air bags, and crush resistance. Each manufacturer must certify their presence in the manufacturerâs vehicles and their compliance with the minimum performance capabilities prescribed in each FMVSS. Some FMVSSs mandate redundancyâmost notably for brakingâbut none specifies how any capability should be provided through specific system designs. An overview of the FMVSSs is provided in Chapter 4. These regula- tions do not prescribe the coverage, content, or ordering of activities that manufacturers must follow in designing, engineering, and manu- facturing their products, including any that are intended to meet an FMVSS. Thus, NHTSA does not prescribe or certify the use of specific design approaches, materials, safety analysis tools, testing protocols, or quality assurance methods to reduce the potential for failures or to min- imize their impactâfor example, by demanding the use of protective shielding, dual memory locations, corrosion resistance, or diagnostic and fail-safe strategies. Because automobile manufacturers have wide lati- tude to choose their own product designs, architectures, and materials, they are left with the responsibility to devise the most appropriate analy- sis, testing, monitoring, and fault response strategies. The proprietary nature of automotive development, coupled with the large number of manufacturers selling vehicles in the United States,2 leads to difficulty in assessing how each manufacturer seeks to ensure the safe performance of its electronics systems and how diligently each 1 As discussed in Chapter 2, brake hydraulics are split so that typically the left front and right rear wheels use half the system and the right front and left rear wheels use the other half. If one system fails, the other will provide degraded but balanced braking. 2 The following 17 OEMs and their major divisions sell an appreciable number of automobiles in North America: Toyota (Lexus, Scion), General Motors (Buick, Cadillac, Chevrolet, GMC), Chrysler (Chrysler, Dodge, Jeep, Ram), Volkswagen (Porsche, Audi, Bentley), Ford (Lincoln), Hyundai/Kia, Honda (Acura), Nissan (Infiniti), Fiat (Fiat, Lancia, Ferrari, Maserati), Suzuki, Subaru, Daimler (Mercedes- Benz, Smart, Orion), BMW (BMW, Mini, Rolls Royce), Mazda, Mitsubishi, Jaguar/Land Rover, and Volvo.
Safety Assurance Processes for Automotive Electronics || 73 carries out these processes. Nevertheless, the committeeâs visits with four major OEMs and a top supplier, consultations with experts from the automotive industry, and literature reviews suggest that automotive manufacturers follow many similar processes intended to ensure a reliable and safe product. The common elements of the processes are described in the first section of this chapter. After these assurance processes are described, consideration is given to industry-level standardization efforts that are intended to aid manu- facturers in improving their assurance methods for meeting new and changing challenges arising from electronics systems. In particular, the pending International Organization for Standardization (ISO) Standard 26262 is discussed. This voluntary standard is intended to guide OEMs and their suppliers as they devise and follow their own processes for identifying, prioritizing, and minimizing risks associated with safety- related electronics systems. As of this writing, the final draft of ISO 26262 was being decided by ballot, and hence its use and influence remain uncertain. Automotive manufacturers already have much at stake in ensuring the safe and dependable performance of their products because of litigation, warranty claims, and loss of brand image and sales. The ISO standard is discussed because it demonstrates the apparent recognition within the automotive industry of the special assurance challenges aris- ing from electronics systems. This standard-setting activity may also pre- sent an opportunity for NHTSA to gain a stronger understanding of the means by which automotive manufacturers seek to ensure the safe and secure performance of their vehicles. The chapter concludes with a summary of key findings from the dis- cussion, which are referred to later in the report to support the commit- teeâs recommendations to NHTSA. Safety aSSurance PracticeS in the automotive induStry The following description of how automotive manufacturers carry out safety assurance during product design, engineering, and manufactur- ing is not intended to be exhaustive. Most of the practices described are well known to practitioners, and more in-depth descriptions of each can be found in the cited literature. The purpose of the description is to inform those unfamiliar with the processes about the basic approaches
74 || The Safety Promise and Challenge of Automotive Electronics and strategies followed within the industry. The discussion explains how manufacturers (a) elicit and define product safety requirements; (b) design system architectures to include system monitoring, diagnostic, and fail-safe strategies; (c) use safety analysis tools during product design and engineering; (d) test and verify system and component designs; (e) validate system conformance to safety requirements; and (f ) monitor for and learn from issues that arise in the field. Taken together, these approaches and strategies make up the product safety assurance pro- cesses that are referred to often in this report. Eliciting and Defining Product Safety Requirements All automotive manufacturers must comply with government regula- tions such as the FMVSSs. In addition, the manufacturers have internal product requirements that include the OEMâs own quality and perfor- mance expectations. For example, an OEM will define the core require- ments associated with each vehicleâs make or product line. Many vehicle performance requirements, such as handling capabilities and ride quality attributes, differ by manufacturer and by product line, depending on the expectations of each vehicleâs customer base. Other requirements, such as those related to safety, may be universally followed by manufacturers for all their products. Consistent application of certain requirements within a product line enables the OEM to maintain brand image and reuse assets across models. The diversity of demands and expectations across product lines, however, leads to thousands of safety, quality, reli- ability, and performance requirements that guide manufacturer decisions governing the design elements, engineering, and material choices for their vehicles and constituent systems. Various manufacturer requirements relate to vehicle safety. First, nearly all products are subject to requirements ensuring that they will not inflict certain hazards on motorists and technicians, such as electric shock, fire, and toxicity. Some of these requirements are rooted in gov- ernment regulation, such as rules demanding flame-resistant seat cov- ers, while others are unique to the manufacturer. Second, certain vehicle systems are subject to additional requirements governing their ability to perform operational functions in a dependable manner. Among such systems are those allowing the driver to maintain visibility and vehicle control, such as wipers, brakes, steering, and external lighting. Government regulations often establish minimum performance capa- bilities for these safety-critical systems (for example, wipers being able to
Safety Assurance Processes for Automotive Electronics || 75 remove a volume of water from a windshield at a certain rate). Even in these cases, the OEM will have internal requirements specifying each systemâs expected dependability in providing the function, such as wipers working with a given degree of reliability under a range of plau- sible operating conditions. Finally, there are internal safety requirements concerning system interfaces and interactions with the driver. For the most part, govern- ment regulations do not prescribe design considerations such as the loca- tion of radio control buttons or the spacing of the brake and accelerator pedals. Accordingly, the manufacturer makes these design choices sub- ject to its own safety requirements. For example, the manufacturer may have a standard requirement that a radio control knob be located to avoid causing the driver to glance away from the road for more than a predetermined number of seconds. OEMs know that vehicles and systems that do not perform safely will become the subject of consumer complaints, warranty claims, law- suits, and possibly safety actions by NHTSA. Eliciting and defining these requirements before the design process begins are therefore central to the safety assurance processes of all manufacturers. To guide the design of safety-critical vehicle systems such as braking and steering, the OEM must be thorough in specifying what these systems should and should not do to keep the vehicle in a safe mode for all foreseeable uses and environmental conditions. Because conformance will need to be evalu- ated and validated at all stages of product development, these expecta- tions must be specific and well documented. The expectation that a system will never fail is generally avoided, since the ability of the system to meet this expectation cannot be verified. A major challenge faced by automotive manufacturers in defining these requirements is in recognizing how the system will be used by and interact with the driverâthat is, in identifying the human aspects of performance. For mature systems with an operational track record, knowledge of past uses and operating conditions can guide the specifica- tion of system safety requirements. For newer and more complex sys- tems, such information must be obtained with assistance from other means, including simulation and modeling, workshops with users, field tests by drivers, and consultations with specialists from other vehicle domains and engineering fields having similar systems. Examples of human factors challenges associated with advancements in vehicle elec- tronics are discussed in Box 3-1.
76 || The Safety Promise and Challenge of Automotive Electronics Box 3-1 human factors in the design of electronics Systems Even with the increasing role played by electronics and software in vehicle control functions, the driver remains the critical deter- minant of safe performance. Driver actions and inactions con- tribute to the majority of crashes and are most often labeled as the proximate causes. The label of driver error, however, can obscure the role that vehicle designs can play in crash causation if insufficient consideration is given to human capabilities and limits. The new capabilities of vehicle electronics promise to eliminate or mitigate some driver errors, but they risk introduc- ing new ones if drivers are not properly considered as integral to the vehicle system. The field of human factors engineering provides various stan- dards, guidelines, and test procedures to aid in the design of systems that are less likely to induce driver errors. These prac- tices apply to the physical layout of the vehicle to ensure that drivers can see, reach, and operate vehicle controls. For exam- ple, human factors practices guide the placement, width, and length of the brake and accelerator pedals to minimize pedal misapplication. Human factors practices also apply to the design of dashboard warning lights and control levers and buttons to ensure that drivers can easily interpret information and control critical vehicle systems. Traditional safety analysis tools such as failure mode and effects analyses (discussed below) help ensure that design choices are consistent with driver expectations and response tendencies. Increasingly, automotive manufacturers apply techniques that have been developed to make other consumer products user-friendly, such as user-centered requirements generation and usability testing. Their applicability is growing as vehicle electronics assume greater control of the vehicle through such features as adaptive cruise control, collision warning systems, lane-keeping aids, and automated braking systems. These and similar âmixed initiativeâ systems could cause the driver to
Safety Assurance Processes for Automotive Electronics || 77 Box 3-1 (continued) Human Factors in the Design of Electronics Systems misunderstand and be startled by the electronics even when the system is operating as designed. A major challenge for system designers is in understanding the long-term adaptation of the driver to the electronics and the degree to which the driver will assume that the vehicle is capable of certain control functions. For example, drivers might begin to believe that the vehicle carries out some control functions in a way that is inconsistent with the designersâ intent. Advances in driving simulators and instrumented vehicles are thus being developed to give human factors engineers new tools to assess and model how the driver and automotive electronics will inter- act. In this sense, automotive vehicles exemplify the mass adop- tion of the assisting or operating ârobot,â partnering with humans to ease or even take over the human workload. Diagnostics and Fail-Safe Strategies in Electronics Architecture All OEMs and OEM suppliers view their system architectures as propri- etary because the architectures provide the foundation for a multitude of design decisions that follow. For example, the vehicleâs embedded elec- tronics architecture, at a minimum, defines the electric components (power, sensors, controller units, actuators) on the vehicle. It maps every electronics-enabled feature to an electronic control unit or multiple units for distributed processing and establishes the communication protocols between the electronic components. These decisions are made with many requirements and constraints in mind, including the need to man- age production costs, accommodate changes such as the addition or removal of features, and use the architecture across multiple product lines. In the case of the embedded electronics architecture, such require- ments can influence decisions about whether to use central or distrib- uted processing and where to locate controllers in relation to sensors and actuators. Hence, during the development of this system architectureâwhen the basic system connections and relationships are establishedâimportant
78 || The Safety Promise and Challenge of Automotive Electronics decisions are made to ensure conformance with the defined safety requirements, including the strategies that will be used to monitor for and diagnose faults and to control their safety risks. Design and imple- mentation of self-diagnostics strategies occur during this phase. Onboard diagnostics are required by the U.S. Environmental Protection Agency (EPA) to facilitate maintenance and servicing of emissions control systems. However, these are minimum requirements and pertain to emissions-related systems only. OEMs have added many other diag- nostic capabilities into their electronics systems architectures for detect- ing, containing, and responding to faults in other systems, especially safety-related faults. Because each OEM uses its own diagnostic strategies (apart from the EPA-mandated elements), there is no single industry self-checking or diagnostic standard. Instead, there are overarching similarities in the approaches used. Diagnostics are performed during vehicle start-up and operation, and the driver is often unaware of the checks being per- formed. In general, diagnostic systems are designed so that when an error is sensed, a diagnostic trouble code (DTC) is recorded. Some DTCs are intended to aid technicians in making necessary repairs and adjust- ments to the vehicle. Others serve a supervisory, or âwatchdog,â func- tion that can force the system into a predefined state, such as causing the engine to shut down or operate at reduced power for limp-home capa- bility. Usually if a detected error is not indicative of a condition affecting vehicle drivability or safety, a DTC will be stored for a limited number of ignition key cycles, during which time it can be retrieved by a repair technician. Detected errors that indicate a problem with vehicle drivabil- ity or certain safety-related functions, such as the condition of an air bag, will set a DTC and be accompanied by a dashboard malfunction indicator light to inform the driver that the function has been disabled or the vehicle needs to be serviced. Detected errors that can adversely affect the ability of the driver to operate the vehicle safely will trigger a DTC as well as an immediate containment and fail-safe action. The exact methods used for detecting and diagnosing faults vary by manufacturer and system architecture and function. In the case of an electronic throttle control system (ETC), a common method for detect- ing faults or unusual behaviors is to use two independent sensors. A disagreement in the two sensor signals will trigger a DTC. Another fre- quently used method is to install a watchdog processor along with the main processor in a control unit. If the watchdog detects an abnormality
Safety Assurance Processes for Automotive Electronics || 79 FIGURE 3-1 ETC input and output flows. that escapes the main processor, it will set a DTC and force the system into a fail-safe mode. Figure 3-1 shows a simplified diagram of the fault detection strategies defined in an ETCâs architecture. The primary input to the ETC is the driverâs depression of the accelerator pedal. Two sensors in the pedal assembly measure the pedal position and send analog signals to digital converters, which send digitized values to the main processor. In addi- tion, the main processor receives signals from one or more sensors that measure the position of the throttle plate.3 If the signals from the two pedal sensors are inconsistent, the processor will trigger a DTC. A DTC will also be triggered if the signal from the throttle plate sensor is incon- sistent with the signals from the pedal sensors. Furthermore, incongru- ent actions by the main processor will cause the watchdog processor to trigger a DTC. The systemâs response to detected faults is defined in the architecture. In the case of faults in the ETC, the response differs according to the perceived severity of the condition. Depending on the strategy used, a DTC may cause the control unit to limit power so that the vehicle can only be driven slowly. More restrictive responses may be to force idle or to shut down the throttle motor, cut off the fuel supply, or stop the spark plugs from firing to render the vehicle inoperable. System designers 3 The throttle plate also contains two springs that automatically return it to a semiclosed position (suf- ficient for idle) when not commanded to be opened further.
80 || The Safety Promise and Challenge of Automotive Electronics must make determinations about the response strategy that is appropri- ate to the detected condition and its implications. Shutting off the engine, for example, may guarantee that the driver will tow the vehicle to a repair station, but it also can risk stranding a motorist, possibly in unsafe circumstances. Having carefully defined and well-articulated safety requirements can therefore guide developers of the ETCâs architecture in making choices about the most appropriate system response to a failure. Safety Analysis During System Design and Development Figure 3-2, adapted from a recent paper by General Motors engineers (Sundaram and Hartfelder 2011), shows how a number of analytic methods are used in an iterative manner by OEMs as part of the safety analysis conducted during product design, development, and produc- tion. There is no need to review each of the methods here, since the techniques are used widely in industry and are described thoroughly in the safety engineering literature. Nevertheless, because its use is noted elsewhere in this report, including the description of the analysis of Toyotaâs ETC by the National Aeronautics and Space Administrationâs (NASAâs) engineering team in Chapter 5, one method warranting discus- sion for illustrative purposes is failure mode and effects analysis (FMEA).4 FMEA was originally developed for military applications. It requires the participation of experts from multiple engineering disciplines and vehicle domains with broad knowledge of the requirements, functions, interfaces, and user actions of the system being analyzed. These teams are tasked with identifying (a) each key system feature and its function; (b) possible modes of failure for each of the functions; (c) the adverse effects that can arise from the failure; (d) failure symptoms and methods of detecting them; and (e) the means by which the failure and its adverse effects are prevented or managed by the system design, including the use of fail-safe mechanisms. An example of an abbreviated FMEA output, developed by NASA to examine Toyotaâs ETC, can be found in Table 5-5 of Chapter 5. An advantage of the FMEA process is that it enables the identification and cataloging of potential failure modes by likelihood and severity, allowing preventive actions to be taken early in the design process. A disadvantage is that it is not useful for examining multiple failure points 4 A more detailed description of FMEA and other safety analysis techniques used in the automotive sector is given by Woltereck et al. (2004).
FIGURE 3-2 Safety analysis during vehicle design, development, and production. (Source: Sundaram and Hartfelder 2011.)
82 || The Safety Promise and Challenge of Automotive Electronics and their effects at a system level. The statement of task for this study implicitly recognizes the challenges automotive manufacturers face in evaluating low-probability hazards by asking for a discussion of the âthe limitations of testing in establishing the causes of rare events.â Examples of these challenges are discussed below. The examples include exhaus- tively testing software for all conceivable anomalous behaviors and pre- dicting failure scenarios that involve coincidental faults occurring among multiple interconnected electronics systems. While even very rare fail- ure modes may arise in a fleet of tens of millions of vehicles operating under a wide range of conditions, anticipating and evaluating them is made more complicated by their intermittent nature and the potential for electronics-related faults to leave no physical trace of causes. For the most part, techniques such as FMEA work best for failures caused by random, wear-out phenomena and for problems arising in the individual system components rather than in their interactions. Thus, manufacturers use many other techniques to model and analyze failure processes in different ways and in combinations that show the causes of a certain event. Fault tree analysis (FTA), for example, is used to analyze how resistant systems are to both single and multiple initiating faults. In addition, because more complex electronics-intensive systems raise the possibility of more unanticipated failure combinations and sequences, manufacturers are using other tools to inform their safety analyses. Among them are computer models of the architectural structure and simulations that include the driver to aid in early identification of a large number of possible failure modes that may arise from system inter- actions and to assess their consequences (TÃ¶rngren et al. 2009). Improving data and methodologies for evaluating and testing for rare events remains a challenge for automotive manufacturers, as it does for manufacturers in other industries. Ideas on collaborative research by NHTSA and industry to address this challenge are offered later in this report (Chapter 6). Component Design and Verification Testing The design and engineering work for most vehicle subsystems and com- ponents is conducted by major suppliers. The scale and scope of supplier procurements have compelled OEMs to convey their needs and demands to suppliers in a multitude of ways. Among them are visual depictions of conceptualized systems and detailed specifications of components con- tained in formal requests for proposals. The exact procedures depend on
Safety Assurance Processes for Automotive Electronics || 83 the maturity and complexity of the products being procured and the relationship between the OEM and the suppliers. Like OEMs, suppliers want to keep their product architectures, designs, and development pro- cesses confidential to the extent possible, since they compete with other suppliers for OEM business. These transparency constraints can limit the depth of an OEMâs knowledge of a supplied component or subsystem design. It is thus common for OEMs to have a generic list of verification requirements for all supplier content as well as additional requirements tailored to the specific product under procurement. The supplier is usu- ally expected to provide a plan for verifying that its product conforms to all agreed-on specifications. Testing is the most common method of verifying that OEM specifica- tions have been met. Procurement contracts may identify hundreds of items requiring certain testing activities up to defined levels for different operating conditions and for various environmental stresses. For exam- ple, tests of resistance to dust, salt spray, water, thermal shock, and vibra- tions may be required. Durability test criteria for electronics hardware will usually simulate aging and associated degradation effects. OEMs and their suppliers also test for electromagnetic compatibility (EMC), as explained in Box 3-2. Many of the tests prescribed will reflect industry- wide and international standards [i.e., those of the Society of Auto- motive Engineers (SAE) and ISO], and others will be unique to the OEM. While suppliers are expected to do most of the testing, OEMs usu- ally inspect and then check results through acceptance methods ranging from hardware-in-the-loop simulations to testing of prototype and sam- pled products in their laboratories and proving grounds. Because sup- pliers of vehicle electronics systems have come to rely on commercial off-the-shelf hardware that has already been tested and warranted for the demanding automotive environment, the need for additional sup- plier testing has been reduced in some cases. Indeed, the proliferation of standardized automotive hardware has made its supply much like that of a commodity, since all OEMs and suppliers have access to the same hard- ware components, from sensors and actuators to drive circuits and microprocessors. In general, automotive software development follows the same path as that described for automotive systems and components generally (TÃ¶rngren et al. 2009, 10-31). The establishment of software architec- ture, algorithms, and testing plans in accordance with the OEMâs require- ments is the primary responsibility of the supplier. Since most software
84 || The Safety Promise and Challenge of Automotive Electronics Box 3-2 automotive emc testing EMC is commonly defined as the ability of equipment or a sys- tem to function satisfactorily in its electromagnetic environment without introducing intolerable electromagnetic disturbances to anything in that environment. There are two main aspects of the EMC challenge. The first, prevention, consists of controlling the generation of radiated and conducted electromagnetic emissions from electronic products and limiting disturbances produced by licensed transmitters. The second, referred to as EMC immunity, is to create products that can operate normally when they are exposed to anticipated electromagnetic environments. The U.S. government does not require EMC immunity for most industrial products. Federal regulations focus instead on controlling emissions and regulating transmitters, mainly so that radio and cellular operations are not disturbed. The absence of federal regulations on product immunity does not preclude com- panies from establishing their own product emissions and immu- nity requirements. Automobile manufacturers have long had to address the effects of electromagnetic interference. For example, short-pulse currents flowing on wiring from the distributor to the spark plugs produced high-frequency electromagnetic fields that disturbed AM radio reception. The problem was alleviated by replacing copper wires with resistive wiring to reduce the level of current flowing. Todayâs automobiles, of course, contain more electronics than radios, and thus many more systems and components that can both emit electromagnetic interference and be susceptible to it. In addition, the electromagnetic environment has changed, with more transmitters on board the vehicle (e.g., mobile phones) and located along the roadway. The automotive industry has come to rely substantially on company- and industry-level testing stan- dards for electromagnetic influences, including industry standards from ISO and SAE. During the committeeâs visits to OEMs, it found significant uniformity in the way EMC testing is performed.
Safety Assurance Processes for Automotive Electronics || 85 Box 3-2 (continued) Automotive EMC Testing In all cases, the OEMs require suppliers to perform and document electromagnetic tests on components and subsystems before the equipment is accepted, and in some cases the OEMs recheck the testing. Most suppliers use standard ISO and SAE test methods, with some adaptations to meet the specific demands of OEMs. These tests appear to consist of both radiated and conducted test- ing, including use of reverberation chambers. The OEMs require testing for both subsystems and complete vehicles, although typically the subsystem testing was at higher levels (approximately 30 V/m) than full vehicle testing. All per- form radiated testing of complete vehicles in semianechoic (and sometimes reverberation) chambers, with antennas set up out- side and near the vehicles to expose them to levels of electro- magnetic fields across the frequency band (up to about 2.5 GHz). The tests are typically performed for both horizontal and vertical polarization of the fields using side and front exposure angles. Some testing was also performed in a strip line to test at the lower frequency range. In some cases an automobile was exposed to a radar-type pulse. Testing was also performed with an electro- static discharge gun. used in the vehicle is contained in these procured subsystems and com- ponents, most vehicle software is developed in modular fashion by the suppliers themselves. Unlike hardware defects, all software deficiencies are by their nature design deficiencies rather than manufacturing flaws. Whereas various tools and techniques are used to check software for coding errors, defec- tive coding is not the only possible source of software-related errors, many of which will not be revealed in software having nontrivial com- plexity even with the most exhaustive testing regime. For example, test- ing cannot reasonably be expected to reveal how complex software will behave under all conceivable conditions, such as the variability that can occur in execution paths and timing of messages to and from the elec- tronic control units. The extent to which OEMs use effective software
86 || The Safety Promise and Challenge of Automotive Electronics engineering practices, such as requirements execution, model-driven design, model checking, and static analysis, is unclear, but such practices are increasingly warranted in light of the expanding role of embedded software. Adding new functions and features to vehicles, which is usually accomplished by adding software, increases software design complexity and complicates efforts to verify software correctness. As is noted in the description of NASAâs analysis of Toyotaâs ETC software given in Chapter 5, code structures can differ substantially in their ability to be inspected and verified as safe. For example, code that minimizes variable scope, the occurrence of cross-coupling, and intertask dependencies is more ame- nable to inspection and to obtaining assurance that implementation errors will be detected during execution. As automotive manufacturers integrate software developed during different time periods and by differ- ent suppliers, such verification can become even more important but more complicated and time-consuming. The challenges associated with software assurance are discussed further in Box 3-3. Software can be customized to a higher degree than can hardware, but a higher degree of customization makes the software even less ame- nable to standardized testing, at least in the same manner as off-the-shelf hardware. Each OEM and supplier can choose to customize software as much as it sees fit, and hence there is likely to be significant variability in the amount of customization in the automotive industry. The testing challenge associated with customized and complex software is recog- nized by the automotive industry. A partnership of leading automotive suppliers and OEMs, known as the Automotive Open System Architecture (AUTOSAR), is pursuing the development of a methodology for soft- ware and software architecture intended to provide an open and stan- dardized architecture. By rendering software designs more transparent and less proprietary, AUTOSAR is intended to facilitate at least some aspects of testing, such as performing tests for interoperability. Details cannot be given here on the objectives and progress of this partnership, but AUTOSAR is an example of how the automotive industry is cooper- ating to manage the growing complexity of electronics systems and the software underlying them. Validating Conformance Validationâdetermining what the hardware and software should do and that they are doing it correctlyâis more difficult than verification
Safety Assurance Processes for Automotive Electronics || 87 Box 3-3 challenges of Software assurance As described in Chapter 2, software is involved in monitoring and controlling most safety-critical vehicle components such as the brakes, engine, steering, and air bags, as well as in enabling many safety features such as lane departure warning and blind spot monitoring. Software is also used throughout the vehicle for non- safety-related systems. The array of software is responsible not only for providing expected functionality under nominal condi- tions but also for detecting abnormal or degraded behavior in hardware components and responding in a safe way. Software assurance, therefore, is intended to ensure that safety-critical systems (a) perform as expected under nominal conditions; (b) respond appropriately to hardware failures, both intermittent and permanent; and (c) do not exhibit unsafe behaviors under any circumstances. In the field of software development, a number of industry- wide standards outline assurance processes to be followed during development, including standards specific to automotive soft- ware.1 These standards describe various assurance activities and steps to be followed during development and for verification and validation. They cover reviews of requirements, architecture, and design; analyses of failure modes and effects; code inspec- tions; and software-in-the-loop laboratory testing. However, even the most rigorous adherence to a process standard cannot guarantee software safety and dependability. Part of the prob- lem is that the huge state space managed by software renders testing ineffective for providing confidence at high levels, since testing can cover only a small proportion of the scenarios that can arise in practice from complex software. Furthermore, because the software components of a complex electronics sys- tem are inevitably mutually dependent, a critical function may be undermined by the failure of a software component thought to be noncritical and thus not subject to the same testing and development processes called for in the standard. (continued on next page)
88 || The Safety Promise and Challenge of Automotive Electronics Box 3-3 (continued) Challenges of Software Assurance In recognition of these software assurance challenges, new analysis techniques intended to provide stronger evidence than does testing are under investigation. Two such techniques are formal methods, which involve the use of powerful algorithms to cover large state spaces more readily than does testing alone, and model-based design, in which software implementations are generated automatically from precise, high-level models. In addi- tion, an approach to software assurance that is attracting atten- tion (especially in Europe)âand that is recommended in a recent National Academies report (NRC 2007)âcalls on the developer not only to follow development process standards but also to construct âassurance casesâ that make explicit the argument that the system is dependable or safe and marshal evidence for soft- ware users in evaluating the safety argument objectively. 1 Examples from the automotive software field are Motor Industry Software Reliability Association guidelines and the pending ISO 26262 functional safety standard. Examples from defense and aviation are RTCA-178B and MILâStd-882C/D. testing in many ways. Because supplier-provided subsystems and com- ponents may be in various stages of design, development, or maturity at any given time, the conduct of vehicle-level validations of systems in a timely manner can be difficult. Yet identifying problems late in vehicle development is undesirable, since such flaws can be costly to correct (though less costly than correcting problems arising in use). The com- mittee could not confirm the validation techniques used within the industry generally and thus cannot know the extent to which OEMs exploit many new tools and processes, such as computer-aided software engineering tools. Use of these tools can allow validation through com- puter simulations rather than through physical prototype testing, which can lead to fewer costly problems that are discovered late in product development. Computer-aided hardware- and human-in-the-loop sim- ulations, for example, allow for analysis of softwareâhardware compat- ibility and driver usability.
Safety Assurance Processes for Automotive Electronics || 89 One problem that may be found during validation of supplier- provided software is that the software does not satisfy OEM-stipulated requirements and thus does not perform as intended. In view of this possibility, OEMs are often most interested in the quality of the soft- ware development process that was carried out, including the extent of adherence to development process standards as discussed in Box 3-3. Accordingly, the traditional method for validating software includes checking for conformance to standardized processes (e.g., through audits) and carrying out a complementary mix of evaluation methods.5 One of these evaluation methods may be for the supplier to specify the assumptions about requirements and to present evidence that the soft- ware will behave in a manner that meets them, perhaps by the use of example application scenarios. Another issue that can arise is that the requirements themselves are incorrect or incomplete, so that even if the software functions as specified, the resultant actions may not be satisfactory or safe (Howard 2004). To ensure that requirements elicita- tion is sound, executable requirement models that enable automated code generation and requirements validation to occur concurrently are becoming available. However, the committee could not confirm the extent to which OEMs and suppliers use these methods. All OEMs conduct testing of vehicles on test tracks and on public roads. Manufacturers often instrument vehicles to log more detailed information on the operation of the vehicle, including the interaction of the electronics systems in the vehicle. Objective and subjective data from such testing are gathered and analyzed for unexpected system and driver behaviors, which may reveal needed product changes. While such full vehicle evaluation is essential, it can occur too late to resolve major issues such as observed qualitative changes in the driving experience resulting from a new technologyâs interface or capability. The validation activities instituted earlier during product design and development, as described above, are intended to identify and resolve such issues long before they arise during road testing. Road tests can nevertheless clarify the need for incremental modifications to the product and enable system calibration (Conrad and Fey 2009, 11-2). 5 A review of automotive software safety assurance processes and standards is given by Czerny et al. (2004).
90 || The Safety Promise and Challenge of Automotive Electronics Field Analysis If safety or quality problems emerge in customer vehicles despite attempts to prevent them, surveillance and analysis of issues arising in the field are critical in resolving the problems quickly and preventing their recur- rence in future designs. To facilitate such surveillance, OEMs have access to warranty repair, field report, and parts data obtained from dealers, including returned parts from warranty repairs. OEMs also log complaints from vehicle owners through their service centers and have access to NHTSAâs consumer complaint data. All manufacturers are strongly moti- vated to support active field monitoring and analysis programs: they have an immediate interest in preventing costly litigation and recall campaigns and a longer-term interest in making product improvements and decreasing warranty expenses. As discussed in Chapter 2, many OEMs have equipped their vehicles with electronic event data recorders (EDRs), originally for monitoring the effectiveness of air bag deployments in crashes. The data saved in these devices are not necessarily available to the OEM, since it does not own the crashed vehicle. Nevertheless, to obtain EDR data, NHTSA and other investigators can require the cooperation of the OEM if the tech- nology for downloading and interpreting the saved data is only available to the manufacturer. Ownership of the data recorded in EDRs is a legal issue with considerable impact on the utility of EDRs for these investiga- tive purposes. In a 2006 rulemaking that required certain common data elements in vehicles equipped with EDRs, NHTSA gave extensive con- sideration to the privacy issues associated with EDRs, acknowledging that the resolution of these issues will affect the value and practicality of mandating EDRs on all vehicles.6 As discussed in Chapters 4 and 6, NHTSA is considering requiring EDRs on all new vehicles, although the privacy and data ownership issues are outside its regulatory purview. induStry StandardS activitieS for electronicS Safety aSSurance Compared with the United States, many other countries with large automotive industries give their manufacturers less leeway to define all aspects of their safety assurance processes. The European Union (EU), 6 http://www.nhtsa.gov/DOT/NHTSA/Rulemaking/Rules/Associated%20Files/EDRFinalRule_ Aug2006.pdf.
Safety Assurance Processes for Automotive Electronics || 91 for example, requires that manufacturers selling automobiles in mem- ber countries demonstrate that they have performed certain tests and followed specified processes during vehicle design, development, and production. Compliance with EMC testing standards is part of the EU certification process.7 EU regulators also require that manufacturers take certain steps during product development and design, such as con- ducting safety analyses by using FMEAs and FTAs. To have their vehicle types certified by a member EU country, the OEM must present evi- dence, usually to independent auditors, confirming that all such steps were satisfied. Because government review and certification of product safety assur- ance are more common in Europe, various industry-led standards-setting bodies have developed guidance for manufacturers. In the area of electronics systems safety assurance, an influential standard is the International Electrotechnical Commission (IEC) standard IEC 61508 (Functional Safety of Electrical/Electronic/Programmable Electronic- Related Systems). It provides guidance on processes to ensure that safety- critical electronics work as intended. The standard calls on manufacturers who subscribe to it to take systematic steps to identify all possible ways in which the product could stop functioning as required to perform its safety-critical functions during its entire lifetime of use. Manufacturers who subscribe to the standard are expected to identify each potential hazard situation systematically and calculate its probability of occurrence with adverse consequences to assign a âsystem integrity levelâ (SIL). The higher the assigned SIL, the more rigorous the safety assurance mea- sures that must be carried out to ensure that the risk of the adverse con- sequence does not exceed âtolerableâ levels. Since its introduction more than 10 years ago, IEC 61508 has induced the creation of a number of industry-specific standards for functional safety, including those for machinery, chemical processing, and nuclear power plants. Various guidance documents that are intended to help 7 The EU and Japan impose certain safety assurance process requirements on automobile manufactur- ers as part of vehicle type certification. In the EU, Framework Directive 2007/46/EC for automotive type approval lists more than 50 separate topics for approval of the whole car, plus other requirements that apply to components. The directive requires OEMs to obtain third-party approval testing, certifi- cation, and production conformity assessments, such as for EMC. If the vehicle prototype passes the required tests and the production arrangements pass inspection, vehicles or components of the same type are approved for production and sale within the EU without further testing of individual vehi- cles. For more details see http://www.vca.gov.uk/vca/additional/files/vehicle-type-approval/vehicle- type-approval/vca004.pdf.
92 || The Safety Promise and Challenge of Automotive Electronics Box 3-4 functional Safety methodology for electromagnetic influences IEC 61508 requires that consideration be given to all of the envi- ronments that could result in an unsafe situation for the subject product. These environments may include shock, vibration, tem- perature, and electromagnetic fields and their induced voltages and currents. Industry testing standards for EMC are usually established for product reliability purposes. For example, the tests may be designed to ensure that the product will operate reli- ably 95 percent of the time for a given period. More sophisticated testing to ensure a lower incidence of failure over the entire product life cycle may be demanded for products having critical safety-related functions. Thus, IEC has offered guidance, in IEC 61000-1-2, on how to consider electromagnetic influences on functional safety. The guidance emphasizes that while electro- magnetic testing remains important for functional safety, the design of the product to avoid electromagnetic influences is para- mount. The standard also emphasizes the importance of the product being designed and tested to ensure that it operates safely during its entire life cycle, which is not required for stan- dard (nonsafety) EMC applications. An additional IEC publi- cation, IEC 61000-2-5 (Classification of the Electromagnetic Environment), provides a survey of the levels of various types of radiated and conducted electromagnetic disturbances present in different locations (including typical and worst case). manufacturers meet the standardâs requirements have been developed. Box 3-4 gives an example of the IEC-approved methodology for address- ing EMC for functional safety. Although automotive manufacturers can follow the guidance of IEC 61508, until recently they have not had an industry-specific standard for ensuring the functional safety of vehicle electronics. Such a standard is now pending, developed by the automotive industry through ISO.
Safety Assurance Processes for Automotive Electronics || 93 ISO 26262, Road Vehicle Functional Safety, is intended to apply to all safety-related automotive systems, but with an emphasis on electronics. Industry interest in developing the standard originated from the recogni- tion that the proliferation of electronics systems in vehicles was intro- ducing greater complexity into both automotive systems and their development processes. Developers of ISO 26262 expect that it will lead to manufacturer safety assurance practices that are more transparent and consistent in analytical rigor. Like the IEC standard it is modeled after, it calls for man- ufacturers to assign automotive safety integrity levels (ASILs) to vehicle systems or functions with corresponding rigor in the safety assurance steps followed. In so doing, it draws attention to the importance of using many of the safety assurance processes discussed earlier in this chapter. Among those processes are eliciting safety requirements, using safety analysis tools such as FMEAs and FTAs, and monitoring for safety per- formance in the field. To make safety assurance a prominent and trans- parent part of product development, ISO 26262 emphasizes formal management review of and sign-off on key safety-related decisions at all stages of product planning, development, verification, and validation. The general structure of ISO 26262 is outlined in Box 3-5. Because of its pending approval status, whether all automotive manu- facturers selling vehicles in the United States will subscribe to ISO 26262 in whole or in part is unknown. Many automotive manufacturers and suppliers have indicated their intention to follow the standard, includ- ing some that met with the committee. A U.S. member of the team responsible for drafting the standard explained to the committee that even companies that already carry out many of the safety assurance processes necessitated by the standard are likely to experience transi- tional challenges because of the implications for organizational struc- ture and requirements for new work products and documentation.8 From the standpoint of many proponents of ISO 26262, one of its early benefits may be to prompt organizational-level scrutiny of long-standing practices and processes through a review of their actual safety assurance contributions. ISO 26262 merits discussion because it represents an industry-led effort to ensure that vehicle electronics systems continue to perform safely as 8 Joseph D. Miller, Chief Engineer, Systems Safety, TRW, and Automotive Member of ISO TC22 SC3, Working Group 16, briefed the committee during its meeting on November 16, 2010.
94 || The Safety Promise and Challenge of Automotive Electronics Box 3-5 General Structure of iSo 26262 Automotive manufacturers and suppliers from Europe, Asia, and North America have participated in the development of ISO 26262. The draft standard consists of 10 parts. Part 1 contains a vocabulary to describe the elements of a system and their rela- tionships, and Part 2 contains overall guidance on safety man- agement. The core parts of the standard consist of the following: Part 3: Concept phase. This part contains guidance on (a) identi- fying items subject to the standard; (b) analyzing use situations and identifying potential hazards associated with each situation; (c) carrying out hazard classifications, including determining the ASIL associated with each item; and (d) determining safety requirements and goals. Parts 4, 5, and 6: Product development at the system level and at the hardware and software levels. These parts contain guidance on (a) specifying the technical safety requirements at the system, hardware, and software levels; (b) defining the design and archi- tecture metrics for each level; (c) evaluating and integrating test- ing; and (d) validating and confirming functional safety before release of the design for production. A standard âVâ model is used to sequence the work products and reporting requirements for each activity. Part 7: Production and operation. Because ISO 26262 is a life-cycle standard, this part provides guidance for ensuring that the func- tional safety is achieved during production through planning measures (e.g., implementation of traceability measures), main- tenance and repair actions, and processes for field monitoring. Parts 8, 9, and 10: Supporting processes. These parts include guid- ance on performing hazard analyses and risk assessments to determine ASILs [ASILs range from A (lowest) to D (highest)]. On the basis of these analyses, the manufacturer can tailor the necessary activities according to each itemâs ASIL. Source: Briefings to the committee by Joseph D. Miller, TRW Automotive Member ISO TC22 SC3, Working Group 16.
Safety Assurance Processes for Automotive Electronics || 95 they grow in complexity and functionality and because adherence to the standard may bring about greater confidence among safety regulators and the public. Whether the confidence will be justified on the basis of the standardâs influence on industry practices and safety outcomes cannot be assessed at this time. chaPter findinGS Finding 3.1: Automotive manufacturers visited during this studyâand proba- bly all the othersâimplement many processes during product design, engineer- ing, and manufacturing intended (a) to ensure that electronics systems perform as expected up to defined failure probabilities and (b) to detect failures when they occur and respond to them with appropriate containment actions. Each manu- facturer is responsible for devising its own safety assurance approaches. Each is responsible for choosing the most appropriate risk and failure analysis techniques, material and manufacturing quality control pro- cesses, and means for verifying and validating performance to acceptable failure rates. In addition, each designs and verifies its strategies for safety in the event of a failure. Measures aimed at preventing faults may not succeed under all circumstances. Therefore, a common strategy for detecting and responding to their occurrence in ETCs is through the use of two independent pedal position sensors, two springs to return the throttle to semiclosed position, a second processor to supervise the actions of the main processor, and a series of programmed fail-safe responses that are triggered in the event of a failure, including shutdown of the engine or restriction of its power. Finding 3.2: Testing, analysis, modeling, and simulation are used by automo- tive manufacturers to verify that their electronics systems, the large majority of which are provided by suppliers, have met all internal specifications and regu- latory requirements, including those relevant to safety performance. Manufac- turers and their suppliers seek to verify the proper performance of their electronics hardware at the component, system, and vehicle levels. Manufacturers reported recognition that even the most exhaustive software testing regimes and strict adherence to software development prescriptions cannot guarantee that complex software will behave safely under all plausible circumstances.
96 || The Safety Promise and Challenge of Automotive Electronics Finding 3.3: Manufacturers face challenges in identifying and modeling how a new electronics-based system will be used by the driver and how it will interface and interact with the driver. All manufacturers visited reported that they engaged experts in human factors early in the design of their new elec- tronics systems and throughout the later stages of product development and evaluation. Finding 3.4: Automotive manufacturers have been cooperating through ISO to develop a standard methodology for evaluating and establishing the func- tional safety requirements for their electronics systems. The pending standardâ ISO 26262, Road Vehicle Functional Safetyâoriginated from recognition within the automotive industry that the proliferation of electronics sys- tems in vehicles is introducing greater complexity into both automotive systems and their development processes. Final approval of the standard is pending but expected in early 2012. Whether all automotive manufac- turers and suppliers selling vehicles and components in the United States will subscribe to ISO 26262 in whole or in part is unknown at this time; however, many companies have signaled their intention to follow the standardâs guidance for safety assurance practices that are more trans- parent and consistent in analytical rigor. referenceS Conrad, M., and I. Fey. 2009. Testing Automotive Control Software. In Automotive Embedded Systems Handbook (N. Navet and F. Simonot-Lion, eds.), CRC Press, Boca Raton, Fla. Czerny, B. J., J. G. DâAmbrosio, P. O. Jacob, B. T. Murray, and P. Sundaram. 2004. An Adaptable Software Safety Process for Automotive Safety-Critical Systems. SAE Paper 2004-01-1666. http://ja.delphi.com/pdf/techpapers/ 2004-01-1666.pdf. Howard, J. 2004. Preserving System Safety Across the Boundary Between System Integrator and Software Contractor. SAE Paper 2004-01-1663. Presented at Society of Automotive Engineers World Congress and Exhibition, Detroit, Mich., March. NRC. 2007. Software for Dependable Systems: Sufficient Evidence? Computer Science and Telecommunications Board, Division on Engineering and Physical Sciences, National Academies Press, Washington, D.C. http://www.nap.edu/ catalog.php?record_id=11923. Sundaram, P., and D. Hartfelder. 2011. Rigor in Automotive Safety Critical System Development. Presented at 29th International System Safety Conference, Las Vegas, Nev., Aug. 8â12.
Safety Assurance Processes for Automotive Electronics || 97 TÃ¶rngren, M., D. Chen, D. Malvius, and J. Axelsson. 2009. Model-Based Development of Automotive Embedded Systems. In Automotive Embedded Systems Handbook (N. Navet and F. Simonot-Lion, eds.), CRC Press, Boca Raton, Fla. Woltereck, M., C. Jung, and G. Reichart. 2004. How to Achieve Functional Safety and What Safety Standards and Risk Assessment Can Contribute. SAE Paper 2004-01-1662. Presented at Society of Automotive Engineers World Congress and Exhibition, Detroit, Mich., March.