Dr. Brian Murray March 4, 2011

Transcription

1 Event that could lead to an accident GM Autonomy HAZARD 1 Q=6e-7 Event that could lead to a hazard Control to prevent HAZARDOUS EVENT 1 HAZARDOUS EVENT 1 HAZARD CONTROL 1 r=6e-008 Q= Q=0.001 Q=0.001 National Geographic, 2002 Software Safety Assurance Processes and Challenges in the Automotive and Aviation Industries Dr. Brian Murray March 4, 2011

2 United Technologies Business units Pratt & Whitney aerospace systems Sikorsky Carrier power solutions UTC Power Hamilton Sundstrand UTC Fire & Security building systems Otis 2

3 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 3

4 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 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 is NOT supposed to do Functional Requirements (What system is supposed to do) Design Process Concept Safety Process Safety Requirements (What system is NOT supposed to do) Product in Service System Safety is the application of systems engineering principles to ENABLE the development of safety-critical systems by managing safety risk 5

6 What is System Safety? Identify problems Convincingly show that the problems are covered Find a way to fix the problems 6

7 Model for System Safety Theory & Practice Safety-Critical Systems Safety Cases Safety Concepts Identify problems Convincingly show that the problems are covered Find a way to fix the problems 7

8 Key Principles of System Safety Identify Hazards Avoid Hazards Evaluate Residual Risk Risk Acceptable? Yes Deploy Add Hazard Controls No 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 8

9 System Safety (Safety Case View) Argument Safety Case Generic Safety Process Steps Evidence Evidence Customer Requirements 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 9

10 System Safety (Process View Work Products) Conceptual Design Requirements Analysis Arch. Design Detailed Design Verification & Validation Production & Deploy. System Safety Program Plan Preliminary Hazard Analysis Hazard Control Specifications (Safety Requirements) Safety Concept & Detailed Hazard Analysis Hazard Control Specifications (Diagnostics, Design Safety Margins, ) Safety Verification Safety Case 10

11 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 Safety Reliability Safety Reliability 11

12 Motivations for System Safety in the Automotive Industry Technology Enablers Solid-state cameras Network communication systems Safety-critical computing platforms Actuators capable of autonomous control Society Drivers Cars Are Safety- Critical Systems Safety, Energy, Infotainment Society more risk averse over time Reduction in deaths and injuries due to seat belts, etc. has leveled off Business Drivers 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 12

13 Safety-Critical Chassis Systems Enable Active Safety Front Steering: Electric Power Steering Active Front Steering Steer by Wire Rear Steering: Active Rear Steer Engine: Torque Management Controlled Suspension: Controlled Dampers Active Stabilizer Bar Braking: Electronic Stability Control Electric Brake by Wire 13

14 Active Safety Path Increasing system autonomy 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 Stand-alone systems Adaptive Cruise Control Lane/Roadway departure Side detection Backup Aid ESC & RSE 360 surround sensing & autonomous vehicle control collision warning system collision avoidance system GPS/Maps Vehicle-to-Vehicle communication Intersection/Roadway Infrastructure Satellite-linked communication Time 14

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 806 million cars and light trucks on the road Goal: zero traffic deaths Electronics market driver 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 Automotive market has not driven the electronics market since the 1980s 15

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 Very low production volumes but high passenger populations Low diversity of users only highly trained pilots Complexity High and growing system complexity Specialty electronics Driven to, but reluctant to use COTS 16

17 System Safety Standards & Guidelines System/SW Safety Process Mechanical Electrical/ Electronics FMVSS 135 Regulations Software MISRA ISO VDA FMEA IEC Analysis MIL-Std-882C/D DO-178B DEF Std Mil-Hdbk-217 SAE FMEA RDF 2000/UTEC Reliability NUREG 0492 FTA

18 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 safety standard published Very influential in Europe Framework standard Adopted by European vehicle manufacturers July 2009 Draft International Standard ISO June 2011 Final DIS (FDIS) ISO expected 18

19 IEC IEC developed by IEC Industrial-Process Measurement Committee Electrical/Electronic/Programmable Electronic System EUC Control System Safety-Related System EUC Control System & Safety-Related System Safety Functions Equipment Under Control (A) Separate SafetyRelated System Equipment Under Control (B) Integrated SafetyRelated System Focus of IEC 61508

20 ISO vs IEC 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 Automotive Sector adaptation Brings in some concepts of MIL-STD882 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 elements according to ASIL 20

21 DO 178B vs ISO 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 Many work packages, may imply high 21 degree of documentation

22 Proposed Automotive Active Safety System Taxonomy and Examples* System Classification Driver Interaction Type Driver Information Expected Driver Responsibility Potential Safety Risk Example Feature Monitor / Supervise Non Safety Related NA No Monitoring / No Supervision Non Safety Related Monitor / Supervise Non Safety Related No Monitoring / No Supervision Non Safety Related Monitor / Supervise Non Safety Related No Monitoring / No Supervision Non Safety Related Driver Warning Vehicle Action / Control Safety Related Safety Related Safety Related Safety Related Safety Related Safety Related Rear back up camera NA Engine Temperature NA Rear back up alert NA Red Brake Tell Tale NA Lane Keeping System NA Automated Steering System *B. Czerny, B. Murray, J. D Ambrosio, Safety Implications of Automotive Active Safety Systems,, SAE Congress, 2008

23 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 CoP helps identify safety-related requirements helps ensure safety requirements are implemented with high integrity Helps ensure the safety-critical aspects of active safety systems are handled appropriately

24 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 opportunity for creating new systems but also add complexity Testing all of the states of these systems is impractical 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-byconstruction 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 design modifications off Discrete control inputs on regen Dynamics Guard condition based on state Hybrid Dynamic System 24