east-adl2 lecture 2010 - chalmerseast-adl overview 4 volvo technology 2010 q2 architecture...
TRANSCRIPT
EAST-ADL2 Overview
@Advanced Software Architecture, 2010 Q2Daniel Karlsson and Henrik Lönn
Volvo Technology
EAST-ADL Overview 2Volvo Technology
2010 Q2
MackTrucks
RenaultTrucks
VolvoTrucks
Volvo Aero
FinancialServices
AB VolvoBusiness Areas
Business Units
Volvo 3P
Volvo Powertrain
Volvo Parts
Volvo Information Technology
Volvo Technology
BA AsiaIncl.
Nissan Diesel
VolvoPenta
ConstructionEquipmentBuses
Volvo Logistics
Volvo Technology within the Volvo Group
EAST-ADL Overview 3Volvo Technology
2010 Q2
The ChallengeProduct Related Challenges- Functionality increase- Complexity increase- Increased Safety-criticality- Quality concerns
Challenges Related to Development Process- Supplier-OEM relationship- Multiple sites & departments- Product families- Componentization- Separation of application from infrastructure- Safety Requirements, ISO 26262
EAST-ADL Overview 4Volvo Technology
2010 Q2
Architecture Description Language for Handling all engineering information required to sustain the evolution of vehicleelectronics
The Response - EAST-ADL2
EAST-ADL Overview 5Volvo Technology
2010 Q2
EAST-ADL2A System Modeling Approach/Architectural Framework that• Is a template for how engineering information is organized and
represented• Provides separation of concerns• Embrace the de-facto
representation of automotive software –AUTOSAR
Vehicle Level
Analysis Level
Design Level
Implementation Level
Operational Level
Feature content
Abstract functional architecture
Functional architecture,HW architecture, platform abstractions
AUTOSAR Software architecture
Embedded system in produced vehicle (not in model)
EAST-ADL Overview 6Volvo Technology
2010 Q2
EAST-ADL2 Characteristics
Alignment/integration:•(SysML, AADL)•AUTOSAR•ISO26262
EAST-ADL has been developed in:• EAST-EAA (ITEA 2000-2004)• ATESST (EC FP6 2006-2008)• ATESST2 (EC FP7 2008-2010)• TIMMO (ITEA 2007-2009)
EAST-ADL2 • Language Metamodel • UML2 Profile• Prototype Tool
Extended compared to traditional ADL as it covers:
• Variability• Requirements• Safety• Behavior• Environment Modelling• Design methodology
EAST-ADL Overview 7Volvo Technology
2010 Q2
EAST-ADL Contributors 2000-2009AUDI AG
BMW AG
Carmeq GmbH
CRF
Daimler AG
ETAS GmbH
Mecel AB
Mentor Graphics
OPEL GmbH
PSA
Renault
Robert Bosch GmbH
Siemens, Continental
Valeo
Vector
Volvo Car Corporation
Volvo Technology AB
ZF
CEA-LIST
INRIA
LORIA
Paderborn Univerisity-C-LAB
Technical University of Darmstadt
Technische Universität Berlin
The Royal Institute of Technology
The University of Hull
…
EAST-ADL Overview 8Volvo Technology
2010 Q2
Relation to other modelinglanguages and approaches?Why Not UML?• EAST-ADL2 is domain-specific but its UML2 profile gives access to UML2 tools.
Why not SysML?• EAST-ADL takes up applicable SysML concepts but provides additional domain-specific
support
Why not Autosar?• EAST-ADL complements Autosar with respect to feature content, functional structure, safety
properties, etc.
Why not AADL• AADL represents the software implementation of a system while EAST-ADL2 starts on a
more abstract level.
Why not proprietary tools (Simulink, Statemate, Modelica, ASCET, …)?• EAST-ADL2 provides an information structure for the engineering data and integrates
external tools
EAST-ADL Overview 9Volvo Technology
2010 Q2
EAST-ADL2 EvolutionEEA AIL
UML2Titus
SYSMLAADL
...
EAST ADL AUTOSAR
ATESST Partners
UML2SYSML
AADL...
EA
ST A
DL2.0
(Metam
odel+Methodology+U
ML2 P
rofile)
EAST-ADL Overview 10Volvo Technology
2010 Q2
Some Typical Engineering Scenarios The Vehicle Manufacturer decides what to include in the
next product
A Chassis engineer analyses a novel control algorithm
Application expert defines detailed design
Software engineer defines software architecture
Packaging and allocation, Integration on ECU
Early phase validation and verification
EAST-ADL Overview 11Volvo Technology
2010 Q2
Product Planners decide what to put in the next product
Features represent the properties/functionality/traits (Brake, Wiper, CollisionWarning,... )
Vehicle Feature Model organize Features for the vehicle
Variability mechanism supports the definition of rules for inclusion in different vehicles – Product Line Architecture
Vehicle Level
Analysis Level
Design Level
Implementation Level
Operational Level
EAST-ADL Overview 12Volvo Technology
2010 Q2
A Chassis engineer analyses a novel control algorithm
Control algorithm is defined as a Function connected to a plant Function in the Environment model
EAST-ADL2 defines structure, legacy tools can be used for behavior definition, simulation, etc.
Realization details are omitted:• Functional validation and verification can be
done with respect to key aspects • Understanding of key aspects is possible
Vehicle Level
Analysis Level
Design Level
Implementation Level
Operational Level
EAST-ADL Overview 13Volvo Technology
2010 Q2
An OEM and Supplier agree on specification
A model of the supplied system provides a clear and effective information exchange
Functions can be integrated and validated before SW and HW exists
Requirements are explicit and traceable to model elements
Interfaces and interaction clarified, avoiding common specification bugs
Vehicle Level
Analysis Level
Design Level
Implementation Level
Operational Level
EAST-ADL Overview 14Volvo Technology
2010 Q2
Application expert defines detailed design
A detailed functional architecture is defined, addressing e.g.
• Hardware architecture• Allocation• Fault tolerance• Implementation concerns• Sensor, actuator constraints• Interfaces to middleware
Focus on behavior and interaction of functions
Abstract system architecture is defined and assessed
Vehicle Level
Analysis Level
Design Level
Implementation Level
Operational Level
EAST-ADL Overview 15Volvo Technology
2010 Q2
Software engineer defines SW Architecture
AUTOSAR Application SW Components are defined
The set of SW components together realizes the Functional Architecture
Software organization and functionalorganization is decoupled and optimization of the SW architecture is possible.
Legacy, sourcing, allocation, performance, verification, responsibility, re-use, etc. influence which functions are realized by each SW component
Vehicle Level
Analysis Level
Design Level
Implementation Level
Operational Level
EAST-ADL Overview 16Volvo Technology
2010 Q2
Outline
•Example usage of EAST-ADL2
•Model Structure
•Example Model
•AUTOSAR Relation
•Areas covered by EAST-ADL2
•Conclusion
EAST-ADL Overview 17Volvo Technology
2010 Q2
How is an EAST-ADL2 model structured?An EAST-ADL2 model is organized in several levels of abstraction, where the software and electronics based artifacts are modeled.
The abstraction levels are “views” on the model and a complete representation of the system.
The contents on an abstraction level forms a complete representation of the vehicle embedded system, with respect to the concerns of that abstraction level
The levels are refined top-down starting at the vehicle level.
Vehicle Level
Analysis Level
Design Level
Implementation Level
Operational Level
EAST-ADL Overview 18Volvo Technology
2010 Q2
How is an EAST-ADL2 model structured?
• On vehicle level the features of the vehicle
• On analysis level the abstract functions
• On design level the hardware topology, concrete functions and their allocation to nodes
• On Implementation level the software architecture as represented by AUTOSAR
Vehicle Level
Analysis Level
Design Level
Implementation Level
Operational Level
Realizes
Realizes
Realizes
EAST-ADL Overview 19Volvo Technology
2010 Q2
Vehicle Level• A Vehicle is characterized by a set of Features• Features are stakeholder requested functional or non-
functional characteristics of a vehicle• A Feature describes that "what", but shall not fix the
"how" • A Feature is specified by
requirements and use cases• From a top-down architecture
approach the features are the configuration points to create a vehicle variant
Analysis Level
Design Level
Implementation Level
Operational Level
Vehicle Level
SystemModel
AnalysisLevel
DesignLevel
ImplementationLevel
Envi
ronm
entM
odel
FunctionalAnalysisArchitecture
FunctionalDesignArchitecture
AUTOSAR System
HardwareDesignArchitecture
VehicleLevel
VehicleFeatureModel
EAST-ADL Overview 20Volvo Technology
2010 Q2
Analysis LevelAnalysis Level is the abstract Functional description of the
EE system• Realizes functionality based on the features and requirements• Captures abstract functional
definition while avoiding implementation details
• Defines the system boundary• Environment model and
stakeholders define context• Basis for safety analysis
Analysis Level
Design Level
Implementation Level
Operational Level
Vehicle Level
SystemModel
AnalysisLevel
DesignLevel
ImplementationLevel
Envi
ronm
entM
odel
FunctionalAnalysisArchitecture
FunctionalDesignArchitecture
AUTOSAR System
HardwareDesignArchitecture
VehicleLevel
VehicleFeatureModel
EAST-ADL Overview 21Volvo Technology
2010 Q2
Design LevelDesign Level captures the concrete functional definition with
a close correspondance with the final implementation• Captures functional definition of application software• Captures functional abstraction of
hardware and middleware • Captures abstract hardware
architecture • Defines Function-to-hardware
allocation
Analysis Level
Design Level
Implementation Level
Operational Level
Vehicle Level
SystemModel
AnalysisLevel
DesignLevel
ImplementationLevel
Envi
ronm
entM
odel
FunctionalAnalysisArchitecture
FunctionalDesignArchitecture
AUTOSAR System
HardwareDesignArchitecture
VehicleLevel
VehicleFeatureModel
EAST-ADL Overview 22Volvo Technology
2010 Q2
Implementation LevelThe Implementation Level represents the software-based
implementation of the system • Software components represent application functionality• AUTOSAR Basic software represents platform• ECU specifications and topology
represent hardware• Model is captured in AUTOSAR
• Software component template• ECU resource template• System Template
Analysis Level
Design Level
Implementation Level
Operational Level
Vehicle Level
SystemModel
AnalysisLevel
DesignLevel
ImplementationLevel
Envi
ronm
entM
odel
FunctionalAnalysisArchitecture
FunctionalDesignArchitecture
AUTOSAR System
HardwareDesignArchitecture
VehicleLevel
VehicleFeatureModel
EAST-ADL Overview 23Volvo Technology
2010 Q2
Environment ModelThe Environment model captures the plant
that the EE system controls and interacts with• In-vehicle, near and far environment is covered
• Same Environment Model may be used on all abstraction levels
• Different Environment models may be used depending on validation scenario
Analysis Level
Design Level
Implementation Level
Operational Level
Vehicle Level
SystemModel
AnalysisLevel
DesignLevel
ImplementationLevel
Envi
ronm
entM
odel
FunctionalAnalysisArchitecture
FunctionalDesignArchitecture
AUTOSAR System
HardwareDesignArchitecture
VehicleLevel
VehicleFeatureModel
EAST-ADL Overview 24Volvo Technology
2010 Q2
Analysis Level
Design Level
Implementation Level
Operational Level
Vehicle Level
SystemModel
AnalysisLevel
DesignLevel
ImplementationLevel
Envi
ronm
entM
odel
FunctionalAnalysisArchitecture
FunctionalDesignArchitecture
AUTOSAR System
HardwareDesignArchitecture
VehicleLevel
VehicleFeatureModel
SW components or runnables on implementation level realizesfunctions on design level
Functions on design level realizesfunctions on analysis level
Functions on analysis level realizesfeatures on vehicle level
Traceability between abstraction levelsRealization relations identify which abstract element is realized by a more concrete entity
EAST-ADL Overview 25Volvo Technology
2010 Q2
Extensions
Analysis Level
Design Level
Implementation Level
Vehicle Level
System Model
AnalysisLevel
DesignLevel
ImplementationLevel
Envi
ronm
ent M
odel
AnalysisArchitecture
FunctionalDesignArchitecture A hi
AUTOSAR Application SW
VehicleLevel
AUTOSAR Basic SW
AUTOSAR HW
HardwareDesignArchitecture
Req
uire
men
t
Ver
ifica
tionV
alid
atio
n
TechnicalFeatureModel
Dep
enda
bilit
y
Tim
ing
Elements in extensions reference elements in “core”
EAST-ADL Overview 26Volvo Technology
2010 Q2
Outline
•Example usage of EAST-ADL2
•Model Structure
•Example Model
•AUTOSAR Relation
•Areas covered by EAST-ADL2
•Conclusion
EAST-ADL Overview 27Volvo Technology
2010 Q2
Function interaction – end-to-end
Simple Brake system Example:• Measure
• Brake pedal position • Wheel speeds
• Actuate • brakes
EAST-ADL Overview 28Volvo Technology
2010 Q2
HW Functionality
<<FunctionalDesignarchitectureLevel>> DemonstratorFDA
<<HWFunction>>PedalSensor
<<HWFunction>>BrakeActuatorFrontLeft
<<HWFunction>>WheelSensorFrontLeft
Application Functionality BSW Functionality
<<LocalDeviceManager>>BrakePedal
<<Function>>BrakeController
<<Function>>ABSFrontLeft <<LocalDeviceManager>>
BrakeActuatorFL<<BSWFunction>>
BrakeIO
<<BSWFunction>>PedalIO
<<LocalDeviceManager>>WheelSensorFL
<<BSWFunction>>WSensIO
VehicleSpeed
Function interaction – end-to-end
Model structure supports interaction with the environment and end-to-end functional definitions
Analysis Level
Design Level
Implementation Level
Operational Level
Vehicle Level
SystemModel
AnalysisLevel
DesignLevel
ImplementationLevel
Envi
ronm
entM
odel
FunctionalAnalysisArchitecture
FunctionalDesignArchitecture
AUTOSAR System
HardwareDesignArchitecture
VehicleLevel
VehicleFeatureModel
EAST-ADL Overview 29Volvo Technology
2010 Q2
<<ECUNode>>ABS_1
<<HardwareDesignArchitecture>>DemoHDA
<<Sensor>>WheelSensorFrontLeft
<<Sensor>>WheelSensorFrontRight
<<Sensor>>WheelSensorRearLeft
<<Sensor>>WheelSensorRearRight
<<ECUNode>>ABS_2
<<ECUNode>>ABS_3
<<ECUNode>>ABS_4
<<ECUNode>>Brake
<<Sensor>>BrakePedal
<<Actuator>>BrakeFrontLeft
<<HWFunction>>BrakePedal
<<HWFunction>>BrakeFrontLeft
<<HWFunction>>BrakeFrontRight
<<HWFunction>>BrakeRearLeft
<<HWFunction>>BrakeRearRight
<<HWFunction>>WheelSensorFrontLeft
<<HWFunction>>WheelSensorFrontRight
<<HWFunction>>WheelSensorRearLeft
<<HWFunction>>WheelSensorRearRight
<<Actuator>>BrakeRearLeft
<<Actuator>>BrakeFrontRight
<<Actuator>>BrakeRearRight
Hardware Design ArchitectureHardware architecture support hardware design and functional allocation
Behavior of HW entites is defined for use in Functional DesignArchitecture
Analysis Level
Design Level
Implementation Level
Operational Level
Vehicle Level
SystemModel
AnalysisLevel
DesignLevel
ImplementationLevel
Envi
ronm
entM
odel
FunctionalAnalysisArchitecture
FunctionalDesignArchitecture
AUTOSAR System
HardwareDesignArchitecture
VehicleLevel
VehicleFeatureModel
EAST-ADL Overview 30Volvo Technology
2010 Q2
Outline
•Example usage of EAST-ADL2
•Model Structure
•Example Model
•AUTOSAR Relation
•Areas covered by EAST-ADL2
•Conclusion
EAST-ADL Overview 31Volvo Technology
2010 Q2
AUTOSARStandard for automotive
software
Purpose: Allow HW-SW independence
Component-based approach
AUTOSAR standardizes• Execution platform (Basic software (middleware) specifications• Application software representation (software components) • Hardware topology representation (control units, busses, etc.)• Application software interfaces• Methodology
EAST-ADL Overview 32Volvo Technology
2010 Q2
EAST-ADL2 Complements AUTOSAR EAST-ADL2 is an information structure including aspects beyond the Software Architecture
Requirements, traceability, feature content, variability, safety, etc.
Provides means to define what the software doesAn AUTOSAR specification defines the software architecture and information required for SW integration - but is neutral to its functionality
Provides means to model strategic properties Key vehicle aspects is captured independently of the software architecture
Supports modelling of error behavior and the representation of safety-related information and requirements
EAST-ADL Overview 33Volvo Technology
2010 Q2
AUTOSAR vs. EAST-ADL2 System Model
AnalysisLevel
DesignLevel
ImplementationLevel
OperationalLevel
Vehicle Level
SystemModel
AnalysisArchitecture
DesignArchitecture
ImplementationArchitecture
Env
ironm
entM
odel
FunctionalAnalysisArchitecture
Functional Design Architecture
AUTOSAR System
Hardware Design Architecture
VehicleFeatureModel
EAST-ADL Overview 34Volvo Technology
2010 Q2
Relation between Model entitiesExample of Mapping
Design Level << ADLFunction >> C1
<< ADLFunction >>
E3
ADLFunction
E2
Implementation Level
<<ADLFunction>> C2
In_A : SCS1
out_A : SCS1 ADLFunction E1
out_B : SCS2 out_D : C_1
In_B : SCS2
In_D : C_1
ADLFunction
E4 ADLFunction
E5
Runnable E1
Runnable E4 Runnable E2
Runnable E3
ApplicationSWC A1
ApplicationSWC A3
ApplicationSWC A2
out_D
out_A : SCS1
out_B : SCS2 In_B : SCS2
In_D : C_1
Vehicle Level
Analysis Level
Design Level
Implementation Level
Operational Level
Realizes
EAST-ADL Overview 35Volvo Technology
2010 Q2
Outline
•Example usage of EAST-ADL2
•Model Structure
•Example Model
•AUTOSAR Relation
•Areas covered by EAST-ADL2
•Conclusion
EAST-ADL Overview 36Volvo Technology
2010 Q2
VariabilityDefinition of Feature Content of Vehicle using Feature Trees• Definition of Product Line in terms of mandatory and optional features
for each vehicle category
Definition of Variability rules for realization• Optional/mandatory functions and components• Definition on how to resolve variability based on feature content
Basic Model
<<refers>> <<refers>>
EAST-ADL Overview 37Volvo Technology
2010 Q2
Requirements and V&VDefinition of Requirement modelling framework based on
SysML• Concepts for capturing requirements and components in same model• Traceability between requirements, components and V&V
V&V constructs to capture test case, test outcome, etc.
Integration of RIF concepts (Requirement InterchangeFormat)
EAST-ADL Overview 38Volvo Technology
2010 Q2
Safety Aspects & ISO 26262ASIL Categorization through requirements
Support for Safety Case – Use of model entities to arguesafety
Organization of information
in line with ISO 26262
Support for methodsrequired by ISO26262
EAST-ADL Overview 39Volvo Technology
2010 Q2
Error modelling & failure analysisModelling Concepts for Hazards and Error Propagation
Basis for Hazard Analysis and Fault Tree and Failure Modes and Effects Analysis
Tool Interface for Automatic FTA/FMEA
EAST-ADL Overview 40Volvo Technology
2010 Q2
BehaviorDefinition of Behavioral semantics to allow legacy tool
integration• Ascet, Simulink, legacy code, etc.
Definition of relation to AUTOSAR behavior
Behavioral Semantics for Environment model (Plant)
«ADLFunction»F1
«ADLFunction»F1.1a
«ADLFunction»F1.2
«ADLFunction»F1.3
«ADLFunction»F1.1b
«ADLFunction»Voter
«ADLFunction»Voter
«ADLBehavior»AB1
EAST-ADL Overview 41Volvo Technology
2010 Q2
TimingFormalization of timing requirements and properties in
relation to structural model elements
Approach is symmetric w.r.t AUTOSAR V4 timing constructs
Reaction, age, synchronization and repetitions can be defined
Braking
BrakeForce
Actuation
Brake Controller
Response 4
BrakePedal
Position
Stimulus
Delay ConstraintD
BrakeForce
Actuation
Response 1
EAST-ADL Overview 42Volvo Technology
2010 Q2
EAST-ADL2 ToolingUML-based Tooling• Based on CEA Papyrus• Integrated Eclipse
application with 5 ATESST plugins
AUTOSAR-based Tooling• MentorGraphics VSA
DSL Tooling• MetaEdit+
EAST-ADL Overview 43Volvo Technology
2010 Q2
Outline
•Example usage of EAST-ADL2
•Model Structure
•Example Model
•AUTOSAR Relation
•Areas covered by EAST-ADL2
•Conclusion
EAST-ADL Overview 44Volvo Technology
2010 Q2
ConclusionEAST-ADL2 provides an information structure
for design of automotive embedded systems• Architecture Description Language and Architectural Framework
Use of abstraction levels is a fundamental concept • entities on lower levels realize entities on higher levels
EAST-ADL2 is a fully aligned complement to AUTOSAR• AUTOSAR is the SW architecture definition enabling SW component
integration on ECU• EAST-ADL2 supports the successful integration of AUTOSAR
components• EAST-ADL2 Supports additional engineering steps including
feature definition, requirements engineering, V&V , safety analysis, functional modeling/integration, product line engineering