Generation of Flow-Preserving Orocos Implementations of - - PowerPoint PPT Presentation

Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models

Matteo Morelli and Marco Di Natale

IEEE-ICRA 2013, Workshop On Software Development and Integration in Robotics May 6th, 2013

TeCIP Institute, Scuola Superiore Sant’Anna Area della Ricerca CNR, Via Moruzzi, 1 56127 Pisa, ITALY

Robot Application Development Process

Key paradigms (see, e.g., BRICS FP7)

◮ Component-Based Software

Engineering (CBSE)

◮ Components as black-boxes with

interfaces

◮ Separation of Roles & Concerns

◮ Component Developer (Comput.) ◮ System Integrator (the other 4Cs)

◮ Model-Driven Engineering (MDE)

◮ Set of rules (meta-model) that

standardize components’ interfaces and their interconnections

◮ Model-to-Model (M2M) &

Model-to-Code (M2C) transformation engines that generate the system’s structure

Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models 2/23

Limitations – Designing Capabilities

Lack of a formal Model of Computation (MoC)

◮ The system-level behavior emerges from the cooperation of

components (event signals) ⇒ Prevent early verification and validation (V&V) of the properties of the controller-controlled system (simulation/model-checking) It’s difficult to realize a formal semantics (synchronous) at system-level

◮ Causal dependency between producers & consumers defines a

partial order of execution ⇒ In general, this is not trivial to express by using event signals Components’ functionalities are mostly handwritten; they can be generated from a model (Orocos-Simulink), but with several limitations

◮ Only single-task implementations can be generated ◮ Only for single-CPU, single-core systems ◮ Only implementations that preserve the synchronous assumption

Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models 3/23

What is the Synchronous Assumption?

Model simulation in Simulink

• 1. Model compilation &

definition of one total execution order

• 2. Virtual time initialization
• 3. Block execution according to

precedences & virtual time

• 4. Advancement of virtual clock

& back to 3 Synchronous assumption ⇒ The reaction of the system (outputs & next state) must be computed before the next event in the system

C A B A B A B A B

t=0

E C D

t=1 t=2 t=3 t=4

D A B

t=0 t=1

E D

E A B C D E A B C D E A B C D E 1 1 4 2 4 A A B B D A B t=0 t=1 t=2 t=3 t=4 t=5 A B C D

Block network and its simulation (virtual time) Single-task implementation (real time) and scheduling issues

Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models 4/23

Flow Preservation

In many cases, what is required from an implementation is not the preservation of the synchronous assumption but a looser property, called flow preservation ⇒ All data flows are preserved, even if results are produced at different times

◮ Possible problems because of

preemption and scheduling

◮ Communication channels to be

protected for data consistency

◮ Buffering mechanism (e.g.,

lock-free commn. policies)

E A B A B A B A B A B

A B C D E 1 1 4 2 4

D

t=0 t=1 t=2 t=3 t=4

D

t=0 t=1

E D C C E

Multi-task implementation is flow-preserving

i (m) j (k)

i

• i (m+1)
• i (m+2)

j (k+1)

i

• i (m+1)
• i (m)

b i

j

b

j (k)

i

• bi

bj

reactions in logical time

Implementation that is not flow-preserving

real-time delayed exec single-task & multi-task implement. do not satisfy the

• synch. assumption

(E is produced after real-time t=1) Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models 5/23

Limitations (cont’d) – Platform Modeling

Available tools do not support execution-platform modeling, crucial for designing reliable applications

◮ Robot applications demand real-

time tasks at different rates

◮ Delays and jitter may degrade the

QoS and even jeopardize the control stability

◮ Complex filtering (e.g. vision) ◮ Bus arbitration ◮ Transmission delay ◮ Control action computation

◮ They depend on the physical

execution platform: single-core, multi-core or distributed, CPU, FPGA, network protocols, . . .

Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models 6/23

Proposed Approach

A system engineering process integrating MBD and MDE

app space architecture space platform abstractions instance of Model of concurrent tasks that exchange messages, preserving the simulation-time execution semantics and the V&V results obtained on the functional model Space of the apps (Simulink/Scicos), independent from the execution hardware Space of the execution hardware (SysML), independent from the functionality Space of the software implementation

• f tasks and messages

(SysML) CU CU CU CU CU CU Refinement process

Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models 7/23

Proposed Approach

Behavioral code (Scicos) Model for Worst-Case Time Analysis (RTSIM, CHEDDAR, ...) T ask code I/O code communication code Functional model with back- annotations of estimated delays, to verify (by simulation) their impact on the control stability Platform-specific implementation (PSI) (Orocos-RTT)

Simulink Scicos model exporter Functional Mapping Platform Functional (ecore) M2M Simulink Scicos h cpp h c h cpp h c

Behavioral code (Simulink) h c

Simulink Coder/ Embedded Coder E4Coder M2M + M2C M2C M2C

Focus of this talk Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models 8/23

Functional modeling

Plant dynamics & control logics are modelled with Simulink/Scicos and tested by simulation with logical execution-time assumptions Main points

◮ Formal execution semantics,

Synchronous-Reactive (SR)

◮ Capability of modelling and

simulating FSMs

◮ Enable early V&V with the

simulation of functionalities (& refinement of control strategies), including models of the plant

◮ Subsystems are units for code-

generation (must be single-rate)

Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models 9/23

From Simulink/Scicos to SysML

Once the simulation results are satisfactory, the model of functional level changes from executable to a structural one (SysML) It’s a two-step procedure

• 1. Import the functional model in EMF

◮ An Ecore meta-model has been

defined for the import process

◮ A description of the Simulink/

Scicos model is created by an importer that conforms to the functional meta-model (blocks, parameters, connections, . . . )

Model name : EString Block id : EString type : EString sampletime : ELong symbol : EString Feedthrough : EBoolean Property id : ELong symbol : EString type : EString size : EString value : EString Signal InPort T

• talOrder

OrderItem index : ELong EventInPort OutPort const_value : EString EventOutP ... EventLink Subsystem Port dimension : EInt index : EInt datatypename : EString explicit : EBoolean block 0..* link 0..* parameter 0..* source 1 destination 1 child 0..*

• rder

0..1 position 1 listitem 0..* activate 0..1 hasinport 0..* hasoutport 0..* eventsout 0..1 actevent 1 genevent 1 eventlinks 0..*

Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models 10/23

From Simulink/Scicos to SysML

• 2. M2M transformation by QVTo

◮ The QVTo transform creates a

Papyrus SysML model

◮ Subsystems, dependencies &

topology of communications are generated automatically

◮ Standard SysML Internal Block

Diagrams (IBD) can be used to represent them

c4 c5 c6 c7 s5 i51

• 51

s4 i41

• 41

s3 i31 i32

• 31

s2 i21 i22

• 21

s1

• 11

plant ip1

• p1

c1 c3 c2

non-feedthrough

Example Simulink diagram Functional model into multiple SysML IBDs

«block» FunctionalSystem «reference» s1: s1

• ut o11

«reference» s2: s2 in i21 in i22

• ut o21

«reference» s3: s3 in i31 in i32

• ut o31

«reference» s5: s5

• ut o51

c1 c3 c4 c5 «block» FunctionalSystem «reference» s2: s2

• ut o21

«reference» s4: s4 in i41 out o41 «reference» plant: Plant in ip1

• ut op1

c6 c2

Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models 11/23

Tailoring SysML: Profiles and Stereotypes

SysML is a general-purpose systems modeling language: it can (should) be customized for specific domains

◮ Stereotypes are domain-

specific definitions that extend existing concepts adding properties and constraints

◮ Profiles are collections of

stereotypes to be used in the context of a modeling or analysis activity

◮ We defined a profile collecting

concepts related to functional modeling (stereotyped Blocks, FlowPorts & Dependency)

«Stereotype» Block «Stereotype» FlowPort «Stereotype» SRSubsystem + feedthrough: Boolean + type: String + sampletime: Integer «Stereotype» FunctionalPort «Stereotype» SRPort «Stereotype» FunctionalBlock Dependency «Stereotype» SRBinaryOrder «Stereotype» FunctionalOrder

Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models 12/23

Generation of the Behavioral Code

Tools: Simulink Coder/Embedded Coder (Simulink) or E4Coder (Scicos) Remark: (single-rate) subsystems are units for code-generation

◮ Each subsystem translates into a

C function, the step()

◮ Each step() performs the output

& state update of all blocks inside the subsystem (in the order imposed by the model semantics)

◮ Subsystem’s ports are accessed

via a middleware-level API (and not as global variables)

dgemm 0.001 void Superblock_32_step(void) { /******** Output Updates ********/ delayTD_82_out[0] = delayTD_82_dstate[0]; ... delayTD_82_out[5] = delayTD_82_dstate[5]; /* Port access via MW-level API */ MW_read(Superblock_32, 1, mwr_9_out); MW_read(Superblock_32, 2, mwr_11_out); /* Execution of all blocks inside the subsystem */ dgemm_OutputUpdate( mwr_9_out, mwr_11_out, dgemm_14_out); gain_83_out[0] = 0.001 * dgemm_14_out[0]; ... gain_83_out[5] = 0.001 * dgemm_14_out[5]; sum_85_out[0] = gain_83_out[0] + delayTD_82_out[0]; ... sum_85_out[5] = gain_83_out[5] + delayTD_82_out[5]; /* Port access via MW-level API */ MW_write(Superblock_32, 1, delayTD_82_out); /******** State Updates ********/ delayTD_82_dstate[0] = sum_85_out[0]; ... delayTD_82_dstate[5] = sum_85_out[5]; }

Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models 13/23

Excution-Platform Modeling

Define the HW & SW resources available in the system

◮ Profiles/Stereotypes for the

embedded system domain

◮ Definition of the physical platform

(Cores, Peripherals, IODevices, Boards, . . . )

◮ Definition of the basic software (RTOS,

IODrivers, CommunicationStack, Middleware)

◮ Some concepts from OMG’s SysML

MARTE profile, other concepts from custom definitions

Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models 14/23

Software Architecture

A profile representing SW concurrency & resources

◮ Thread is the unit of

concurrent execution

◮ Thread’s period & priority are

specified by the designer

◮ SRSubsystems are executed in

the context of Threads

◮ Signal variables (Comm.Imp.)

represent functional commns. (according to the actual mapping & deployment)

Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models 15/23

Mapping Modeling

SRSubsystems must be deployed onto the execution platform A profile for mapping (Allocated stereotype)

◮ FunctionToThreadMapping

defines SRSubsystems-to- Threads mapping

◮ step()s executed according

to the mappingOrder (subject to validation)

◮ SignalImplementationMapp.

maps communications to signals

• vars. (UDP, lock-free, etc.)

◮ ThreadToCPUDeployment is for

Thread-to-CPU allocation

«Stereotype» Allocated «Stereotype» Mapping «Stereotype» FunctionToThreadMapping + mappingOrder: Integer «Stereotype» SignalToResourceMap... «Stereotype» ThreadToCPUDeployment + coreAnity: Integer «Stereotype» SignalImplementationMapping «Stereotype» SignalToFrameMapp...

Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models 16/23

Mapping Modeling

«block» MappingSystem «part» functionalsystem: FunctionalSystem «reference» s1: s1

• ut o11

«reference» s3: s3 in i31

• ut o31

in i32 «reference» s5: s5

• ut o51

«reference» s2: s2 in i21 in i22

• ut o21

«part» process1: Process1 «part» thread1: Thread1 «part» lf3: LF3 «part» local1: Local1 «part» thread2: Thread2 «part» platformsystem: PlatformSystem «part» board1: Board1 «part» cpu1: CPU1 s1ToThread1 s3ToThread1 s5ToThread1 c1 c3 c4 c5 c3ToLF3 c5ToLocal1 «sRBinaryOrder» s3DependsOns5 Thread1ToCPU1 s2ToThread2 Thread2ToCPU1

◮ It’s good practice to use multiple IBDs to define mapping models

Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models 17/23

Orocos-RTT as Excution-Platform

From the mapping model, a set of M2M & M2C transforms generate the flow-preserving, platform-dependent code for threads & commns. A profile for a subset of Orocos-RTT (refinement)

◮ Static deployments

(stereotyped Block)

◮ RTT components (stereotyped

Blocks)

◮ In/Out data-flow, In event

ports (stereotyped FlowPorts)

◮ Connection policy (stereotyped

Connector)

«Stereotype» Block «Stereotype» Activity + scheduler: SchedulingPolicy + priority: Integer + period: Integer + cpuAnity: Integer «Stereotype» TaskContext «Enumeration» SchedulingPolicy ORO_SCHED_OTHER ORO_SCHED_RT «Stereotype» FlowPort «Stereotype» Port «Stereotype» InputPort «Stereotype» OutputPort «Stereotype» EventInputPort «Stereotype» DataFlowInputPort «Stereotype» Block «Stereotype» StaticDeployment «metaclass» Connector «Stereotype» ConnectionPolicy + buerSize: Integer + type: ConnectionPolicyType + lockPolicy: ConnectionPolicyLockPolicy «Enumeration» ConnectionPolicyType BUFFER DATA «Enumeration» ConnectionPolicyLockPolicy UNSYNC LOCKED LOCK_FREE activity

Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models 18/23

Orocos-RTT as Excution-Platform

• 1. M2M transform by QVTo

◮ The abstract concept of Thread is

represented by the pair Activity/TaskContext

◮ Activities are non-periodic ◮ Inter-component commns. are

represented by data-flow ports on the components & lock-free ConnectionPolicy objects

◮ Model elements are generated to

implement scheduling strategies preserving the functional model semantics ⇒ A model of the PSI

Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models 19/23

Orocos-RTT as Excution-Platform

• 2. M2C transform by Acceleo

◮ Task-code (updateHook() as a

sequence of calls to the step()s mapped on it & serialized according to the mapping order)

◮ Code implementation of the signal

variables (local, inter-component communications, etc)

◮ Code implementation of the

scheduling & event infrastructure that guarantees the execution

• rder among components

⇒ The Code of the PSI

// middleware-level API #define mw_read(block_id, port_id, value) \ mw_read_##block_id##_##port_id(value) #define mw_write(block_id, port_id, value) \ mw_write_##block_id##_##port_id(value) // Implementation of intra-task communication port_type s5_o51; void mw_write_s5_o51(const port_type value) { s5_o51 = value; } void mw_read_s3_i32(port_type *value) { *value = s5_o51; } // Implementation of inter-task communication extern RTT::TaskContext *pTask1; #define mw_read_s3_i31(value) task1_read_1(pTask1, value) #define mw_write_s1_o11(value) task1_write_1(pTask1, value) #define mw_write_s3_o31(value) task1_write_2(pTask1, value) void task1_read_1(RTT::TaskContext *t1, port_type *value) { t1->ports()->getPort("s3_i31")->read(*value); } void task1_write_1(RTT::TaskContext *t1, const port_type value) { t1->ports()->getPort("s1_o11")->write(value); } void task1_write_2(RTT::TaskContext *t1, const port_type value) { t1->ports()->getPort("s3_o31")->write(value); } /* Implementation of Thread1 (Task1): s1, s5, s3 */ class Task1 : public TaskContext { /* ... input (s3_i31), output (s1_o11, s3_o31) ports ... */ public: /* ... Ctor, configure, start, stop hooks ... */ void updateHook() { s1_step(); s5_step(); s3_step(); } };

Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models 20/23

Scheduling Strategies for Flow Preservation

◮ Single-core platforms

◮ One additional TaskContext

generated as a dispatcher

◮ It runs periodically at the base

period at the highest priority

◮ A scheduling table specifies the

• rder of exec. of non-periodic

components in the hyperperiod

◮ They are added as peers to the

dispatcher that triggers them according to the sched. table

◮ Single-CPU, multi-core platforms

◮ One dispatcher for core ◮ Enforcement of precedence

constraints by event signals

Activity

period: 0 priority: 25 void updateHook() { s4_step(); }

T ask3

10ms 20ms 30ms

T ask2 T ask1 t=10ms t=20ms t=30ms t=40ms t=50ms t=0 T ask2, T ask1, T ask3 T ask2 T ask2, T ask1 T ask2, T ask3 T ask2, T ask1 T ask2 activation time T ask2 E.E.

runs runs calls calls calls

Activity

period: 0 priority: 1

T ask1

runs

E.E. T ask3 E.E.

runs Activity period: 0 priority: 1 runs void updateHook() { //trigger peers according //to the scheduling table ... }

Dispatcher E.E.

peer peer peer

Activity

period: 10 priority: 49 calls

Deployment in a single core

void updateHook() { s1_step(); s5_step(); s3_step(); } void updateHook() { s2_step(); }

Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models 21/23

Conclusions

The current approach to SW develop. in robotics has limitations:

◮ Lack of a formal MoC that enables MBD and V&V of controls ◮ No support for the definition of concepts & models of physical

execution platforms (HW/basic SW) We described a design flow where MBD (Simulink/Scicos) & MDE (SysML) are used in a complementary way, enabling:

◮ Separation of concerns (functional & platform models) ◮ Automatic code-generation of flow-preserving PSI (Orocos-RTT) of

functional algorithms, verified earlier by, e.g., simulation

◮ Evaluation of computation and communication delays & their

impact, e.g., on the task-set schedulability & the control stability and that leverages standards (MOF, SysML, MARTE, M2M, M2C) Future work concerns

◮ Extension to models & examples for distributed architectures ◮ Estimation of delays & automated synthesis of optimal

implementations (according to non-functional metrics)

Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models 22/23

dummy

thank you!

matteo.morelli@sssup.it

Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models 23/23