dtsi/sla/ 1 mda for embedded system development, brest, france, september 16, 2002 uml and real time...

Dtsi/SLA/

1MDA for Embedded System Development, Brest, France, September 16, 2002

UML and Real Time

•François Terrier, Sébastien Gérard

•DRT-LIST/DTSI/SLA/LLSP, CEA/Saclay, F-91191 Gif sur Yvette Cedex France

Phone: +33 1 69 08 62 59 ; Fax: +33 1 69 08 83 95•[email protected] ; [email protected]

Dtsi/SLA/


Plan of the presentation

• UML2 standardization status

• Real Time, QoS, SPT profile and UML

• Point on current tools for RT with UML(TAU UML Suite, ARTiSAN Studio, Rhapsody

ROSE RT, Esterel Studio)

• Real Time modeling with ACCORD/UML Protocol state machine RT Component Model MDE through UML profiles

Dtsi/SLA/


RT in UML 1.4

•Quantitative aspects TimeEvent in state-machine Timing mark in Sequence Diagram

Qualitative aspects Concurrency : Active object, Concurrent state, …

Discrete behavior via state machinesand activity

diagrams

Attempts of integrating continuous behaviorwithin activities of state-

machines

Dtsi/SLA/


Status of the UML2 proposals

Two remaining main prop. for Infra/Super U2 group (www.u2-partners.org )

Infrastructure latest version is v.2.0 beta R2 released 2002/06/02 2U group (www.2uworks.org )

Infrastructure latest version is v0.81 released 2002/07/02

Helsinki meeting (End of September 2002) 1st revised submission presentation for Superstructure 2nd revised submission presentation for Infrastructure

UML2 RFP split into 4 parts UML 2.0 OCL UML 2.0 Diagram Interchange UML2 Infrastructure core language of UML UML2 Superstructure state-machine, sequence diag., …

Dtsi/SLA/




• Real Time, QoS, SPT profile and

UML




Dtsi/SLA/


Proposers and supporters ARTiSAN, I-Logix, Rational, Telelogic,

TimeSys, Tri-Pacific, CEA-LIST

Main concepts resources & quality of service (QoS) uniform basis to attach quantitative information to UML

specifications (e.g. required for RT analysis performing)

ClientClientS1S1S1S1

ResourceAResourceAS2S2S2S2

ResourceBResourceBResourceBResourceB

CPUCPU

CPU

Physical ProcessorPhysical Processor

Not THE Real Time UML profile… !

Scheduling, Performance & Time Profile

Dtsi/SLA/


Current architecture of UML SPT profile

General Resource Sub-profile (Defines abstract concepts of Resource & QoS)

• Resource concept has been developed• QoS concept remains abstract !

General Time Sub-profileGeneral Concurrency Sub-profile

Genericsub-profiles for real-time applications

Specific sub-profilesfor dedicated activities

around real-timeapplication development

• Performance Sub-profile

• Schedulability Sub-profile

Consists of 5 sub-profiles

Dtsi/SLA/


SPT base concept QoS

• Use example of the QoS concept in a model

ResourceService

0..n0..n +offeredQoS

Resource

0..n0..n

ResourceUsage

0..n

+requiredQoS

0..n0..n0..n

1..n0..n 1..n0..n

QoSCharacteristic (Abstract class !)

/:SRV

aDriver/:Driver regOutput/:Display

start

display«RTaction»

{RTstart=(10, 'ms')}

Required QoS

display():

«SAAction»

{SAWorstCase=(25,'ms'),

RTduration=(5,'ms')}

Offered QoS

Dtsi/SLA/


Issues relating to QoS within SPT prof.

QoS remains an abstract concept never concretized by other SPT sub-profiles

Specific sub-profiles(Schedulability, Performance, RT-CORBA)• defines implicitly required QoS (eg. TVs SAPriority, SADelay, …)

• but no links with the QoScharacteristics concept !

SPT does not proposes solutions to specify:• domain specific QoS characteristics quantifiables with specific

values (e.g. capacity of fligth plan managnt, antenna sign. accuracy)

• QoS contracts in subsystems, components and use cases

• QoS modes the systems supports: adaptations & QoS levels

• monitoring of QoS values and their impact in the architectures

Dtsi/SLA/


<<metamodel>>

QoSCharacteristics

<<metamodel>>

QoSContracts

<<metamodel>>

QoSModes

RTResourceModeling

<<metamodel>>

QoSAdaptation

<<metamodel>>

QoSCharacteriscCore

<<metamodel>>

QoSContexts

CoreResourceModel

Architecture of QoS (& Fault Toler.) prof.

What are you talking about?

1

What we need to take into account?

2What can you do?

What do you want?3

What happen when ...?5

How can you execute?

4

Dtsi/SLA/


RT refactoring in UML

Schedulability Analysis Performance Analysis Code Generation

Specific sub-profiles for dedicated activitiesaround real-time application development

...…

3 points:

Generics for RT domain

QoS & Resource

Concurrency Time Throughput/Performance Lantency ...

1

<<metamodel>>

QoS & Resource MM

<<profile>>

QoS & Resource SP

MOF UML MM

<<instantiate>>2

UML 2

RT package

?

3

Dtsi/SLA/





• Point on current tools for RT

with UML TAU UML Suite

ARTiSAN Studio, Rhapsody, ROSE RT, Esterel Studio


Dtsi/SLA/


Passive objects Abstract Data Types of SDL

Active object declarations SDL processes

ActuatorControl

RegControl [cmd

]

C1

SensorControl

[speed]

C2

ActuatorControlRegContr

ol

SensorControl

pRC 1

pAC

1

RegulatingLaw

pAC

1

Newtype RegulatingLaw

Operators

calculate : Speed, Speed -> TorqueVariation

endnewtype:;

SpeedRegulator_Behavior

On

stopRegulating() / updateScreen(OFF);

Off startRegulating()

/ targetSpeed = returnValue;

Stopped

Running

Stopped

Running

stopRegulating

updateScreen(OFF)

startRegulating

targetSpeed = returnvalue

TAU UML/SDL Suite UML modeling is used at the first modeling stage,

SDL used for design…

Dtsi/SLA/


TAU UML/SDL Suite : conclusions

• How to ensure independencybetween model and implementation

?• Timing specifications:

only with low level implementation mechanisms(Timers, SDL priorities… )

UML/SDL: mapping is under user responsibility… he has to clarify the mapping of

UML state machines SDL specifications

Use of shared passive objects in UML model SDL

Active object communication SDL signal exchange

Dtsi/SLA/





• Point on current tools for RT with

UMLTAU UML Suite,

ARTiSAN Studio Rhapsody, ROSE RT, Esterel Studio


Dtsi/SLA/


An explicit task model in a specific diagram

Actuatorcontrol

MotorActuator

Controlcalculation

Speedmetercontrol

Channel1

Speedmeter

PMH

Explicit modeling of concurrency features !!!

A logical model in usual class/object diagrams

Concurrency diagram

::Regulator

stopRegulating()

startRegulating()

::RegulatingLaw

calculate

*

pRegLaw

ARTiSAN Real-time Studio two orthogonal models, weak integration

Dtsi/SLA/


making schedulable objects & scheduling them using tasks

wrapping data and functions in object wrappers

A mapping stage assignment of objects to tasks

Actuatorcontrol

MotorActuator

Controlcalculation

Speedmetercontrol

Channel1

Speedmeter

PMH

::Commande

update

read

::RegulatingLaw

calculate

*

pRegLaw

regLaw:Commande

update()

read()

Actuatorcontrol

MotorActuator

Controlcalculation

Speedmetercontrol

Channel1

Speedmeter

PMH

encapsulating tasks & their communications behind interf.

Three techniques

ARTiSAN Real-time Studio

Dtsi/SLA/


Timing constraints must be translated on implement.

Communication between objects of different tasks must be implemented by the user with low level RT concepts

ARTiSAN Real-time Studio: conclusions

Relation between task and object model is weak

Task model has to be manually implemented

Concurrent diagram is out of the standard

A tool dedicated to high skill real-time developers with a lot of things to be done by hand and at the standard borders.

Dtsi/SLA/






UMLTAU UML Suite, ARTiSAN Studio,

Rhapsody, ROSE RT, Esterel Studio


Dtsi/SLA/


Identify system task Populate tasks with objects of analysis and design stages

Rhapsody (RT-UML) two «orthogonal» but «integrated» models

Explicit modelling of concurrency

Inter tasks communication = Synchro. + data exchange

Dtsi/SLA/


Rhapsody (RT-UML)

ActuatorControl« reactive »RegContr

ol

SensorControl

pRC 1

pAC

1

RegulatingLawpAC

1

RegControlTask

RegControl

ActControlTask

ActuatorControl


On

stopRegulating()

/ updateScreen(OFF);




On

stopRegulating()

/ updateScreen(OFF);



Behavior specified by state machine of reactive obj.

Reactive objects are assigned to active objects…

Communication by message between reactive obj.

SensorControl

Dtsi/SLA/


Explicit tasking model (described & maintained by hand)

Communication issues Triggered operation : concept between event & operation Only return value of operation call can be defined …

… but under responsibility of the caller ! (cf. conc. conflict) Complex semantic diff. between signals & operation calls

Low level of Real Time specifications Priorities can be assigned to active objects Timing constraints must be implemented by hand

A tool dedicated to high skill real-time developers with animation opportunities but not really “real-time”.

Rhapsody (RT-UML) : conclusions

Dtsi/SLA/





• Point on current tools for RT

with UMLTAU UML Suite, ARTiSAN Studio, Rhapsody

ROSE RT, Esterel Studio


Dtsi/SLA/


Rose Real-Time (UML-RT) attempt to integrate task and object paradigms«capsule» stereotype identifies active objects

They will be assigned to task at implementation stage

mapping with task & priorities must be managed by hand They have state automaton but low level timing specification

Defines the set and protocol of the exchanged messages

Communication is performed through « ports » Sending of signal via port of communication

« capsule » anEmitter : Emitter

State 1

State 2

portA.send (s1) ; Signal sending

Communication port

« protocol » infoProto

incoming S1

Protocol

portA : infoProto

portB : infoProto~ capsule link

« capsule » aReceiver : Receiver

Behaviour

Dtsi/SLA/


/ aSpM : Speedometer

+ / carSpeed : SpdAcq

/ aReg : Regulator

+ / carSpeed : SpdAcq~

Initiated

InitialInitial

t3t3

get

value (data)

Off Inter

Initial

t1

Trigger:Signal get on port carSpeedAction:carSpeed->value(data).reply();

Action:RTMessage retMsg;mcarSpeed.get().invoke(&retMsg);int newCarSpeed= *(const int *) retMsg.getData();

t1

A synchronous communication with return value

blocked until reply receipt release by reply receipt

Synchronous call with reply

Rose Real-Time (UML-RT)

Not to forget « reply » action on server side !

Dtsi/SLA/


Rose Real-Time (UML-RT): conclusions A high level concept for concurrency with an

implicit logical execution model Capsule

"Unusual" OO paradigm

The concept of “Capsule” is certainly very powerfull but a little bit “exotic” regarding usual OO paradigm (eg. For communication). About RT constraint spec., it is equal to other, i.e. only timing event, because the concept of priority reveals to be not useable!

Capsule paradigmEntities communicating via signal exchange through ports.

vs.

Usual object paradigmEntities communicating via operation call.

Behavior spec. via limited UML state machine

Timing specification through low level mechanisms

… but close to an Interface with Protocol State Machine

Dtsi/SLA/






UMLTAU UML Suite, ARTiSAN Studio, Rhapsody, ROSE RT,

Esterel Studio


Dtsi/SLA/


Esterel Studio A "graphical form" equivalent to Esterel

• S_Capsule (“Synchronized_Capsule”) Inherited from ROOM’ Capsule Get ports typed by a “pluget” (~ ROOM Protocol)

• Concurrent components inside behavior

• SyncChartA "graphical form" equivalent to Esterel

languageSynchronous computation modelThe Zero-Delay hypothesisAbsence of event may be a triggerPossibility of events conjunction

Dtsi/SLA/


Esterel studio (SyncCharts)

Running

suspension

macro-state

simple state

initial pseudo-state

final stateweak abortion

strong abortion s / e

parallel component

suspend

normal terminaison

/ e

transition label

Dtsi/SLA/


Esterel studio (SyncCharts): conclusions

• Based on an abstract ideal view of real

systems “Synchronous assumption” Convenient for “hardware-intensive” systems

Difficult to insure in other case

• Behavior = SyncChart formalism Formal view possibility of formal verification

Out of UML standard (notation + semantics)

• Methodology aspect under-development

• The tool support only behavior aspect Prototype of coupling with Rose

Dtsi/SLA/







• Real Time modeling with

ACCORD/UML Protocol state machine RT Component Model MDE through UML profiles

Dtsi/SLA/


ACCORD/UML methodology

- Results of 10 years of OO researches for RT-Syst. of nuclear plant + PhD work with PSA (Peugeot) + AIT-WOODDES IST Eur. proj. + ACOTRIS a Nat. proj.

ProvidesModeling methodology:

continuous process, separation of functional spec. and implementation constraints or choices

Tools supporting the process and the method

Model transform., code gen. for rapid prototyping

Model analysis, test generation

Dtsi/SLA/


Protocol state machine in UML

Protocol transitions have the following info.:a pre condition (guard)one or several triggering eventa post condition. Everyzero or one operation that belongs to the

context classifier of the protocol state machine.

It can be associated to Interfaces and Ports

expresses legal transit. a classifier can trigger

defines a lifecycle for objects or an invocation order of its operations

Dtsi/SLA/


unObjet

operation()

« signal »Signal()

E1 E2

‘Evt’ ‘[’ garde ‘]’ / ‘liste-Actions’

CallEventCallEventSignalEvent

ChangeEventTimeEvent

operation()

Signal()

Maintainability Reusability

C

Off On

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

RegulatorLogicLogic AlgorithmicAlgorithmic&

Usual way to use the state machine …

… UML state machine notations

Dtsi/SLA/


• Separation on concerns to improve behaviour modelling

Protocol View"what it can do"

Reactive View"what it must do"

Object behaviour

Algorithmic aspect

Logic aspect

AIT-WOODDES / ACCORD proposal : a more structured way !

Control logic & Algorithms aspects

Dtsi/SLA/


Arret Marche

C

Arret Marche

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

LogicLogic AlgorithmicAlgorithmic&

« describe protocol view »

tgSpeed : int

initReg()stopReg()

Regulator

Off On

initReg()

stopReg()

maintainSp()

Class behavior=

Control logic (protocol use)

Protocol-transition

call-event ‘(’params‘)’ ‘[’ guard ‘]’

Method behavior=

Algorithmic parts

carSpeed = cptVit->getSpeed()

delta=k1*atan(tgSpeed-cuSpeed)

mot->sendCmd(torqueVariation)

Maintainability

Reusability

Regulator

+tgSpeed : integer

+initReg()+stopReg()+maintainSp()

Regulator interface

Dtsi/SLA/


/ maintainSp()

RegOnOff / stopReg()

RegOnOff / initReg()

On Off

[carSpeed<50] / stopReg()

Triggering view (ACCORD/UML)

• ChangeEvent• CompletionEvent

• SignalEvent• TimeEvent

Set of consistent rules betweenprotocol and triggering views

Class interface

Regulator

+tgSpeed : integer

+initReg()+stopReg()+maintainSp()

« Signal »RegOnOff()

‘evt-name ’ ‘(’param-list‘)’ ‘[’ guard ‘]’ / <ope-name> ‘(’params‘)’

Triggering-transition

« describe reactive view »

Dtsi/SLA/


S1 S2

‘call-event-name’ ‘(’param-list‘)’ ‘[’ guard ‘]’

S2S1

‘event-name’ ‘(’param-list‘)’ ‘[’ guard ‘]’

/ called-operation-name ‘(’param-list‘)’

Trigger view (ACCORD/UML)=

“What the instances of this class have to do”

Class

m1() S1

S2

m1()

Class structure

Class behavior

=control logic

Protocol view (UML ~standard)=

“What instances of this class may do”

Method view(~UML standard)

=How

processingis performed

Summary on ACCORD behavior model

act1

act2

Dtsi/SLA/








ACCORD/UML Protocol state machine

RT Component Model MDE through UML profiles

Dtsi/SLA/


Decomposition heuristics

& component model

Initial Model

Initial Model

ACCORD/UML

(PAM ou DAM)

ACCORD/UML

(PAM ou DAM)

Sub-system Model

Sub-Syst_1 Sub-Syst_2

Sub-Syst_3

«refine»

ER1C_Sub-Syst_1

C_Sub-Syst_2

C_Sub-Syst_3

Component Model

«parts»

ER2

ER1 = Heuristics to ease decomposition of a system into a sub-systems model

ER1 = Heuristics to ease decomposition of a system into a sub-systems modelER2 = Model mappings to transform resulting sub-systems model into component model

- required & offered interface- component connexions / association links- …

ER2 = Model mappings to transform resulting sub-systems model into component model

- required & offered interface- component connexions / association links- …

Component definition 2 possible views:

-“Black box” (= external view) set of interfaces

-“White box” (= internal view) sub-system

Dtsi/SLA/


Component

• Component Model based on

UML2 component Model + RT_QoS

ACCORD/UML RT-Component Model

Interface

provided

required

RT_QoS

Interface can have both BehavioralFeatures:

• operations also with QoS specif.• receptions (signals) with QoS specif.

Dtsi/SLA/


ACCORD/UML RT-Component Model

based on a MDA approach…

ER3 = Mappings from the RT-Comp. Mod. of ACCORD/UML towards a platform model (e.g., RT-CCM model) PIM-to-PSM

RT_QoS

RT_QoS

RT_QoS

C_Sub-Syst_1

C_Sub-Syst_2

C_Sub-Syst_3

Component Model

ER2

RT_QoS

RT_QoSSub-system Model

Sub-Syst_1 Sub-Syst_2

Sub-Syst_3

RT_QoS

RT_QoS

ER2 = These mappings take into account specified RT features of the sub-system model PIM-to-PIMER2 = These mappings take into account specified RT features of the sub-system model PIM-to-PIM

CCM

ER

3

Dtsi/SLA/








ACCORD/UML Protocol state machine RT Component Model

MDE through UML profiles

Dtsi/SLA/


MDA Challenges

Methods to define well-structured models Business oriented (versus software techn oriented) Activity oriented: req/spec/design/impl/proof/test/simul, etc.

Techniques to exploit development expertise Profile, script, meta-modeling, aspect progr., etc.

Expertise implementation (RT, emb., safety, valid., etc.)

Implementation platform models (CCM, RT-OS, etc.)

Tooling & standards (interf., coop., interact., exch., etc.)

What MDA means: modelling with UML to develop a system with

• a clear separation of implementation technology• following a continuous modelling process• using intensively model synthesis

What we need :

Dtsi/SLA/


ACCORD/UML methodoology:Models everywhere…

Prototype Model

Train Con

trol

Circuit

STRUCTUR

E

INTERACTIO

NS

COMPORTEMENTS Application Code

Code Mappings Compiling & Link Mappings

Executable Application

Design Mappings

Analysis Model

Train Con

trol

Circuit

STRUCTUR

E

INTERACTIO

NS

COMPORTEMENTS

1 2 3

App

licat

ion

synt

hesi

s

Test Model

INTERACTIONS Formal Language

of AGATHA

SET2UML Mapping UML2AGATHA Mappings

Analysis model

Train Con

trol

Circuit

STRUCTUR

E

INTERACTIO

NS

COMPORTEMENTS

Symbolic Execution Tree

Test S

ynthesis

Dtsi/SLA/


user

!+

Structure of ACCORD Methodology

ACCORD/UMLMethodology

relizes

Modelling tools

defined by

ACCORD/UML Profile

OMG’ Standard profiles !!!

SPE profileSPT profile AL profile

Dtsi/SLA/


ACCORD/UML profile

for Embedded Systems ► Real-time QoS model

• The domain viewpoint- Model overview- Model details

• The UML viewpoint- Stereotypes and tagged values definition- Tagged Value Types

► Communication model ► Behaviour model ► Concurrency model

Real-Time QoS Model

Communication ModelBehavior Model

Concurrency Model

Dtsi/SLA/


Real-time features model

domain viewpoint overview

• Definifion of a Real-Time QoS

TimingRTF ReadyTime

Deadline

SPTprofile::Core Ressource Model

QoScharacteristic

PriorityRTF

Priority

Period

RTFgeneric concept of RT QoS

Priority-based RT QoS

Timing-based RT QoS

Dtsi/SLA/


Real-time features model

domain viewpoint details

• PriorityRTF

AttributesOperations

- create ( ref in RTtimeValue, pr in Priority, pe in Period=-1, peNb=-1 in integer ) : It create an instance of priority-based RTF according to values passed as parameters. “pr” is the priority, “pe” is the period and “peNb” is the number of period of the new instance.

Associations- itsPr:Priority (1-1): It denotes the priority feature of the current

priority RTF.- itsPe:Period (0-1): It denotes the period feature of the current priority RTF if

necessary.

PriorityRTF

RTF

Priority

Period+create(In pr:Priority ,In pe:Period ,In peNb:integer)

itsPr1

itsPe0..1

Dtsi/SLA/


► RT_QoStype “(“ <timingQoS> | <priorityQoS> ”)

<timingQoS> ::= “(“ <RefDate> “, “ <Deadline> “, “ <ReadyTime> “,“ <Period> “, “ <NoPeriod> ”)” <priorityQoS> ::= “(“ <Priority> “, “ <Period> “, “ <NoPeriod> ”)”

<RefDate> ::= “(RefDate, “ <value> “, “ <timeUnitStr> ”)”<Deadline> ::= “(Deadline, “ <value> “, “ <timeUnitStr> ”)”<Priority> ::= “(Priority, “ <value> ”)”<ReadyTime> ::= “(ReadyTime, “ <value> “, “ <timeUnitStr> ”)”<Period> ::= “(Period, “ <value> “, “ <timeUnitStr> ”)”<NoPeriod> ::= “(NoPeriod, “ <value> “, “ <timeUnitStr> ”)”<value> ::= <Integer> | <Real><timeUnitStr> ::= “ ’ns’ ” | “ ’us’ ” | “ ’ms’ ” | “ ’s’ ” | “ ’hr’ ” | “ ’days’ ” | “ ’wks’ ” | “

’mos’ ” | “ ’yrs’

• RTF

Real-time features model – UML viewpoint

Stereotype

BaseClass

Parent Tags

«RTF» Action RTF_value Transition

Message Tag

NameTag Type Multiplicit

yRTF_value RT_QoStyp

e[0..1]

From SPT Profile

Dtsi/SLA/


Conclusions

• Industrial tools support model based development Modelling is not new ! Moderation around the new key-word MDA

… but MDA not supported, they are too limited on: Model analysis, Model transformation and mappings Platform independent model writing

• UML 2: better for RT, but not a RT formalism! Should better support profile definition and, thus, MDA

Strong lacks on the model exploitation language No graphical formalism at this time

No standard and very "tool dependent"

dtsi/sla/ 1 mda for embedded system development, brest, france, september 16, 2002 uml and real time...

Documents

uml profiles

real time uml profile

uml tau uml suite

uml point

parts uml

ocl uml

uml specifications

embedded system development