EAST-ADL Introduction. Support for ISO26262

Transcription

1 EAST-ADL Introduction Support for ISO26262

2 Environment Model EAST-ADL Overview SystemModel Vehicle TechnicalFeatureModel Analysis FunctionalAnalysisArchitecture Design FunctionalDesignArchitecture HardwareDesignArchitecture Implementation EAST-ADL defines an Engineering information structure Feature content Functional content Software architecture Requirements Variability Safety information V&V Information Behavior Application SW Basic SW HW Data exchange over ports Allocation 2

3 Environment Model Requirements Variability Timing EAST-ADL+ Representation SystemModel Vehicle TechnicalFeatureModel Analysis FunctionalAnalysisArchitecture Features of the vehicle Abstract functions Chassis Extensions Steer Brake Cruise TechnicalFeatureModel <<AnalysisArchitecture>> DemonstratorAA <<FunctionalAnalysisArchitecture>> DemoFAA <<FunctionalDevice>> BrakePedal VehicleSpeed <<ADLFunction>> <<ADLFunction>> AbstractABSFrontLeft <<FunctionalDevice>> BrakeAlgorithm BrakeFrontLeft <<FunctionalDevice>> WheelSensorFrontLeft Design FunctionalDesignArchitecture HardwareDesignArchitecture Hardware topology, concrete functions, allocation to nodes FunctionalDesignArchitecture <<LocalDeviceManager>> <<BSWFunction>> BrakePedal PedalIO VehicleSpeed <<DesignFunction>> <<DesignFunction>> <<LocalDeviceManager>> <<BSWFunction>> ABSFrontLeft BrakeController BrakeActuatorFL BrakeIO <<LocalDeviceManager>> <<BSWFunction>> WheelSensorFL WSensIO <<Sensor>> <<ECUNode>> Pedal PedalNode HardwareDesignArchitecture <<ECUNoder>> WheelNode <<HWFunction>> BrakePedal <<HWFunction>> BrakeFrontLeft <<HWFunction>> WheelSensorFrontLeft <<Actuator>> Brake Implementation Application SW Basic Software SW Architecture HW as represented Data exchange over ports by Allocation SWComposition <<SensorSWC>> BrakePedal VehicleSpeed <<SWC>> <<SWC>> ABSFrontLeft BaseBrake <<LocalDeviceManager>> WheelSensorFL <<Realize>> <<ActuatorSWC>> Brake 3

4 Environment Model Requirements Variability Timing EAST-ADL Extensions SystemModel Extensions Vehicle TechnicalFeatureModel Analysis FunctionalAnalysisArchitecture Design FunctionalDesignArchitecture HardwareDesignArchitecture Implementation Application SW Basic SW HW Data exchange over ports Allocation 4

5 Environment Model Requirements Variability Timing EAST-ADL Extensions SystemModel Vehicle TechnicalFeatureModel Extensions Analysis FunctionalAnalysisArchitecture Design FunctionalDesignArchitecture HardwareDesignArchitecture Implementation Application SW Basic SW HW Data exchange over ports Allocation 5

6 EAST-ADL vs EAST-ADL For Features, Functional Architecture and Topology For Software Architecture and Execution Platform 6

7 EAST-ADL vs Different Abstraction s: EAST-ADL complements with early phase information Different Engineering Information Scope: EAST-ADL complements Requirements Engineering Variant Management Behaviour (nominal/error) Timing Safety Same Meta-Metamodel Enterprise Architect model used for both Same file exchange ARXML-EAXML Same tool infrastructure possible ARTOP-EATOP Scope in depending on version 7

8 EAST-ADL Related Projects ADAMS EDONA TIMMO2 SAFE CESAR TIMMO EAST-EEA ATESST ATESST2 MAENAD JASPAR EAST-ADL Association EEA AIL UML2 Titus SYSML AADL UML2 SYSML AADL EAST-ADL EAST-ADL EAST-ADL2 EAST-ADL 2.1 EAST-ADL 2.x 8

9 ISO reference life cycle 9

10 Six ISO26262 Concerns 1. Concept Phase Safety Goals Risk assessment 2. Concept Phase Functional Safety Concept Topology-independent Solution 3. Product Development Technical Safety Concept Preliminary System solution 4. Product Development Hardware and Software Detailed hardware and software architecture 5. Safety Element out of Context Matching ASIL with ASIL 6. Supplier-OEM Exchange Matching ASIL with ASIL 10

11 Product development Concept phase 8-6 Specification and management of safety requirements Specification and management of safety requirements ISO What to handle for each phase 3-7 Hazard analysis and risk assessment Hazard analysis and risk assessment 3-7 Hazard analysis and risk assessment Specification of safety goals Focus on functional objectives and not technological solutions 3-8 Functional safety concept Specification of functional safety requirements Realization by high level architectural elements without notion of HW 4-6 Specification of technical safety requirements Specification of technical safety requirements 5-6 Specification of hardware 6-6 Specification of software safety requirements safety requirements Introducing HW & SW in architecture Implementation of SW/HW Hardware safety requirements Software safety requirements 12

12 What to handle on each abstraction level Vehicle Analysis Design Implementation Operational Focus on functional objectives and not technological solutions Realization by high level architectural elements without notion of HW Introducing HW & SW in architecture Implementation of SW/HW 13

13 Environment Model Requirements Variability Timing 1. Safety Goals: Vehicle Part 3.7 artifacts in EAST-ADL Vehicle SystemModel Vehicle TechnicalFeatureModel Analysis Analysis FunctionalAnalysisArchitecture Design Design FunctionalDesignArchitecture HardwareDesignArchitecture Implementation Implementation Application SW Basic SW HW 15

14 Item Definition Vehicle DemoVehicleVL TechnicalFeatureModel VehicleRoot Chassis Requirements Requirement PB force shall be applied when parking brake function is active Satisfy Brakes CruiseControl ActiveSuspension ServiceBrake ParkingBrake Item ItemEPB Basic Advanced Item ItemSB 16

15 Item Definition 17

16 Preliminary Hazard Analysis Vehicle FeatureModel Feature ParkingBrake Item ItemPB Item ItemSB Feature ServiceBrake FeatureFlaw BrakeForceDeviates from request >60% Satisfy NonFulfilledRequirement Requirement Brake force shall be applied when brakes are activated Hazard SuddenLossofBraking HazardousEvent + SuddenLossofBrakinginSlope + Controllability=C3 + Severity=S3 + Exposure=E4 + ASIL= ASIL C DerivedFrom SafetyGoal + EPB_Goal1 + Brake force shall not be below 40% of driver request + ASIL=ASIL C + safestate: none OperatingMode EnvironmentSituation BrakeActivated Slope TrafficSituation OperatingSituationUseCase AdjacentVehicle HighwayDriving 18

17 Environment Model Requirements Variability Timing 2. Functional Safety Concept: Analysis Part 3.8 artifacts in EAST-ADL Vehicle SystemModel Vehicle TechnicalFeatureModel Analysis Analysis FunctionalAnalysisArchitecture Design Design FunctionalDesignArchitecture HardwareDesignArchitecture Implementation Implementation Application SW Basic SW HW 19

18 Safety Modelling Basic Concept SafetyConstraint ASILValue FaultFailure How sure can I be to avoid something unsafe, and where in the architecture does this apply Core Model EAST-ADL ErrorModel EAST-ADL core ErrorModel core 22

19 Functional Safety Concept TechnicalFeatureModel Feature ParkingBrake Feature ItemServiceBrake ItemParkingBrake SafetyGoal EPB_SG1 ASIL=ASILC ServiceBrake Satisfy Requirement Brake force shall not be below 40% of driver request Goal FunctionalAnalysisArchitecture BrakeFunction BrakeRequest Brake Pedal ServiceBrakeCtrl BrakeGovernor BrakeActuator Satisfy Satisfy DeriveReq Requirement Brake command shall not deviate more than 60% from requested braking level DeriveReq DeriveReq RefineReq Requirement Brake request shall not deviate more than 60% from pedal command SafetyConstraint ASIL=C FunctionaSafetyRequirement FunctionaSafetyRequirement FunctionaSafetyRequirement FunctionalSafetyConcept ServiceBrake Satisfy RefineReq Requirement BrakeActuator force shall not deviate more than 60% from requested level RefineReq SafetyConstraint ASIL=C SafetyConstraint ASIL=C 23

20 Functional Safety Requirement Functional Analysis Architecture Requirement BrakeActuator force shall not deviate more than 60% from requested level RefineReq BrakeFunction BrakeErrorModel SafetyConstraint ASIL=C Target ServiceBrakeErrorModel BrakeActuationErrorModel Brake_ActivationFailure FaultFailure BrakeOmission Value=Dev60% Activation_Fault 24

21 Environment Model Requirements Variability Timing 3. Technical Safety Concept: Design Part 4 artifacts in EAST-ADL Vehicle SystemModel Vehicle TechnicalFeatureModel Analysis Analysis FunctionalAnalysisArchitecture Design Design FunctionalDesignArchitecture HardwareDesignArchitecture Implementation Implementation Application SW Basic SW HW Data exchange over ports Allocation 25

22 Technical Safety Concept FunctionalAnalysisArchitecture BrakeFunction Brake Pedal DriverPBRequest ParkBrakeCtrl FunctionalSafetyConcept ServiceBrake BrakeGovernor BrakeActuator FunctionaSafetyRequirement ServiceBrakeCtrl Satisfy Requirement Brake Pedal shall not request deviating braking level Realize FunctionalDesignArchitecture DeriveReq TechnicalSafetyConcept ServiceBrake BrakeFunction PedalSensor PedalSensorLoRes BrakeRequest BrakeRequest 2 PedalCollector Satisfy Requirement BrakePedalSensors shall be indipendent TechnicalSafetyRequirement Satisfy DeriveReq Requirement Fault Tolerant Time Interval shall be at least 100 ms 26

23 Environment Model Requirements Variability Timing 4. HW & SW Requirements: Implementation Part 5 artifacts in (and IP-XACT) Part 6 artifacts in SystemModel Vehicle Vehicle TechnicalFeatureModel Analysis Analysis FunctionalAnalysisArchitecture Design Design FunctionalDesignArchitecture HardwareDesignArchitecture Implementation Implementation Application SW Basic SW HW Data exchange over ports Allocation 27

24 WheelSpeedSenso... D e r i v e R e q T e c h n i c a l S a f e t y R e q u i r e m e n t T e c h n i c a l S a f e t y C o n c e p t Elements FunctionalDesignArchitecture BrakeFunction Brake Pedal BrakeRequest ServiceBrakeCtrl BrakeGovernor BrakeActuator Requirement Brake command shall not deviate more than 60 % from requested braking level RefineReq S e r v i c e B r a k e Realize Satisfy SafetyConstraint ASIL = C DeriveReq BrakePeda... BrakeTorqueCalculation::... Realize GlobalBrakeController::GbBrkCtrl Satisfy Requirement BrakePedalSensors shall be indipendent PedalPosition BrakePedalPosition_P PedalPos_InpoutDIO DriverRequestedBrakeTorque_P DriverRequestedBrakeTorque_P BrakeRef_FL BrakePedalPosition... PedalPosition_Debug ErrorLED VehicleModel::VehModel... BrakeActuato... PedalReading PedalPressedLED PedalCalSwitch WheelSpeed_P RoadCondition VehicleSpeed_P ElectricalMotorFeedback:... ABS_FL::ABS DriverRequestedBrakeTorque_P VehicleSpeed_P BrakeRef_P WheelSpeed_P ElectricalMotorA... ErrorLED BrakeTorqueRequeste... BrakeActuatorPort BrakeOnLED BrakeTorqueRequest BA_Debug Satisfy Requirement PedalCollectorOutput shall not deviate more than 60 % from requested level WheelSpeed_OUT SpeedSensorPeriodTime ErrorLED WheelSpeed_ABS WheelSpinningLED WSS_Debug_Interface WheelSpeed_P Motor_PWM MotorOnLED ElectricMotorPWM ExperimentStartButton RequestedPWM ErrorLED RequestInitialPWM BrakePedalPosition EMA_Debug GlobalDebugRece... BA_Debug EMA_Debug BPS_PedPos WSS_WheelSpeed RefineReq SafetyConstraint ASIL = C 28

25 Environment Model 5. Safety Element out of Context SystemModel Vehicle Architecture Hazard Item SafetyGoal ASIL X Analysis Architecture FaultFailure ErrorModel SafetyConstraint ASIL X Design Architecture FaultFailure ErrorModel SafetyConstraint ASIL Y Implementation Architecture FaultFailure ErrorModel SafetyConstraint ASIL Y E.g. Technical Safety Concept without Functional Safety Concept: Allocated Safety Constraints can play the role of Technical Safety Requirements when Functional Safety Concept is available 29

26 6. Supplier-OEM interaction: A/D/I Supplier A Supplier B SafetyConstraint ASIL Y SafetyConstraint ASIL Y FaultFailure FaultFailure ErrorModel ErrorModel SystemModel Architecture Architecture Nominal aspects: aspects: Interfaces match between subsystems Safety Constraints Match between subsystems 30

27 EAST-ADL vs. Safety Bench Marking Safety is about avoiding Failures that may cause Hazards ISO26262 defines a systematic approach: 1. Identify Safety Goal 2. Create a safe architecture with safety requirements that meet safety Goal ISO26262 element Purpose Safety Goal Avoid Hazard / FeatureFlaw Functional Safety Concept Avoid Failure (of abstract Function) Trace Technical Safety Concept HW and SW requirements Avoid Failure (of Function on HW) Avoid Failure (of SW Component on HW) 31

28 EAST-ADL vs. Safety Bench Marking Safety Benchmarking is about assessing how well a system/subsystem/component/mechanism/ fulfills requirements In-context Out-of-context Assessing Ability to Meet ASIL X Safety Goal Conformance to Functional Safety Requirements Conformance to Technical Safety Requirements Conformance to HW and SW Requirements 32

29 EAST-ADL vs. Safety Bench Marking Benchmarking out-of-context = Conformance to anticipated Functional Safety Requirements Technical Safety Requirements HW and SW Requirements To be able to draw conclusions on safety, the assessment of fault tolerance must Address relevant faults Be represented adequately =the fault tolerance capability can be related to requirements and safety goal 33

30 EAST-ADL vs. Safety Bench Marking SystemModel Vehicle Feature Item Hazard SafetyGoal ASIL x Analysis App ErrorModel ErrorModel FaultFailure ASIL ASIL ASIL Y z Design App HW ErrorModel ErrorModel FaultFailure ASIL ASIL ASIL Y z Implementation App BSW HW ErrorModel ErrorModel FaultFailure ASIL ASIL ASIL Y w ErrorModel capture Failure propagation logic can be identified using fault injection FaultFailure capture faults and failures on ports of ErrorModel ASIL constraint define expected or established probability of the fault or failure 34

31 Activities vs. Abstraction s Vehicle Analysis Design Implementation Define Features and requirements Identify FeatureFlaw and Hazard Identify Scenorios and Hazardous Event Define SafetyGoal Define Functional Architecture Define Functional Safety Requirements and Concept Define ErrorModel and FaultFailure Define SafetyConstraints Define Concrete Functional and Hardware Architecture Define Technical Safety Requirements and Concept Define ErrorModel and FaultFailure Define SafetyConstraints Define Software and detailed Hardware Architecture Define Software and Hardware Requirements Define ErrorModel and FaultFailure Define SafetyConstraints 35

32 Finally EAST-ADL is a language for Automotive EE engineering information Shared ontology/terminology across companies and domains EAXML exchange format to secure tool interoperability Allows joint efforts on methodology, modelling and tools supports cross-cutting aspects through extensions. is aligned with elements and modelling infrastrucure provides means to plan, document and utilize safety benchmarking EATOP Eclipse platform can foster tool prototyping EAST-ADL Association is a structure to coordinate and harmonize language progress Collaborative aspect of EAST-ADL is particularly relevant for ISO26262 W W W. E A S T - A D L. I N F O 36