Safe Automotive soFtware architEcture (SAFE) Project Presentation SAFE project partners

1. Safe Automotive soFtwarearchitEcture (SAFE) Project Presentation SAFE project partners

2. Content • Motivation • Concept Level • Implementation Level • Organization

3. SAFE – MotivationIssues in Safety Analysis*) The coherency issue • How do safety analysis results relate to the actual design? • How can safety engineers keep track with ongoing evolvements and changes in design models? The plausibility issue • How can a system designer relate a cut set to „his“ model? • How can he understand, how the cut-set can arise? • How can the propagation of a failure be traced in the system? The accuracy issue • How can mission phases be assessed without over-engineering? • How can numerical thresholds be assessed? The completeness issue • How can a safety designer assert, that all minimal cut sets have been identified? • How can it be assessed that all relevant effects have been considered? *) Model-BasedSafety Analysis - OFFIS 2006

4. SAFE – MotivationModel Based Development Safety Analysis Requirements Reuse Functional Model System Architecture Autotest Why not the safety analysis? Autocode HW/SW Architecture Simulation We base the entire development cycle around the model! *) Model-Based Safety Analysis – University of Minnesota

5. SAFE – MotivationModel Based Development Safety Analysis Common Model for Development and Safety Analysis • To represent safety properties and requirements in the same notation of the development models • To perform safety analysis having the possibility to trace back through the results in the system model in order to understand expected behavior Safety analysis based on formal models • Facilitates consistency in safety analysis • Facilitates completeness of safety analysis • Makes safety analysis more systematic and repeatable Reduced manual effort in error-prone areas • Automated support for safety analysis • Explore various failure scenarios

6. SAFE – MotivationModel Based Development Safety Analysis Environment Requirement Geometrical Variability Technical SAFETY Function Logical … … NEW Abstraction Levels Perspectives

7. SAFE – MotivationAdditional perspective - ISO26262 Vehicle Development Vehicle Level (Features) System Level (Functional Blocks) Level of abstraction System Development System Level (Architectural Blocks) Component Level 1-2 (components) Component Development

8. SAFE – MotivationScope and Goals Scope • Automotive electronics architecture (system + software + electronic hardware including electrical distribution system) Goals • Improve dependability from vehicle to component • Ensure process compliance to ISO26262 • at the best cost (automation required, and no over design) • matching AUTOSAR requirements • methods • to reference supplier chain job split, liability and • to respect intellectual property rights • Early evaluation of safety architecture and reuse (quality and cost driven) • Demonstrate preservation of functional design choice (safety oriented) on component architecture

9. 1. Vocabulary 2. Management of functional safety 2-7 Safety management after release for production 2-5 Overall safety management 2-6 Safety management during item development 4. Product development: system level 3. Concept phase 7. Production and operation 3-5 Item definition 4-5 Initiation of product development at the system level 4-11 Release for production 7-5 Production 4-10 Functional safety assessment 3-6 Initiation of the safety lifecycle 7-6 Operation, service and decommissioning 4-6 Specification of the technical safety requirements 4-9 Safety validation 3-7 Hazard analysis andrisk assessment 4-7 System design 4-8 Item integration and testing 3-8 Functional safety concept 6. Product development: software level 5. Product development: hardware level Core processes 6-5 Initiation of product development at the software level 5-5 Initiation of product development at the hardware level 6-6 Specification of software safety requirements 5-6 Specification of hardware safety requirements 6-7 Software architectural design 5-7 Hardware design 6-8 Software unit design and implementation 5-8 Hardware architectural metrics 5-9Evaluation of violation of the safety goal due to random HW failures 6-9 Software unit testing 6-10 Software integration and testing 5-10 Hardware integration and testing 6-11 Software verification 8. Supporting processes 8-5 Interfaces within distributed developments 8-6 Overall management of safety requirements 8-10 Documentation 8-7 Configuration management 8-11 Qualification of software tools 8-8 Change management 8-12 Qualification of software components 8-9 Verification 8-13 Qualification of hardware components 9. ASIL-oriented and safety-oriented analyses 8-14 Proven in use argument 9-5 Requirements decomposition with respect to ASIL tailoring 9-7 Analysis of dependent failures 9-6 Criteria for coexistence of 9-8 Safety analyses 10. (Informative) Guidelines on ISO 26262 SAFE – MotivationScope with respect to ISO26262

10. SAFE – MotivationApproach Developer ISO26262 Requirements Modeling Language 3-7 Hazardanalysisandriskassessment Seamless tool- supported development Interoperable Toolset 3-8 Functionalsafetyconcept Guidelines, Application Rules 4-6 Specificationoftechnicalsafetyrequirements 6-6 Specificationofsoftwaresafetyrequirements 5-6 Specificationofhardwaresafetyrequirements HW-SW Component Models

11. SAFE – Motivation Results Concept Level • Open meta-model for description of system, software, hardware • Assessment process to demonstrate compliance to ISO26262 Implementation Level • Technology Platform, i.e. set of interfaces, plug-ins and tools to realize open meta-model • Industrial use cases demonstrating methods and tools Completive Material • Training Material • Recommendation and Guidelines

12. Content • Motivation • Concept Level • Open Meta-model • AssessmentMethodology • Implementation Level • Organization

13. SAFE – Concept LevelMeta-model for Model based Safety Analysis Modeling Language Safety goals modeling Methods for analysis Variant Management Safety code generation Architecture modeling Interoperable Toolset Hazard analysis, safety goals and ASIL def. Failure and cut-sets analysis Safety Requirement Expression Safety evaluation System and Software models enhancement Safety case documentation Hardware Description safety and multi-criteria architecture benchmarking Guidelines, Application Rules COTS evaluation Integrated Meta-Model ReqIF EAST-ADL AUTOSAR Approach:existing, basetechnologiesareusedandextended

14. SAFE – Concept LevelHazard analysis and risk assessment ISO26262 SAFE – Safety Goal Modeling 3-7 Hazardanalysisandriskassessment Item Definition 3-8 Functionalsafetyconcept Hazard 4-6 Specificationoftechnicalsafetyrequirements Hazardous Event Operational Situation 6-6 Specificationofsoftwaresafetyrequirements 5-6 Specificationofhardwaresafetyrequirements ASIL Safety Goal QM A D B C

15. SAFE – Concept LevelFunctional safety concept Specification of the functional safety requirements … and their interaction necessary to achieve the safety goals. ISO26262 SAFE - Functionalsafetyconcept 3-7 Hazardanalysisandriskassessment Safety Goal 3-8 Functionalsafetyconcept Safe State 4-6 Specificationoftechnicalsafetyrequirements 6-6 Specificationofsoftwaresafetyrequirements 5-6 Specificationofhardwaresafetyrequirements ASIL FunctionalArchitecture Item FunctionalSafetyRequirement QM A D B C

16. SAFE – Concept LevelTechnical safety concept Specification of the technical safety requirements and their allocation to system elements for implementation by the system design. ISO26262 SAFE – Technical safetyconcept 3-7 Hazardanalysisandriskassessment 3-8 Functionalsafetyconcept FunctionalArchitecture Item FunctionalSafetyRequirement 4-6 Specificationoftechnicalsafetyrequirements Technical Architecture Item Technical SafetyRequirement 6-6 Specificationofsoftwaresafetyrequirements 5-6 Specificationofhardwaresafetyrequirements

17. SAFE – Concept LevelHW-SW Safety concept SAFE – Architecturemodeling ISO26262 3-7 Hazardanalysisandriskassessment Technical Architecture Item Technical SafetyRequirement 3-8 Functionalsafetyconcept HW SW HW SafetyRequirement SW SafetyRequirement 4-6 Specificationoftechnicalsafetyrequirements HW – SW Interface Specification 6-6 Specificationofsoftwaresafetyrequirements 5-6 Specificationofhardwaresafetyrequirements SW Architecture Item HW Architecture Item

18. SAFE – Concept LevelSummary: Safety Requirement Expression Modeling Language Functional analysis at vehicle level Interoperable Toolset Safety Goals Functional Safety Requirements Technical Safety Requirements HW/SW Safety Requirements Hazard analysis and risk assessment Guidelines, Application Rules System design & Architecture Functional safety concept Component design & Architecture Technical safety concept HW/SW HW/SW safety concept

19. SAFE – Concept LevelMeta-model integration approach Configuration System Process Validation Requirements Hardware Software References Hazards Dysfunctional Analysis

20. Content • Motivation • Concept Level • Open Meta-model • AssessmentMethodology • Implementation Level • Organization

21. SAFE – Concept LevelAssessment Methodology Modelling Language Objectives • Tackle the introduction of a comprehensive functional safety process according to ISO26262 to a real engineering team • Assessment procedure for functional safety • Process step and adequate measures to allow seamless implementation in the different engineering disciplines Interoperable Toolset Guidelines, Application Rules

22. Content • Motivation • Concept Level • Implementation Level • Technology Platform • Industrial use cases • Organization

23. SAFE – Concept LevelMeta-model for Model based Safety Analysis Modelling Language Tool Interfacing SpecializedPlugins Interoperable Toolset Autofocus (Fortiss) Traceability and requirement import CATIA V6 (Dassault Systèmes) Failure and cutsetanalysis Guidelines, Application Rules HeRaClea (OFFIS) Variabilityseamlessintegration PREEvision (Vector) pure::variants (pure-systems) Safety and multi-criteria architecture benchmarking Safety code generator SAFE Meta-Model Implementation RMF (ReqIFmodelingframework) EATOP (EAST-ADL toolplatform) ARTOP (AUTOSAR toolplatform) Platform Software platform for mixed criticality Sphinx Eclipse

24. Content • Motivation • Concept Level • Implementation Level • Technology Platform • Industrial use cases • Organization

25. SAFE – WP 5Evaluation Scenarios Mixed criticality software layer Project Targets Tier1’s perspective (eGas & Electrical Brake) safety analysis of a system with MCU and MCAL • Definition ofassessmentcriteria SAFE Requirements (WP2) loop safety analysis at high level safety code generation Requirements on WP 3/4/6 Evaluation Scenarios (WP5) WP 3/4/6 results

26. Content • Motivation • Concept Level • Implementation Level • Organization

27. SAFE – Project OrganizationConsortium • Accreditation body • TÜV NORD Mobilität (G) • Academia • Fortiss (G) • FZI, Karlsruhe University (Ge) • OFFIS (Ge) • LaBRi, Bordeaux University (Fr) • Engineering Partner • AVL Software & Function (G) • Silicon Supplier • Infineon Technologies (G) • Tool suppliers & SME • Aquintos (G) • DassaultSystemes (Fr) • ITEMIS France (Fr) • Pure Systems (G) • TTTEch (Aut) OEMs • BMW-CarIT (G) Tiers1 • Continental Automotive (G) • Continental Automotive (Fr) • Continental Teves (G) • Valeo EEM(Fr) • ZF (G)

28. SAFE – Project OrganizationBasic Data • Duration: 36 months • Timing: 01.07.2011 – 30.06.2014 • Partners: 18 • Countries: Austria, France, Germany • Budget: 12 M€ • Coordinator: Dr. Stefan Voget, Continental Automotive (G) • OEM Advisory Board • Audi (G) • Daimler (G) • Fiat (It) • Renault (Fr) • Volvo Technology (Swe)

29. SAFE – Project OrganizationWork-Package Structure WP1: Project Management, Exploitation WP5: Evaluation Scenarios WP2: Requirement Elicitation Modelling Language WP3: Model Based Development for Functional Safety Interoperable Toolset WP4: Technology Platform Guidelines, Application Rules WP6: Methodology & Application Rules WP7: Training, Dissemination

30. MS2 (06.12) MS4 (12.12) MS6 (07.13) MS8 (02.14) MS10 (06.14) SAFE – Project OrganizationMilestones M3 (09.12) MS9 (04.14) MS7 (12.13) MS5 (02.13) MS1 (04.12) Requirements Loop 2 Meta model and method definition Loop 3 Development of tool Evaluation Meta model and method definition Loop 1 Development of tool Evaluation Meta model and method definition Development of tool support Evaluation Platform v1 Platform v2 Platform v3

31. SAFE – MiscellaneousLink to SAFE Project contract regulations • All SAFE parties give each other the right to integrate results into AUTOSAR • The SAFE parties grant to all AUTOSAR partners & members the rights to use the results of SAFE • The only way of providing input to AUTOSAR is that a SAFE party submits that input to AUTOSAR. AUTOSAR status • AUTOSAR R4.0 includes safety mechanism and documentation report SAFE provides to AUTOSAR • Set up link to ISO26262 and engineering processes • Provide complete overview on system level • Complement hardware description

32. SAFE – Motivation Market Impact OEMs • Methods and tools that will give the flexibility to develop new architectures with a Safety In the Loop approach • Possibility to deploy new architectures with a shorter time to market. First Tiers • Possibility to demonstrate safety conformity of developed ECUs and automotive subsystems • Optimize the cost of the development • Allow reduction of re-certification due to late changes Semiconductor manufacturers and IP hardware providers • Help to develop and focus on new component architectures capable to support ISO26262. Tool vendors • Opportunity to develop an integrated tool-chain, including design and safety analysis in a single process • Easy to adapt the tools to other embedded domains with strong concerns in Safety like Aerospace and Train.

33. Content • BACKUP

34. SAFE – WP 2Requirements Elicitation Filter: ProjectTargets ISO26262 • Requirements on model baseddevelopment > 500 requirements SAFE Project Requirements State oftheart • Parallel projectstocooperatewith UseCases • Exemplarilyindustrialusecases > 60 requirements

35. Thank you for your attentionThis document is based on the SAFE project in the framework of the ITEA2, EUREKA cluster program Σ! 3674. The work has been funded by the German Ministry for Education and Research (BMBF) under the funding ID 01IS11019, and by the French Ministry of the Economy and Finance (DGCIS). The responsibility for the content rests with the authors.