How to enrich AUTOSAR based design processes with enabled … · Autosar World wide private partnership of automotive OEMs, tier1/tier2 suppliers, SW-houses, vendors to push standardization

How to enrich AUTOSAR baseddesign processes

with enabledSystem-level Analysis

Werner Damm

08.06.2008 2 © Werner Damm , OFFIS

The Challenge

To have the cake and eat it:

Maintain target-hardware independence of capturing function networks

re-use across multiple platforms!

Yet assess realizability of new functions early (but this is dependent on the target … )

frontloading!


Structure of Talk

Key Benefits of Autosar

Rich components

Speeds integration technology

Rich Component Based Design

Adding Speeds to Autosar: what it takes


Drivers for Change in automotive embedded systems developmentFlexibility

Decouple growth rate of #functions from growth rate of #electronic componentsFreedom in choosing boundary of in-house and external development

AdaptabilityTowards emerging technologiesTowards emerging hardware platformsMaintainability : at life-time

CostDecouple growth of #functions from growth rate of development costsDecouple growth rate of number of supported platforms from development costs

QualityMaintain/Improve Quality while allowing growth of #functions


Anticipated Changes in ProcessesStrong push to virtual subsystem models Target

independentTopic in Autosar

Strong push towards component based developmentTopic in AutosarRequires component characterizations dealing with non-functional aspects (e.g. real-time, safety, ...)

Need to support safety standardsto support IEC 61508 customized to automotive domain: ISO WD 26 26 2 – compliant processes

Deployment analysis capabilities will be keycompetence

for price-competetive offerings of tier 1 supliersFor realizability analysis of new functions for innovatorOEMs


Autosar

World wide private partnership of automotive OEMs, tier1/tier2 suppliers, SW-houses, vendors to push standardization of E/E architectures with more than 100 partnersStandardized meta-model, release 3.0 available from www.autosar.org


Autosar

Decoupling functional design from implementation platform

© Autosar ConsortiumAchievements and exploitation of the AUTOSAR development partnership, Convergence 2006


Key Benefits Autosar Design Methodology

Separation of application specification and development from implementation on specific hardware platforms

a key enabler for enhanced cross platform re-use of applicationsallows cost-tuned hardware implementations for the specific set of functions and features integrated in a particular vehicle development.

Supports a stepwise refinement of the overall system designstarting at a coarse grain system topology defined in the systemtemplate stepwise enriched by hardware-related information based on mappings to the ECU network.

The AUTOSAR metamodel gives a formal standardized specification of information required for a functional system design

provides skeleton for additional information to support further aspects of a full system-level analysis. Allows to extend early assessment of key functional requirements by an analysis of non-functional requirements based on an extended AUTOSAR meta-model.


Linking and Autosar


The StoryRhapsodyTM

SimulinkTM SCADETMSildexTM

Heterogeneous model-based designSemantic integration of industry standard tools

ContractEditor

Transmit(D_out) each 30ms withmax. 7ms jitter

Receive(D_in) each 30ms withmax. 4ms jitter

ContractAssumption Promise

Contract-based multi-criteriasystem-level analysis

AnalysisAnalysing complianceof Autosar Configurations

against vertical assumptions


Technical Highlights of the IP Speeds

Speeds providesThe capability of Modeling and Integration of Architectural Abstractions at all System Design Levels for multiple viewpoints including real-time and safetyA Rich Component Model allowing to completely encapsulate functional and non-functional aspects of a design in an assume-guarantee style with cross viewpoint dependencies, including the capability of expressing assumptions on lower design levels captured as architectural abstractionsA harmonized meta-model allowing a semantic integration of industry standard system- and software design toolssupporting rich components based on an open tool integration standard, compatible with the AutosarMetamodelA suite of compositional analysis and design space exploration methods supporting real-time and safety analysis


Acknowledgements

This talk represents the collaborative effort of the Speeds consortium

End-users: Airbus, Bosch, Carmeq, EADS, IAI, Knorr-Bremse, MagnaSteyr, Saab

VendorsEsterel Technologies, Extesy, Geensys, Telelogic

Research OrganizationsINRIA, OFFIS, Parades, Verimag

The integrated project Speeds is funded by the European Commission under contract FP6-033471

Rich Components


SC - Safety Critical Systems4, March 2008 15

„Rich Components“- Objectives

To provide a characterization of components of automotive electronic components

supporting all phases, levels, and viewpoints of electronic system designAllowing complete re-use (across multiple platforms, across multiple organizations, and/or as part of design libraries)Allowing characterization of allowed/assumed environments of component (for all viewpoints)Basis for (de-facto) standardization, compatible with Autosar Component Model

As basis for tool-independent meta-model for capturing and validating function networks

Supporting semantic based integration of industry standard System & SW design tools (UML, Matlab-Simulink/Stateflow, ASCET, …)Supporting view-point specific and cross viewpoint requirement capturing, modeling, analysis and design


SC - Safety Critical Systems16

Rich Component Model

Follows Design by Contract Paradigm

Assumptionsreflect current degree of knowledge of anticipated design contextDetermine boundary conditions on actual design context for each view-point under which component is promising its servicesare decorated with confidence levels

PromisesAre guaranteed if component is used in assumed design context

Organized per viewpointBehaviour, Coordination, Safety, Real-Time, ….But allows specification of cross viewpoint dependencies

Assumed

EL

FL

SL

From/by lower design levels

from neighbors

Promised

From/by higher design levels

to neighbors

HL



DCPS

Assumption:Status of vehicle‘ availableevery t ms

Promise:Status(vehicle‘) == braking(p)impliesSignal(Brake(p)) within t‘ ms

Assumption:Distance sensor values davailable every t ms

Promise:<d at t1> less than <d at t0>impliesSignal(Brake) within t‘ ms

…

PBK

PDS

Get statusinformation of vehicle ahead

Get distance informationbased on sensor values

Provide controlcommands

Contracts


Adding contracts: ExampleExpressing assumptions on task activation

Use contract editorto identify relevant component and port

Choose patternfrom real-timelibrary to captureassumptions

Here: Activation patternfor periodicsystems

18


Adding contracts: ExampleExpressing promise on maximal delay

19

Use contract editorto identify relevant component and port

Choose patternfrom real-timelibrary to captureassumptions

Here: Delay Pattern

Link assumption on task activation to promise on maximal delay


20

Heterogenous Rich ComponentsMetamodel Characteristics

Based on SysMLAdded Features

Contracts (Assumptions, Promises)ViewpointsLayers (Functional Network, ECU, Physical Architecture, ..)

Available as Standalone Metamodel Implementationand SysML ProfileEquipped with formal semantics

building on few „semantic atoms“: continuous evolution, discretetransitions, random choicesemantic basis for contract compliance/dominance

a

b?b!

c c

A1A2 for all viewpoints v:

∩ L(A(OutI.v.prj)) ⊆∩ L(A(InI.v.assmi))

SpeedsSemantic Foundation

SpeedsMetamodel

AK

BR

GR SK

LR

component Cbegin view Real-time

interface I beginbegin ……. endend ….

view functional ….begin end C…end

view safetybegin…end

User‘s View: COTS modeling toolsSimulinkTM SCADETMRhapsodyTMSildexTMContractEditor


Use Cases supported by Speeds bus

SPEEDS Engineering Bus

Model Repository

Modeling

Tool X

Modeling

Tool Y

Simulink

Rhapsody

SCA

DE

Analysis X

Analysis Y

RT-B

uilder

Simulink

SCA

DE

Rhapsody

Tool Z

SCA

DE D

isplay

Adapter Adapter

ProcessAdvisor

Modeling

Tool X

Use Case 1: Designing Functional Network (Structure) in Tool 1

SYS

F1

F3

F4

F2

Contracts for F3

Contract C1:Assumption:

……..Promise:

…..


……..Promise:

…..

Contracts for SYS

Contract C:Assumption:

……..Promise:

…..

Contract C’:Assumption:

……..Promise:

…..

Tool 1 – Functional NetworkTool 1 – Functional Network

SYS

F1

F3

F4

F2Contracts for F 3


……..Promise:

…..


……..Promise:

…..

Contracts for SYS


……..Promise:

…..


……..Promise:

…..


SYS

F1

F3

F4

F2Contracts for F3


……..Promise:

…..


……..Promise:

…..

Contracts for SYS


……..Promise:

…..


……..Promise:

…..

Classification of contracts w.r.t. viewpoints

Functional BehaviourAssumption:

in1 in range [a..b]in2 in range [a..b]

Promise:out = funct(in1, in2)

Real-TimeAssumption:

every request for sensor values willbe answered within [t0..t1]

Promise:new actuator values will be transmitted every t ms




Model Repository

Modeling

Tool X

Modeling

Tool Y

Simulink

Rhapsody

SCA

DE

Analysis X

Analysis Y

RT-B

uilder

Simulink

SCA

DE

Rhapsody

Tool Z

SCA

DE D

isplay

Adapter Adapter

ProcessAdvisor

SYS

F1

F3

F4

F2

Contracts for F3


……..Promise:

…..


……..Promise:

…..

Contracts for SYS


……..Promise:

…..


……..Promise:

…..


Simulink

Use Case 2: Designing a Component (Implementation) in Tool 2Tool 2 – Component F3Tool 2 – Component F3

F3Contracts for F 3


……..Promise:

…..


……..Promise:

…..

1

Transmissionratio

NinNout

Tout

gear

TinTorqueconverter

2

3

1

2

Ti

Tout

Ne

gear

Nout

turbine torque

F3

1

Transmissionratio

NinNout

Tout

gear

TinTorqueconverter

2

3

1

2

Ti

Tout

Ne

gear

Nout

turbine torque

Contracts for F3


……..Promise:

…..


……..Promise:

…..


SYS

F1

F3

F4

F2Contracts for F 3


……..Promise:

…..


……..Promise:

…..

Contracts for SYS


……..Promise:

…..


……..Promise:

…..

Tool 2 – Component F3Tool 2 – Component F3

F3Contracts for F3


……..Promise:

…..


……..Promise:

…..

1

Transmissionratio

NinNout

Tout

gear

TinTorqueconverter

2

3

1

2

Ti

Tout

Ne

gear

Nout

turbine torque




Model Repository

Modeling

Tool X

Modeling

Tool Y

Simulink

Rhapsody

SCA

DE

Analysis X

Analysis Y

RT-B

uilder

Simulink

SCA

DE

Rhapsody

Tool Z

SCA

DE D

isplay

Adapter Adapter

ProcessAdvisor

SYS

F1

F3

F4

F2

Contracts for F3


……..Promise:

…..


……..Promise:

…..

Contracts for SYS


……..Promise:

…..


……..Promise:

…..


Analysis 1

Use Case 3: Analysis 1 (Compatibility)Tool 2 – Component F3Tool 2 – Component F3

F3Contracts for F 3


……..Promise:

…..


……..Promise:

…..

1

Transmissionratio

NinNout

Tout

gear

TinTorqueconverter

2

3

1

2

Ti

Tout

Ne

gear

Nout

turbine torque

Analysis 1 – Compatibility F3 - SYSAnalysis 1 – Compatibility F3 - SYS

Select Components

StructureSYS

F1

F4

F3F2

PortsContracts

C1

ImplementationF3

PortsContracts

Con1

Component 2

Component 1

Con2

C2

Options Analysis

Check Compatibility of ContractsΞ Defined in the Structure DefinitionΞ Defined in the Implementation

Check Compatibility of PortsΞ Defined in the Structure DerfitionΞ Defined in the Implementation

Check ...

F3

1

Transmissionratio

NinNout

Tout

gear

TinTorqueconverter

2

3

1

2

Ti

Tout

Ne

gear

Nout

turbine torque

Contracts for F3


……..Promise:

…..


……..Promise:

…..


Select Components

StructureSYS

F1

F4

F3F2

PortsContracts

C1

Implementation

F3PortsContracts

Con1

Component 2

Component 1

Con2

C2

Options Analysis

Check Compatibility of ContractsDefined in the Structure DefinitionDefined in the Implementation

Check Compatibility of PortsDefined in the Structure DefinitionDefined in the Implementation

Check ...


SYS

F1

F3

F4

F2Contracts for F 3


……..Promise:

…..


……..Promise:

…..

Contracts for SYS


……..Promise:

…..


……..Promise:

…..




Model Repository

Modeling

Tool X

Modeling

Tool Y

Simulink

Rhapsody

SCA

DE

Analysis X

Analysis Y

RT-B

uilder

Simulink

SCA

DE

Rhapsody

Tool Z

SCA

DE D

isplay

Adapter Adapter

ProcessAdvisor

SYS

F1

F3

F4

F2

Contracts for F3


……..Promise:

…..


……..Promise:

…..

Contracts for SYS


……..Promise:

…..


……..Promise:

…..


Analysis 2

Use Case 4: Analysis 2 (Advanced Analysis Techniques)Tool 1 – Functional NetworkTool 1 – Functional Network

SYS

F1

F3

F4

F2

Contracts for F 3


……..Promise:

…..


……..Promise:

…..

Tool 2 – Component F3Tool 2 – Component F3

F3Contracts for F 3


……..Promise:

…..


……..Promise:

…..

1

Transmissionratio

NinNout

Tout

gear

TinTorqueconverter

2

3

1

2

Ti

Tout

Ne

gear

Nout

turbine torque

Analysis 2 – SchedulabilityAnalysis 2 – Schedulability

Advanced Analysis Techniques

I2 O2

I1 O1

TDMAschedule

TDMAschedule

TDMAschedule

Supplier X

Function A

Function B

OEM OEM

OEM

OEM

I2 O2

I1 O1

I2 O2

I1 O1

I2 O2I2 O2I2 O2

I1 O1I1 O1I1 O1

TDMAschedule

TDMAschedule

TDMAschedule

Supplier X

Function A

Function B

OEM OEM

OEM

OEM


Select Components

StructureSYS

F1

F4

F3F2

PortsContracts

C1

ImplementationF3

PortsContracts

Con1

Component 2

Component 1

Con2

C2

Options Analysis

Check Compatibility of ContractsΞ Defined in the Structure DefinitionΞ Defined in the Implementation

Check Compatibility of PortsΞ Defined in the Structure DerfitionΞ Defined in the Implementation

Check ...

F3

1

Transmissionratio

NinNout

Tout

gear

TinTorqueconverter

2

3

1

2

Ti

Tout

Ne

gear

Nout

turbine torque

Contracts for F3


……..Promise:

…..


……..Promise:

…..

I2 O2

I1 O1

TDMAschedule

TDMAschedule

TDMAschedule

Supplier X

Function A

Function B

OEM OEM

OEM

OEM

I2 O2

I1 O1

I2 O2

I1 O1

I2 O2I2 O2I2 O2

I1 O1I1 O1I1 O1

TDMAschedule

TDMAschedule

TDMAschedule

Supplier X

Function A

Function B

OEM OEM

OEM

OEM


RCM in the Design Process (Focus Real-time)

OEM Supplier

Specification of Functional Network

Design SpaceExploration

DecompositionOf Contracts

Contracts(Ai, Pi)

Guaranteedby OEM

(resp. othersuppliers)

Requirements

Contracts(A, P)

To beGuaranteedby Supplier

Component Design

Final Deployment


RCM in the Design Process (Focus Real-time)

OEM Supplier




Contracts(Ai, Pi)

Guaranteedby OEM


Requirements

Contracts(A, P)


Component Design

Final Deployment


System level timinganalysis

Is applied to meta-modelrepresentation of designsat function layerVerifies end-to-endproperties and/or timedsequence diagramsIs based on verticalassumptions (typicallydelay constraints)Assumptions annotatedwith confidence levels

S

DSAK

BRvsvs

dsd

bsp

asp

gdmd

S AK DS BR

S.vs→AK.vs

AK.gd→DS.md

DS.d→AK.ds

AK.bsp→BR.sp

ENV

BR.a[0,50]ms

delay(vs,gd)=[0,8]msdelay(ds,bsp)=[0,5]ms

Vertical assumption

delay(md,d)=[0,1]ms

Vertical assumption

Vertical assumption

End-

to-e

ndde

adlin

e

ConfLevel=high

ConfLevel=highConfLevel=low

ConfLevel=low

delay(DS.d,AK.ds) =[0,6]ms


Contract Compatability

Assumptions in contractsassociated with ports constrainallowed environmentsContracts of virtualcommunication componentcharacterize space of viablecommunication architecturesExample use case for contractcompatibility: composition of components coming fromdifferent suppliersExample compatability check:Is contract of component DS compliant to assumptions of communication component

DS

AK

Supplier A

Supplier B

Receive(DS) each 30ms withmax. 8ms jitter

Send(DS) each30ms with max. 3ms jitter

Flexray BackboneCAN

Transmit(DS) each 30ms withmax. 7ms jitter



C1=(A1,P1)

C2=(A2,P2)

VirtualCommunicationComponent


SPEEDS – System-level hostedsimulation

SimulinkTM SCADETM

RhapsodyTM

SildexTM

Compiler

SWC1.c

Wrapper

Code generation

SWC2.c

Wrapper

Code generation

SWC3.c

Wrapper

Code generation

SWC4.c

Wrapper

Code generation


SC - Safety Critical Systems31

Design Space ExplorationOEM Supplier




Contracts(Ai, Pi)

Guaranteedby OEM


Requirements

Contracts(A, P)


Component Design

Final Deployment

Analysis of the architecture also w.r.t. other viewpoints, e.g.

Safety


Architectureexploration

Given:Partially defined architectureNetwork of functions, partiallyknown by re-use of alreadydesigned components

Early assessment of architectural solutionsContracts to lower layer of abstraction used to definerequirements forimplementation of functionsExpress contracts based on

ExperiencePrevious developmentsModel based estimations

DS AS VS

LS GS MSBA TA LA

S

BR

GR SK

LR

Flexray Backbone

CANDS

AK


Architectur exploration – Approach

Establish link betweenvertical assumptions at system level and vertical promises of detailed designCheck dominance

SimulinkTM SCADETM

RhapsodyTM

SildexTM

S AK DS BRS.vs→AK.vs

AK.gd→DS.md

DS.d→AK.ds

AK.bsp→BR.sp

ENV

BR.a[0,50]ms

Requirement

Vertical Assumptionon AK:

AK.vs every 50ms with max. 3ms

jitter

Flexray

S vs

AK

vs

ds

bsp

gd

CAN

S vs

AK

vs

ds

bsp

gd

Vertical Promiseon AK:


jitter

Vertical Promiseon AK:


jitter

Solution 1 Solution 2


Assessments of architectural variantssupported by automatic analysismethodsMinimize the number of ECUsRobustness : Often parameters, e.g. WCET, are uncertain. Design optimization has to consider robustness under variations of WCET

Penalty of changes: late integration of new functions induces changes in the already implemented system, but number of changes has to be kept small. Must assess deployment wrt penalty for changes


SC - Safety Critical Systems354, March 2008

Creating Deployable Units

OEM Supplier




Contracts(Ai, Pi)

Guaranteedby OEM


Requirements

Contracts(A, P)


Component Design

Final Deployment

ContractsReal-time View

Assm: ...Promise:

„Local End-to-End Deadlines“



Generating requirements for suppliersDesign space exploration returns class of feasible architecture

After finding architecture and communication matrix (used slots in TDMA rounds on bus and ECUs), generate timing requirements for outsourced software components:

Requirements for these delivered to supplier as part of contract

Assume class of architectureAssume allowed behavior of environment (e.g. activation pattern)Promise maximal delay and jitter

Enables incremental integration by OEM based on contracts

If supplier fulfills its contract, integration will be successfulAllows supplier to develop function in isolation without the need to consider functions coming from OEM or other suppliers


Getting the best of both worlds

RCM supports system leveldesign

RCM enables combination of model based design and contract-based reasoning

AUTOSAR starts on functionalnetwork level

Combination of both covers theentire V-cycle starting fromrequirements and ending in implementation of operational architecture


Requirements

System level design

Detailed design

Implementation Arch.

AUTOSAR Operational Architecture – OS, COM

AUTOSARApplication SW Arch.

BSWArch.

HWArch.

EnvironmentM

odel


AUTOSAR enabled system level analysisSystem level analysisis based on verticalassumption, e.g. response times of components

AUTOSAR definesoperational architecture

Special tailoredanalysis can be usedto verify correctnessof assumptions usedfor system analysis(e.g. schedulinganalysis) SC - Safety Critical Systems4, March 2008 38

SimulinkTM SCADETM

RhapsodyTM

SildexTM

S AK DS BRS.vs→AK.vs

AK.gd→DS.md

DS.d→AK.ds

AK.bsp→BR.sp

ENV

BR.a[0,50]ms

RequirementVerticalAssumption3

VerticalAssumption2

VerticalAssumption1

Analysis


Integration with Autosar: what it takes

PrinciplesAllow association of contracts to SWCsTiming Extensions of Autosar Meta-Model (under development), incl. timing characteristics of BSWSimilarly: Extensions wrt other supported viewpoints, such as safetyAnalysis of System- and ECU configurations to derive promises characterizing configurationTranslation of Autosar Meta-Model concepts into HRC meta-model

VFB, runnables, topology, tasks, …


Translation of SW components

Software components of AUTOSAR and those of RCM are similar

Definition as well as refinement can be directlytranslated

AUTOSAR runnables aretransformed into RCM components, Inter Runnable Variables becomeports and connections

AKPS

PDS

AKPS

PDS

<<PortSpec>>PS

discrete in speed : float

HRC

RPort behaviorsee next slides


4, March 2008 41 SC - Safety Critical Systems

Triggering runnables – TimerEvents

AUTOSAR runnables are transformed into RCM components, Inter Runnable Variables become portsand connections

Timer events triggering runnables can be mapped to a component which implements the timers behavior

Periods of timer events can be mapped to promisesof timer components

Timer Runnable

Promise:E every10ms

E


ConclusionAdding Speeds to Autosar provides a seamless design flow from requirements to Autosar based implementations supportingMulti-viewpoint contract based requirement capturingSemantic integration of industry standard design tools for capturing system-level requirements and specificationsA suite of analysis and design methods, including

Contract compatibility and dominance checkingSystem-level safety and timing analysisDesign Space exploration Hosted Simulation enhanced with run-time contract monitoring

Assessment and optimization of implementation architecture as captured in Autosar configurations

Documents

How to enrich AUTOSAR based design processes with enabled … · Autosar World wide private partnership of automotive OEMs, tier1/tier2 suppliers, SW-houses, vendors to push standardization