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
