Component models for embedded systems: from UML to Autosar Franois - - PowerPoint PPT Presentation

▶
component models for embedded systems from uml to autosar
SMART_READER_LITE
LIVE PREVIEW

Component models for embedded systems: from UML to Autosar Franois - - PowerPoint PPT Presentation

Dec 17, 2022 119 likes •490 views

Component models for embedded systems: from UML to Autosar Franois Terrier with contributions from Sylvain Robert, Ansgar Radermacher, Frdric Loiret CEA-List francois.terrier@cea.fr DTSI Monterey Workshop, Paris - 2006, October 17 1

slide-1
SLIDE 1

Monterey Workshop, Paris - 2006, October 17 1

DTSI

Component models for embedded systems: from UML to Autosar

François Terrier

with contributions from Sylvain Robert, Ansgar Radermacher, Frédéric Loiret CEA-List francois.terrier@cea.fr

slide-2
SLIDE 2

Monterey Workshop, Paris - 2006, October 17 2

DTSI

Local context of researchs

Usine Logicielle

@

slide-3
SLIDE 3

Design and control of complex systems

slide-4
SLIDE 4

Multi domain tools for Model Driven Engineering Heterogeneity & interoperability management

Usine Logicielle

@

Design and control of complex systems Models Verification, testing, co-simulation Heterogeneous modeling

Formalisms Bridges MARTE UML RTE DSL Plug EMF Reposit. Scilab Action Language DSL Plug Scade Formalisms Bridges UML2 Meta M Model transfortation language

Execution infrastructure built through generation & libraries Integration of fault tolerance services

Container

Component

www.usine-logicielle.org

slide-5
SLIDE 5

NUM@TEC

AUTOMOTIVE

NUM@TEC

AUTOMOTIVE

Research program on embedded systems for automotive & transportation

AUTOMOTIVE AUTOMOTIVE

Requirement modeling, traceability & ADL Execution platform and design for Safety Performance analysis

  • n OSEK

plateform Heterogenous system simulation

Usine Logicielle

@ Automotive instanciation

Design and control of complex systems

www.numatec-automotive.com

slide-6
SLIDE 6

Monterey Workshop, Paris - 2006, October 17 6

DTSI

UML & Component model

… Starting with a UML profile for RT!

slide-7
SLIDE 7

Monterey Workshop, Paris - 2006, October 17 7

DTSI

Building a MDE tool chain for RTES

  • a conceptual framework
  • a development process and method,
  • a set to software engineering tools
  • an execution platform

to assist in developing applications from requirements to deployment

Req. documents

Accord|UML

Preliminary analysis rules

Prototyper Spec. valider System Analyst System Analyst PAM DAM Validation Model Prototype Model Testing Model

Accord|UML

Detailed analysis rules

Accord|UML

Validation rules

Accord|UML

Testing rules

Accord|UML

Prototyping rules

  • UML and profile based approach

UML models Modelling rules

  • UML 2.0 Profiles

For RTE concepts

  • Tools to support methodology

Automated refinement Pattern appliance Model validation

  • Dedicated RT Kernel

Code generation

slide-8
SLIDE 8

Monterey Workshop, Paris - 2006, October 17 8

DTSI

Introduce High level concepts

RealTimeObject: extend UML active object

aRealTimeObject

Selection & concurrency control

Attributes

  • pe_1

signal_1 ... task

Method code Memory space

UML stereotype

Chose way to model RealTimeObject behavior

Use of protocol state machines ( now in UML2, see DIPES’2000…)

Off On C initReg[cptVit->getSpeed()=<30] /display("ON"); stopReg/display("OFF"); tm(100)/tgSpeed = cptVit->getSpeed(); [carSpeed=<30]/display("OFF"); /delta=k1*atan(tgSpeed-cuSpeed); mot->sendCmd(coupleVariation);

tgSpeed : int initReg() stopReg() Regulator

Logic Logic Algorithmic Algorithmic

&

Method behavior Algorithmic parts

start_ maintainSp() / endOf_maintainSp() Begin End carSpeed = cptVit->getSpeed(); delta=k1*atan(tgSpeed-cuSpeed); mot->sendCmd(coupleVariation); Regulator +tgSpeed : integer +initReg() +stopReg() +maintainSp() Off On initReg() stopReg() maintainSp()

Class behavior-Control logic (protocol of use)

slide-9
SLIDE 9

Monterey Workshop, Paris - 2006, October 17 9

DTSI

Fix execution model

Specify queue management policy Specify signal management Specify concurrency constraints …

Refine UML protocol statemachines

Attach selection criteria on each message in the queue

RealTimeFeature

Declare constraints instead to implement them for implementation/platform independence purpose…

slide-10
SLIDE 10

Monterey Workshop, Paris - 2006, October 17 10

DTSI

Building complete models

Separate control (object life cycle) from data processing:

  • Control mechanisms are modeled using state machines
  • Data processing actions are modeled using UML activity diagrams
  • Require addition of explicit notations and some basic actions
  • Mathematical actions are modeled using MathML language syntax
  • Accord|ALproposes two formalisms
  • A textual (edited in the model)
  • A graphic based on UML activity diagram

In the profile, each action is defined by 3 elements + examples: semantics, textual notation (in EBNF), graphic notation

Ada like SDL like …. Java like

slide-11
SLIDE 11

Monterey Workshop, Paris - 2006, October 17 11

DTSI

Modeling rules for preliminary model definition

Interactions with the developed system seen as a black box Focuss on use case definition and collaboration specifications

slide-12
SLIDE 12

Monterey Workshop, Paris - 2006, October 17 12

DTSI

Assistance and automation: generation (& trace) of the detailed model squeleton

slide-13
SLIDE 13

Monterey Workshop, Paris - 2006, October 17 13

DTSI

Model translation into formal model Behavior analysis through symbolic execution

Formal analysis of system behavior from its UML model

slide-14
SLIDE 14

Monterey Workshop, Paris - 2006, October 17 14

DTSI

Feedback for behaviour representation

Test sequences automatically generated and imported in modeler

slide-15
SLIDE 15

Monterey Workshop, Paris - 2006, October 17 15

DTSI

UML for RTES: a set of ongoing actions

Formalise an action language

UML 2 MOF XMI

Executable UML foundation

Autosar 2

Time model (clock/synchr) Characteristics Ressources Aligment

  • f timing

infos

slide-16
SLIDE 16

Monterey Workshop, Paris - 2006, October 17 16

DTSI

Overview of the tool set

Component Based Execution infrastructure built through generation & libraries

UML back bone

UML2 MetaM MARTE Accord1 prof Action

  • Lang. Ed.
  • Comp. ADL prof.

Platform models Code, wrapper generator

Formal techniques

Test generation Scheduling analysis Requirement validation

  • Sched. prof

Accordn prof

  • Test. prof
  • Req. prof

Method support

EMF Reposit.

slide-17
SLIDE 17

Monterey Workshop, Paris - 2006, October 17 17

DTSI

Component diagram

Model the system architecture identifying

  • Modular and replaceable parts of a system

Content is encapsulated Can be replaced during design time or execution time

  • Provided and required interface describing:

Some structural points (attributes, associations, …) Its behaviour (operation, reception, state-machine, …)

  • Two possible views

Extern (“black box”): contract of use, visible behaviour Intern (“white box”)

Shows elements being purely intern to the component (« private ») Shows how behaviour defined by the interface are implemented

  • Connexion mechanisms

Interface dependencies (association, use, realization)

slide-18
SLIDE 18

Monterey Workshop, Paris - 2006, October 17 18

DTSI

UML 2.0 Interface

Specify operation, signal, attribute, behaviour No instances (~abstract class) “Provided” realized by a classifier (Class, Component…)

A classifier can realize several interfaces

Required used by a classifier

« Interface » Starter start() stop() « reception » OnOff maxSp: float

Starter Display

« component »

SpeedRegulator Figure2: condensed notation

Provided Provided provided

  • peration

provided signal reaction provided data

slide-19
SLIDE 19

Monterey Workshop, Paris - 2006, October 17 19

DTSI

Interface can have constraint of use

  • Conformance between Interface / Realisation

protocol state-machine conformance

  • State invariant, pre- and post-conditions of interface

protocol apply on realization state-machine

TorqueManager

+start() +stop() « reception » +OnOff +maxSp: float

  • calcTorque()
  • targetSp: float

waiting running start stop OnOff OnOff

{protocol}

calcTorque

New states, transitions,

  • perations,

receptions are allowed

« Interface » Starter start() stop() « reception » OnOff maxSp: float waiting running start stop OnOff OnOff

{protocol}

Possible formal interpretation:

  • Real. state Inv. ⇒ Interf. state Inv.
  • For each mapped operation
  • Interf. Pre ⇒ Real. Pre
  • Real. Post ⇒ Interf. Post
slide-20
SLIDE 20

Monterey Workshop, Paris - 2006, October 17 20

DTSI

Connectors

  • Delegation connector links interfaces
  • f a component with contained parts

Display Starter

« component »

SpeedRegulator

SpM_I

DispSp

« component »

SpeedSensorManager TorqueManager

mySSM 0..1

Used to model behaviour

implementation in nested components

Implementation conformity required

  • Assembly connector links

required and provided interfaces

Conformity of the interfaces required

Starter Display

« component »

SpeedRegulator

« component »

RegulatorScreen

Implicit assembly connector

slide-21
SLIDE 21

Monterey Workshop, Paris - 2006, October 17 21

DTSI

Ports

  • Ports to structure usages of the interfaces

Display Starter

« component »

SpeedRegulator

SpM_I

DispSp

« component »

SpeedSensorManager TorqueManager

mySSM 0..1

ErrorOut ErrorIn

  • Ports making explicit communication links

« component »

SpeedRegulator

« component »

RegulatorScreen

{CCM RPC}

slide-22
SLIDE 22

Monterey Workshop, Paris - 2006, October 17 22

DTSI

  • From Models to Implementation:

Use of a MW component model

slide-23
SLIDE 23

Monterey Workshop, Paris - 2006, October 17 23

DTSI

A CCM component and its container

  • Principle of CCM component definition

IDL interface descr. CCM Component Life cycle management Event sink Receptacles Event source Facets Attributes

component

Mgt

CIDL component deployment descr.

  • CCM component model
slide-24
SLIDE 24

Monterey Workshop, Paris - 2006, October 17 24

DTSI

Container/Component model

  • Container associated to component aims to

Localise functional product upgrade in the component Localise dependencies to platforms in the container Provide acces to infrastructure services

Execution Infrastructure

Component

Container

Component

  • Separation of concerns:

business logic 'technical' properties

  • Explicit description of:

provided services to other components requested services from other components

Containers are provided as part of the infrastructure Based on descriptors move from programmatic to declarative Easier deployment and reuse, needed for reconfiguration

slide-25
SLIDE 25

Monterey Workshop, Paris - 2006, October 17 25

DTSI

Containter limitation on interactions

  • CCM interactions extensions:

Complex RTE interactions (Streaming, Event passing with priorities,

Buffering, Various pub/sub, Deferred synchronous call, Blackboard)

Modular, extensible interactions

  • Make interactions independent from CORBA

Embedded Constrained HW platforms

  • Have minimal impact on CCM

Reuse of existing items

  • Methodological benefits:

Interactions management peculiar to business domain Expertise capitalization

slide-26
SLIDE 26

Monterey Workshop, Paris - 2006, October 17 26

DTSI

Introducing connectors: C3M Component-Container-Connector Model

  • Software entity managing inter-components interaction:

May be considered as part of the container Fragmented Communication layer specific to the connector (potentially) complex intermediary processing

Node A

container component

Node B

container component

Communication layer – connector specific (e.g. OSEKcom)

Interaction Connector Client connector fragment Server connector fragment

slide-27
SLIDE 27

Monterey Workshop, Paris - 2006, October 17 27

DTSI

Introducing connectors: C3M

  • Conceptual mapping with UML components

Node A

container component

Node B

container component Interaction Connector Client connector fragment Server connector fragment

« component » « component » {Genric: Deleyed synchronous} {Domain: “Aloha” protocol}

Communication layer – connector specific (e.g. OSEKcom)

slide-28
SLIDE 28

Monterey Workshop, Paris - 2006, October 17 28

DTSI

Illustration with the OSEK platform

  • Execution infrastructure for highly constrained

hardware platforms

  • an operating system (OSEK-OS)
  • multi-tasking operating system
  • highly static, all resources declared at compile time (OIL file)
  • coupled with a communication environment (OSEK-COM)
  • simple message-based communication

From CCM to OSEK: Mapping a (highly dynamic) component- based approach (CCM) on a basic (and highly static) RT/OS!

How preserving the CCM development process?

slide-29
SLIDE 29

Monterey Workshop, Paris - 2006, October 17 29

DTSI

Illustration with OSEK - Execution model

  • Activities instead of components

Identification of activities (control flows) in application architecture

Basically linked to application entry points

Activities timing features description (e.g. end-to-end deadline)

  • Mapping to tasks

Components are design-time development artifacts,

with no runtime counterpart

Component code is kept intact

Task2 Task1 CF1 CF2

slide-30
SLIDE 30

Monterey Workshop, Paris - 2006, October 17 30

DTSI

Illustration with OSEK - Communications

  • Each Interaction mechanism is realized by a
  • connector. Ex: synchronous call:

The connector fragment at caller side sends an event The connector fragment at target side receives this event Infinite loop

TASK

WAIT EVENT CLEAR EVENT CALL ACTIVITY

C1 C2 provided asynchronous Enqueue request + SetEvent required

slide-31
SLIDE 31

Monterey Workshop, Paris - 2006, October 17 31

DTSI

Illustration with OSEK - container services

C1

  • Periodic activation:

Achieved through the use of

alarms and counters

Interaction with a timer module

(part of framework)

Alarm_C1 Period = P_C1

Callback

Timer

Periodic increment BaseCounter

Callback

Alarm_C2 Period = P_C

C2

slide-32
SLIDE 32

Monterey Workshop, Paris - 2006, October 17 32

DTSI

Illustration with OSEK – complete generation chain

C

IDL

C

IDL

C

IDL

Architecture Deployment generated

make file OIL Desc. Container SRC Component OBJ or LIB (COTS ) Init. Component SRC (App. specific) CFG.

Generation tool Compile and Link tool

  • Mapping from IDL to Embedded C++
  • Connector gen. for asynch invocations
  • Integrated into OSEK develop. Chain
  • Achieved small footprint (1 component)
  • component ROM : 2,71 kBytes RAM : 17 Bytes
  • container ROM : 23,8 kBytes RAM : 1,43 kBytes

Application CPU 1 Application CPU 2 Application CPU N

…

slide-33
SLIDE 33

Monterey Workshop, Paris - 2006, October 17 33

DTSI

Conclusion

  • The (MDE) process is similar

to several approaches such as (e.g.)

AADL & tools Fractal / Think Autosar + tools

slide-34
SLIDE 34

Monterey Workshop, Paris - 2006, October 17 34

DTSI

Component interface description « Fractal IDL » Component deployment description “Fractal ADL” MW&OS generation MW&OS assembly

slide-35
SLIDE 35

Monterey Workshop, Paris - 2006, October 17 35

DTSI

Component interface description « Autosar IDL » Component deployment description “Autosar ADL” Autosar MW (RTE) and task parameters generation

slide-36
SLIDE 36

Monterey Workshop, Paris - 2006, October 17 36

DTSI

Starting action…

Fractal C3M UML LwCCM PolyORB OASISCEA UML profile for RT-ADL MARTE UML Common component model Think µCCM PolyORB OASISCEA

Try to push some convergence on component Models and technologies