Titre aliquando tempo tatum commentum - IRISA

Sébastien Gérard

([email protected])

CEA Tech / LIST, France

Bran Selić

([email protected])

Note: this presentation is based on a full day tutorial presentation on MARTE prepared in collaboration with Bran Selic.

Ecole Temps-Réel 2015 Rennes, August 24th To 28th 2015

TUTORIAL OVERVIEW

| PAGE 2

• WHAT, WHY, AND HOW

• A SIMPLE EXAMPLE

• FOUNDATIONS

• APPLICATION MODELING

• PLATFORM MODELING

• ALLOCATION

• MODEL ANALYSIS

• SUMMARY

ETR’2015, MARTE outlines through examples, S. Gérard / Copyright CEA LIST & Malina Software

# 3

A domain-specific computer language for design and analysis real-time and embedded (RTE) software applications

Modeling and Analysis of Real-Time and Embedded systems

Realized as an industry-standard profile of the UML 2 modeling language

Integral part of the Object Management Group’s (OMG) Model-Driven Architecture™ (MDA) initiative

WHAT IS MARTE?


# 4

Modern RTE systems are increasing in complexity while demands for greater dependability, better quality and higher productivity are also on the increase!

Traditional methods are no longer adequate

From craft to a systematic engineering discipline through Model-Based Engineering (MBE)

WHY: THE RATIONALE

CRAFT ENGINEERING


# 5

An approach to system and software development in which computer-based models play an indispensable role

Based on two time-proven ideas:

HOW (1): MODEL-BASED ENGINEERING (MBE)

switch (state) {

case‘1:action1;

newState(‘2’);

break;

case‘2:action2;

newState(‘3’);

break;

case’3:action3;

newState(‘1’);

break;}

(2) AUTOMATION

S1

S3

S2

e1/action1

e2/action2

e3/action3

switch (state) {

case‘1:action1;

newState(‘2’);

break;

case‘2:action2;

newState(‘3’);

break;

case’3:action3;

newState(‘1’);

break;}

(1) ABSTRACTION

S1

S3

S2

e1/action1

e2/action2

e3/action3


# 6

Potential to significantly reduce cost and risk, because standards:

Facilitate communication between stakeholders by providing a shared conceptual and syntactical framework

Facilitate tool interoperability through shared semantics and shared interchange formats

Facilitate development of complementary tools based on a shared standard

Typically support and codify industry-wide best practices

Facilitate availability of trained experts and of teaching materials

Enable vendor independence (no vendor “lock-in”)

Standards also encourage vendors to compete and add value to their products

HOW (2): USE OF INDUSTRY STANDARDS


# 7

Support for the industrial exploitation of MBE

An Object Management Group (OMG) initiative

Manifested as a set of complementary industry standards and associated guidelines

UML, SysML, QVT, MOF, BPMN,...

SIDEBAR: MODEL-DRIVEN ARCHITECTURE™ (MDA) STANDARDS


# 8

WARNING: THE MARTE SPECIFICATION

The MARTE specification is 750+ pages long Not for the faint-hearted (excellent cure for insomnia)

Product of contributions by a number (~10) of diverse (international) technical teams Some overlap and a few inconsistencies between parts


# 9

FORTUNATELY, HELP IS ON HAND (SHAMELESS PLUG ;-)

Available in a web page/bookstore near you:

Publisher: Morgan Kaufmann ISBN: 978-0-12-416619-6


# 10

1. SUPPORT FOR CONCISE AND SEMANTICALLY MEANINGFUL MODELING OF RTE/CPS SYSTEMS:

A domain-specific modeling language for modeling real-time, embedded, and cyber-physical systems

Support for precise specifications of quality of service (QoS) characteristics (e.g., delays, memory capacities, CPU speeds, energy consumption)

Can be used directly in conjunction with SysML for greater CPS support

2. SUPPORT FOR FORMAL ENGINEERING ANALYSES:

A generic framework for certain types of (automatable) quantitative analyses of UML models

Suited (needed) to computer-based automation

WHAT MARTE ADDS TO UML

TUTORIAL OVERVIEW

| PAGE 11



• FOUNDATIONS



• ALLOCATION

• MODEL ANALYSIS

• SUMMARY


# 12

SAMPLE REAL-TIME APPLICATION – THE UML MODEL

ClockApp

«signal» tick()

Ticker 0..1

0..*

Display

display(v:String)

0..*

1

sd

loop

:Ticker :ClockApp :Display

@t2

tick()

display(v)

@t1

{(@t2 - @t1) <= 100}


# 13

SUPPLEMENTARY INFORMATION NEEDED

ClockApp

«signal» tick()

Ticker 0..1

0..*

Display

display(v:String)

0..*

1

sd

loop


@t2

tick()

display(v)

@t1

OS timer utility Hardware

HW interrupt (frequency?)

Execution time?

Scheduling delay?

How many?

{(@t2 - @t1) <= 100} Which units?


# 14

STEP 1: APPLYING THE MARTE PROFILE

This gives us access to the MARTE concepts (stereotypes)

ClockApp

«signal» tick()

Ticker 0..1

0..*

Display

display(v:String)

0..*

1

sd

loop


@t2

tick()

display(v)

@t1

(@t2 - @t1) <= 100

ClockAppModel

«profile»

MARTE

NB: MARTE is used in conjunction with standard UML – as a complement


# 15

STEP 2: ANNOTATING THE UML MODEL USING MARTE (1)

ClockApp Ticker

0..1

0..*

Display

display(v:String)

0..*

1

«timerResource»

{isPeriodic=true,

duration=(100, us)}

«swSchedulableResource»

{isStaticSchedulingFeature=true,

isPreemptable=false}

«signal» tick()

«resourceUsage»

{execTime = ((47*CPUrating), us)}

«hwDevice»

{description=“DSP1455A”}

«resourceUsage»

{execTime = (1.5, us)}

NB: variable


# 16

SIDEBAR: “UN-APPLYING” A UML PROFILE

The annotations of a profile do not affect the underlying model ...and can be removed or hidden when not needed

ClockApp Ticker

0..1

0..*

Display

display(v:String)

0..*

1 «signal» tick()


# 17

STEP 2: ANNOTATING THE UML MODEL USING MARTE (2)

sd

loop


@t2

tick()

display(v)

@t1

«timedProcessing»

{duration=(5, us)}

«timedConstraint»

{kind=required,

Interpretation=duration,

((t2-t1) <= (100, us))}


# 18

HOWEVER...

We still do not have enough information to make meaningful predictions (e.g., about timeliness) i.e., will the application meet all of its deadlines?

What is missing? Computer application = software + hardware

Platform’s physical characteristics (e.g.: CPU speed)

Impact of other applications sharing the same platform

Modeling just the application is generally insufficient to predict its QoS characteristics


# 19

STEP 3.1: MODELING THE PLATFORM (GENERIC = “A PTF TYPE”)

«swSchedulable Resource»

OSTimer

«hwProcessor»

Processor {speedFactor=$CPUrating}

GenericPlatformModel

0..*

1


OSThread

1

0..*

«scheduler»

ThreadScheduler {schedPolicy=EarliestDeadlineFirst,

processingUnits=Processor, schedulableResources=OsThread}

1..*

1


# 20

SpecificPlatformModel

STEP 3.2: MODELING A SPECIFIC SYSTEM

Deals with instances (vs. classes)

«hwProcessor»

:Processor


:OSThread[0]


:OSThread[1]


:OSTimer

«scheduler»

:ThreadScheduler

Generic Platform

Model


# 21

STEP 4: SPECIFYING DEPLOYMENT (ALLOCATION)

Binding of software elements to platform elements

SystemModel


:OSThread[0]


:OSTimer


:OSThread[1]


:OtherApp


:Ticker


:ClockApp

«allocate» «allocate» «allocate»

«import»

Specific App

Model

«import»

Specific Platform

Model


# 22

SUMMARY: THE THREE BASIC ELEMENTS OF MARTE MODELING

APPLICATION (ARCHITECTURE) MODEL

PLATFORM MODEL

ALLOCATION (DEPLOYMENT)

TUTORIAL OVERVIEW

| PAGE 23



• FOUNDATIONS



• ALLOCATION

• MODEL ANALYSIS

• SUMMARY


# 24

A CONCEPTUAL VIEW OF MARTE (MODULES/FOCUS AREAS)

2: Platform Modeling

4: Model-based Analysis

3: QoS-aware Modeling

1: Architecture Modeling

GCM architecture modeling based on

components interacting by either messages or

data.

NFP declaring, qualifying, and applying

semantically well-formed non-functional

concerns.

HLAM modeling high-level RT QoS,

including qualitative and quantitative concerns.

Time defining time and manipulating its

representations.

VSL Value Specification Language is a

textual language for specifying algebraic

expressions.

GRM common platform resources at

system-level and for specifying their usage.

SRM multitask-based design

HRM hardware platform

Alloc allocation of functionalities to

resources

GQAM annotating models subject to

quantitative analysis.

SAM annotating models subject of

scheduling analysis.

PAM annotating models subject of

performance analysis.


# 25

MARTE

Foundations

Real-Time Domain Modeling Support

«import»

Real-Time Domain Analysis Support

«import»

Annexes

Shared abstractions and concepts

Support for QoS analyses

For precise modeling of RT phenomena

Highly modular to allow selective application of MARTE

A STRUCTURAL VIEW OF THE MARTE PROFILE


# 26

MARTE FOUNDATIONS

Shared abstractions and concepts Includes an abstract model of dynamic semantics (necessary for scenario modeling)

Foundations

Non-Functional Properties Specification

(NFP)

Time Modeling Support

Abstract Resources Modeling (GRM)

Allocation Specification


# 27

CORE CONCEPT: RESOURCE

Resource: A source of supply of money, materials, staff and other assets that can be drawn upon…in order to function effectively [Oxford dictionary]

In MARTE, a platform is viewed as a collection of different types of resources, which can be drawn upon by applications The finite nature of resources reflects the physical nature of the underlying hardware platform(s)

Platform Resource 1..*

Computing Resource

Memory Resource

etc.


# 28

CORE CONCEPT: RESOURCE SERVICES

In MARTE resources are viewed as service providers Consequently, applications are viewed as service clients

Resource Resource Service

1..*

Resource services are characterized by their

Functionality

Quality of Service (QoS)

e.g. (platform services): • memory provisioning • processing power • bandwidth • energy • mutual exclusion


# 29

CORE CONCEPT: QUALITY OF SERVICE (QoS)

Quality of Service def.: A measure of the effectiveness of service provisioning

Two complementary perspectives on QoS Required QoS: the demand side (what applications require)

Offered QoS: the supply side (what platforms provide)

Many (most of) engineering analyses consist of calculating whether (QoS) supply can meet (QoS) demand.


# 30

EXAMPLE OF RESOURCE MODELING

«storageResource» {elementSize = 1024x1024x8, resMult = 256}

«computingResource» {speedFactor = 0.6}

Controller

«deviceResource» {speedFactor = 1.0}

RobotArm

«computingResource» {speedFactor = 1.0}

NT_Station

«communicationsMedia» {speedFactor = 8.5}

«communicationsMedia» {speedFactor = 1.0}

VME_Bus

CAN_Bus


# 31

MARTE FOUNDATIONS

Foundations


(NFP)





# 32 THE SEMANTICS OF VALUES

transmMode = Half-Duplex

speedFactor = 0.8

Capacity = 4

packetT = 64

myCan: CAN_Bus

• The system requires a CAN bus with a capacity of 4 kHZ max

???

• What do these numbers represent? (i.e., semantics)

• Which measurement units are used?

• How were they obtained (measured? estimated? computed?)

Providing necessary semantic information for values appearing in models is key to successful model-based automated analyses


# 33

SPECIFYING QoS VALUES WITH MARTE

QoS may be specified either quantitatively or qualitatively

Examples: Quantitative QoS values:

3 MB of memory

4.5 MIPS of processing power

10 MB/s throughput

5 ms response time

Qualitative QoS values: LIFO

Shortest Deadline First

PriorityInheritanceProtocol


# 34

QUANTITATIVE QoS VALUES IN MARTE

Expressed as an amount of some physical measure Need a means for specifying physical quantities Value: quantity

Dimension: kind of quantity (e.g., time, length, speed)

Unit: measurement unit (e.g., second, meter, km/h)

However, additional optional qualifiers can also be attached to these values: source: estimated/calculated/required/measured

precision

direction: increasing/decreasing (for QoS comparison)

statQ: maximum/minimum/mean/percentile/distributio


# 35

MARTE LIBRARY: PREDEFINED TYPES


# 36

MARTE LIBRARY: MEASUREMENT UNITS


# 37

MARTE FOUNDATIONS

Foundations


(NFP)





# 38

TOPICS COVERED BY THE MARTE TIME MODEL

Using Time

• timed elements

• timed events

• timed actions

• timed constraints

Structure of Time

• time bases

• multiple time bases

• instants

• instants relationships

TB1

TB2

Access to Time

• clocks

• logical clocks

• chronometric clocks

• current time


# 39

FOCUS ON TIMED ELEMENTS

Serves to associate time with many different concepts in a model

TimedElement

ModelElement

Clock

nature : {discrete, dense}

resolution : Real =1.0

currentTime : Real

maximalValue : Real [0..1]

on 1..*

TimedEventOccurrence

EventOccurrence

InstantValue

at 1..*


# 40

EXAMPLE MARTE ANNOTATIONS

:Controller :Sensor

start()

acquire()

ack()

sendData(data)

@t2 @t0

@t1

@t3

Sd DataAcquisition Sd DataAcquisition

:Controller :Sensor

acquire() { d1<=(1, ms) }

sendData (data) { [(0, ms)..(10, ms)] }

ack()

@t2

{ [d1..30*d1] }

&d1

constraint1= { (t0[i+1] - t0[i]) > (100, ms) }

constraint2= { (t3 when data<5.0) < t2+(30, ms) }

Extended

duration

intervals with

bound « [ ] »

specification

Instant Interval

Constraint

Constraint in an

observation with condition

expression

Duration expression

between two sucessive

occurrences

start() { jitter(t0)<(5, us) }

@t0

{ ]t1..t1+(8, ms)] }

Jitter constraint

@t3

@t1

TUTORIAL OVERVIEW

| PAGE 41



• FOUNDATIONS



• ALLOCATION

• MODEL ANALYSIS

• SUMMARY


# 42 THIS SECTION


PLATFORM MODEL



# 43

DOMAIN MODELING

MARTE

Foundations


«import»


«import»

Annexes


# 44

DETAILED APPLICATION AND RESOURCE MODELING

Modeling

Abstract Component Model (GCM)

Application Modeling Support (HLAM)

Software Resources Modeling (SRM)

Hardware Resource Modeling (HRM)

Detailed refinements of GRM’s concepts for software platform resources based on

existing RTOS, with specialized notations.

Detailed refinements of GRM’s concepts for hardware platform

resources commonly used in RTE systems.

Precised semantics of

UML composite structures

for enabling Component-based MDE.

Further refinements of the GRM concurrency-related

concepts from the applications standpoint.


# 45

MARTE’s GCM rationale

Need to unify component models for CPS (e.g., AADL, Autosar, EAST-ADL2, Lightweight-CCM, and IP-XACT).

Lack of concepts for CPS:

► Needs for precise semantics (specially between behavior and structure)

► Needs for open semantics enabling various Models of Comm & Comp.

► Needs for data-flow communication at component-level

THE GENERIC COMPONENT MODEL OF MARTE

« metaclass »

UML2::Ports::Port

« stereotype»

ClientServerPort

« stereotype»

FlowPort

Support for data-based communication schema between components.

Support for “classic” OO message-based

communication schema.


# 46

Atomic flow ports

Non-atomic flow ports typed by flow specification!

SOME EXAMPLES OF FLOW PORTS

CarSpeedRegulator

rgm:Regulator [1]spm:Speedometer [1] rgm:Regulator [1]« flowPort »

inSpeed: Integer [1]

spm:Speedometer [1]

« flowPort »

outSpeed: Integer [1]

Flow port conveying output integer data values

Flow port conveying input integer data values

cSpeed : SpeedDT

cTime : Time

« interface »

« flowSpecification »

SpeedSensorFS

Out flow property

In flow property

Speedometer « flowPort »outSpeed : SpeedSensorFS

Non-atomic inout flow port


# 47

SEMANTICS VIEW OF MARTE FLOW PORTS: PUSH SEMANTICS

CarSpeedRegulator

spm:Speedometer [1]

« flowPort »

outSpeed: Integer [1]

« flowPort »


rgm:Regulator [1]

In behavior flow port conveying integer values

MARTE modeling rule: A model owning in or inout behavior flow ports

with delegation connectors is considered to be ill-formed.

Reception Semantics Consumption Semantics

When a data is received on

the port, a DataEvent is

raised and stored in the

event pool of the receiving

instance.

Standard UML semantics

for Event apply also to

MARTE’s DataEvent.


# 48

SEMANTICS OF MARTE FLOW PORTS: PUSH SEMANTICS (CONT.)

- compute (in p1: Integer [1])

Regulator

inSpeed : Integer

DataDrivenFilterClassifierBehavior

computeInteger

from inSpeed

Activity denoting the classifier behavior of Regulator

AcceptEventAction with a trigger based on a « DataEvent ».

In behavior flow port conveying integer values

« stereotype »

DataEvent

« metaclass »

AnyReceiveEvent

« metaclass »

Classifier

classifier

[1]


# 49

SEMANTICS OF MARTE FLOW PORTS: PUSH SEMANTICS (CONT.)

- filter (input :Integer[1]) : Integer [1]

DataDrivenFilter

inData: Integer outData: Integer

DataDrivenFilterBehavior

input output

{streaming} {streaming}

filter

Reception Semantics Consumption Semantics

Data received on such port is made available as a data token on the activity parameter via the delegation connector.

The semantics of token consumption is those of UML 2 activities.

Note: if streaming parameter activity execution can accept & produce data in a pipeline manner.

IN non-behavior flow port with a delegation connector to an input parameter of the classifier behavior.


# 50

Pull semantics rely on a specific modeling pattern defined in:

Bock, C., "UML 2 Activity and Action Models Part 4: Object Nodes", in Journal of Object Technology, vol.3, no.1, pp.27-41.

PULL SEMANTICS OF MARTE FLOW PORTS

CarSpeedRegulator

spm:Speedometer [1]

« flowPort »


rgm:Regulator [1]

currentSpeed: Integer [1]

Data arriving on the IN flow port via the delegation connector are stored in a

property (by default, overload policy).

IN flow port conveying integer data values


# 51

Possible other standard storing policies defined using the stereotype: «DataPool»

PULL SEMANTICS OF MARTE FLOW PORTS (CONT.)

CarSpeedRegulator

spm:Speedometer [1]

« flowPort »


rgm: Regulator [1]

« dataPool »

{ordering = FIFO}

currentSpeed: Integer [*]

Multiplicity of the property specifies the size of the pool:

e.g., an infinite FIFO.

Two standard policies defined via the property ordering: FIFO and LIFO


# 52

CPS APPLICATION MODELING

Modeling






# 53

Provides high-level concepts for modeling qualitative real-time features on classes / structured classes / components

Real-Time Unit (RTUnit)

► Generalization of the Active Objects of the UML 2

► Owns at least one schedulable resource

► Resources are managed either statically (pool) or dynamically

► May have operational mode description (similar to AADL modes)

Protected Passive Unit (PPUnit)

► Generalization of the Passive Objects of the UML2

► Requires schedulable resources to be executed

► Supports different concurrency policies (e.g. sequential, guarded)

► Policies are specified either locally or globally

► Execution is either immediateRemote or deferred

RTE MODEL OF COMPUTATION AND COMMUNICATION


# 54

Provides high-level concepts for modeling quantitative real-time features on classes / structured classes / components

Real-Time Behavior (RtBehavior)

► Message Queue size and policy bound to a provided behavior

Real-Time Feature (RTF)

► Relative/absolute/bound deadlines, ready time and miss ratio

► Apply to UML Action, Message, Signal, BehavioralFeature

Real-Time Connector (RteConnector)

► Throughput, transmission mode and max blocking/packet Tx time

► Apply to UML Connector

RTE MODEL OF COMPUTATION AND COMMUNICATION (CONT.)


# 55

EXAMPLE OF «RTUNIT» AND «PPUNIT»

CruiseControlSystem

getSpeed(): Speed

« ppUnit »

{concPolicy=guarded}

Speedometer

«rtService» {exeKind=deferred} start()

«rtService» {exeKind=deferred} stop()

tgSpeed: Speed

« rtUnit »

CruiseControler

1

spm

« dataType »

Speed

startDetection()

stopDetection()

« rtUnit »

ObstacleDetector

1

spm

isDynamic = false

isMain = false

poolSize = 10

poolPolicy = create

isMain = true

main = start

TUTORIAL OVERVIEW

| PAGE 56



• FOUNDATIONS



• ALLOCATION

• MODEL ANALYSIS

• SUMMARY


# 57 THIS SECTION


PLATFORM MODEL



# 58

Application

Platform

Platform def.:

“the full complement of software and/or hardware required for a given application program to execute”

PLATFORMS: WHERE SOFTWARE MEETS PHYSICS

The physical characteristics of the platform have a fundamental impact on the quality characteristics of software applications

Software Application [SW]

OS and/or Runtime Framework [SW]

runs on

Computing hardware [HW]

runs on


# 60

MARTE AS AN ENABLER OF PLATFORM-BASED DESIGN

Modeling






# 61

A FOUNDATION PATTERN FOR MODELING PLATFORMS

Resource

ResourceService

1..*

0..*

MARTE::GRM

MARTE::SRM

MARTE::HRM


# 62

A UML profile for modeling APIs of RT/E sw execution supports

Real Time Operating Systems (e.g., ARINC653-like OS)

Dedicated Language Libraries (e.g., ADA)

BUT it is NOT a new API standard dedicated to the RT/E domain!

SRM is the result of a very deep state of the art and of the practices in the domain of RTOS, including:

► e.g., POSIX, ARINC 653, SCEPTRE, Linux RT, …

WHAT IS THE SOFTWARE RESOURCE MODELING PROFILE (SRM) ?

SRM = a unified mean to model RTOS (or equivalent language constructs) APIs


# 63

WHAT IS SUPPORTED BY THE SRM PROFILE ?

SRM

SW_Concurrency

GRM

« import »

SW_BrokeringSW_Interaction

SW_ResourceCore« import » « import »

« import »

63

Interactions between concurrent contexts: Communication

► Shared data ► Message (~Message queue)

Synchronization ► Mutual Exclusion (~Semaphore) ► Notification Resource (~Event mechanism)

Concurrent execution contexts:

Schedulable Resource (~Task) Memory Partition (~Process) Interrupt Resource Alarm

Hardware and software resources brokering:

Drivers Memory management


# 64

SNAPSHOT OF THE UML EXTENSIONS PROVIDED BY SRM

64

SRM::SW_Brokering SRM::SW_Interaction

« MessageComResource » « NotificationResource »

« SharedDataResource » « SwMutualExclusionResource »

SRM::SW_Concurrency

X

« MemoryPartition »« SwSchedulableResource » « InterruptResource » « Alarm »

« EntryPoint »

« SwTimerResource »


# 65

Main characterisics

► A single processor operating system

► A static RTOS where all kernel objects are created at compile time

Main artifacts supporting concurrent computing

► Task - A task provides the framework for the execution of functions

► Interrupt - Mechanism for processing asynchronous events

► Alarm & Counter - Mechanisms for processing recurring events

Support for synchronizations of concurrent computing

► Event - Mechanism for concurrent processing synchronization

► Resource - Mechanism for mutual concurrent access exclusion

OVERVIEW OF THE OSEK/VDX-OS LAYER


# 66

Semantic An OSEK-VDX task provides the framework for computing application functions. A scheduler will organize the sequence of task executions.

Example of properties Priority: UINT32

► Priority execution of the task

StackSize: UINT32

► Stack size associated to the execution of the task Example of provided services ActivateTask (TaskID: TaskType)

► Switch the task, identified by the TaskID parameter, from suspended to ready state

ChainTask (TaskID: TaskType)

► Terminate of the calling task and activate the task identified by the TaskID parameter

FOCUS ON THE OSEK/VDX TASK DEFINITION


# 67

WHICH SRM CONCEPTS FOR OSEK TASK?

SRM

SW_Concurrency

GRM

« import »

SW_BrokeringSW_Interaction

SW_ResourceCore« import » « import »

« import »

67

Concurrent execution contexts:

Schedulable Resource (~Task) Memory Partition (~Process) Interrupt Resource Alarm


# 68

Semantic (from MARTE::SRM::Concurrency package)

Resource which executes, periodically or not, concurrently to other concurrent resources

SRM artifacts for modeling OSEK-VDX Task!

Main features

Owns an entry point referencing the application code to execute

May be restricted to execute in a given address space (i.e. a memory partition)

Owns properties: e.g., Priority, Deadline, Period and StackSize

Provides services: e.g., activate, resume and suspend

DETAILS OF «SWSCHEDULABLERESOURCE»


# 69

Step 1 - Define a UML model for OSEK_VDX::Task

Add model library applying the SRM profile

Add a class and defines its features (properties and operations)

Step 2 – Apply stereotype «SwSchedulableResource»

Step 3 – Set properly its tagged values

MODEL OF AN OSEK TASK WITH «SWSCHEDULABLERESOURCE»

(Step 1) (Step 2) (Step 3)


# 70

SRM EXAMPLE: APPLICATION MODELING

A reader and writer accessing a shared database resource using a mutex


w1 : Writer


w2 : Writer

«acquire» get ()

«release» rel ()

«swMutualExclusionResource»

dbSem : Mutex

{mechanism = Mutex,

waitingQueuePolicy = FIFO,

concurrentAccessProtocol = PCP,

ceiling = 4}

«sharedDataComResource»

db : DataBase


# 71

HRM: for describing structure of hardware ptf

Different abstraction levels. Two possible views:

HARDWARE PLATFORM-BASED MODELLING

« hwComponent »

smp : SMP

{grid = {4,3},

area = 5000mm²,

r_conditions = (Temperature; Operating; ‘’; [10°C,60°C])}

« hwComponent »

cpu1 : CPU

{position = {[1,1], [1,1]},

staticConsumption = 5W}

« hwComponent »

cpu3 : CPU

{position = {[2,2], [1,1]},


« hwComponent »

cpu4 : CPU

{position = {[2,2], [3,3]},


« hwComponent »

cpu2 : CPU

{position = {[1,1], [3,3]},


« hwComponent »

dma : DMA

{position = {[3,3],

[3,3]}}

« hwPowerSupply »

battery : Battery

{position = {[4,4], [3,3]},

capacity = 10Wh,

weight = 150g}

« hwComponent »

sdram : SDRAM

{position = {[3,4], [1,1]},

nbPins = 144}

« hwComponent »

fsb : FSB

{position = {[1,4], [2,2]}}

« hwLogical::hwResource »

smp : SMP

« hwProcessor »

cpu1 : CPU

{frequency = 800Mhz}

« hwCache »

l2 : UL2

{memorySize = 512kB}

« hwRAM »

sdram : SDRAM

{frequency = 266Mhz,

memorySize = 256MB}

« hwSupport »

battery : Battery

« hwDMA»

dma : DMA

{managedMemories = sdram}

« hwProcessor »

cpu2 : CPU


« hwCache »

l2 : UL2


« hwProcessor »

cpu3 : CPU


« hwCache »

l2 : UL2


« hwProcessor »

cpu4 : CPU


« hwCache »

l2 : UL2


« hwBus »

fsb : FSB

{frequency = 133Mhz,

wordWidth = 128bit}

Logical view (functionality) Physical view (layouts)

S. Taha, A. Radermacher, S. Gérard, and J.L. Dekeyser, “An Open Framework for Detailed Hardware Modeling”, in

proc. of SIES ’07, Lisbon, Portugal, 2007

S.Taha, A. Radermacher and S. Gérard. “An Entirely Model-Based Framework for Hardware Design and

Simulation Distributed, Parallel and Biologically Inspired Systems”, IFIP Advances in Information and

Communication Technology, Springer, 2010.

Usage examples of a HW platform models

• More precised model-based analysis, e.g. for WCET analysis.

• More precised model-based simulation


# 72

Hierarchical taxonomy of hardware concepts

Successive inheritance layers

From generic concepts (GRM-like)

► e.g., HwComputingResource, HwMemory and HwCommunicationResource

To specific and detailed resources

► e.g., HwProcessor, HwBranchPredictor, HwCache, HwMMU and HwBus

All HRM concepts are HwResource(s)

HRM STRUCTURE

« stereotype »

HwResource0..*

0..1

ownedResources

« stereotype »

HwResourceService

providedServices

1..*

requiredServices

0..*


# 73

Provides a functional description based on a functional classification of hardware resources:

HRM STRUCTURE -- LOGICAL MODELING

HRM::HwCommunication HRM::HwDevice HRM::HwTiming

HRM::HwStorage HRM::HwComputing


# 74

Enable modeling of physical properties of HW resources, via two viewpoints:

HwLayout

► Forms: Chip, Card, Channel…

► Dimensions, area and arrangement mechanism within rectilinear grids

► Environmental conditions: e.g. temperature, vibration, humidity…

HwPower

► Power consumption and heat dissipation

HRM STRUCTURE -- PHYSICAL MODELING

HRM::HwPower HRM::HwLayout


# 75

« profile »

HRM

« profile »

HwLogical

« profile »

HwPhysical

HwComputingHwStorage

HwCommunication

HwTiming

HwLayout

HwStorageManager

HwDevice

« profile »

MARTE::GRM

« import »

HwPower

HwGeneral HwGeneral

« modelLibrary »

MARTE::Library::BasicNFP_Types

« import »

HwMemory

HRM PROFILE OVERVIEW

75


# 76

« profile »

HRM

« profile »

HwLogical

« profile »

HwPhysical

HwComputingHwStorage

HwCommunication

HwTiming

HwLayout

HwStorageManager

HwDevice

« profile »

MARTE::GRM

« import »

HwPower

HwGeneral HwGeneral

« modelLibrary »

MARTE::Library::BasicNFP_Types

« import »

HRM PROFILE -- HWMEMORY

76

HwMemory


# 77

memorySize : NFP_DataSize

addressSize : NFP_DataSize

timings : Timing [*]

« stereotype »

HwMemory

« stereotype »

MARTE::GRM::Storage

« stereotype »

HwResource

level : NFP_Natural = 1

type : CacheType

structure : CacheStructure

repl_Policy : Repl_Policy

writePolicy : WritePolicy

« stereotype »

HwCache

organization : MemoryOrganization

isSynchronous : NFP_Boolean

isStatic :NFP_Boolean

isNonVolatile : NFP_Boolean



« stereotype »

HwRAM

Data

Instruction

Unified

Other

Undefined

« enumeration »

CacheType

notation : NFP_String

description : NFP_String

value : NFP_Duration

« dataType »

Timing

nbRows : NFP_Natural

nbColumns : NFP_Natural

nbBanks : NFP_Natural

wordSize : NFP_DataSize

« dataType »

MemoryOrganization

nbSets : NFP_Natural

blocSize : NFP_DataSize

associativity : NFP_Natural

« dataType »

CacheStructure

WriteBack

WriteThrough

Other

Undefined

« enumeration »

WritePolicy

LRU

NFU

FIFO

Random

Other

Undefined

« enumeration »

Repl_Policy

type : ROM_Type

organization : MemoryOrganization

« stereotype »

HwROM

MaskedROM

EPROM

OTP_EPROM

EEPROM

Flash

Other

Undefined

« enumeration »

ROM_Type

sectorSize : NFP_DataSize

« stereotype »

HwDrive

buffer

{subsets ownedHW}

0..1

HwMemory

HRM PROFILE -- HWMEMORY

77


# 78

HRM PROFILE -- HWMEMORY -- HWCACHE

Data

Instruction

Unified

Other

Undefined

« enumeration »

CacheType




« dataType »

CacheStructure

WriteBack

WriteThrough

Other

Undefined

« enumeration »

WritePolicy

LRU

NFU

FIFO

Random

Other

Undefined

« enumeration »

Repl_Policy


type : CacheType




« stereotype »

HwCache

HwCache is a processing memory where frequently used data can be stored for rapid access

Detailed description of the HwCache is necessary for performance analysis and simulation


# 79 HRM PROFILE -- HWMEMORY -- HWCACHE

79

Data

Instruction

Unified

Other

Undefined

« enumeration »

CacheType




« dataType »

CacheStructure

WriteBack

WriteThrough

Other

Undefined

« enumeration »

WritePolicy

LRU

NFU

FIFO

Random

Other

Undefined

« enumeration »

Repl_Policy


type : CacheType




« stereotype »

HwCache

Specifies the cache structure

HwCache is organized under sets of blocks and Associativity denotes the number of blocks within each set: • If associativity = 1, cache is direct mapped • If nbSets = 1, cache is fully associative.

OCL rule: memorySize = nbSets x blocSize x associativity


# 80 HRM PROFILE -- HWMEMORY -- HWCACHE

80

Data

Instruction

Unified

Other

Undefined

« enumeration »

CacheType




« dataType »

CacheStructure

WriteBack

WriteThrough

Other

Undefined

« enumeration »

WritePolicy

LRU

NFU

FIFO

Random

Other

Undefined

« enumeration »

Repl_Policy


type : CacheType




« stereotype »

HwCache

Specifies the cache write policy

• WriteBack: Cache write is not immediately reflected to the backing memory.

• WriteThrough: Writes are immediately mirrored.


# 81

«hwResource»

ProcessingNode

«hwProcessor»

: CPU

«hwBus»

: Bus

«hwDMA»

: DMA

«hwDrive»

: Disk[2] «hwRAM»

: RAM

{isSynchronous = true}

{mips = 5,

nbCores = 2}

{memorySize = (300, GB),

timing[1] = (, averageAxTime, (5, ms)),

timing[2] = (, maximumAxTime, (50, ms)}

{nbChannels = 2} {isSynchronous = true

isStatic = false}

EXAMPLE: MODELING HARDWARE WITH MARTE

A hardware platform with specified QoS values

TUTORIAL OVERVIEW

| PAGE 82



• FOUNDATIONS



• ALLOCATION

• MODEL ANALYSIS

• SUMMARY


# 83 THIS SECTION


PLATFORM MODEL



# 84

MARTE FOUNDATIONS

Foundations


(NFP)





# 85

Purpose

Provide support for denoting the "mapping/association” of the functional parts of a system (also called application) onto its resources (also called platform).

Similar to the SysML Allocation, but…

More restrictive

► Focus on application allocation on its underlying platform

2 natures of allocation:

► Spatial distribution - e.g., a variable allocated to a given memory resource.

► Temporal scheduling - e.g., a function computed/executed on a given processor resource.

Possibly associated with QoS constraints

OUTLINE OF THE ALLOCATION CONCEPT


# 86

OUTLINE OF THE ALLOCATION STEREOTYPE

«metaclass»

UML::Abstraction

«stereotype»

Allocate

kind : AllocationKind

nature : AllocationNature

«enumeration»

AllocationNature

spatialDistribution

timeScheduling

«stereotype»

NFP_Modeling::

NfpConstraint

impliedConstraint

*

«enumeration»

AllocationKind

structural

behavioral

hybrid


# 87

MARTE allocation rely on the distinction between:

Model elements of the application

Model elements of the platform

« allocated »

DEFINING THE ROLES OF MODEL ELEMENTS WITHIN ALLOCATION

/allocatedTo : Allocated [*]

/allocatedFrom : Allocated [*]

kind : AllocationEndKind

«stereotype»

Allocated

«metaclass»

NamedElement

undef

application

executionPlatform

both

« enumeration »

AllocationEndKind


# 88

On one hand an application Model

On the other hand a platform model

ALLOCATION EXAMPLE: ORIGINAL SITUATION

Application

cs: CarSpeed

reg : SpeedRegulatorSystem

sc: SpeedController

OperatingSystem

«schedulableResource»

th1: Thread«storageResource»

vm1: VirtualMemory


# 89 ALLOCATION EXAMPLE: STEP1 - IDENTIFICATION OF ALLOCATION ROLES

Application

«allocated»

{kind=application}

cs: CarSpeed


«allocated»

{kind=application}

sc: SpeedController

«allocated» {kind=executionPlatform}

«storageResource»

vm1: VirtualMemory

OperatingSystem

«allocated»

{kind=executionPlatform}


th1: Thread


# 90 ALLOCATION EXAMPLE: STEP 2 – DENOTE ALLOCATIONS

Application


«storageResource»

vm1: VirtualMemory

OperatingSystem

«allocated»



th1: Thread

«allocated»

{kind=application}

cs: CarSpeed


«allocated»

{kind=application}

sc: SpeedController

«allocate»

{nature=spatialDistribution}«allocate»

{nature=timeScheduling}


# 91

APPLICATION AND PLATFORM ROLES ARE RELATIVE CONCEPTS

Application

«allocated» {kind=both}«storageResource»

vm1: VirtualMemory

OperatingSystem

«allocated» {kind=both}


th1: Thread

«allocated»

{kind=application}

cs: CarSpeed


«allocated»

{kind=application}

sc: SpeedController

«allocate»

{nature=spatialDistribution}«allocate»



«storageResource»

mem1: Memory

HwPlatform

«allocated»


«computingResource»

cpu1: CPU

«allocate»

{nature=timeScheduling}«allocate»

{nature=spatialDistribution}


# 92

A dashed arrow is the right representation

The semantics should prevail on the representation

Semantics of the allocation,

An allocation is NOT always a dependency

An allocation is NOT always an abstraction

In MARTE Domain view: explicit distinction between allocation and abstraction/refinement.

Abstraction relates two concepts of different abstraction levels

Often allocation relates two concepts at the same level but of a different nature (application vs. execution platform)

MARTE::Alloc defines: « Assign »

PROBLEM WITH MARTE/SYSML ALLOCATION


# 93

ASSIGNEMENTS

Sébastien Gérard, MARTE Tutorial on HLAM

93

kind : AssignmentKind

nature : AssignmentNature

« stereotype »

Assign

« metaclass »

Comment

« metaclass »

Elementto

1..*

from

1..*

« stereotype»

NfpConstraint

impliedConstraint

*


# 94

MARTE ALTERNATIVE FOR ALLOCATION: ASSIGNEMENT

PlatformModel

ApplicationModel

«allocated»

{kind = executionPlatform}


CPU

«allocated» {kind = application}


Processor

« allocate »


AssignementsModel

ApplicationModel

«allocated» {kind = application}


Processor

PlatformModel

«allocated»

{kind= executionPlatform}


CPU

«assign»


+ Straightforward modeling concept. - Dependency between both application and platform models.

« allocate » « assign »

- Used of an unexpected UML model element, a Comment. + No dependencies between both application and platform models.

versus

TUTORIAL OVERVIEW

| PAGE 95



• FOUNDATIONS



• ALLOCATION

• MODEL ANALYSIS

• SUMMARY


# 96

DOMAIN MODELING

MARTE

Foundations


«import»


«import»

Annexes


# 97 IMPROVING MODEL EXPLOITATION: FROM MENTAL TO COMPUTER-AIDED ANALYSIS.

High-expertise

Unreliable

Not-scalable

Mental-based model analysis

expertise

reliability

scalability

Computer-aided model analysis


# 98

UML/MARTE MODEL

AUTOMATED MODEL-BASED ANALYSIS (CONT.)


PLATFORM MODEL


EQUIVALENT

ANALYSIS

MODEL

m M2M Xform

COMPUTER-BASED

ANALYSIS

0

5

10

15

20

0 0.2 0.4 0.6 0.8

Arrival rate

Qu

eu

e len

gth

MODELER


# 99

REAL-TIME DOMAIN ANALYSIS SUPPORT

Extensible to other analysis types in the future

Analysis

Abstract QoS Analysis Model (GQAM)

Schedulability Analysis Support (SAM)

Performance Analysis Support (PAM)

«import» «import»


# 100

Analysis

Context

Workload

Behavior

Resources

Platform

uses

evaluate

situation

evaluate

capacity

MARTE framework for

Generic Quantitative

Analysis Modelling

MARTE::GQAM

ANNOTATING DESIGN MODELS FOR QUANTITATIVE ANALYSIS

« profile »

SchedulabilityAnalysisModeling

analysis language construct

(UML profile)

« profile »

WorkloadBehavior

« profile »

ResourcesPlatform

UML user models

class Platform

sd Report

:Reporter :ServosData

get ()

start ()

Structural Models

Behavior Models

:SCADAServer

:RTUMaster

class Platform

sd Report

« allocation »

:Reporter«sharedResource»

:ServosData

« gaStep » get ()

{ execT= (8, ms)}

« gaStep » start ()

{ execT= (5, ms)}

Structural Models

Behavior Models

« execHost »

{speedFactor= 0.8,

utilization= $v1}

:SCADAServer

:RTUMaster

• Stimuli models

• Execution times

• Transmission delays

• RT constraints

• RTOS capacity

• RTOS overheads

• Scheduling schemes

• Resources access

Profile definition

(Language def. level)

Profile application

(User model level)

TUTORIAL OVERVIEW

| PAGE 101



• FOUNDATIONS



• ALLOCATION

• MODEL ANALYSIS

• SUMMARY


# 102

SUMMARY: THE MARTE PROFILE

The MARTE profile adds an important new capability to UML and UML-based languages: the ability to specify quantitative info (e.g., QoS)

It targets two main areas of application: Modeling of systems Analysis of systems

It is extensible and intended to be specialized further for various concerns and application domains.


# 103

SO WHAT ABOUT CRITICAL CPS AND MDE?

1.Need formal MDE

2.Need model-based analysis


# 104

TOWARDS FORMAL-MDE @ OMG

WG 1: UML2.5 Complete revision of its text description to simplify its presentation and disambiguate its semantics description (available in english).

WG 2: fUML Foundational UML (fUML) is an executable subset of standard UML that can be used to define, in an operational style, the structural and behavioral semantics of systems.

2 dedicated working groups


# 105

Class diagram

Activity diagrams

activity LaunchPingPongExample() {

game = new Game() ;

game.b.Start() ;

game.a.Start() ;

}

Alf Spec. of an activity

fUML scope

Alf = textual surface notation for fUML.

Object diagram


# 106 A formalized semantics for UML composite structures

UML Class and Activities

Execution Model

UML Composite Structures

Execution Model

UML

Classes + Activities

UML

Composite Structure

MARTE CM

EM

Semantic mapping

SysML IBB

EM

SysML

IBD

MARTE

CM PSCS

f U M L

CM:Component Model

EM: Execution Model

Precise semantics of UML Composite Structures (“PSCS”) New OMG standard defining a formal semantics for UML composite

structures and their extensions.

PSCS enables UML to be used as a formal ADL!

Syntax Semantics


# 107

Roadmap of the FM WG @ OMG

fUML

PSCS

Operational Semantic

Model

Operational Semantic

Model Composite structures

Classes + Activities

StateMachine

Profiles

Interactions

…

Alf

UML

PSSM: formalisation of

UML StateMachine (ongoing work)

Precise semantics of UML profiles: J. Tatibouet et al., “Formalizing Profiles

Execution Semantics With fUML Models”, MODELS Conf., Valencia, Spain, 2014.


# 108

SUMMARY

Standards

Architecturing

Component-based

Various MoCC

Dedicated abstractions for

RT/E domains

Platform-based

Automation/ Assistance


# 109

MARTE is not perfect but you can improve it…

Please, do not reinvent it because of some of its flaws but help us to make it better. Thanks.

A LAST WORD…

Commissariat à l’énergie atomique et aux énergies alternatives

Institut Carnot CEA LIST

Centre de Saclay | 91191 Gif-sur-Yvette Cedex

T. +33 (0)169 077 093 | M. +33 (0)688 200 047

Etablissement public à caractère industriel et commercial | RCS Paris B 775 685 019

| PAGE

110 Direction DRT

Département DILS

Laboratoire LISE

Titre aliquando tempo tatum commentum - IRISA

Documents

Transcript of Titre aliquando tempo tatum commentum - IRISA