Towards a metamodel for the Rubus Component Model Alessio Bucaioni, Antonio Cicchetti and Mikael Sjödin

Arcticus Systems

Motivations (i)

More than: 70 embedded systems 100s ECUs 100 million lines of code

past present

Motivations (i)

Complex = distributed + embedded + real time + safety critical

Motivations (ii)

time-to-market development costs

SEAMLESS SOFTWARE DEVELOPMENT CHAIN

CBSE

Develops the system at higher level of abstraction

Promotes the re-use of components

Annotates components, at design time, with real-time properties and constraints

Enables pre-run-time analysis, e.g., end-to-end response time and delay analysis

EAST-ADL based development approach

Vehicle level

Analysis level

Design level

Standardized the terminology Promoted separation of concerns (top-down) Makes use of CMs at the implementation level AUTOSAR, RCM Implementation level

EAST-ADL

Vehicle level

Analysis level

Design level

Standardized the terminology Promoted separation of concerns (top-down) Makes use of CMs at the implementation level AUTOSAR Implementation level

What about the seamless development chain? (Interoperability, Information management and Traceability)

Intuition (i)

exploit the crossplay of MDE and CBSE for realizing a seamless chain for modeling software for vehicular embedded systems

Intuition (ii)

metamodels definition of all the technologies used along the software development 1

Intuition (ii)

RCM metamodel

metamodels definition of all the technologies used along the software development 1

Intuition (ii)

RCM metamodel

metamodels definition of all the technologies used along the software development 1model transformations among those technologies 2

Intuition (ii)

RCM metamodel

RCM2AUTOSAR transformation

metamodels definition of all the technologies used along the software development 1model transformations among those technologies 2

Background – RUBUS Concept

Based around the RCM and Rubus-ICE Collection of methods, theories and tools for component based development of resource-constrained embedded real-time systems.

Rubus Analysis Framework

Rubus Code Generator and Run-Time System  

Rubus SIMulation Model (RSIM)  

Rubus Execution Platform  

Background – RCM

Fig.1. Single-node real time system

RCM metamodel (i)

68 Eclass(es) 81 Ereference(s) realized in Ecore

RCM metamodel (ii)

Fig.2. Metamodel backbone fragment

RCM metamodel (iii)

Fig.3. Metamodel data elements fragment

RCM metamodel (iv)

Fig.4. Metamodel control elements fragment

RCM2AUTOSAR transformation (i) 1: new VirtualFunctionBus V FB;!2: for each Circuit c in a Target t do!3: ! !switch c:name do!4: ! ! !case (1) //c.name ends in Sensor!5: ! ! ! !new SensorSoftwareComponent sc;!6: ! ! ! !sc:name = c:name;!7: ! ! !case (2) //c.name ends in Actuator!8: ! ! ! !new ActuatorSoftwareComponent sc;!9: ! ! ! !sc:name = c:name;!10: ! !case (default)!11:! ! ! !new SoftwareComponent sc;!12: ! ! !sc:name = c:name;!13: !for each Interface i in c do!14: ! !for each PortDataIn di in i do!15: ! ! !new RequiredPortClientServer rp;!16:! ! ! !rp:name = di:name;!17: ! !end for!18: ! !for each PortDataOut do in i do!19: ! ! !new ProvidedPortClientServer pp;!20: ! ! !pp:name = do:name;!21: ! ! !pp:receiver = do:dataOutToDataIn;!22: ! !end for!23: !end for!24: end for!

RCM2AUTOSAR transformation (ii)

Fig.5. RCM model serialization

Fig.6. AUTOSAR model serialization

Conclusions We proposed the adoption of a methodology exploiting the crossplay of MDE and CBSE and took initial steps towards the realization of the aforesaid chain. We:

motivated the usage of RCM within the vehicular domain formalized a metamodel based on RCM presented the RCM2AUTOSAR model transformation

The metamodel serves as base for embracing the MDE vision, but it also aims in restoring the separation of concerns lost during the evolution of RCM The RCM2AUTOSAR transformation outlines the potential benefits gained in having a proper metamodel for RCM, in terms of automation, interoperability and traceability

Future works

Investigate further metamodel refinements targeting the enhancement of vehicular tool chaining while preserving the current expressive power

Identify additional languages used along the software development with the aim of

formalizing their metamodels and hence enable model transformations for

supporting a more extensive tool chain

Thank you ! …questions?

Background – EAST-ADL

Vehicle level

Analysis level

Design level

Implementation level

What the system is supposed to do. Feature models, requirements.

Formal notations. Behaviors and interfaces.

Software, middleware abstraction and hardware architecture. Software functions to hardware allocation is expressed.

Complete software architecture used for the code synthesis. AUTOSAR, RCM.

Related works - AUTOSAR

Software Components (SWCs) and Virtual Function Bus (VFB) VFB handles the virtual integration and communication hiding details

No

ability to specify and handle detailed timing information at design time distinction between data and control flow distinction between inter and intra node communication

Related works – TIMMO and TIMMO-2-USE

TIMMO tries to provide a timing model to AUTOSAR defines a language, TADL, for expressing timing requirements and constraints. has no concrete industrial implementation

TIMMO-2-USE

follows-up on the TIMMO project redefines TADL

There is no focus in these initiatives on how to extract low level and timing information from the model or perform timing analysis or synthesize the run-time framework