5 EAST-ADL Lönn.ppt - ArtistDesign NoE - Home Page · traditional ADL as it covers: •Variability...

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



• Basis for safety analysisImplementation

Level

Operational

ImplementationLevel

EnvFunctionalDesignArchitecture

AUTOSAR System


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


architecture • Defines Function-to-hardware

allocation

AnalysisLevel

DesignLevel

AnalysisLevel

DesignLevel

viro

nmen

tMod

el



ImplementationLevel

Operational

ImplementationLevel


AUTOSAR System


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



ImplementationLevel

Operational

ImplementationLevel


AUTOSAR System


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


• Different Environment models may be used depending on validation scenario

AnalysisLevel

DesignLevel

AnalysisLevel

DesignLevel

viro

nmen

tMod

el


FunctionalDesignArchitecturevalidation scenario Implementation

Level

Operational

ImplementationLevel


AUTOSAR System


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




Functions on analysis level realizesfeatures on vehicle level

ImplementationLevel

Operational

ImplementationLevel

E

AUTOSAR System


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

5 EAST-ADL Lönn.ppt - ArtistDesign NoE - Home Page · traditional ADL as it covers: •Variability...

Documents

Transcript of 5 EAST-ADL Lönn.ppt - ArtistDesign NoE - Home Page · traditional ADL as it covers: •Variability...