Software Safety Assurance Processes and
Challenges in the Automotive and Aviation Industries
National Geographic, 2002 GM Autonomy HAZARD 1 Q=6e-7 Event that could lead to an accident HAZARDOUS EVENT 1 Event that could lead to a hazard r=6e-008 Q=0.0006 HAZARD CONTROL 1 Control to prevent HAZARDOUS EVENT 1 Q=0.001 Q=0.001Dr. Brian Murray
March 4, 2011
United Technologies
aerospace
systems
aerospace
systems
power
solutions
power
solutions
building
systems
building
systems
UTC Power
UTC Power
Otis
Otis
UTC Fire
UTC Fire
& Security
& Security
Hamilton
Hamilton
Sundstrand
Sundstrand
Sikorsky
Sikorsky
Carrier
Carrier
Pratt & Whitney
Pratt & Whitney
Brief Bio Brian Murray
Education
1982 – Albion College, BA physics and mathematics
1984 – Duke University, MSEE, IC manufacturing
1994 – University of Michigan, Ph.D., computer engineering
25 years in automotive industry, 1.5 years United Technologies Research
Center (aerospace and buildings)
Auto industry
General Motors and Delphi Corp.
Researcher IC design tools, especially for testing
Project manager future engine controller architecture
Project manager for system safety process development
Manager systems engineering for drive-by-wire, including embedded
systems
Manager advanced vehicle dynamics and active safety
Manager system safety for electric power steering
Currently
Manager embedded systems and networks UTRC
Principle investigator investigating design of complex systems
Professional (Relevant)
Safety-Critical Systems Session organizer/session chair, SAE
Congress, 10 years
Outline
Views of system safety
Safety-critical systems in the automotive
industry
Some comparisons of system and software
safety standards
Some comparisons of automotive and
aerospace systems
Addressing safety issues of active safety
systems
Future of design for complex systems
What is System Safety?
What are Safety-Critical Systems?
Any system with the potential to cause harm
A system defined both by what it is supposed to do and by what it is
NOT supposed to do
System Safety is the application of systems engineering principles to
ENABLE
the development of safety-critical systems by managing safety
risk
Concept
Product
in Service
Design Process
Functional Requirements
(What system is supposed to do)
Safety Process
Safety Requirements
What is System Safety?
Identify problems
Find a way to fix the problems Convincingly show that
Model for System Safety Theory & Practice
Safety-Critical
Systems
Safety
Cases
Safety
Concepts
Identify problems
Find a way to fix
the problems
Convincingly show that
Key Principles of System Safety
Risk is a function of the severity and likelihood of a mishap
Hazards are conditions that could lead to a mishap
Caused by failures or other conditions
Hazard Controls mitigate the risk of a hazard
Standards dictate how residual risk should be evaluated
Hazard avoidance goals must be captured as realizable engineering
requirements
Add Hazard
Controls
Risk
Acceptable?
No
Yes
Deploy
Identify
Hazards
Evaluate
Residual
Risk
Avoid
Hazards
System Safety (Safety Case View)
Safety Case
Evidence that safety requirements
are understood
Evidence that safety requirements
are met
Argument for acceptance of
residual risk based on the evidence
For all stakeholders– OEMs,
Suppliers, Society
System Safety Process
Sequence of tasks leading to the
development and acceptance of a safety case, usually involves:
Safety Requirements
Safety Concept
Safety Case
Resolution of stakeholder
requirements related to safety
Safety Case
Generic Safety
Process Steps
Customer
Requirements
Argument
Evidence
Evidence
System Safety (Process View – Work Products)
Preliminary Hazard Analysis Hazard Control Specifications (Diagnostics, Design Safety Margins, …) Safety Verification Safety Case System Safety Program Plan Hazard Control Specifications (Safety Requirements) Safety Concept & Detailed Hazard Analysis Conceptual Design Requirements Analysis Arch. Design Detailed Design Verification & Validation Production & Deploy.Other Dependability Attributes: Reliability and Availability vs Safety
Reliability focuses on reducing overall failure
probability
Availability focuses on maximizing up-time
Safety focuses on identifying and minimizing
risks associated with hazards and avoiding
mishaps
May identify controls for potential undesired effects rather than focus on causes
Still require credible scenarios
Safety may decrease reliability and availability
Diagnostics and shutdown mechanisms
Reliable systems may not be safe
Uncovered hazards in ultra-reliable systems may be severe
Serious accidents have occurred when all system components were functioning exactly as specified (without failure)
Safety programs prioritize concerns
With finite design time and resources, focus on issues of biggest concern first
Reliability Safety
Motivations for System Safety in the Automotive Industry
Inflation-adjusted price
of vehicles has
declined for several
years
Auto companies seek
to identify value-adding
features to gain price
as well as market
share
Safety, Energy,
Infotainment
Society more risk
averse over time
Reduction in deaths
and injuries due to
seat belts, etc. has
leveled off
Society
Drivers
Business
Drivers
Technology
Enablers
•
Solid-state cameras
•
Network communication
systems
•
Safety-critical computing
platforms
•
Actuators capable of
autonomous control
Cars Are
Safety-Critical Systems
Safety-Critical Chassis Systems Enable Active
Safety
Braking:
Electronic Stability Control Electric Brake by Wire
Rear Steering:
Active Rear Steer
Engine:
Torque Management
Front Steering:
Electric Power Steering
Active Front Steering Steer by Wire
Controlled Suspension:
Controlled Dampers Active Stabilizer Bar
Active Safety Path
In
c
re
a
s
in
g
s
y
s
te
m
a
u
to
n
o
m
y
Time
360° surround sensing & autonomous vehicle control
collision warning system collision avoidance system GPS/Maps Vehicle-to-Vehicle communication Intersection/Roadway Infrastructure Satellite-linked communication Stand-alone systems
Adaptive Cruise Control Lane/Roadway departure Side detection
Backup Aid ESC & RSE
Sensor-fusion Integrated Systems
Driver Support system
Collision warning & mitigation Pre-crash & mitigation
Lane-change assist Lane-keeping
Advanced Stability Control – Coordination of ESC and other chassis systems
Attributes of Automotive Systems
High expectations for quality
Less than 1 ppm 10yrs, 100,000 -> 20yrs, 250,000 -> Lifetime
Low expectations for maintenance
Efficiency
Engineers fight over inches of space and pennies of cost
Safety
In the US alone, the total vehicle miles traveled is measured in billions Around the world there are about 806
million cars and light trucks on the road
Goal: zero traffic deaths
Electronics market driver
Automotive market has not driven the electronics market since the 1980s
High production volumes and
user populations
In 2007, 71.9 million new
automobiles were sold worldwide
Large diversity of users
In countries with the highest growth, many people have never even driven cars
Complexity
Configuration complexity
Brands, models, dozens of controllers per vehicle System complexity
Until now moderate complexity
New active safety systems are rapidly growing in complexity
Attributes of Aerospace Systems
High expectations for safety
Focused on very low failure rates forcritical components, e.g., 10-9
Continuous maintenance
Efficiency
Engineers fight over inches of space but worry less about cost
Electronics market driver
Specialty electronics Driven to, but reluctant to use COTS
Very low production volumes
but high passenger
populations
Low diversity of users – only
highly trained pilots
Complexity
System Safety Standards & Guidelines
Regula-tions
Analysis
Mechanical
Electrical/
Electronics
Software
System/SW Safety Process
Reliability
MIL-Std-882C/D
DEF Std 00-56
SAE FMEA
VDA FMEA
NUREG
0492
FTA
FMVSS 135
ISO 26262
Mil-Hdbk-217
RDF 2000/UTEC 80810
MISRA
DO-178B
00-55
IEC 61508
One Page History of System Safety Standards in
Automotive
1990 – Motor Industry Software Reliability Association (MISRA)
publishes guidelines for safety-critical automotive software
Very influential, but not a safety process
1993 – MIL-STD-882C published – primary strategy for system
safety in US
1998 – MIL-STD-882C used within US automotive industry
1998 – IEC 61508 safety standard published
Very influential in Europe
Framework standard
Adopted by European vehicle manufacturers
July 2009 – Draft International Standard ISO 26262
June 2011 – Final DIS (FDIS) ISO 26262 expected
IEC 61508
IEC 61508 developed by IEC Industrial-Process Measurement
Committee
Equipment Under ControlEUC Control
System
Safety-Related
System
Equipment Under ControlEUC Control System &
Safety-Related System
Safety Functions
(A) Separate
Safety-Related System
(B) Integrated
Safety-Related System
Electrical/Electronic/Programmable Electronic System
Focus of
IEC 61508
ISO 26262 vs IEC 61508
IEC 61508:
Framework standard
Scope: functional aspects of
electronic, electrical and software systems
Implied context of
Process/Automation industries (where validation is done after install)
Safety Integrity Levels, “SIL”
SIL 1 – SIL 4
Focus on safety functions
Architectural metrics
Defines acceptable software process
elements according to SIL
ISO CD 26262:
IEC 61508 Automotive Sector adaptation
Brings in some concepts of
MIL-STD-882
Applies to passenger vehicles
Automotive SIL, “ASIL”
Expands SIL1-3 to four (ASIL A-D)
SIL4 not applicable
No top-level probability associated
with an ASIL
Focus on safety goals
Adds required work products
New architectural metrics
Defines acceptable software process
DO 178B vs ISO 26262
International: jointly developed by US RTCA SC-167 and the European
Organization for Civil Aviation Equipment (EUROCAE) WG-12
DO 178B
Provides guidelines for the production
of software for airborne systems and equipment
Design Assurance Levels – A-E
Increasing number of software process
objectives and independence with level
Highest level includes suggestions for
software coverage techniques such as MCDC
Addresses software requirements only
Focused toward suppliers of electronic
systems
Highly detailed but not prescriptive
Implies high degree of documentation
ISO CD 26262:
Focused on automotive industry
Automotive Safety Integrity Levels – A-D
Includes notion of controllability
Increasing number of software process
objectives with level
Highest level includes suggestions for
software coverage techniques such as MCDC
Addresses functional safety associated
with electronic controllers – hardware and software
Addresses both design faults in hardware
and software as well random failures in hardware
Addresses both OEM and supplier issues
Highly detailed – sometimes prescriptive
Proposed Automotive Active Safety System
Taxonomy and Examples*
System Classification Example Feature Driver Interaction Type Expected Driver
Responsibility Potential Safety Risk
Driver Information
Monitor / Supervise
Non Safety Related NA
Safety Related Rear back up camera No Monitoring /
No Supervision
Non Safety Related NA
Safety Related Engine Temperature
Driver Warning
Monitor / Supervise
Non Safety Related NA
Safety Related Rear back up alert No Monitoring /
No Supervision
Non Safety Related NA
Safety Related Red Brake Tell Tale Vehicle Action /
Control
Monitor / Supervise
Non Safety Related NA
Safety Related Lane Keeping System No Monitoring /
No Supervision
Non Safety Related NA
Emerging Guideline: PReVENT/RESPONSE 3
Project
European project to develop an Advanced Driver Assistance Systems Code of
Practice
CoP describes a methodology for evaluating and assessing interactions
between the driver (and vehicle occupants) and the system being controlled
Provides guidance to help ensure potential issues of concern are identified and
resolved during development
Coupling CoP and ISO 26262
CoP helps identify
safety-related requirements
26262 helps ensure safety
requirements are
implemented with high integrity
Helps ensure the safety-critical aspects of
active safety systems are handled appropriately
