SAFE-Safe Automotive SoFtware ArchitEcture

Safe Automotive soFtwarearchitEcture(SAFE)Project PresentationSAFE project partners

Content Motivation Project Organization Work Packages MiscellaneousITEA 2 10039

SAFE – MotivationScope and GoalsScope: Automotive electronics architecture(system software electronic hardware including electrical distributionsystem)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) oncomponent architectureITEA 2 10039

SAFE – MotivationScope and Goals1. Vocabulary2-5 Overall safety management2-6 Safety management during item development3. Concept phase3-5 Item definition3-6 Initiation of the safety lifecycle3-7 Hazard analysis and riskassessment3-8 Functional safetyconcept2-7 Safety management after release forproduction4. Product development: system level4-5 Initiation of productdevelopment at the system level4-6 Specification of the technicalsafety requirements4-7 System design4-11 Release for production4-10 Functional safetyassessment4-9 Safety validation7. Production and operation7-5 Production7-6 Operation, service anddecommissioning4-8 Item integration and testing5. Product development:hardware level6. Product development:software level5-5 Initiation of productdevelopment at the hardware level5-6 Specification of hardwaresafety requirements5-7 Hardware design5-8 Hardware architectural metrics5-9 Evaluation of violation of thesafety goal due to random HWfailures5-10 Hardware integration andtesting6-5 Initiation of productdevelopment at the software level6-6 Specification of software safetyrequirements6-7 Software architectural design6-8 Software unit design andimplementation6-9 Software unit testing6-10 Software integration andtesting6-11 Software verificationCore processes2. Management of functional safety8. Supporting processes8-5 Interfaces within distributed developments8-6 Overall management of safety requirements8-7 Configuration management8-8 Change management8-9 Verification8-10 Documentation8-11 Qualification of software tools8-12 Qualification of software components8-13 Qualification of hardware components8-14 Proven in use argument9. ASIL-oriented and safety-oriented analyses9-5 Requirements decomposition with respect to ASIL tailoring9-6 Criteria for coexistence of9-7 Analysis of dependent failures9-8 Safety analyses10. (Informative) Guidelines on ISO 26262ITEA 2 10039

SAFE – MotivationProject geInteroperableToolsetEAST-ADL Verificationand Validation ModelV&V CasesTargetsGuidelines,Application RulesEAST-ADL RequirementsModelTargetsReq &ConstraintsSatisfiesSatisfiesEAST-ADL ArchitectureModelComp ATargetsEAST-ADL Error ModelSafetyRequirementsDerivesA Rel BHazardComp BPropagatesThroughErrorModel ATargetsErrModel BPropagatesToErr BehaviorHW-SW ComponentModelsITEA 2 10039

SAFE – MotivationApproachesTo achieve the goals, SAFE will bring a new approach based on: Model based technology to anticipate safety evaluationProcess assessment to demonstrate conformance to the standardIntegrated workflow including design and safety analysis in a fullytraceable and automated tool chainConcurrent engineering experience on new technology to ensureinteroperability of processes within the supply chainOptimization of verification process, using new technology for assessment(automated FTA, architecture benchmark, .)Guidance and design guidelines to define safety patterns– architecture, AUTOSAR platform configuration, product line management,independence and non interference of functions and components, codegenerator .ITEA 2 10039

SAFE – MotivationExpected Results Open meta model for description of system, software, hardware Technology Platform Training Material Industrial use cases demonstrating methods and tools Assessment process to demonstrate compliance to ISO26262 Recommendation and Guidelines for– System decomposition for effective design of safety mechanism– Compliance with architecture constraints and safety mechanism– AUTOSAR platform configuration for safety– Inclusion of COTS in a safety systemITEA 2 10039

SAFE – MotivationMarket ImpactOEMs Methods and tools that will give the flexibility to develop new architectures witha 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 automotivesubsystems Optimize the cost of the development Allow reduction of re-certification due to late changesSemiconductor manufacturers and IP hardware providers Help to develop and focus on new component architectures capable to supportISO26262.Tool vendors Opportunity to develop an integrated tool-chain, including design and safetyanalysis in a single process Easy to adapt the tools to other embedded domains with strong concerns inSafety like Aerospace and Train.ITEA 2 10039

Content Motivation Project Organization Work Packages MiscellaneousITEA 2 10039

SAFE – Project OrganizationBasic Data tor:36 months01.07.2011 – 30.06.201418Austria, France, Germany12 M Dr. Stefan Voget, Continental Automotive (G) OEM Advisory Board Audi (G) Daimler (G) Fiat (It) Renault (Fr) Volvo Technology (Swe)ITEA 2 10039

SAFE – Project OrganizationConsortiumOEMsEngineering PartnerAccreditation body BMW-CarIT (G) AVL Software &Function (G) TÜV NORD Mobilität(G)Silicon SupplierAcademiaTiers1 ContinentalAutomotive (G) ContinentalAutomotive (Fr) Infineon Technologies Fortiss (G)(G) FZI, KarlsruheUniversity (Ge) Continental Teves (G) Tool suppliers & SME Valeo EEM(Fr) Aquintos (G) ZF (G) Dassault Systemes(Fr) OFFIS (Ge) LaBRi, BordeauxUniversity (Fr) ITEMIS France (Fr) Pure Systems (G) TTTEch (Aut)ITEA 2 10039

SAFE – Project OrganizationWork-Package StructureWP3:Model Based Developmentfor Functional SafetyWP4:Technology PlatformWP6:Methodology &Application es,Application RulesWP5: Evaluation ScenariosWP2: Requirement ElicitationWP1: Project Management, ExploitationWP7: Training, DisseminationITEA 2 10039

SAFE – Project 2)M3(09.12)MS6 (07.13)MS5 (02.13)MS7(12.13)MS8MS10(02.14)(06.14)MS9 (04.14)RequirementsMeta model andmethod definitionDevelopment of toolEvaluationMeta model andmethod definitionDevelopment of toolEvaluationMeta model and methoddefinitionDevelopment of tool A 2 10039

Content Motivation Project Organization Work Packages–––––WP2 – Requirements ElicitationWP3 – Model Based Development for Functional SafetyWP4 – Technology PlatformWP5 – Evaluation ScenariosWP6 – Methodology & Application Rules MiscellaneousITEA 2 10039

Content Work Packages–––––WP2 – Requirements ElicitationWP3 – Model Based Development for Functional SafetyWP4 – Technology PlatformWP5 – Evaluation ScenariosWP6 – Methodology & Application RulesITEA 2 10039

SAFE – WP 2Requirements ElicitationISO26262Requirements onmodel baseddevelopmentFilter:Project Targets 500requirementsState of the artParallel projects tocooperate withSAFEProjectRequirementsUse CasesExemplarilyindustrial use cases 60requirementsITEA 2 10039

Content Work Packages–––––WP2 – Requirements ElicitationWP3 – Model Based Development for Functional SafetyWP4 – Technology PlatformWP5 – Evaluation ScenariosWP6 – Methodology & Application RulesITEA 2 10039

ReqIFEAST-ADLMethodsfor analysisAUTOSARSafety code generationVariant Managementsafety and multimulti-criteriaarchitecturebenchmarkingSafety evaluationArchitecturemodellingFailure and cutcut-setsanalysisCOTS evaluationHardware DescriptionSafety goalsmodellingSystem and Softwaremodels enhancementSafety casedocumentationSafety RequirementExpressionHazard analysis, safetygoals and ASIL def.SAFE – WP 3Model based dev. for Functional nes,Application RulesImplemented inMeta Model DefinitionApproach: base technologies are used and extendedIP-XACTITEA 2 10039

SAFE – WP 3Meta-model integration References30.06.201230.04.201328.02.2014 Initial release Intermediary release Final releaseITEA 2 10039

SAFE – WP 3Use meta-model backbone for SAFESAFE TechnologyPlatformReq-IFUSESMM:EAST-ADLSAFE projectUSESToolplatform:SAFE project&Eclipse A-IWGMM:OMGToolplatform: Eclipse RMF projectMM:EAST-ADL AssociationToolplatform: EATOP (In creation phase)AUTOSARUSESMM:AUTOSARToolplatform: ARTOPIP-XACTUSESMM:IEEE 1685-2009Toolplatform: XMLSchema, Eclipse EditorITEA 2 10039

Content Work Packages–––––WP2 – Requirements ElicitationWP3 – Model Based Development for Functional SafetyWP4 – Technology PlatformWP5 – Evaluation ScenariosWP6 – Methodology & Application RulesITEA 2 10039

SAFE – WP 4Technology Platform – Functional ed PluginsTraceability and requirement importBehavioural translatorFailure and cutset analysisGuidelines,Application RulesPlatformVariability seamless integrationSafety and multi-criteriaarchitecture benchmarkingSafety code generatorSoftwareplatform ionMetamodel implementationITEA 2 10039

SAFE – WP 4Technology Platform – Architectural ViewSAFE PluginSAFE PluginSAFE PluginSAFE PluginSAFE Technology Platform(Req IF)ValidationEATOP (EAST-ADL)EAST-ADL ExplorerEAST-ADL Meta Model ImplementationSerializationAbstraction level M2MEAST-ADL EditorTool AdaptersARTOP(AUTOSAR)DSDP(IP-XACT)User Group that implementsthe AUTOSAR meta-model inan Eclipse based platform.SPHINXRMFEclipseITEA 2 10039

SAFE WP4 - technology platformMeta Model ImplementationGoals & expected results Based on existing meta-models (EAST-ADL2/SysML, AUTOSAR,Matlab/ Simulink, SystemC, IP-XACT) Enrich them with new concepts to support– failure description, failure mode analysis, and other information necessary toperform safety analysis Definition in EMF/Ecore, generation of corresponding model and editplug-ins in Java Integration in to Artop/Sphinx platform Model-to-model transformations from existing meta-models to SAFEmeta-model Model-to-model transformation from SAFE meta-model to UML2ITEA 2 10039

SAFE WP4 - technology platformSpecialized plug-in realization Traceability and requirement import– Requirement import from Doors and Requirement Interchange format– Traceability between artifacts allowing linkage of SAFE meta-model withalready existing modeling concepts (IP-XACT, AUTOSAR) Behavioural Translator– Dependency analysis on behavioural Simulink/ StateFlow models (optionalSystemC, UML2 state chart diagrams)– Graphs capturing failure propagation from initial errors to resulting hazardousevents Model Based Failure and Cut-set AnalysisVariant seamless integrationSafety and multi criteria architecture modelling and benchmarkingSafety code generationITEA 2 10039

SAFE WP4 - technology platformSpecialized plug-in realization Traceability and requirement importBehavioural TranslatorModel Based Failure and Cut-set Analysis– Analysis of quantitative failure propagation mechanism and model basedfailure propagation (FMEA, FTA) including backward annotation on the initialmodels– Generate Altarica code from the model that will generate analysis results(FTA)– XML connector to the FTA/FMEA generator adopted from SPEEDS projectresults, built from fault injection and analysis of propagation Variant seamless integrationSafety and multi criteria architecture modelling and benchmarkingSafety code generationITEA 2 10039