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 Software AG, Erlangen 30.04.2012 Hazard Analysis and Risk Assessment
Functional and Technical Development
Software Process in detail
Tool Qualification
Summary
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 2 of 69
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 USA: Detroit, Miami Process and Safety demands in Automotive 2006, 2007, 2009 2009
Hazard Analysis and Risk Assessment Revenue & employees Business unit revenue Functional and Technical Development
33%
Software Process in detail 45% Products Training & Consulting Engineering Tool Qualification 22%
Summary
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 3 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 4 of 69 Portfolio Our Customers
Product Engineering Automotive Engineering/ Healthcare Defense Areas: •Audi Automation •Carl Zeiss •Airbus Deutschland •Automotive Lighting •7 layers •Siemens •Diehl • Project Coaching •Blaupunkt •ABB •Fresenius •EADS • Software Development & Support •BMW •BDT •Agfa •Raytheon Anschütz Solution for integrated • On Site Support •Bosch •Carl Schenk •Ziehm Imaging •KID •Brose •EBM Papst •NewTec • Off Site Projects process management •Continental •Heidelberger •Innovations Software Further • Fixed Price Projects •Daimler Druckmaschinen •Technology •Bosch und Siemens Hausgeräte •Delphi •Insta •Deutsche Post •ETAS •Kratzer Automation IT/ •GMC Software Technologies •Helbako •Magirus Telecommunications •Kodak •IAV •Mettler Toledo •GFT •Landesbank Kiel •Knorr-Brakes •Mühlbauer Group •Intersoft •Raab Karcher Consulting/Coaching Training •Marquardt •Rohde&Schwarz •Nash Technologies •Giesecke & Devrient •Peiker Acustic •Siemens Industries •NEC •Thales Rail Signaling •Preh •Wago •Micronas Topics: Wide range of seminars in the division •Thales •Siemens • Software Process Improvement system and software development •TRW Government/Public •Teleca • CMMI®, SPICE, Automotive SPICE® •Volkswagen •Bundesagentur für Arbeit •Webasto • AUTOSAR, Functional Safety Accredited by the following organizations: •Curiavant SEI, ISTQB, ISQI, INTACS, IREP •ZF •Kassenärztliche Vereinigung • Requirements Management •Zollner Baden-Württemberg • Project and Quality Management • Software Architecture & Design • Software Testing
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 5 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 6 of 69
Contents Examples
Who is Method Park? Ariane 5 (July 4th, 1996) Detonation shortly after Why do we need Safety Standards? takeoff because of an error in the control software Process and Safety demands in Automotive Root cause: Insufficient tests of a reused Hazard Analysis and Risk Assessment “proven in use” software component
Functional and Technical Development
Software Process in detail
Tool Qualification
Source: ESA Summary Source: YouTube
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 7 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 8 of 69 Examples Examples
Application that can cause harm (a risk): Airbag exploding when infant is sitting in front seat
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 Question: Do we dare putting An infant in front seat is not exposed measures? software in direct to an unacceptable (unreasonable) risk control of people’s life?
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 9 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 10 of 69
Reasons for Failures 63% Complexity
60% Root cause analysis of software failures in 90 50% healthcare companies
40%
30%
20% 16% 10% 11% 10%
Implementation Architecture Requirements Other
Design Source: Fraunhofer Institute for Experimental Software Engineering 2007 Source: © Courtesy of Daimler; Presentation given at Automotive Electronics and Electrical Systems Forum 2008, May 6, 2008, Stuttgart, Germany
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 11 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 12 of 69 Extract from German law Contents
§ 823 Abs. 1 BGB: Who is Method Park? „Anyone who injures intentionally or negligently the life, body, health, liberty, property or any other right of another person, is Why do we need Safety Standards? obliged to compensate for the resulting damages.“
Process & Safety demands in Automotive § 1 Abs. 1 ProdhaftG: „If someone is killed, his body or health injured or an item Hazard Analysis and Risk Assessment damaged by a defect in a product, the manufacturer of the product is obliged to replace the resulting damages.“ Functional and Technical Development
Software Process in detail
Tool Qualification
Summary
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 13 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 14 of 69
Definitions Existing Standards
IEC 61508 Safety Functional safety of electrical / electronic / … is the absence of unacceptable (unreasonable) risks that can programmable electronic safety-related systems cause harm achieved through a planned strategy
Functional Safety EN 62061 EN 50271 IEC 61511 … is part of the overall safety that depends on a system or ISO 13849 EN 50402 Automation equipment operating correctly in response to its inputs. Manufactoring Gas Measuring … is achieved when every specified safety function is carried out and the level of performance required of each safety function is IEC 61513 EN 50126 DO 178B met IEC 60880 EN 50128 Aviation … is not to provide the perfect car, but a safe car. Nuclear EN 50129 Rail Functional Safety Management IEC 62304 ISO 26262 … is the management (plan, do, act, check) of all activities Medical Automotive necessary to reach functional safety.
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 15 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 16 of 69 Scope of ISO 26262 Structure of ISO 26262
Why not using IEC 61508?
Lessons learnt from application of IEC 61508 in automotive industry: Not adapted to real-time and integrated embedded systems Not adapted to automotive development and life cycles No requirements for manufacturer / supplier relationship No ‘consumer-goods’ orientation … Companies had to solve these issues themselves until introduction of
Source: ISO/FDIS 26262 - BL18
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 17 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 18 of 69
ISO 15504 & Automotive SPICE ® Structure of ISO 26262
Primary Life Cycle Processes Supporting Life Cycle Processes AcquisitionAcquisition ProcessProcess GroupGroup (ACQ)(ACQ) SupportSupport ProcessProcess GroupGroup (SUP)(SUP) ACQ.1ACQ.1 AcquisitionAcquisition preparationpreparation AA H H SUP.1 SUP.1 QualityQuality assuranceassurance ACQ.2ACQ.2 SupplierSupplier selectionselection AA SUP.2 SUP.2 VerificationVerification Management Process Improvement Resource & Infrastructure AA ACQ.3 ACQ.3 ContractContract agreementagreement SUP.3SUP.3 ValidationValidation AA H H ACQ.4 ACQ.4 SupplierSupplier monitoringmonitoring AA SUP.4 SUP.4 JointJoint reviewreview ACQ.5ACQ.5 CustomerCustomer acceptanceacceptance SUP.5SUP.5 AuditAudit AA ACQ.11 ACQ.11 TechnicalTechnical requirementsrequirements SUP.6SUP.6 ProductProduct evaluationevaluation AA ACQ.12 ACQ.12 LegalLegal andand administrativeadministrative requirementsrequirements A SUP.7 Documentation Process Category Process A SUP.7 Documentation Process Group Process AA ACQ.13 ACQ.13 ProjectProject requirementsrequirements A H SUP.8 Configuration management Engineering (System) Process A H SUP.8 Configuration management AA ACQ.14 ACQ.14 RequestRequest forfor proposalsproposals AA H H SUP.9 SUP.9 ProblemProblem resolutionresolution managementmanagement AA ACQ.15 ACQ.15 SupplierSupplier qualificationqualification AA H H SUP.10 SUP.10 ChangeChange requestrequest managementmanagement SupplySupply ProcessProcess GroupGroup (SPL)(SPL) Organizational Life Cycle Processes AA SPL.1 SPL.1 SupplierSupplier tenderingtendering AA SPL.2 SPL.2 ProductProduct releaserelease ManagementManagement ProcessProcess GroupGroup (MAN)(MAN) Operation SPL.3SPL.3 ProductProduct acceptanceacceptance supportsupport MAN.1MAN.1 OrganizationalOrganizational alignmentalignment MAN.2MAN.2 OrganizationalOrganizational managementmanagement EngineeringEngineering ProcessProcess GroupGroup (ENG)(ENG) AA H H MAN.3 MAN.3 ProjectProject managementmanagement Engineering AA ENG.1 ENG.1 RequirementsRequirements elicitationelicitation MAN.4MAN.4 QualityQuality managementmanagement AA H H ENG.2 ENG.2 SystemSystem requirementsrequirements analysisanalysis AA MAN.5 MAN.5 RiskRisk managementmanagement (Software) AA H H ENG.3 ENG.3 SystemSystem architecturalarchitectural designdesign AA MAN.6 MAN.6 MeasurementMeasurement A H ENG.4 Software requirements analysis A H ENG.4 Software requirements analysis Process Improvement Process Group (PIM) AA H H ENG.5 ENG.5 SoftwareSoftware designdesign Process Improvement Process Group (PIM) PIM.1 Process establishment AA H H ENG.6 ENG.6 SoftwareSoftware constructionconstruction PIM.1 Process establishment PIM.2 Process assessment AA H H ENG.7 ENG.7 SoftwareSoftware integrationintegration PIM.2 Process assessment A PIM.3 Process improvement AA H H ENG.8 ENG.8 SoftwareSoftware testingtesting A PIM.3 Process improvement A H ENG.9 System integration A H ENG.9 System integration Resource & Infrastructure Process Group (RIN) AA H H ENG.10 ENG.10 SystemSystem testingtesting Resource & Infrastructure Process Group (RIN) ENG.11 Software installation RIN.1RIN.1 HumanHuman resourceresource managementmanagement Aquisition Supply Support Reuse ENG.11 Software installation RIN.2 Training ENG.12ENG.12 SoftwareSoftware andand systemsystem maintenancemaintenance RIN.2 Training RIN.3RIN.3 KnowledgeKnowledge managementmanagement RIN.4 Infrastructure OperationOperation ProcessProcess GroupGroup (OPE)(OPE) RIN.4 Infrastructure OPE.1OPE.1 OperationalOperational useuse Reuse Process Group (REU) OPE.2 Customer support Reuse Process Group (REU) A = Automotive SPICE® A = Automotive H = HIS-Scope OPE.2 Customer support REU.1REU.1 AssetAsset managementmanagement AA REU.2 REU.2 ReuseReuse programprogram managementmanagement Source: ISO/FDIS 26262 - BL18 REU.3REU.3 DomainDomain engineeringengineering ISO 15504 Process Groups © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 19 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 20 of 69 Safety Lifecycle Overview Safety Lifecycle Overview
2-5 to 2-7 Management of functional safety Concept Phase 3-5 Item definition Focus on entire system Initiation of the 3-6 safety lifecycle Risks Concept Hazard analysis 3-7 and risk assessment Safety Goals and Requirements
Functional safety Concept phase 3-8 Safety functions concept
4 Product development: system level
5 HW 6 SW Allocation Operation Production External 7-6 7-5 level level to other Controllability planning planning measures technologies Development 4-9 Safety validation Product development
Functional safety 4-10 assessment
Release 4-11 for production
7-5 Production In the case of a modification, back to the appropriate Production Operation, service
lifecycle phase After the release for 7-6 and production decommissioning Source: ISO/FDIS 26262-2 – BL18
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 21 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 22 of 69
Safety Lifecycle Overview Product Development
Product Development at the Product Development System Level System, Hardware and Software Safety validation and assessment Production and Operation (Planning)
Source: ISO/FDIS 26262-2 – BL18
Source: ISO/FDIS 26262-4 – BL18
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 23 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 24 of 69 Product Development Product Development
Product Development at the Product Development at the Hardware Level Software Level
ISO 26262-5: Product development at the hardware level
4.7 System Design Scope of ISO 26262-5
Initiation of product development 5.5 at the hardware level
Specification of hardware safety 5.6 requirements
7.5 Production 5.7 Hardware design Operation, service (maintenance 7.6 and repair), and decommissioning
5.8 Evaluation of the hardware architectural metrics
Evaluation of safety goal violations 5.9 Qualification of hardware due to random hardware failures 8.13 components Source: ISO/FDIS 26262-2 – BL18 Source: ISO/FDIS 26262-2 – BL18
5.10 Hardware integration and testing 4.8 Item integration and testing
Source: ISO/FDIS 26262-5 – BL18 Source: ISO/FDIS 26262-6 – BL18
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 25 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 26 of 69
Safety Lifecycle Overview Contents
After Release for Production Who is Method Park? Production Installation Why do we need Safety Standards? Operation Process and Safety demands in Automotive Maintenance and reparation Disassembly Hazard Analysis and Risk Assessment
Functional and Technical Development
Software Process in detail
Tool Qualification
Summary
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 27 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 28 of 69 Hazard Analysis and Risk Assessment Hazard Analysis and Risk Assessment
Risk reduction to an acceptable level 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!) Involve persons with good knowledge and domain experience
Source: IEC 61508-5
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 29 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 30 of 69
Hazard Analysis and Risk Assessment Hazard Analysis and Risk Assessment
Associations of the central concepts Severity – Measure of the extent of harm to an individual in a specific situation
Class S0 S1 S2 S3
Description No Light and Severe and life- Life-threatening injuries injuries moderate threatening injuries (survival uncertain), fatal injuries (survival probable) injuries
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 31 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 32 of 69 Hazard Analysis and Risk Assessment Hazard Analysis and Risk Assessment
Exposure – State of being in Controllability – Avoidance of an operational situation that can the specified harm or damage be hazardous if coincident with through the timely reactions of the failure mode under analysis 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 Event Situations that Situations that Situations that All situations Definition Controllable 99% or more of 90% or more of Less than 90% of all occur less occur a few occur once a that occur in general all drivers or all drivers or drivers or other often than times a year month or more during almost other traffic other traffic traffic participants once a year for the great often for an every drive on participants are participants are are usually able, or for the great majority of average driver average usually able to usually able to barely able, to avoid majority of drivers avoid a specific avoid a specific a specific harm. drivers harm. harm.
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 33 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 34 of 69
Hazard Analysis and Risk Assessment Hazard Analysis and Risk Assessment
Combinations of Severity, C1 C2 C3 Safety Goals Exposure and E1 QM QM QM Top-level safety requirements as a result of the hazard analysis Controllability result in the and risk assessment applicable ASIL. E2 QM QM QM S1 E3 QM QM A Assigned to each identified hazard rated with an ASIL A-D Lead to item characteristics needed to avert hazards or to The ASIL’s influence the E4 QM A B development process of reduce risks associated with the hazards to an acceptable level the items. E1 QM QM QM E2 QM QM A S2 Example for safety goals: Park Brake System QM = Quality Management E3 QM A B ID Safety Goal ASIL No specific ISO 26262 E4 A B C requirement has to be G1 Avoidance of unintended maximum brake force build up at one or D observed E1 QM QM A several wheels during drive and in all environmental conditions E2 QM A B S3 G2 Guarantee the specified parking brake function in use case A If S0 or E0 or C0 is set, no E3 A B C situation "parking on slope" in all environmental conditions ASIL is required (QM). E4 B C D G3 Avoidance of unintended release of the parking brake in use case C situation "parking on slope" in all environmental conditions
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 35 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 36 of 69 Contents Functional Safety Concept
Who is Method Park? Safety Goals and Functional Safety Requirements
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
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 37 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 38 of 69
ASIL Decomposition Architectures
before alternative alternative decomposition ASIL D decompositions ASIL D decompositions ASIL D ASIL D ASIL D ASIL D requirements requirements requirements in 5.4.11 in 5.4.11 in 5.4.11 Example: Three channel structure 2oo3 ASIL D ASIL and 5.4.12
decomposition ASIL C(D) + ASIL A(D) ASIL B(D) + ASIL B(D) ASIL D(D) + QM(D) after decomposition Output Central Circuit 1 before Input alternative decomposition ASIL C decompositions ASIL C Processing ASIL C ASIL C Sensor Circuit Unit Output requirements requirements in 5.4.11 in 5.4.11 Circuit 2 ASIL C ASIL
decomposition ASIL B(C) + ASIL A(C) ASIL C(C) + QM(C) after decomposition Output Central Circuit 1 before Input alternative decomposition Sensor Processing ASILB decompositions ASIL B Circuit ASILB ASIL B Unit Output requirements requirements Circuit 2 in 5.4.11 in 5.4.11 ASIL B ASIL
decomposition ASIL A(B) + ASIL A(B) ASIL B(B) + QM(B) after decomposition Output Central Circuit 1 Input before Sensor Processing decomposition Circuit ASIL A Unit ASIL A Output Circuit 2 requirements in 5.4.11 ASIL A ASIL
decomposition ASIL A(A) + QM(A) after decomposition Actuator
Source: ISO/FDIS 26262-9 – BL18
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 39 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 40 of 69 Product Development at Hardware & Contents Software Level
4-7 System Design Who is Method Park?
Why do we need Safety Standards? Specification of Hardware Safety Specification of Software Safety 5-6 Requirements 6-6 Requirements Important part: 4-7 Hardware-Software Interface Process and Safety demands in Automotive Hardware-Software Specification (HSI) Interface Hazard Analysis and Risk Assessment Specification (HSI) 5-7 Hardware Design 6-7 Software Architecture Design
Software Unit Design and Hardware Architectural Constraints 5-8 6-8 Implementation Functional and Technical Development
Assessment Criteria for Probability Software Unit Testing 5-9 of Violation of Safety Goals 6-9 Software Process in detail 5-10 Hardware Integration and Testing 6-10 Software Integration and Testing
Tool Qualification Verification of Software Safety 6-11 Requirements
Source: ISO/FDIS 26262-4 – BL18 Summary 4-8 Item Integration and Testing
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 41 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 42 of 69
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 A B C D 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 + + + ++
1f Use of unambiguous graphical representation + ++ ++ ++ Detail the hardware-
1g Use of style guides + ++ ++ ++ software interface requirements 1h Use of naming conventions ++ ++ ++ ++
Source: ISO/FDIS 26262-6:2011
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 43 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 44 of 69 Software Architectural Design Software Architectural Design
Goals Principles for software architectural design
ASIL Develop an Architecture that Methods implements the Software A B C D 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 + + + +
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/FDIS 26262-6:2011
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 45 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 46 of 69
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 A B C D A B C D A B C D 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 + ++ ++ ++ Graceful 1b + + ++ ++ degradation 1b Plausibility check + + + ++ 1c Simulation of dynamic parts of the design + + + ++ Independent Detection of data 1c parallel o o + ++ 1c + + + + errors redundancy 1d Prototype generation o o + ++ External Correcting codes 1d o + + ++ 1d + + + + monitoring facility for data 1e Formal verification o o + + Control flow 1e o + ++ ++ monitoring Error handling 1f Control flow analysis + + ++ ++ Diverse software 1f o o + ++ design 1g Data flow analysis + + ++ ++
Error detection Source: ISO/FDIS 26262-6:2011 Source: ISO/FDIS 26262-6:2011
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 47 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 48 of 69 Software Unit Design and Implementation Software Unit Design and Implementation
Goals Design principles for software unit design and implementation
ASIL Methods Specify SW Units based on: A B C D 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 + + ++ ++ 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/FDIS 26262-6:2011
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 49 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 50 of 69
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
Infos: www. misra .org
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 51 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 52 of 69 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 A B C D Requirements- that the software units achieve: 1a ++ ++ ++ ++ based test ASIL Methods Compliance with the software 1b Interface test ++ ++ ++ ++ A B C D 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/FDIS 26262-6:2011 Source: ISO/FDIS 26262-6:2011 Robustness Sufficiency of the resources to support the functionality
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 53 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 54 of 69
Software Unit Testing Software Integration and Testing
Structural coverage metrics at the software unit level Goals
ASIL Methods Integrate SW components A B C D Integration sequence 1a Statement coverage ++ ++ + + Testing of interfaces between components/units 1b Branch coverage + ++ ++ ++
1c MC/DC (Modified Condition/Decision Coverage) + + + ++ Verify correct implementation of the SW Architecture
Source: ISO/FDIS 26262-6:2011
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 55 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 56 of 69 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 A B C D software architectural Methods 1a Function coverage + + ++ ++ design A B C D Compliance with the Requirements- 1a ++ ++ ++ ++ 1b Call coverage + + ++ ++ specification of the based test hardware-software interface 1b Interface test ++ ++ ++ ++
Correct implementation of 1c Fault injection test + + ++ ++ the functionality Resource usage 1d + + + ++ Source: ISO/FDIS 26262-6:2011 Robustness and sufficiency test Back-to-back of the resources to support comparison test 1e + + ++ ++ the functionality between model and code, if applicable
Source: ISO/FDIS 26262-6:2011
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 57 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 58 of 69
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 Coverage of the software A B C D
safety requirements Hardware-in-the- 1a + + ++ ++ loop A pass or fail criteria Electronic control 1b unit network ++ ++ ++ ++ environments
1c Vehicles ++ ++ ++ ++
Source: ISO/FDIS 26262-6:2011
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 59 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 60 of 69 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
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 61 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 62 of 69
Qualification of Software Tools Qualification of Software Tools
To determine the required level of confidence in a software tool, Tool Impact (TI) – Possibility that a safety requirement, perform a use case analysis: allocated to the safety-related item or element, is violated if the Evaluate if a malfunctioning software tool and its erroneous software tool is malfunctioning or producing erroneous output output can lead to the violation of any safety requirement TI1 – no such possibility allocated to the safety-related item or element to be developed TI2 – all other cases Establish probability of preventing or detecting such errors in its output Tool error Detection (TD) – Probability of preventing or Considers measures internal to the software tool (e.g. detecting that the software tool is malfunctioning or producing monitoring) 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 TD2 – medium degree … (e.g. guidelines, tests, reviews) TD3 – all other cases
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 63 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 64 of 69 Qualification of Software Tools Qualification of Software Tools
Tool Confidence Level (TCL) – Based on the values determined Qualification methods:
for the classes of TI and TD ASIL Qualification methods of software tools classified TCL3 A B C D 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/FDIS 26262-8:2011 1d Development in accordance with a safety standard + + ++ ++
ASIL Qualification methods of software tools classified TCL2 A B C D
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/FDIS 26262-8:2011
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 65 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 66 of 69
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
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 67 of 69 © 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 68 of 69 Thank you !
Bernhard Sechser Principal Consultant SPICE & Safety
Method Park Software AG 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
© 2012 Method Park Software AG / Bernhard Sechser / 30.04.2012 / Verlässliche Echtzeitsysteme Slide 69 of 69