Requirements

Transcription

Requirements
EAST-ADL Introduction
Support for ISO26262
EAST-ADL Overview
SystemModel
EAST-ADL defines an
Engineering information structure
VehicleLevel
Environment Model
TechnicalFeatureModel
 Feature content
 Functional content
 Software architecture
AnalysisLevel
FunctionalAnalysisArchitecture
 Requirements
 Variability
 Safety information
 V&V Information
 Behavior
DesignLevel
FunctionalDesignArchitecture
HardwareDesignArchitecture
ImplementationLevel
AUTOSAR
Application SW
AUTOSAR Basic
SW
Data exchange over ports
AUTOSAR
HW
Allocation
EAST-ADL Introduction: Support for ISO26262
2
EAST-ADL+AUTOSAR Representation
TechnicalFeatureModel
Features
of the vehicle
VehicleLevel
Chassis
Extensions
…
Steer
Brake
Cruise
<<AnalysisArchitecture>> DemonstratorAA
<<FunctionalAnalysisArchitecture>> DemoFAA
FunctionalAnalysisArchitecture
DesignLevel
FunctionalDesignArchitecture
HardwareDesignArchitecture
<<ADLFunction>>
AbstractABSFrontLeft
<<ADLFunction>>
BrakeAlgorithm
<<FunctionalDevice>>
BrakeFrontLeft
<<FunctionalDevice>>
WheelSensorFrontLeft
Hardware topology,
concrete functions,
allocation to nodes
Timing
AnalysisLevel
<<FunctionalDevice>>
BrakePedal
VehicleSpeed
Variability
Abstract
functions
Requirements
Environment Model
TechnicalFeatureModel
Dependability
SystemModel
FunctionalDesignArchitecture
<<LocalDeviceManager>>
BrakePedal
<<BSWFunction>>
PedalIO
<<HWFunction>>
BrakePedal
VehicleSpeed
<<DesignFunction>>
BrakeController
<<DesignFunction>>
ABSFrontLeft
<<LocalDeviceManager>>
BrakeActuatorFL
<<LocalDeviceManager>>
WheelSensorFL
<<Sensor>>
Pedal
<<ECUNode>>
PedalNode
<<BSWFunction>>
BrakeIO
<<HWFunction>>
BrakeFrontLeft
<<BSWFunction>>
WSensIO
<<HWFunction>>
WheelSensorFrontLeft
HardwareDesignArchitecture
<<ECUNoder>>
WheelNode
<<Actuator>>
Brake
ImplementationLevel
AUTOSAR
Application SW
AUTOSAR Basic
SW
AUTOSAR
HW
Software Architecture
as represented
Data exchange over portsby AUTOSAR
Allocation
EAST-ADL Introduction: Support for ISO26262
<<Realize>>
SWComposition
<<SensorSWC>>
BrakePedal
VehicleSpeed
<<SWC>>
BaseBrake
<<SWC>>
ABSFrontLeft
<<ActuatorSWC>>
Brake
<<LocalDeviceManager>>
WheelSensorFL
3
EAST-ADL Extensions
SystemModel
Extensions …
VehicleLevel
Dependability
DesignLevel
Timing
FunctionalAnalysisArchitecture
Variability
AnalysisLevel
Requirements
Environment Model
TechnicalFeatureModel
FunctionalDesignArchitecture
HardwareDesignArchitecture
ImplementationLevel
AUTOSAR
Application SW
AUTOSAR Basic
SW
Data exchange over ports
AUTOSAR
HW
Allocation
EAST-ADL Introduction: Support for ISO26262
4
EAST-ADL Extensions
SystemModel
Extensions …
VehicleLevel
DesignLevel
FunctionalDesignArchitecture
§
§
§
HardwareDesignArchitecture
§
§
§
ImplementationLevel
AUTOSAR
Application SW
Dependability
§
§
§
FunctionalAnalysisArchitecture
Timing
Requirements
Environment Model
AnalysisLevel
Variability
§
§
§
TechnicalFeatureModel
AUTOSAR Basic
SW
Data exchange over ports
AUTOSAR
HW
Allocation
EAST-ADL Introduction: Support for ISO26262
5
EAST-ADL vs AUTOSAR
EAST-ADL
For Features, Functional Architecture and Topology
AUTOSAR
For Software Architecture and Execution Platform
EAST-ADL Introduction: Support for ISO26262
6
EAST-ADL vs AUTOSAR
 Different Abstraction Levels:
 EAST-ADL complements AUTOSAR with “early phase”
information
 Different Engineering Information Scope:
 EAST-ADL complements AUTOSAR
 Requirements Engineering
 Variant Management
 Behaviour (nominal/error)
 Timing
 Safety
Scope in AUTOSAR
depending on version
 Same Meta-Metamodel
 Enterprise Architect model used for both
 Same file exchange ARXML-EAXML
 Same tool infrastructure possible ARTOP-EATOP
EAST-ADL Introduction: Support for ISO26262
7
EAST-ADL
ADAMS
TIMMO2
Related Projects
EDONA
SAFE
CESAR
TIMMO
EAST-EEA
ATESST
ATESST2
MAENAD
AUTOSAR
JASPAR
EAST-ADL Association
2005
2000
2010
UML2
SYSML
AADL
AUTOSAR
EAST-ADL
EEA AIL
UML2
Titus
SYSML
AADL
EAST-ADL
EAST-ADL Introduction: Support for ISO26262
EAST-ADL2
EAST-ADL 2.1
EAST-ADL 2.x
8
ISO 26262 reference life cycle
EAST-ADL Introduction: Support for ISO26262
9
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
EAST-ADL Introduction: Support for ISO26262
10
ISO 26262 - What to handle for each phase
Hazard analysis and risk
assessment
Specification and management of safety requirements
8-6 Specification and management of safety requirements
Product development
Concept phase
3-7 Hazard analysis and
risk assessment
3-7 Hazard analysis and
risk assessment
Focus on functional
objectives and not
technological solutions
Specification of safety goals
3-8 Functional safety
concept
Specification of functional safety
requirements
4-6 Specification of
technical safety requirements
Realization by high level
architectural elements
without notion of HW
Introducing HW & SW
in architecture
Specification of technical safety
requirements
5-6 Specification of hardware
safety requirements
6-6 Specification of software
safety requirements
Hardware safety requirements
Software safety requirements
Implementation
of SW/HW
12
What to handle on each abstraction level
Focus on functional
objectives and not
technological solutions
Vehicle Level
Analysis Level
Design Level
Implementation Level
Realization by high level
architectural elements
without notion of HW
Introducing HW & SW
in architecture
Operational Level
Implementation
of SW/HW
EAST-ADL Introduction: Support for ISO26262
13
1. Safety Goals: Vehicle Level
 Part 3.7 artifacts in EAST-ADL
SystemModel
Vehicle
Level
Implementation
Level
DesignLevel
FunctionalDesignArchitecture
HardwareDesignArchitecture
Dependability
FunctionalAnalysisArchitecture
Timing
AnalysisLevel
Variability
Requirements
Design
Level
Environment Model
Analysis
Level
VehicleLevel
TechnicalFeatureModel
ImplementationLevel
AUTOSAR
Application SW
AUTOSAR Basic
SW
EAST-ADL Introduction: Support for ISO26262
AUTOSAR
HW
15
Item Definition
Requirements
VehicleLevel DemoVehicleVL
TechnicalFeatureModel
Requirement
PB force shall be
applied when parking
brake function is active
VehicleRoot
Chassis
Satisfy
Brakes
CruiseControl
Basic
ActiveSuspension
ServiceBrake
Advanced
EAST-ADL Introduction: Support for ISO26262
Dependability
ParkingBrake
Item
ItemEPB
Item
ItemSB
16
Item Definition
EAST-ADL Introduction: Support for ISO26262
17
Preliminary Hazard Analysis
Vehicle
FeatureModel
Dependability
Item
ItemPB
Feature
ParkingBrake
Item
ItemSB
Feature
ServiceBrake
Satisfy
FeatureFlaw
BrakeForceDeviates
from request >60%
NonFulfilledRequirement
Requirement
Brake force shall be
applied when brakes
are activated
Hazard
SuddenLossofBraking
HazardousEvent
+ SuddenLossofBrakinginSlope
+ Controllability=C3
+ Severity=S3
+ Exposure=E4
+ ASIL= ASIL C
OperatingMode
DerivedFrom
SafetyGoal
+ EPB_Goal1
+ Brake force shall not be
below 40% of driver
request
+ ASIL=ASIL C
+ safeState: none
BrakeActivated
EnvironmentSituation
TrafficSituation
OperatingSituationUseCase
Slope
AdjacentVehicle
HighwayDriving
EAST-ADL Introduction: Support for ISO26262
18
2. Functional Safety Concept: Analysis Level
 Part 3.8 artifacts in EAST-ADL
SystemModel
Vehicle
Level
Implementation
Level
DesignLevel
FunctionalDesignArchitecture
HardwareDesignArchitecture
Dependability
FunctionalAnalysisArchitecture
Timing
AnalysisLevel
Variability
Requirements
Design
Level
Environment Model
Analysis
Level
VehicleLevel
TechnicalFeatureModel
ImplementationLevel
AUTOSAR
Application SW
AUTOSAR Basic
SW
EAST-ADL Introduction: Support for ISO26262
AUTOSAR
HW
19
Safety Modelling – Basic Concept
”How sure can I be
to avoid something
unsafe,
SafetyConstraint
ASILValue
FaultFailure
Dependability
“Core Model”
EAST-ADL
ErrorModel
EAST-ADL “core”
EAST-ADL Introduction: Support for ISO26262
and where in the
architecture does
this apply”
AUTOSAR
ErrorModel
AUTOSAR “core”
22
Functional Safety Concept
Dependability
ItemServiceBrake
Requirement
Brake force shall not be
below 40% of driver
request
Satisfy
ServiceBrake
SafetyGoal
EPB_SG1
ASIL=ASILC
ItemParkingBrake
Goal
DeriveReq
FunctionalAnalysisArchitecture
BrakeFunction
Satisfy
Requirement
Brake command shall not
deviate more than 60% from
requested braking level
RefineReq
BrakeRequest
Brake Pedal
ServiceBrakeCtrl
BrakeGovernor
BrakeActuator
SafetyConstraint
ASIL=C
DeriveReq
DeriveReq
Satisfy
Requirement
Brake request shall not deviate
more than 60% from pedal
command
Satisfy
RefineReq
FunctionalSafetyConcept
ServiceBrake
Feature
FunctionaSafetyRequirement
ParkingBrake
FunctionaSafetyRequirement
Feature
FunctionaSafetyRequirement
TechnicalFeatureModel
Requirement
BrakeActuator force shall not
deviate more than 60% from
requested level
RefineReq
SafetyConstraint
ASIL=C
EAST-ADL Introduction: Support for ISO26262
SafetyConstraint
ASIL=C
23
Functional Safety Requirement
Functional
Analysis
Architecture
Dependability
Requirement
BrakeActuator force shall not
deviate more than 60% from
requested level
RefineReq
SafetyConstraint
ASIL=C
BrakeErrorModel
BrakeFunction
Target
ServiceBrakeErrorModel
FaultFailure
BrakeOmission
Value=Dev60%
BrakeActuationErrorModel
Brake_ActivationFailure
Activation_Fault
EAST-ADL Introduction: Support for ISO26262
24
3. Technical Safety Concept: Design Level
 Part 4 artifacts in EAST-ADL
SystemModel
Vehicle
Level
Implementation
Level
DesignLevel
FunctionalDesignArchitecture
HardwareDesignArchitecture
Dependability
FunctionalAnalysisArchitecture
Timing
AnalysisLevel
Variability
Requirements
Design
Level
Environment Model
Analysis
Level
VehicleLevel
TechnicalFeatureModel
ImplementationLevel
AUTOSAR
Application SW
AUTOSAR Basic
SW
Data exchange over ports
AUTOSAR
HW
Allocation
EAST-ADL Introduction: Support for ISO26262
25
Technical Safety Concept
FunctionalAnalysisArchitecture
Dependability
BrakeFunction
Brake Pedal
DriverPBRequest
FunctionalSafetyConcept
ServiceBrake
ParkBrakeCtrl
FunctionaSafetyRequirement
BrakeGovernor
BrakeActuator
Requirement
Brake Pedal shall not request
deviating braking level
ServiceBrakeCtrl
Satisfy
Realize
FunctionalDesignArchitecture
DeriveReq
TechnicalSafetyConcept
ServiceBrake
BrakeFunction
PedalSensor
TechnicalSafetyRequirement
BrakeRequest
BrakeRequest 2
PedalCollector
Satisfy
PedalSensorLoRes
Satisfy
Requirement
BrakePedalSensors shall
be indipendent
DeriveReq
Requirement
Fault Tolerant Time
Interval shall be at least
100 ms
EAST-ADL Introduction: Support for ISO26262
26
4. HW & SW Requirements: Implementation Level
 Part 5 artifacts in AUTOSAR (and IP-XACT)
 Part 6 artifacts in AUTOSAR
SystemModel
Vehicle
Level
Implementation
Level
DesignLevel
FunctionalDesignArchitecture
HardwareDesignArchitecture
Dependability
FunctionalAnalysisArchitecture
Timing
AnalysisLevel
Variability
Requirements
Design
Level
Environment Model
Analysis
Level
VehicleLevel
TechnicalFeatureModel
ImplementationLevel
AUTOSAR
Application SW
AUTOSAR Basic
SW
Data exchange over ports
EAST-ADL Introduction: Support for ISO26262
AUTOSAR
HW
Allocation
27
Dependability
BrakeFunction
BrakeGovernor
BrakeRequest
ServiceBrakeCtrl
Realize
Satisfy
DeriveRe q
Brake Pedal
BrakeActuator
Requirement
Brake command shall not
deviate more than 60% from
requested braking level
RefineReq
SafetyConstraint
ASIL=C
Techn ica lSafetyCo ncep t
Service Bra ke
FunctionalDesignArchitecture
Techn ica lSafetyRe quir ement
AUTOSAR Elements
DeriveReq
AUTOSAR
Realize
BrakePeda...
PedalPosition
PedalPos_InpoutDIO
BrakeTorqueCalculation::...
Satisfy
GlobalBrakeController::GbBrkCtrl
Requirement
BrakePedalSensors shall
be indipendent
BrakePedalPosition_P
DriverRequestedBrakeTorque_P
DriverRequestedBrakeTorque_P
BrakeRef_FL
BrakePedalPosition...
PedalPosition_Debug
ErrorLED
VehicleModel::VehModel...
BrakeActuato...
PedalReading
ABS_FL::ABS
PedalPressedLED
WheelSpeed_P
PedalCalSwitch
ErrorLED
BrakeTorqueRequeste...
DriverRequestedBrakeTorque_P
RoadCondition
VehicleSpeed_P
BrakeActuatorPort
VehicleSpeed_P
BrakeOnLED
BrakeRef_P
WheelSpeed_P
BrakeTorqueRequest
BA_Debug
ElectricalMotorFeedback:...
ElectricalMotorA...
WheelSpeedSenso...
WheelSpeed_OUT
SpeedSensorPeriodTime
ErrorLED
WheelSpeed_P
Motor_PWM
MotorOnLED
ElectricMotorPWM
ExperimentStartButton
RequestedPWM
ErrorLED
RequestInitialPWM
BrakePedalPosition
EMA_Debug
GlobalDebugRece...
Requirement
PedalCollectorOutput shall
not deviate more than 60%
from requested level
RefineReq
BA_Debug
EMA_Debug
WheelSpeed_ABS
WheelSpinningLED
WSS_Debug_Interface
Satisfy
BPS_PedPos
WSS_WheelSpeed
EAST-ADL Introduction: Support for ISO26262
SafetyConstraint
ASIL=C
28
5. Safety Element out of Context
SystemModel
Design
Level
Implementation
Level
“Architecture”
Environment Model
Analysis
Level
Hazard
ErrorModel
SafetyConstraint
ASIL Y
ErrorModel
FaultFailure
Architecture
SafetyConstraint
ASIL X
FaultFailure
Architecture
ASIL X
Item
FaultFailure
Architecture
SafetyGoal
Dependability
Vehicle
Level
SafetyConstraint
ASIL Y
ErrorModel
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
6. Supplier-OEM interaction: A/D/I Level
Supplier A
Dependability
Supplier B
SafetyConstraint
SafetyConstraint
ASIL Y
ASIL Y
FaultFailure
FaultFailure
ErrorModel
SystemModel
Nominal aspects:
Dependability aspects:
Architecture
ErrorModel
Architecture
Interfaces match between subsystems
Safety Constraints Match between subsystems
30
EAST-ADL vs. Safety Bench Marking
 Safety is about avoiding Failures that may cause
Hazards
 ISO26262 defines a systematic approach:
1.
2.
Identify Safety Goal
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)
Technical Safety Concept
Avoid Failure (of Function on HW)
HW and SW requirements
Avoid Failure (of SW Component on HW)
Trace
31
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
EAST-ADL Introduction: Support for ISO26262
32
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
EAST-ADL Introduction: Support for ISO26262
33
EAST-ADL vs. Safety Bench Marking
SystemModel
Vehicle
Level
Hazard
Feature
Analysis
Level
Design
Level
App
App
App
SafetyGoal
ASIL x
Item
FaultFailure
FaultFailure
ASIL
Y
ASIL
ASILYz
FaultFailure
FaultFailure
ASIL
Y
ASIL
ASILYz
FaultFailure
FaultFailure
ASIL
Y
ASIL
ASILYw
ErrorModel
ErrorModel
ErrorModel
HW
Implementation
Level
Dependability
BSW
HW
ErrorModel
ErrorModel
ErrorModel
ErrorModel
ErrorModel
ErrorModel
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
Activities vs. Abstraction Levels
Vehicle
Level
Define Features and requirements
Identify FeatureFlaw and Hazard
Identify Scenorios and Hazardous Event
Define SafetyGoal
Analysis
Level
Define Functional Architecture
Define Functional Safety Requirements and Concept
Define ErrorModel and FaultFailure
Define SafetyConstraints
Design
Level
Define Concrete Functional and Hardware Architecture
Define Technical Safety Requirements and Concept
Define ErrorModel and FaultFailure
Define SafetyConstraints
Implementation
Level
Define Software and detailed Hardware Architecture
Define Software and Hardware Requirements
Define ErrorModel and FaultFailure
Define SafetyConstraints
EAST-ADL Introduction: Support for ISO26262
35
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 AUTOSAR 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





EAST-ADL Introduction: Support for ISO26262
W W W. E AS T- AD L . I N F O
36

Similar documents

The slides of the presentation are available now

The slides of the presentation are available now  Assist and promote the development and application of the EAST-ADL.  The EAST-ADL Association will stipulate the content of new versions of the EAST-ADL language.

More information