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 A 1. Model compilation & 1 C E definition of one total 4 4 B execution order 1 D 2 2. Virtual time initialization A B C D E 3. Block execution according to t=0 t=1 t=2 t=3 t=4 t=5 precedences & virtual time A B C D E A B A B D A B A B C D E 4. Advancement of virtual clock Block network and its simulation (virtual time) & back to 3 Synchronous assumption t=0 t=1 t=2 t=3 t=4 ⇒ The reaction of the system A B C D E A B A B D A B (outputs & next state) must t=0 t=1 A B C D E be computed before the next Single-task implementation (real time) event in the system and scheduling issues Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models 4/23

Flow Preservation A 1 In many cases, what is required from C E 4 4 single-task & B an implementation is not the 1 multi-task implement. D do not satisfy the preservation of the synchronous 2 synch. assumption (E is produced after assumption but a looser property, t=0 t=1 real-time t=1) A B C D E called flow preservation t=0 t=1 t=2 t=3 t=4 A B A B A B A B ⇒ All data flows are preserved, even D D if results are produced at C E E different times Multi-task implementation is flow-preserving ◮ Possible problems because of b i b j reactions in b i b j logical time preemption and scheduling ◮ Communication channels to be o i (m) i j (k) o i (m+1) o i (m+2) i j (k+1) protected for data consistency real-time ◮ Buffering mechanism (e.g., o i (m+1) o i (m) lock-free commn. policies) delayed exec i j (k) Implementation that is not flow-preserving 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 Space of the apps instance of (Simulink/Scicos), independent from the app space execution hardware Model of concurrent Refinement tasks that exchange process Space of the software messages, preserving the platform implementation simulation-time execution of tasks and messages abstractions semantics and the V&V (SysML) results obtained on the functional model CU Space of the execution architecture hardware (SysML), space independent from the CU CU functionality CU CU CU Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models 7/23

Proposed Approach Focus of this talk Functional model exporter Simulink (ecore) Scicos M2M Functional model with back- Simulink annotations of estimated delays, Functional to verify (by simulation) their E4Coder Scicos M2C impact on the control stability Model for M2C Worst-Case Time Analysis Mapping (RTSIM, CHEDDAR, ...) M2M + M2C Simulink Coder/ communication Platform Embedded Coder code I/O code T ask code h h cpp h h h Behavioral code c Behavioral code (Simulink) cpp (Scicos) c c Platform-specific implementation (PSI) (Orocos-RTT) 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) Port dimension : EInt index : EInt OutPort datatypename : EString const_value : EString It’s a two-step procedure explicit : EBoolean 1 0..* 1. Import the functional model in EMF EventInPort EventOutP ... Property InPort id : ELong symbol : EString ◮ An Ecore meta-model has been 1 1 type : EString 0..* 0..1 0..1 size : EString 1 activate value : EString genevent defined for the import process hasinport eventsout 0..* actevent hasoutport parameter ◮ A description of the Simulink/ EventLink Block id : EString type : EString 0..* sampletime : ELong Scicos model is created by an symbol : EString Feedthrough : EBoolean importer that conforms to the 1 0..* 0..* position child OrderItem Subsystem eventlinks functional meta-model (blocks, index : ELong block 0..* destination source parameters, connections, . . . ) listitem Signal T otalOrder 0..* 0..1 order link Model name : EString Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models 10/23

From Simulink/Scicos to SysML non-feedthrough o11 c1 s1 i21 c6 c2 o21 i41 o41 ip1 op1 i22 s4 c3 c4 s2 plant 2. M2M transformation by QVTo i31 o31 c7 c5 i32 o51 i51 ◮ The QVTo transform creates a s3 Example Simulink diagram s5 Papyrus SysML model «block» FunctionalSystem ◮ Subsystems, dependencies & «block» FunctionalSystem «reference» s2: s2 topology of communications «reference» «reference» «reference» s4: s4 plant: Plant s1: s1 c6 c2 are generated automatically out o21 in i41 out o41 in ip1 out o11 out op1 ◮ Standard SysML Internal Block «reference» c1 s2: s2 Diagrams (IBD) can be used in i21 out o21 in i22 to represent them c4 c3 «reference» s3: s3 «reference» in i31 s5: s5 out o31 c5 in i32 out o51 Functional model into multiple SysML IBDs 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- «Stereotype» «Stereotype» specific definitions that extend Dependency Block FlowPort existing concepts adding properties and constraints ◮ Profiles are collections of «Stereotype» «Stereotype» «Stereotype» FunctionalOrder FunctionalPort stereotypes to be used in the FunctionalBlock context of a modeling or analysis activity ◮ We defined a profile collecting «Stereotype» concepts related to functional SRSubsystem «Stereotype» «Stereotype» + feedthrough: Boolean SRBinaryOrder SRPort + type: String modeling (stereotyped Block s, + sampletime: Integer FlowPort s & Dependency) Generation of Flow-Preserving Orocos Implementations of Simulink/Scicos Models 12/23