Contents

Verlässliche Echtzeitsysteme – ° Who is Method Park? Können wir unseren Autos noch vertrauen? ° Why do we need Safety Standards?

Bernhard Sechser ° Process and Safety demands in Automotive Method Park Consulting GmbH, Erlangen 23.06.2015 ° Hazard Analysis and Risk Assessment

° Functional and Technical Development

° Software Process in detail

° Tool Qualification

° Summary

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 2 of 75

Contents Method Park - Facts and Figures

° Who is Method Park? Facts Awards

• Founded in 2001 2004 2005 • Locations: 2008 ° Why do we need Safety Standards? Germany: Erlangen, Munich, 2011 Stuttgart USA: Detroit, Miami ° Process and Safety demands in Automotive 2006, 2007, 2009 2009

° Hazard Analysis and Risk Assessment Revenue & employees Business unit revenue Revenue ° Functional and Technical Development Employees 200 EM / 10 Mio. EUR 24% Method Park Software AG 49% ° Software Process in detail Method Park 100 EM / 5 Mio. EUR Consulting GmbH Method Par Engineering GmbH ° Tool Qualification 26% - 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 ° Summary

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 3 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 4 of 75 Portfolio Our Customers

Product Engineering Automotive Engineering/ Healthcare Defense Areas: • Automation •Carl Zeiss •Airbus Deutschland •Automotive Lighting •7 layers •Siemens •Diehl • Project Coaching •Blaupunkt •ABB •Fresenius •EADS • Software Development & Support •BMW •BDT •Agfa •Elbit Solution for integrated • On Site Support •Bosch •Carl Schenk •Ziehm Imaging •Orbital •Brose •EBM Papst •NewTec •Raytheon Anschütz process management • Off Site Projects •Continental •Heidelberger •Innovations Software •KID • Fixed Price Projects •Daimler Druckmaschinen •Technology •Delphi •Insta Further •ETAS •Kratzer Automation IT/ •Bosch und Siemens Hausgeräte Consulting/Coaching Training •HE System Elektronik • Telecommunications •Deutsche Post •Helbako •Mettler Toledo •GFT •GMC Software Technologies • •Mühlbauer Group •Intersoft •Kodak Topics: Wide range of seminars in the division •IAV •Rohde&Schwarz •Nash Technologies •Landesbank Kiel ® ® • CMMI , SPICE, Automotive SPICE systems and software engineering •Johnson Controls •Siemens Industries •NEC •Raab Karcher • Project Management & Agile Development •Knorr-Brakes •Wago •Micronas •Giesecke & Devrient • Process Improvement & Quality Management Accredited by the following organizations: •Kostal •Siemens •Thales Rail Signaling • Functional Safety (ISO 26262) SEI, ISTQB, iSQI, iNTACS, IREB, iSAQB, ECQA •Marquardt Government/Public •Teleca • Variant & Complexity Management •Peiker Acustic •Bundesagentur für Arbeit • Product Line Management (PLM) •Preh •Curiavant • Application Lifecycle Management (ALM) •Renesas •Kassenärztliche Vereinigung • Requirements Management •Thales Baden-Württemberg • System & Software Architecture & Design •TRW • • AUTOSAR •Webasto • System & Software Testing •Witte Automotive •ZF •Zollner

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 5 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 6 of 75

Contents Example – Ariane 5 (July 4th, 1996)

° Who is Method Park? Detonation shortly after takeoff because of an error in the control software ° Why do we need Safety Standards? Root cause: Insufficient tests of a reused ° Process and Safety demands in Automotive “proven in use” software component ° Hazard Analysis and Risk Assessment

° Functional and Technical Development

° Software Process in detail

° Tool Qualification

Source: ESA ° Summary Source: YouTube

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 7 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 8 of 75 Example – Therac-25 Examples

Irradiation of patients with a Application that can cause harm (a risk): lethal dose ° Airbag exploding when infant is sitting in front seat Root cause: Insufficient safety functions Need to assess the risk ° Infant getting injured – “not good at all”

Find a mitigation strategy, e.g. a safety function: ° Detecting infant in front seat and disabling airbag a) sensor delivers signal to b) software/hardware controlling an c) actuator (disabler) Question: How to measure Functional Safety is then: and agree on the ° An infant in front seat is not exposed measures? to an unacceptable (unreasonable) risk

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 9 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 10 of 75

Examples Reasons for Failures 63%

60% Root cause analysis of software failures in 90 50% healthcare companies

40%

30%

20% 16% 10% 11% 10% Question: Do we dare putting software in direct Implementation Architecture Requirements Other control of people’s life? Design Source: Fraunhofer Institute for Experimental Software Engineering 2007

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 11 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 12 of 75 Complexity Extract from German law

§ 823 Abs. 1 BGB: „Anyone who injures intentionally or negligently the life, body, health, liberty, property or any other right of another person, is obliged to compensate for the resulting damages.“

§ 1 Abs. 1 ProdhaftG: „If someone is killed, his body or health injured or an item damaged by a defect in a product, the manufacturer of the product is obliged to replace the resulting damages.“

Source: © Courtesy of Daimler; Presentation given at Automotive Electronics and Electrical Systems Forum 2008, May 6, 2008, Stuttgart, Germany

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 13 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 14 of 75

Contents Definitions

° Who is Method Park? Safety … is the absence of unacceptable (unreasonable) risks that can ° Why do we need Safety Standards? cause harm achieved through a planned strategy

° Process & Safety demands in Automotive Functional Safety … is part of the overall safety that depends on a system or ° Hazard Analysis and Risk Assessment equipment operating correctly in response to its inputs. … is achieved when every specified safety function is carried out and the level of performance required of each safety function is ° Functional and Technical Development met … is not to provide the perfect car, but a safe car. ° Software Process in detail

Functional Safety Management ° Tool Qualification … is the management (plan, do, act, check) of all activities necessary to reach functional safety. ° Summary

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 15 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 16 of 75 Existing Standards Scope of ISO 26262

IEC 61508 Why not using IEC 61508? Functional safety of electrical / electronic / programmable electronic safety-related systems Lessons learnt from application of IEC 61508 in : ° Not adapted to real-time and integrated embedded systems EN 62061 EN 50271 ° Not adapted to automotive development and life cycles IEC 61511 ISO 13849 EN 50402 ° No requirements for manufacturer / supplier relationship Automation Manufactoring Gas Measuring ° No ‘consumer-goods’ orientation ° … IEC 61513 EN 50126 DO 178B Companies had to solve these issues themselves until introduction of IEC 60880 EN 50128 Aviation Nuclear EN 50129 Rail IEC 62304 ISO 26262 Medical Automotive

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 17 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 18 of 75

Structure of ISO 26262 ISO 15504 & Automotive SPICE ®

Primary Life Cycle Processes Supporting Life Cycle Processes Acquisition Process Group (ACQ) Support Process Group (SUP) ACQ.1 Acquisition preparation A H SUP.1 Quality assurance ACQ.2 Supplier selection A SUP.2 Verification A ACQ.3 Contract agreement SUP.3 Validation A H ACQ.4 Supplier monitoring A SUP.4 Joint review ACQ.5 Customer acceptance SUP.5 Audit A ACQ.11 Technical requirements SUP.6 Product evaluation A ACQ.12 Legal and administrative requirements A SUP.7 Documentation Process Category Process Process Group Process A ACQ.13 Project requirements A H SUP.8 Configuration management Process A ACQ.14 Request for proposals A H SUP.9 Problem resolution management A ACQ.15 Supplier qualification A H SUP.10 Change request management Supply Process Group (SPL) Organizational Life Cycle Processes A SPL.1 Supplier tendering A SPL.2 Product release Management Process Group (MAN) SPL.3 Product acceptance support MAN.1 Organizational alignment MAN.2 Organizational management Engineering Process Group (ENG) A H MAN.3 Project management A ENG.1 Requirements elicitation MAN.4 Quality management A H ENG.2 System requirements analysis A MAN.5 Risk management A H ENG.3 System architectural design A MAN.6 Measurement A H ENG.4 Software requirements analysis A H ENG.5 Software design Process Improvement Process Group (PIM) A H ENG.6 Software construction PIM.1 Process establishment A H ENG.7 Software integration PIM.2 Process assessment A H ENG.8 Software testing A PIM.3 Process improvement A H ENG.9 System integration A H ENG.10 System testing Resource & Infrastructure Process Group (RIN) ENG.11 Software installation RIN.1 Human resource management ENG.12 Software and system maintenance RIN.2 Training RIN.3 Knowledge management Operation Process Group (OPE) RIN.4 Infrastructure OPE.1 Operational use Reuse Process Group (REU) OPE.2 Customer support A = Automotive SPICE® A Automotive = HIS-Scope H = REU.1 Asset management A REU.2 Reuse program management Source: ISO 26262:2011 REU.3 Domain engineering © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 19 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 20 of 75 Structure of ISO 26262 Safety Lifecycle Overview

Management Process Improvement Resource & Infrastructure

Engineering (System) ° Concept

Operation

Engineering (Software) ° Development

Aquisition Supply Support Reuse

° Production

ISO 15504 Process Groups Source: ISO 26262:2011 Source: ISO 26262-2:2011 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 21 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 22 of 75

Safety Lifecycle Overview Safety Lifecycle Overview

Concept Phase Product Development ° Focus on entire system ° System, Hardware and Software ° Risks ° Safety validation and assessment ° Safety Goals and Requirements ° Production and Operation ° Safety functions (Planning)

Source: ISO 26262-2:2011 Source: ISO 26262-2:2011

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 23 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 24 of 75 Product Development Product Development

Product Development at the Product Development at the System Level Hardware Level

Source: ISO 26262-2:2011 Source: ISO 26262-2:2011

Source: ISO 26262-4:2011 Source: ISO 26262-5:2011

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 25 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 26 of 75

Product Development Safety Lifecycle Overview

Product Development at the After Release for Production Software Level ° Production ° Installation ° Operation ° Maintenance and reparation ° Disassembly

Source: ISO 26262-2:2011

Source: ISO 26262-6:2011 Source: ISO 26262-2:2011

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 27 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 28 of 75 Contents Hazard Analysis and Risk Assessment

° Who is Method Park? Risk reduction to an acceptable level

° Why do we need Safety Standards?

° Process and Safety demands in Automotive

° Hazard Analysis and Risk Assessment

° Functional and Technical Development

° Software Process in detail

° Tool Qualification

° Summary Source: IEC 61508-5:2010

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 29 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 30 of 75

Hazard Analysis and Risk Assessment Hazard Analysis and Risk Assessment

Associations of the central concepts Situation analysis and hazard identification ° List of driving and operating situations ‰ Estimation of the probability of Exposure ° Detailing failure modes leading to hazards in specific situations ‰ Estimation of Controllability ° Evaluating consequences of the hazards ‰ Estimation of potential Severity

‰ Respect only the plain item (do not take risk-reducing measures into account!) E = Exposure ‰ Involve persons with good knowledge C = Controllability and domain experience S = Severity ASIL = Automotive Safety Integrity Level

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 31 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 32 of 75 Hazard Analysis and Risk Assessment Hazard Analysis and Risk Assessment

Exposure Controllability State of being in an operational situation that can be hazardous if Avoidance of the specified harm or damage through the timely coincident with the failure mode under analysis reactions of the persons involved

Class E0 E1 E2 E3 E4

Description Incre- Very low Low Medium High Class C0 C1 C2 C3 dible probability probability probability probability Time Not specified Less than 1% 1% - 10% of > 10% of Description Controllable Simply Normally Difficult to control or of average average average in general controllable controllable uncontrollable operating time operating time operating time Definition Controllable 99% or more of 90% or more of Less than 90% of all Event Situations that Situations that Situations that All situations in general all drivers or all drivers or drivers or other occur less occur a few occur once a that occur other traffic other traffic traffic participants often than times a year month or more during almost participants are participants are are usually able, or once a year for for the great often for an every drive on usually able to usually able to barely able, to avoid the great majority of average driver average avoid a specific avoid a specific a specific harm. majority of drivers harm. harm. drivers Source: ISO 26262-3:2011 Source: ISO 26262-3:2011

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 33 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 34 of 75

Hazard Analysis and Risk Assessment Hazard Analysis and Risk Assessment

Severity Combinations of Severity, C1 C2 C3 Exposure and Measure of the extent of harm to an individual in a specific situation E1 QM QM QM Controllability result in the applicable ASIL. E2 QM QM QM S1 E3 QM QM A

The ASIL’s influence the E4 QM A B development process of the items. E1 QM QM QM E2 QM QM A S2 QM = Quality Management E3 QM A B

No specific ISO 26262 E4 ABC requirement has to be Class S0 S1 S2 S3 observed E1 QM QM A Description No Light and Severe and life- Life-threatening injuries E2 QM A B S3 injuries moderate threatening injuries (survival uncertain), fatal If S0 or E0 or C0 is set, no E3 ABC injuries (survival probable) injuries ASIL is required (QM). E4 BCD

Source: ISO 26262-3:2011 Source: ISO 26262-3:2011 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 35 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 36 of 75 Hazard Analysis and Risk Assessment Hazard Analysis and Risk Assessment

Safety Goals Safe State – Operating mode of an item without an unreasonable ° top-level safety requirements as a result of the hazard analysis level of risk and risk assessment ° Example: intended operating mode, degraded operating mode ° assigned to each identified hazard rated with an ASIL A-D or switched-off mode ° lead to item characteristics needed to avert hazards or to reduce

risks associated with the hazards to an acceptable level Failure Failure permanent Safe State Hazard Reaction shall be reached ° are assigned to a safe state that must be reached in case of occurs detected possible appearance ° indicate the maximum fault tolerance time within the safe state FTT –Fault Tolerant Time must be reached

diagnostic test interval reaction time buffer time fault tolerance time = fault recognition time + fault reaction time

reaction time hazard can occur

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 37 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 38 of 75

Hazard Analysis and Risk Assessment Contents

Example for Safety Goals: Park Brake System ° Who is Method Park?

ID Safety Goal ASIL Safe FTT ° Why do we need Safety Standards? State G1 Avoidance of unintended maximum brake force D Brake 50 ° Process and Safety demands in Automotive build up at one or several wheels during drive released ms and in all environmental conditions ° Hazard Analysis and Risk Assessment G2 Guarantee the specified parking brake function A Brake 500 in use case situation "parking on slope" in all closed ms environmental conditions ° Functional and Technical Development G3 Avoidance of unintended release of the parking C Brake 500 brake in use case situation "parking on slope" closed ms ° Software Process in detail in all environmental conditions ° Tool Qualification

° Summary

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 39 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 40 of 75 Functional Safety Concept ASIL Decomposition

Safety Goals and Functional Safety Requirements

Source: ISO 26262-9:2011

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 41 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 42 of 75

Architectures Contents

Example: Three channel structure 2oo3 ° Who is Method Park?

Output ° Why do we need Safety Standards? Central Circuit 1 Input Processing Sensor Circuit Unit Output Circuit 2 ° Process and Safety demands in Automotive

Output Central Circuit 1 ° Hazard Analysis and Risk Assessment Input Processing Sensor Circuit Unit Output Circuit 2 ° Functional and Technical Development

Output Central Circuit 1 Input ° Software Process in detail Processing Sensor Circuit Unit Output Circuit 2 ° Tool Qualification

Actuator ° Summary

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 43 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 44 of 75 Product Development at Hardware & How to understand the standard tables Software Level

For each method, the degree of recommendation to use corresponding methods depends Highly Recommended on the ASIL and is categorized as follows: Important part:

Hardware-Software ZMETHOD Interface ”++” The method is highly Recommended

Specification (HSI) recommended for this METHOD Y ASIL

“+“ The method is XMETHOD recommended for this ASIL

“o“ The method has no Gained systematic confidence recommendation for or against its usage for this o + ++ ASIL

Source: ISO 26262-4:2011

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 45 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 46 of 75

Initiation of Product Development at the Specification of Software Safety Software Level Requirements

Topics to be covered by modeling and coding guidelines Goals

ASIL Topics ABCD ° Derive Software Safety Requirements from and 1a Enforcement of low complexity ++ ++ ++ ++ ensure consistency with 1b Use of language subsets ++ ++ ++ ++ ° System Design 1c Enforcement of strong typing ++ ++ ++ ++ ° Technical Safety Concept 1d Use of defensive implementation techniques o + ++ ++

1e Use of established design principles + + + ++ Source: ISO 26262-6:2011 1f Use of unambiguous graphical representation + ++ ++ ++ ° Detail the hardware-

1g Use of style guides + ++ ++ ++ software interface requirements 1h Use of naming conventions ++ ++ ++ ++

Source: ISO 26262-6:2011

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 47 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 48 of 75 Specification of Software Safety Specification of Software Safety Requirements Requirements

Methods for specifying Safety Requirements Methods for the verification of Safety Requirements ° Safety requirements shall be specified by an appropriate combination of natural language and methods listed in the table ° For higher level safety requirements (e.g. functional and technical safety requirements) natural language is more

appropriate while for lower level safety requirements (e.g. ASIL software and hardware safety requirements) notations listed in Methods the table are more appropriate ABCD

ASIL 1a Verification by walk-through ++ + o o

Methods 1b Verification by inspection + ++ ++ ++ ABCD

1c Semi-formal verification (e.g. executable models) + + ++ ++ 1a Informal notations for requirements specification ++ ++ + +

1d Formal verification o + + + 1b Semi-formal notations for requirements specification + + ++ ++

1c Formal notations for requirements specification + + + +

Source: ISO 26262-8:2011 Source: ISO 26262-8:2011

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 49 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 50 of 75

Software Architectural Design Software Architectural Design

Goals Principles for software architectural design

ASIL ° Develop an Architecture that Methods implements the Software ABCD Safety Requirements 1a Hierarchical structure of software components ++ ++ ++ ++ ° Static and dynamic interfaces 1b Restricted size of software components ++ ++ ++ ++ ° Safety-related and non safety related requirements 1c Restricted size of interfaces + + + +

Source: ISO 26262-6:2011 1d High cohesion within each software component + ++ ++ ++

° Verify the Software Architecture 1e Restricted coupling between software components + ++ ++ ++ ° Compliance with the requirements 1f Appropriate scheduling properties ++ ++ ++ ++ ° Compatibility with hardware 1g Restricted use of interrupts + + + ++ ° Respect of design principles and standards Source: ISO 26262-6:2011

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 51 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 52 of 75 Software Architectural Design Software Architectural Design

Based on the results of the safety analysis the mechanisms for Methods for the verification of the software architectural design error detection and error handling shall be applied ASIL

ASIL ASIL Methods Methods Methods ABCD ABCD ABCD 1a Walk-through of the design ++ + o o Range checks of Static recovery 1a + + + + 1a input and output ++ ++ ++ ++ mechanism data 1b Inspection of the design + ++ ++ ++ 1b Graceful degradation + + ++ ++ 1b Plausibility check + + + ++ 1c Simulation of dynamic parts of the design + + + ++ Independent parallel 1c o o + ++ Detection of data redundancy 1c + + + + errors 1d Prototype generation o o + ++ Correcting codes for 1d + + + + External monitoring data 1d o + + ++ facility 1e Formal verification o o + + Control flow Error handling 1e o + ++ ++ monitoring 1f Control flow analysis + + ++ ++ Diverse software 1f o o + ++ design 1g Data flow analysis + + ++ ++ Error detection Source: ISO 26262-6:2011 Source: ISO 26262-6:2011

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 53 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 54 of 75

Software Unit Design and Implementation Software Unit Design and Implementation

Goals Design principles for software unit design and implementation

ASIL ° Specify SW Units based on: Methods ABCD ° SW Architecture 1a One entry and one exit point in subprograms and functions ++ ++ ++ ++ ° SW Safety Requirements 1b No dynamic objects or variables, or else online test during their + ++ ++ ++ creation 1c Initialization of variables ++ ++ ++ ++ ° Implement the SW Units 1d No multiple use of variable names + ++ ++ ++ 1e Avoid global variables or else justify their usage + + ++ ++ Source: ISO 26262-6:2011 1f Limited use of pointers o + + ++ ° Verify SW Units 1g No implicit type conversions + ++ ++ ++ ° Code reviews / inspections 1h No hidden data flow or control flow + ++ ++ ++ 1i No unconditional jumps ++ ++ ++ ++ 1j No recursions + + ++ ++

Source: ISO 26262-6:2011

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 55 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 56 of 75 Software Unit Design and Implementation Software Unit Testing

Example: MISRA C Goals

° Programming standard developed by Motor Industry Software ° Demonstrate that the Reliability Association software units fulfil the Software Unit Specifications ° Avoidance of runtime errors due to unsafe C constructs

° Verify absence of undesired The respect of MISRA C shall be demonstrated static code ° Ï functionalities analysis Source: ISO 26262-6:2011

Infos: www. misra .org

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 57 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 58 of 75

Software Unit Testing Software Unit Testing

ASIL The software unit testing methods Methods Methods for deriving test cases for software unit testing shall be applied to demonstrate ABCD Requirements- that the software units achieve: 1a ++ ++ ++ ++ based test ASIL Methods ° Compliance with the software 1b Interface test ++ ++ ++ ++ ABCD unit design specification Fault injection 1c + + + ++ 1a Analysis of requirements ++ ++ ++ ++ ° Compliance with the test Resource usage specification of the hardware- 1d + + + ++ Generation and analysis of equivalence test 1b + ++ ++ ++ software interface classes Back-to-back comparison test 1c Analysis of boundary values + ++ ++ ++ ° Correct implementation of the 1e between model + + ++ ++ functionality and code, if 1d Error guessing + + + + applicable ° Absence of unintended functionality Source: ISO 26262-6:2011 Source: ISO 26262-6:2011 ° Robustness ° Sufficiency of the resources to support the functionality

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 59 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 60 of 75 Software Unit Testing Software Integration and Testing

Structural coverage metrics at the software unit level Goals

ASIL Methods ° Integrate SW components ABCD ° Integration sequence 1a Statement coverage ++ ++ + + ° Testing of interfaces between components/units 1b Branch coverage + ++ ++ ++

1c MC/DC (Modified Condition/Decision Coverage) + + + ++ ° Verify correct implementation Source: ISO 26262-6:2011 of the SW Architecture

Source: ISO 26262-6:2011

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 61 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 62 of 75

Software Integration and Testing Software Integration and Testing

The software integration test methods shall be applied to Structural coverage metrics at the software architectural level demonstrate that both the software components and the embedded software achieve: ASIL ° Compliance with the Methods ASIL ABCD software architectural Methods 1a Function coverage + + ++ ++ design ABCD

° Compliance with the Requirements-based 1a ++ ++ ++ ++ 1b Call coverage + + ++ ++ specification of the test hardware-software interface 1b Interface test ++ ++ ++ ++ Source: ISO 26262-6:2011 ° Correct implementation of 1c Fault injection test + + ++ ++ the functionality 1d Resource usage test + + + ++ ° Robustness and sufficiency Back-to-back of the resources to support comparison test 1e + + ++ ++ the functionality between model and code, if applicable

Source: ISO 26262-6:2011

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 63 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 64 of 75 Verification of Software Safety Verification of Software Safety Requirements Requirements

Goals ° Verify that the embedded software fulfils the software safety requirements

° Verify that the embedded ° Verification of the software safety requirements shall be software fulfils the Software executed on the target hardware Safety Requirements in the ° The results of the verification of the software safety target environment requirements shall be evaluated in accordance with: ° Compliance with the expected results ASIL Methods Source: ISO 26262-6:2011 ° Coverage of the software ABCD

safety requirements Hardware-in-the- 1a + + ++ ++ ° A pass or fail criteria loop Electronic control 1b unit network ++ ++ ++ ++ environments

1c Vehicles ++ ++ ++ ++

Source: ISO 26262-6:2011

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 65 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 66 of 75

Functional Safety Assessment Contents

What shall be provided to support the Safety Case? ° Who is Method Park?

Product Validated Definition Product ° Why do we need Safety Standards? C

r Hazard e fy a ri t Analysis e Design Ve Verify Function Function ° Process and Safety demands in Automotive

De Design sig Verify Architecture n Architecture ° Hazard Analysis and Risk Assessment

Design Verify System System ° Functional and Technical Development Safety Safety Verification Analysis Design Verify Component Component ° Software Process in detail

Create Hardware & Software ° Tool Qualification

Safety Case - Arguments ° Summary

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 67 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 68 of 75 Qualification of Software Tools Qualification of Software Tools

To determine the required level of confidence in a software tool, Tool Impact (TI) perform a use case analysis: Possibility that a safety requirement, allocated to the safety- ° Evaluate if a malfunctioning software tool and its erroneous related item or element, is violated if the software tool is output can lead to the violation of any safety requirement malfunctioning or producing erroneous output allocated to the safety-related item or element to be developed TI1 – no such possibility ° Establish probability of preventing or detecting such errors in TI2 – all other cases its output Tool error Detection (TD) ° Considers measures internal to the software tool (e.g. monitoring) Probability of preventing or detecting that the software tool is malfunctioning or producing erroneous output ° Measures external to the software tool implemented in the TD1 – high degree of confidence for prevention or detection development process for the safety-related item or element (e.g. guidelines, tests, reviews) TD2 – medium degree of confidence for prevention or detection TD3 – all other cases

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 69 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 70 of 75

Qualification of Software Tools Qualification of Software Tools

Tool Confidence Level (TCL) Qualification methods: Based on the values determined for the classes of TI and TD ASIL Qualification methods of software tools classified TCL3 ABCD TD1 TD2 TD3 1a Increased confidence from use ++ ++ + + TI1 TCL1 TCL1 TCL1 1b Evaluation of the tool development process ++ ++ + + TI2 TCL1 TCL2 TCL3 1c Validation of the software tool + + ++ ++ Source: ISO 26262-8:2011 1d Development in accordance with a safety standard + + ++ ++

ASIL Qualification methods of software tools classified TCL2 ABCD

1a Increased confidence from use ++ ++ ++ +

1b Evaluation of the tool development process ++ ++ ++ +

1c Validation of the software tool + + + ++

1d Development in accordance with a safety standard + + + ++

Source: ISO 26262-8:2011 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 71 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 72 of 75 Contents Summary

° Who is Method Park? ° Today’s electronic systems are too complex to ° Why do we need Safety Standards? understand all potential hazards ° Process and Safety demands in Automotive ° An approach for Functional Safety is needed to avoid ° Hazard Analysis and Risk Assessment severe injuries and damages in human lives and property ° Functional and Technical Development ° A standardized way to show ° Software Process in detail that your product is safe is needed – best practice yet not fully established – ° Tool Qualification guidance needed

° Summary

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 73 of 75 © 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 74 of 75

Thank you !

Bernhard Sechser Principal Consultant SPICE & Safety

Method Park Consulting GmbH Wetterkreuz 19a 91058 Erlangen Germany

Phone: +49 9131 97206-427 Mobile: +49 173 3882055

[email protected] http://www.xing.com/profile/Bernhard_Sechser http://www.methodpark.com

© 2015 Method Park Consulting GmbH / Bernhard Sechser / 23.06.2015 / Verlässliche Echtzeitsysteme Slide 75 of 75