Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 71
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
OCR for page 72
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 As discussed in Chapter 2, brake hydraulics are split so that typically the left front and right rear 1 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. The following 17 OEMs and their major divisions sell an appreciable number of automobiles in North 2 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.
OCR for page 73
73 Safety Assurance Processes for Automotive Electronics || 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
OCR for page 74
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
OCR for page 75
75 Safety Assurance Processes for Automotive Electronics || 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.
OCR for page 76
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
OCR for page 77
77 Safety Assurance Processes for Automotive Electronics || 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
OCR for page 78
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
OCR for page 79
79 Safety Assurance Processes for Automotive Electronics || 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 The throttle plate also contains two springs that automatically return it to a semiclosed position (suf- 3 ficient for idle) when not commanded to be opened further.
OCR for page 80
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 A more detailed description of FMEA and other safety analysis techniques used in the automotive 4 sector is given by Woltereck et al. (2004).
OCR for page 81
FIGURE 3-2 Safety analysis during vehicle design, development, and production. (Source: Sundaram and Hartfelder 2011.)
OCR for page 88
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. Examples from the automotive software field are Motor Industry Software Reliability 1 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.
OCR for page 89
89 Safety Assurance Processes for Automotive Electronics || 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). A review of automotive software safety assurance processes and standards is given by Czerny et al. 5 (2004).
OCR for page 90
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), h ttp://www.nhtsa.gov/DOT/NHTSA/Rulemaking/Rules/Associated%20Files/EDRFinalRule_ 6 Aug2006.pdf.
OCR for page 91
91 Safety Assurance Processes for Automotive Electronics || 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 The EU and Japan impose certain safety assurance process requirements on automobile manufactur- 7 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.
OCR for page 92
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.
OCR for page 93
93 Safety Assurance Processes for Automotive Electronics || 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 Joseph D. Miller, Chief Engineer, Systems Safety, TRW, and Automotive Member of ISO TC22 SC3, 8 Working Group 16, briefed the committee during its meeting on November 16, 2010.
OCR for page 94
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.
OCR for page 95
95 Safety Assurance Processes for Automotive Electronics || 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.
OCR for page 96
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.
OCR for page 97
97 Safety Assurance Processes for Automotive Electronics || 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.
OCR for page 98