EAST-ADL dependability package illustrated by a brake example Dr. Stefan Voget

1. EAST-ADL dependability package illustrated by a brake example Dr. Stefan Voget

2. Content • The Story • The Example • ArchitectureOverview • System Model • Safety Modeling

3. The StoryFrom Requirement to Implementation Model Based Development Safety Analysis Dependability FunctionalSafetyConcept ServiceBrake SystemModel FunctionaSafetyRequirement Safety Goal Features Model VehicleLevel Requirement Brake Pedal shall not request deviating braking level Functional Safety concept AnalysisLevel Derive Abstract functions TechnicalSafetyConcept DeriveReq ServiceBrake DesignLevel Technical Safety concept Concrete functions TechnicalSafetyRequirement Implementation Level Requirement BrakePedalSensors shall be indipendent Refine Software Architecture DeriveReq Requirement Fault Tolerant Time Interval shall be at least 100 ms

4. The StoryFrom Requirement to Implementation Safety Modeling System Model Vehicle Model Functional Requirements Hazard & Risk Analysis Behavior Safety Goals Functional Safety Requirements Analysis Level Technical Safety Requirements Design Level HW/SW SafetyRequirements Implementation Level (HW/SW)

5. The StoryDistribution to meta-model standards ReqIF Requirement SAFE EAST-ADL FunctionalRequirement Requirement Item HazardandRiskanalysis Safety Goal Functionalsafetyconcept Analysis Function FunctionalSafetyRequirement DerivedRequirement Technical safetyconcept Design Function Technical SafetyRequirement DerivedRequirement Satisfyanalysis (Error model, FMEA, FTA, …) Refinesafetyconcept AUTOSAR SW / HW SafetyRequirement DerivedRequirement SW Configuration Code

6. Content • The Story • The Example • ArchitectureOverview • System Model • Safety Modeling

7. The ExampleReferences Thispresentation will showextracts out of a brakesystem. Thisexamplehasalreadybeenpublishedseveraltimestoillustratetheuseof EAST-ADL. Togetmoreinformationabouttheexamplesee: Atesstproject • http://www.atesst.org/home/liblocal/docs/ows/I6_ATESST2_OWS_Validators.pdf • http://www.atesst.org/home/liblocal/docs/ATESST2_Deliverable_D6.1.2_V1.0.pdf Maenadproject • http://maenad.eu/public_pw/conceptpresentations/MAENAD_Validator_RegenerativeBraking_2011.pdf The exampleismodeledwith a graphicaleditorbased on EATOP usingthe EAST-ADL language 2.1.11. EATOP • http://eclipse.org/proposals/modeling.eatop/ • http://code.google.com/a/eclipselabs.org/p/eclipse-auto-iwg/ EAST-ADL • http://www.east-adl.info/

8. The ExampleOverview The brakesystemhasbeenmodeled in severalversionsbefore. In thispresentationwetake a versionincludingservicebrakeandparkingbrake. Itisnottheintentionofthispresentationto model thebrakesystemcompleteandcorrect. Intention istoillustratethe EAST-ADL principlesforsafetymodelingwith a realisticsystem. Therefore, someextensions in thesafetymodelingandanalysispartaredonecomparedtopreviouspublications. See (2)

9. Content • The Story • The Example • ArchitectureOverview • System Model • Safety Modeling

10. ArchitectureOverview • The architectureiscomposed in packages. • RequirementsModel:onepackageforfunctionalandoneforsafetyrequirements • Behavior: enclosesmainlythemodesneededforthehazardandriskanalysis • System Model: structurestheabstractionlevels, definestherootofthearchitectures, • enclosesvehiclefeature model andtheallocation model • Analysis Type Package: collects all analysisfunctiontypesandtheirparts • HardwareComponentTypePackage:collects all hardwarecomponenttypesandtheirparts • DesignTypePackage: collects all design functiontypesandtheirparts • DependabilityVehicleLevel: hazardandriskanalysis • DependabiliyAnalysisLevel: derivedsafetyrequirementsallocatedtofunctionalsafetyconcept • DependabilityDesignLevel: derivedsafetyrequirementsallocatedtotechnicalsafetyconcept • DependabilitySafetyCase:safetycasemodeling

11. ArchitectureOverviewWearehere Vehicle Model Functional Requirements Hazard & Risk Analysis Behavior Safety Goal Functional Safety Requirement Analysis Level Technical Safety Requirement Design Level

12. ArchitectureOverviewFunctionalRequirements

13. Content • The Story • The Example • ArchitectureOverview • System Model • Safety Modeling

14. System ModelOverview • The System Model • structurestheabstractionlevels, • definestherootofthearchitectures • enclosesthevehiclefeature model • enclosestheallocation model • Vehiclelevelwhichcontainsthevehiclefeature model • Analysis levelcontainsthefunctionalanalysisarchitecture, i.e. therootofthearchitectureelements on thislevel • Design levelcontains • thefunctional design architecture • thehardwarearchitecture • theallocation model • Implementationlevelreferstothe AUTOSAR model

15. System ModelWearehere Vehicle Model Functional Requirements Hazard & Risk Analysis Behavior Safety Goal Functional Safety Requirement Analysis Level Technical Safety Requirement Design Level

16. System ModelVehicle Feature model

17. System ModelWearehere Vehicle Model Functional Requirements Hazard & Risk Analysis Behavior Safety Goal Functional Safety Requirement Analysis Level Technical Safety Requirement Design Level

18. System ModelLibrary of Analysis FunctionTypes EPB_FAA (electronic park brake) istherootanalysisfunction type. Itisthe type ofthe FAA element, whichis a prototype. i

19. System ModelParts oftheFunctional Analysis Architecture Thispictureshowstheinternalsofthe EPB_FAA. These prototypesarepartsofthe EPB_FAA type. i

20. System ModelParts ofthevehiclecontrolsystem Thispictureshowstheinternalsofthe VCS-Function. These prototypesarepartsofthe VCS-Function type. i

21. System ModelSummaryof so farshownhierarchy System Model VCS-Function EPB_FAA contains Types Is of type part part Is of type Prototypes pVCSFunction pObserver HEMB_FAA (Functional Analysis Architecture) The chainof „isof type“ and „part“ relationshipsbetweentypesandprototypesdefines a hierarchyofanalysisfunctionprototypes. i

22. System ModelWearehere Vehicle Model Functional Requirements Hazard & Risk Analysis Behavior Safety Goal Functional Safety Requirement Analysis Level Technical Safety Requirement Design Level

23. System ModelLibrary of Design FunctionTypes EPB_FDA (electronic park brake) istheroot design function type. Itisthe type ofthe FDA element, whichis a prototype. i

24. System ModelParts oftheFunctional Design Architecture Thispictureshowstheinternalsofthe EPB_FDA. These prototypesarepartsofthe EPB_FDA type. i

25. System ModelLibrary of Hardware ComponentTypes EPB_HDA (electronic park brake) istheroothardwarecomponent type. Itisthe type ofthehardwarearchitectureelement, whichis a prototype. i

26. System ModelParts ofthe Hardware Architecture Thispictureshowstheinternalsofthe EPB_HDA. These prototypesarepartsofthe EPB_HDA type. i

27. System ModelAllocation The allocationmapsthe design functionstohardware. Thisisthesystemconfiguration on design level, whichisdone on implementationlevel in AUTOSAR. i

28. Content • The Story • The Example • ArchitectureOverview • System Model • Safety Modeling

29. SafetyModelingHazard analysis and risk analysis 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 A D B C

30. Safety ModelingWearehere Vehicle Model Functional Requirements Hazard & Risk Analysis Behavior Safety Goal Functional Safety Requirement Analysis Level Technical Safety Requirement Design Level

31. Safety ModelingBehaviorPackage The behaviorpackagedefinesthemodeswhich will beusedtodefinescenarios in thehazardandriskanalysis. i

32. Safety ModelingWearehere Vehicle Model Functional Requirements Hazard & Risk Analysis Behavior Safety Goal Functional Safety Requirement Analysis Level Technical Safety Requirement Design Level

33. Safety ModelingHazardandRisk Analysis Fromthe item „parkingbrake“ 8 safetygoalsarederived Fromthe item „servicebrake“ thesafetygoal „Do not applybrakeforceunlessdriverbrakesisderived. i i

34. SafetyModelingFunctional 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 ASIL Safe State 4-6 Specificationoftechnicalsafetyrequirements A D B C 6-6 Specificationofsoftwaresafetyrequirements 5-6 Specificationofhardwaresafetyrequirements FunctionalArchitecture Item FunctionalSafetyRequirement

35. Safety ModelingWearehere Vehicle Model Functional Requirements Hazard & Risk Analysis Behavior Safety Goal Functional Safety Requirement Analysis Level Technical Safety Requirement Design Level

36. Safety ModelingDerived safety requirements Safetygoalsare top levelsafetyrequirements. Theyarederivedbysafetyrequirements on analysislevel. These analysislevelsafetyrequirementsarederivedbysafetyrequirements on design level. i

37. Safety ModelingFunctionalSafetyConcept On analysislevel, thefunctionalsafetyconceptcontainsthesafetyrequirementsderivedfromthesafetygoal. The satisfyrelationshiptracestheirfulfillment on horizontal level. i

38. Safety ModelingWearehere Vehicle Model Functional Requirements Hazard & Risk Analysis Behavior Safety Goal Functional Safety Requirement Analysis Level Technical Safety Requirement Design Level

39. Safety ModelingTechnical SafetyConcept 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

40. Safety ModelingTechnical SafetyConcept On design level, thetechnicalsafetyconceptcontainsthesafetyrequirementsderivedfromthesafetyrequirements on analysislevel. The satisfyrelationshiptracestheirfulfillment on horizontal level. i

41. Safety ModelingSafety Goal Fulfillment These viewsshowthesafetyrequirementstracingtree. The satisfyingarchitectureelementsareshownasleavesofthetree. In case a safetyrequirementissatisfied, itisshown in greentextcolor, otherwise in redtextcolor. Yellowicon: safetygoal Blue icon: derivedsafetyrequirement Redicon: analysisfunction Green icon: design function i

42. 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.