EAST-ADL2 Overview
Henrik Lönn, Volvo Technology ABCPS Week 2010, KTH, Stockholm
The Automotive 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
S ti f li ti f i f t t- Separation of application from infrastructure- Safety Requirements, ISO 26262
Response: EAST-ADL2A System Modeling Approach/Architectural Framework thatA System Modeling Approach/Architectural Framework that• Is a template for how engineering information is organized and
represented• Provides separation of concerns• Provides separation of concerns• Embrace the de-facto
standard representation of automotiveof automotive software –AUTOSAR
Vehicle Level
Analysis Level
Design Level
Implementation Level
Operational Level
H i EAST AD 2 d l d?How is an EAST-ADL2 model structured?An EAST-ADL2 model is organized in several evels of abstraction,
h th ft d l t i b d tif t d l dwhere the software and electronics based artifacts are modeled
The abstraction levels are “views” on the model and a complete representation of the systemrepresentation of the system
The contents on anabstraction level forms
Feature content
Abstract functional abstraction level forms a complete representation of the vehicle embedded system, with respect to the
Vehicle Level
Analysis Level
Design Level
architecture
Functional architecture,HW architecture, platform
b t tiy , p
concerns of that level
The levels are refined
Implementation Level
Operational Level
abstractions
AUTOSAR Software architecture
Embedded system in top-down
yproduced vehicle (excluded)
Vehicle Level• A Vehicle is characterized by a set of FeaturesA Vehicle is characterized by a set of Features
• Features are stakeholder requested functional or non-functional characteristics of a vehicle
• A Feature describes "what", but shall not fix the "how"
• A Feature is specified by Vehicle L l
SystemModel
VehicleLevelp yrequirements and use cases
• From a top-down architecture Analysis
Level
Design
Level
AnalysisLevel
DesignLevel nmen
tMod
el
FunctionalAnalysisArchitecture
VehicleFeatureModel
approach the features are the configuration points to create a vehicle variant
gLevel
ImplementationLevel
DesignLevel
ImplementationLevel
Envi
ron
FunctionalDesignArchitecture
AUTOSAR System
HardwareDesignArchitecture
a e c e a aOperational
Level
Analysis LevelAnalysis Level is the abstract Functional description of theAnalysis Level is the abstract Functional description of the
EE system• Realizes functionality based on the features and requirements
C t b t t f ti l• Captures abstract functional definition while avoiding implementation detailsD fi th t b d
Vehicle Level
SystemModel
VehicleLevel VehicleFeatureModel
• Defines the system boundary• Environment model and
stakeholders define context
AnalysisLevel
DesignLevel
AnalysisLevel
DesignLevel
viro
nmen
tMod
el
FunctionalAnalysisArchitecture
FunctionalDesignArchitecture
• Basis for safety analysisImplementation
Level
Operational
ImplementationLevel
EnvFunctionalDesignArchitecture
AUTOSAR System
HardwareDesignArchitecture
OperationalLevel
Design LevelDesign Level captures the concrete functional definition withDesign Level captures the concrete functional definition with
a close correspondance with the final implementation• Captures functional definition of application software
C t f ti l b t ti f• Captures functional abstraction of hardware and middleware
• Captures abstract hardware hit t
Vehicle Level
SystemModel
VehicleLevel VehicleFeatureModel
architecture • Defines Function-to-hardware
allocation
AnalysisLevel
DesignLevel
AnalysisLevel
DesignLevel
viro
nmen
tMod
el
FunctionalAnalysisArchitecture
FunctionalDesignArchitecture
ImplementationLevel
Operational
ImplementationLevel
EnvFunctionalDesignArchitecture
AUTOSAR System
HardwareDesignArchitecture
OperationalLevel
Implementation LevelThe Implementation Level represents the software-based
i l t ti f th timplementation of the system • Software components represent application functionality• AUTOSAR Basic software represents platformp p• ECU specifications and topology
represent hardware• Model is captured in AUTOSAR
Vehicle Level
SystemModel
VehicleLevel VehicleFeatureModel Model is captured in AUTOSAR
• Software component template• ECU resource template• System Template
AnalysisLevel
DesignLevel
AnalysisLevel
DesignLevel
viro
nmen
tMod
el
FunctionalAnalysisArchitecture
FunctionalDesignArchitecture
ImplementationLevel
Operational
ImplementationLevel
EnvFunctionalDesignArchitecture
AUTOSAR System
HardwareDesignArchitecture
OperationalLevel
Environment ModelThe Environment model captures the plantThe Environment model captures the plant
that the EE system control and interact with• In-vehicle, near and far environment is covered
• Same Environment Model may be used on all abstraction levels
Vehicle Level
SystemModel
VehicleLevel VehicleFeatureModel
• Different Environment models may be used depending on validation scenario
AnalysisLevel
DesignLevel
AnalysisLevel
DesignLevel
viro
nmen
tMod
el
FunctionalAnalysisArchitecture
FunctionalDesignArchitecturevalidation scenario Implementation
Level
Operational
ImplementationLevel
EnvFunctionalDesignArchitecture
AUTOSAR System
HardwareDesignArchitecture
OperationalLevel
T bili b b i l lSystemModel
Traceability between abstraction levelsRealization relations
Analysis
Vehicle Level
AnalysisLevel l
VehicleLevel
VehicleFeatureModel
identify which abstract element is realized by a more concrete entity
Level
DesignLevel
y
DesignLevel
Envi
ronm
entM
ode
FunctionalAnalysisArchitecture
FunctionalDesignArchitecture
HardwareDesignArchitecture
Functions on analysis level realizesfeatures on vehicle level
ImplementationLevel
Operational
ImplementationLevel
E
AUTOSAR System
HardwareDesignArchitecture
SW components or runnables on
Functions on design level realizesfunctions on analysis level
OperationalLevel
SW components or runnables on implementation level realizesfunctions on design level
Extensions
Elements in extensions reference elements in “core”
Vehicle Level
System Model
VehicleLevelTechnicalFeatureModel
Analysis Level
AnalysisLevel
men
t Mod
el
AnalysisArchitecture
uire
men
t
onVa
lidat
ion
enda
bilit
y
imin
g
Design Level
Impl
DesignLevel
ImplementationLevel
Envi
ronm
FunctionalDesignArchitecture A hiHardwareDesignArchitecture
Req
u
Ver
ifica
tio
Dep
eTi
Impl. Level
ImplementationLevel
AUTOSAR Application SW
AUTOSAR Basic SW
AUTOSAR HW
EAST-ADL2 CharacteristicsExtended compared to
EAST-ADL has been developed in:• EAST-EAA (ITEA 2000-2004)• ATESST (EC FP6 2006-2008)
traditional ADL as it covers:• Variability• Requirements• Safety
/
( )• ATESST2 (EC FP7 2008-2010)• TIMMO (ITEA 2007-2009)
• Safety• Behavior• Environment Modelling• Design methodology
Alignment/integration:•(SysML, AADL)•UML/MARTE•AUTOSAR
EAST-ADL2 • Language Metamodel
g gy
•AUTOSAR•ISO26262
• Language Metamodel • UML2 Profile• Prototype Toolset
EAST-ADL Contributors 2000-2009---including Valeo
AUDI
BMW
Carmeq /VW
Vector
Volvo Car Corporation
Volvo Technology
CRF/FIAT
Daimler
ETAS
ZF
CEA-LIST
INRIA
Mecel
Mentor Graphics
OPEL
LORIA
Paderborn Univerisity-C-LAB
Technical University of Darmstadt
PSA
Renault
Robert Bosch
Technische Universität Berlin
The Royal Institute of Technology
The University of Hull
Siemens, Continental …
Relation to other modeling languages and approaches?g g ppWhy Not UML?• EAST-ADL2 is domain-specific but its UML2 profile gives access to UML2 tools.
Why not SysML?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 AADLAADL represent the software implementation of a system while EAST ADL2 starts on a• AADL represent the software implementation of a system while EAST-ADL2 starts on a more abstract level.
Why not proprietary tools (Simulink, Statemate, Dymola, ASCET, …)?• EAST-ADL2 provides an information structure for the engineering data and integratesEAST ADL2 provides an information structure for the engineering data and integrates
external tools
EAST-ADL2 EvolutionEEA AIL
EAST ADL
EA
ST
(Meta
UML2Titus
SYSML
EAST ADL AUTOSAR
T AD
L2.0am
odel+MSYSMLAADL
...UML2
0Methodol
UML2SYSML
AADL
logy+UM
L
ATESST Partners
... L2 Profilee)
EAST-ADL2 Complements AUTOSAR EAST-ADL2 is an information structure including aspects beyond the g p ySoftware Architecture
Requirements, traceability, feature and function content, variability, etc.
Provides means to define what the software doesProvides 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
P id t d l t t i tiProvides 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-pp g p yrelated information and requirements
EAST-ADL2 ToolingUML based Tooling AUTOSAR-based ToolingUML-based Tooling• Based on CEA Papyrus• Integrated Eclipse
application with 5 ATESST plugins
g• MentorGraphics VSA
ATESST plugins
DSL T liDSL Tooling• MetaEdit+
ConclusionEAST-ADL2 provides an information structure p
for design of automotive embedded systems• Architecture Description Language and Architectural Framework
Use of abstraction levels is a fundamental conceptUse of abstraction levels is a fundamental concept • entities on lower levels realize entities on higher levels
EAST-ADL2 is a fully aligned complement to AUTOSARy g p• AUTOSAR is the SW architecture definition enabling SW component
integration on ECU• EAST-ADL2 supports the successful integration of AUTOSAR pp g
components• EAST-ADL2 Supports additional engineering steps including
feature definition, requirements engineering, V&V , safety analysis, f ti l d li /i t ti d t li i ifunctional modeling/integration, product line engineering