Embed Size (px)
Citation preview
Software Safety Assurance Processes andChallenges in the Automotive and Aviation Industries
National Geographic, 2002
GM Autonomy
HAZARD 1Q=6e-7
Event thatcould lead to an
accident
HAZARDOUS EVENT 1
Event thatcould lead to a
hazard
r=6e-008Q=0.0006
HAZARD CONTROL 1
Control to preventHAZARDOUS
EVENT 1
Q=0.001Q=0.001
Dr. Brian MurrayMarch 4, 2011
United Technologies
aerospacesystemsaerospacesystems
powersolutionspowersolutions
buildingsystemsbuildingsystems
UTC PowerUTC Power
OtisOtisUTC FireUTC Fire& Security& Security
HamiltonHamiltonSundstrandSundstrand
SikorskySikorsky CarrierCarrier
Pratt & WhitneyPratt & WhitneyBusiness units
2
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 ResearchCenter (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
3
Outline
Views of system safetySafety-critical systems in the automotive
industrySome comparisons of system and software
safety standardsSome comparisons of automotive and
aerospace systemsAddressing safety issues of active safety
systemsFuture of design for complex systems Issues to consider
4
5
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 isNOT supposed to do
System Safety is the application of systems engineering principles toENABLE the development of safety-critical systems by managing safetyrisk
Concept
Productin Service
Design Process
Functional Requirements(What system is supposed to do)
Safety Process
Safety Requirements(What system is NOT supposed to do)
6
What is System Safety?
Identify problems
Find a way to fixthe problems
Convincingly show thatthe problems are covered
7
Model for System Safety Theory & Practice
Safety-CriticalSystems
SafetyCases
SafetyConcepts
Identify problemsFind a way to fix
the problemsConvincingly show thatthe problems are covered
8
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 engineeringrequirements
Add HazardControls
RiskAcceptable?
No
YesDeploy
IdentifyHazards
EvaluateResidual
Risk
AvoidHazards
9
System Safety (Safety Case View)
Safety Case Evidence that safety requirements
are understood
Evidence that safety requirementsare met
Argument for acceptance ofresidual risk based on theevidence
For all stakeholders– OEMs,Suppliers, Society
System Safety Process Sequence of tasks leading to the
development and acceptance of asafety case, usually involves:
Safety Requirements
Safety Concept
Safety Case
Resolution of stakeholderrequirements related to safety
Safety Case
Generic SafetyProcess Steps
CustomerRequirements
Argument
EvidenceEvidence
10
System Safety (Process View – Work Products)
PreliminaryHazardAnalysis
Hazard ControlSpecifications(Diagnostics,Design SafetyMargins, …)
SafetyVerification
SafetyCase
System SafetyProgram Plan
Hazard ControlSpecifications
(SafetyRequirements)
SafetyConcept &DetailedHazardAnalysis
ConceptualDesign
RequirementsAnalysis
Arch.Design
DetailedDesign
Verification& Validation
Production& Deploy.
11
Other Dependability Attributes: Reliability and Availability vs Safety
Reliability focuses on reducing overall failureprobability
Availability focuses on maximizing up-time Safety focuses on identifying and minimizing
risks associated with hazards and avoidingmishaps 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
ReliabilitySafety
Safety Reliability
12
Motivations for System Safety in the Automotive Industry
Inflation-adjusted priceof vehicles hasdeclined for severalyears
Auto companies seekto identify value-addingfeatures to gain priceas well as marketshare
Safety, Energy,Infotainment
Society more riskaverse over time
Reduction in deathsand injuries due toseat belts, etc. hasleveled off
SocietyDrivers
BusinessDrivers
TechnologyEnablers
• Solid-state cameras• Network communication
systems• Safety-critical computing
platforms• Actuators capable of
autonomous control
Cars Are Safety-Critical Systems
13
Safety-Critical Chassis Systems Enable ActiveSafety
Braking:
Electronic Stability Control
Electric Brake by Wire
Rear Steering:
Active Rear Steer
Engine:
Torque Management
Front Steering:
Electric PowerSteering
Active Front SteeringSteer by Wire
ControlledSuspension:
Controlled Dampers
Active Stabilizer Bar
14
Active Safety PathIn
cre
as
ing
sys
tem
au
ton
om
y
Time
360° surround sensing &autonomous vehicle control
collision warning systemcollision avoidance system
GPS/MapsVehicle-to-VehiclecommunicationIntersection/RoadwayInfrastructureSatellite-linked communication
Stand-alone systemsAdaptive Cruise ControlLane/Roadway departureSide detectionBackup AidESC & RSE
Sensor-fusion IntegratedSystems
Driver Support systemCollision warning & mitigationPre-crash & mitigationLane-change assistLane-keepingAdvanced Stability Control –Coordination of ESC and otherchassis systems
15
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 806million cars and light trucks on theroad
Goal: zero traffic deaths
Electronics market driver Automotive market has not driven the
electronics market since the 1980s
High production volumes anduser 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 drivencars
Complexity Configuration complexity
Brands, models, dozens ofcontrollers per vehicle
System complexity
Until now moderate complexity
New active safety systems arerapidly growing in complexity
16
Attributes of Aerospace Systems
High expectations for safety Focused on very low failure rates for
critical 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 volumesbut high passengerpopulations
Low diversity of users – onlyhighly trained pilots
Complexity High and growing system 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
NUREG0492FTA
FMVSS 135
ISO 26262
Mil-Hdbk-217 RDF 2000/UTEC 80810
MISRA
DO-178B
00-55
IEC 61508
18
One Page History of System Safety Standards inAutomotive
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 systemsafety 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 MeasurementCommittee
EquipmentUnderControl
EUC ControlSystem
Safety-RelatedSystem
EquipmentUnderControl
EUC Control System &Safety-Related System
Safety Functions
(A) Separate Safety-Related System
(B) Integrated Safety-Related System
Electrical/Electronic/Programmable Electronic System
Focus ofIEC 61508
20
ISO 26262 vs IEC 61508
IEC 61508: Framework standard
Scope: functional aspects ofelectronic, electrical and softwaresystems
Implied context ofProcess/Automation industries (wherevalidation is done after install)
Safety Integrity Levels, “SIL”
SIL 1 – SIL 4
Focus on safety functions
Architectural metrics
Defines acceptable software processelements 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 associatedwith an ASIL
Focus on safety goals
Adds required work products
New architectural metrics
Defines acceptable software processelements according to ASIL
DO 178B vs ISO 26262
International: jointly developed by US RTCA SC-167 and the EuropeanOrganization for Civil Aviation Equipment (EUROCAE) WG-12
21
DO 178B Provides guidelines for the production
of software for airborne systems andequipment
Design Assurance Levels – A-E
Increasing number of software processobjectives and independence with level
Highest level includes suggestions forsoftware coverage techniques such asMCDC
Addresses software requirements only
Focused toward suppliers of electronicsystems
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 processobjectives with level
Highest level includes suggestions forsoftware coverage techniques such asMCDC
Addresses functional safety associatedwith electronic controllers – hardware andsoftware
Addresses both design faults in hardwareand software as well random failures inhardware
Addresses both OEM and supplier issues
Highly detailed – sometimes prescriptive
Many work packages, may imply highdegree of documentation
Proposed Automotive Active Safety SystemTaxonomy and Examples*
System Classification
Example Feature
DriverInteraction
TypeExpected DriverResponsibility Potential Safety Risk
DriverInformation
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
Safety Related Automated Steering System
*B. Czerny, B. Murray, J. D’Ambrosio, “Safety Implications of Automotive Active Safety Systems,”, SAE Congress, 2008
Emerging Guideline: PReVENT/RESPONSE 3Project European project to develop an Advanced Driver Assistance Systems Code of
Practice
CoP describes a methodology for evaluating and assessing interactionsbetween the driver (and vehicle occupants) and the system being controlled
Provides guidance to help ensure potential issues of concern are identified andresolved during development
Coupling CoP and ISO 26262 CoP helps identify
safety-related requirements
26262 helps ensure safetyrequirements areimplemented with highintegrity
Helps ensure the safety-critical aspects ofactive safety systems are handledappropriately
Thoughts on Future of Complex Embedded Systems All products (not just automotive or aerospace)
are increasingly adding autonomous features –adding functional complexity
Modularity and networking provide opportunityfor creating new systems but also add complexity
Testing all of the states of these systems isimpractical
Increasing trend toward “Model-Based Design” Inspiration is the integrated circuit industry Design proceeds through series of
abstraction levels Models are the primary design artifact (as
opposed to code or drawings) Verification and validation primarily aimed at
models and aided by automated reasoning Code and hardware synthesized from
models, in some cases “correct-by-construction”
Testing aimed at confirmation Safety cases (certification packages, …) should
become modular and incremental Appropriate reasoning about need and type
of verification and validation for all designmodifications
24
off on
regen
Dynamics
Discretecontrolinputs
Guardconditionbased onstate
Hybrid Dynamic System
