east-adl2 lecture 2010 - chalmers · east-adl overview 2 volvo technology 2010 q2 mack trucks...

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


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


2010 Q2

Architecture Description Language for Handling all engineering information required to sustain the evolution of vehicleelectronics

The Response - EAST-ADL2


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)


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


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

…


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


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)


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


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


Operational Level


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


Operational Level


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


Operational Level


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


Operational Level


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


Operational Level


2010 Q2

Outline

•Example usage of EAST-ADL2

•Model Structure

•Example Model

•AUTOSAR Relation

•Areas covered by EAST-ADL2

•Conclusion


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


Operational Level


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


Operational Level

Realizes

Realizes

Realizes


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


Operational Level

Vehicle Level

SystemModel

AnalysisLevel

DesignLevel

ImplementationLevel

Envi

ronm

entM

odel

FunctionalAnalysisArchitecture

FunctionalDesignArchitecture

AUTOSAR System

HardwareDesignArchitecture

VehicleLevel

VehicleFeatureModel


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


Operational Level

Vehicle Level

SystemModel

AnalysisLevel

DesignLevel

ImplementationLevel

Envi

ronm

entM

odel



AUTOSAR System


VehicleLevel

VehicleFeatureModel


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


Operational Level

Vehicle Level

SystemModel

AnalysisLevel

DesignLevel

ImplementationLevel

Envi

ronm

entM

odel



AUTOSAR System


VehicleLevel

VehicleFeatureModel


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


Operational Level

Vehicle Level

SystemModel

AnalysisLevel

DesignLevel

ImplementationLevel

Envi

ronm

entM

odel



AUTOSAR System


VehicleLevel

VehicleFeatureModel


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


Operational Level

Vehicle Level

SystemModel

AnalysisLevel

DesignLevel

ImplementationLevel

Envi

ronm

entM

odel



AUTOSAR System


VehicleLevel

VehicleFeatureModel


2010 Q2

Analysis Level

Design Level


Operational Level

Vehicle Level

SystemModel

AnalysisLevel

DesignLevel

ImplementationLevel

Envi

ronm

entM

odel



AUTOSAR System


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


2010 Q2

Extensions

Analysis Level

Design 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


Req

uire

men

t

Ver

ifica

tionV

alid

atio

n

TechnicalFeatureModel

Dep

enda

bilit

y

Tim

ing

Elements in extensions reference elements in “core”


2010 Q2

Outline


•Model Structure

•Example Model

•AUTOSAR Relation


•Conclusion


2010 Q2

Function interaction – end-to-end

Simple Brake system Example:• Measure

• Brake pedal position • Wheel speeds

• Actuate • brakes


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


Operational Level

Vehicle Level

SystemModel

AnalysisLevel

DesignLevel

ImplementationLevel

Envi

ronm

entM

odel



AUTOSAR System


VehicleLevel

VehicleFeatureModel


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


Operational Level

Vehicle Level

SystemModel

AnalysisLevel

DesignLevel

ImplementationLevel

Envi

ronm

entM

odel



AUTOSAR System


VehicleLevel

VehicleFeatureModel


2010 Q2

Outline


•Model Structure

•Example Model

•AUTOSAR Relation


•Conclusion


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


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


2010 Q2

AUTOSAR vs. EAST-ADL2 System Model

AnalysisLevel

DesignLevel

ImplementationLevel

OperationalLevel

Vehicle Level

SystemModel

AnalysisArchitecture

DesignArchitecture

ImplementationArchitecture

Env

ironm

entM

odel


Functional Design Architecture

AUTOSAR System

Hardware Design Architecture

VehicleFeatureModel


2010 Q2

Relation between Model entitiesExample of Mapping

Design Level << ADLFunction >> C1

<< ADLFunction >>

E3

ADLFunction

E2


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


Operational Level

Realizes


2010 Q2

Outline


•Model Structure

•Example Model

•AUTOSAR Relation


•Conclusion


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


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)


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


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


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


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


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+


2010 Q2

Outline


•Model Structure

•Example Model

•AUTOSAR Relation


•Conclusion


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

east-adl2 lecture 2010 - chalmers · east-adl overview 2 volvo technology 2010 q2 mack trucks...

Documents