Support for ISO in the EAST-ADL/AUTOSAR context. Dr. Henrik Lönn Volvo Technology

Transcription

1 Support for ISO in the EAST-ADL/ context Dr. Henrik Lönn Volvo Technology 1

2 Evolution of Vehicle Electronics 2

3 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 3

4 Environment Model Requirements Variability Timing Dependability 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 4

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

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

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

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

9 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 9

10 ISO reference life cycle 10

11 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 11

12 Product development Concept phase 8-6 Specification and management of safety requirements Specification and management of safety requirements Safety Requirement Hierarchy 3-7 Hazard analysis and risk assessment Hazard analysis and risk assessment Hazardous situations S, E, C 3-7 Hazard analysis and risk assessment Specification of safety goals ASIL attribute 3-8 Functional safety concept Specification of functional safety requirements 4-6 Specification of technical safety requirements Specification of technical safety requirements Inherited ASIL attributes 5-6 Specification of hardware safety requirements Hardware safety requirements 6-6 Specification of software safety requirements Software safety requirements 12

13 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 13

14 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 14

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

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

17 Item Definition

18 Preliminary Hazard Analysis Vehicle FeatureModel Feature ParkingBrake Dependability 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 19

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

20 Modelling Safety Constraints Cover needs for Safety Requirements in ISO ASIL attribute Allocable on architectural element How sure do I have to be that this safety requirement will be fulfilled i.e. there is a remaining risk that something unwanted of concern still happens. What failures in what architectural elements do I want to restrict Let s call this a Failure (for Safety Goals we call the unwanted to avoid a Hazard) 21

21 Timing Constraints Basic Concept Timing Modelling was the first constraint set defined for EAST-ADL and (TIMMO project) Constraint Timing Core Model EAST-ADL Event EAST-ADL core Event core

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

23 Functional Safety Concept TechnicalFeatureModel Feature ParkingBrake Feature ItemServiceBrake ItemParkingBrake Dependability 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 24

24 Functional Safety Requirement Functional Analysis Architecture Dependability 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 25

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

26 Technical Safety Concept FunctionalAnalysisArchitecture Dependability 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 27

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

28 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 Dependability 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 29

29 Environment Model Dependability 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 30

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

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 32

32 Conclusion 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 several aspecs (timing, variability, behavior, V&V, etc. through extensions) EAST-ADL is aligned with modelling elements and modelling infrastrucure EATOP 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 33