EAST-ADL2 Overview @Advanced Software Architecture, 2010 Q2 Daniel - - PowerPoint PPT Presentation

east adl2 overview
SMART_READER_LITE
LIVE PREVIEW

EAST-ADL2 Overview @Advanced Software Architecture, 2010 Q2 Daniel - - PowerPoint PPT Presentation

EAST-ADL2 Overview @Advanced Software Architecture, 2010 Q2 Daniel Karlsson and Henrik Lnn Volvo Technology Volvo Technology within the Volvo Group AB Volvo Business Areas BA Asia Mack Renault Volvo Construction Volvo Volvo Financial


slide-1
SLIDE 1

EAST-ADL2 Overview

@Advanced Software Architecture, 2010 Q2 Daniel Karlsson and Henrik Lönn Volvo Technology

slide-2
SLIDE 2

EAST-ADL Overview 2

Volvo Technology

2010 Q2 Mack Trucks Renault Trucks Volvo Trucks Volvo Aero Financial Services

AB Volvo

Business Areas Business Units Volvo 3P Volvo Powertrain Volvo Parts Volvo Information Technology Volvo Technology BA Asia Incl. Nissan Diesel Volvo Penta Construction Equipment Buses Volvo Logistics

Volvo Technology within the Volvo Group

slide-3
SLIDE 3

EAST-ADL Overview 3

Volvo Technology

2010 Q2

The Challenge

Product 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
slide-4
SLIDE 4

EAST-ADL Overview 4

Volvo Technology

2010 Q2

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

The Response - EAST-ADL2

slide-5
SLIDE 5

EAST-ADL Overview 5

Volvo Technology

2010 Q2

EAST-ADL2

A 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

  • f 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)

slide-6
SLIDE 6

EAST-ADL Overview 6

Volvo 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
slide-7
SLIDE 7

EAST-ADL Overview 7

Volvo Technology

2010 Q2

EAST-ADL Contributors 2000-2009

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

slide-8
SLIDE 8

EAST-ADL Overview 8

Volvo Technology

2010 Q2

Relation to other modeling languages 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

slide-9
SLIDE 9

EAST-ADL Overview 9

Volvo Technology

2010 Q2

EAST-ADL2 Evolution

EEA AIL UML2 Titus SYSML AADL ... EAST ADL AUTOSAR ATESST Partners UML2 SYSML AADL ...

EAST ADL2.0 (Metamodel+Methodology+UML2 Profile)

slide-10
SLIDE 10

EAST-ADL Overview 10

Volvo 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

slide-11
SLIDE 11

EAST-ADL Overview 11

Volvo 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

slide-12
SLIDE 12

EAST-ADL Overview 12

Volvo 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

slide-13
SLIDE 13

EAST-ADL Overview 13

Volvo 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

slide-14
SLIDE 14

EAST-ADL Overview 14

Volvo 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

slide-15
SLIDE 15

EAST-ADL Overview 15

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

  • rganization is decoupled and
  • ptimization 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

slide-16
SLIDE 16

EAST-ADL Overview 16

Volvo Technology

2010 Q2

Outline

  • Example usage of EAST-ADL2
  • Model Structure
  • Example Model
  • AUTOSAR Relation
  • Areas covered by EAST-ADL2
  • Conclusion
slide-17
SLIDE 17

EAST-ADL Overview 17

Volvo 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

slide-18
SLIDE 18

EAST-ADL Overview 18

Volvo 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

slide-19
SLIDE 19

EAST-ADL Overview 19

Volvo 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 EnvironmentModel FunctionalAnalysisArchitecture FunctionalDesignArchitecture AUTOSAR System HardwareDesignArchitecture VehicleLevel VehicleFeatureModel

slide-20
SLIDE 20

EAST-ADL Overview 20

Volvo Technology

2010 Q2

Analysis Level

Analysis 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 EnvironmentModel FunctionalAnalysisArchitecture FunctionalDesignArchitecture AUTOSAR System HardwareDesignArchitecture VehicleLevel VehicleFeatureModel

slide-21
SLIDE 21

EAST-ADL Overview 21

Volvo Technology

2010 Q2

Design Level

Design 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 EnvironmentModel FunctionalAnalysisArchitecture FunctionalDesignArchitecture AUTOSAR System HardwareDesignArchitecture VehicleLevel VehicleFeatureModel

slide-22
SLIDE 22

EAST-ADL Overview 22

Volvo Technology

2010 Q2

Implementation Level

The 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 EnvironmentModel FunctionalAnalysisArchitecture FunctionalDesignArchitecture AUTOSAR System HardwareDesignArchitecture VehicleLevel VehicleFeatureModel

slide-23
SLIDE 23

EAST-ADL Overview 23

Volvo Technology

2010 Q2

Environment Model

The 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 EnvironmentModel FunctionalAnalysisArchitecture FunctionalDesignArchitecture AUTOSAR System HardwareDesignArchitecture VehicleLevel VehicleFeatureModel

slide-24
SLIDE 24

EAST-ADL Overview 24

Volvo Technology

2010 Q2

Analysis Level Design Level Implementation Level Operational Level Vehicle Level

SystemModel

AnalysisLevel DesignLevel ImplementationLevel EnvironmentModel FunctionalAnalysisArchitecture FunctionalDesignArchitecture AUTOSAR System HardwareDesignArchitecture VehicleLevel VehicleFeatureModel

SW components or runnables on implementation level realizes functions on design level Functions on design level realizes functions on analysis level Functions on analysis level realizes features on vehicle level

Traceability between abstraction levels

Realization relations identify which abstract element is realized by a more concrete entity

slide-25
SLIDE 25

EAST-ADL Overview 25

Volvo Technology

2010 Q2

Extensions

Analysis Level Design Level Implementation Level Vehicle Level

System Model

AnalysisLevel DesignLevel ImplementationLevel Environment Model AnalysisArchitecture FunctionalDesignArchitecture A hi

AUTOSAR Application SW

VehicleLevel

AUTOSAR Basic SW AUTOSAR HW

HardwareDesignArchitecture Requirement VerificationValidation TechnicalFeatureModel Dependability Timing

Elements in extensions reference elements in “core”

slide-26
SLIDE 26

EAST-ADL Overview 26

Volvo Technology

2010 Q2

Outline

  • Example usage of EAST-ADL2
  • Model Structure
  • Example Model
  • AUTOSAR Relation
  • Areas covered by EAST-ADL2
  • Conclusion
slide-27
SLIDE 27

EAST-ADL Overview 27

Volvo Technology

2010 Q2

Function interaction – end-to-end

Simple Brake system Example:

  • Measure
  • Brake pedal position
  • Wheel speeds
  • Actuate
  • brakes
slide-28
SLIDE 28

EAST-ADL Overview 28

Volvo 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 EnvironmentModel FunctionalAnalysisArchitecture FunctionalDesignArchitecture AUTOSAR System HardwareDesignArchitecture VehicleLevel VehicleFeatureModel

slide-29
SLIDE 29

EAST-ADL Overview 29

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

Hardware 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 EnvironmentModel FunctionalAnalysisArchitecture FunctionalDesignArchitecture AUTOSAR System HardwareDesignArchitecture VehicleLevel VehicleFeatureModel

slide-30
SLIDE 30

EAST-ADL Overview 30

Volvo Technology

2010 Q2

Outline

  • Example usage of EAST-ADL2
  • Model Structure
  • Example Model
  • AUTOSAR Relation
  • Areas covered by EAST-ADL2
  • Conclusion
slide-31
SLIDE 31

EAST-ADL Overview 31

Volvo Technology

2010 Q2

AUTOSAR

Standard 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
slide-32
SLIDE 32

EAST-ADL Overview 32

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

An 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

  • f safety-related information and requirements
slide-33
SLIDE 33

EAST-ADL Overview 33

Volvo Technology

2010 Q2

AUTOSAR vs. EAST-ADL2 System Model

Analysis Level Design Level Implementation Level Operational Level Vehicle Level

SystemModel

AnalysisArchitecture DesignArchitecture ImplementationArchitecture EnvironmentModel FunctionalAnalysisArchitecture Functional Design Architecture AUTOSAR System Hardware Design Architecture VehicleFeatureModel

slide-34
SLIDE 34

EAST-ADL Overview 34

Volvo Technology

2010 Q2

Relation between Model entities

Example of Mapping

Design Level

<< ADLFunction >> C1

<< ADLFunction >>

E3

ADLFunction

E2

Implementation Level

<<ADLFunction>> C2

In_A : SCS1

  • ut_A : SCS1

ADLFunction E1

  • ut_B : SCS2
  • ut_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

  • ut_D
  • ut_A : SCS1
  • ut_B : SCS2

In_B : SCS2 In_D : C_1

Vehicle Level Analysis Level Design Level Implementation Level Operational Level Realizes

slide-35
SLIDE 35

EAST-ADL Overview 35

Volvo Technology

2010 Q2

Outline

  • Example usage of EAST-ADL2
  • Model Structure
  • Example Model
  • AUTOSAR Relation
  • Areas covered by EAST-ADL2
  • Conclusion
slide-36
SLIDE 36

EAST-ADL Overview 36

Volvo Technology

2010 Q2

Variability

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

slide-37
SLIDE 37

EAST-ADL Overview 37

Volvo Technology

2010 Q2

Requirements and V&V

Definition 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 Interchange Format)

slide-38
SLIDE 38

EAST-ADL Overview 38

Volvo Technology

2010 Q2

Safety Aspects & ISO 26262

ASIL Categorization through requirements Support for Safety Case – Use of model entities to argue safety Organization of information in line with ISO 26262 Support for methods required by ISO26262

slide-39
SLIDE 39

EAST-ADL Overview 39

Volvo Technology

2010 Q2

Error modelling & failure analysis

Modelling 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

slide-40
SLIDE 40

EAST-ADL Overview 40

Volvo Technology

2010 Q2

Behavior

Definition 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

slide-41
SLIDE 41

EAST-ADL Overview 41

Volvo Technology

2010 Q2

Timing

Formalization 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

Brake Force Actuation Brake Controller

Response 4

Brake Pedal Position

Stimulus

Delay Constraint D Brake Force Actuation

Response 1

slide-42
SLIDE 42

EAST-ADL Overview 42

Volvo Technology

2010 Q2

EAST-ADL2 Tooling

UML-based Tooling

  • Based on CEA Papyrus
  • Integrated Eclipse

application with 5 ATESST plugins

AUTOSAR-based Tooling

  • MentorGraphics VSA

DSL Tooling

  • MetaEdit+
slide-43
SLIDE 43

EAST-ADL Overview 43

Volvo Technology

2010 Q2

Outline

  • Example usage of EAST-ADL2
  • Model Structure
  • Example Model
  • AUTOSAR Relation
  • Areas covered by EAST-ADL2
  • Conclusion
slide-44
SLIDE 44

EAST-ADL Overview 44

Volvo Technology

2010 Q2

Conclusion

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