Meta-models Combination for Reusing Veriﬁcation Techniques

Hui Zhao

, Ludovic Apvrille

and Fr

eric Mallet

Universit

e C

ote d’Azur, I3S, INRIA, France

LTCI, Telecom ParisTech, Universit

e Paris Saclay, France

Keywords:

CPSs, MBSE, AADL, Arcadia, Model Transformation.

Abstract:

The complexity of Cyber-Physical Systems (CPSs) is rapidly increasing because more and more aspects

have been considered during the design phase. Each aspect involves its domain-speciﬁc modeling language

(DSML), How to combine various DSMLs was a challenging problem. Rather than build-in all analysis and

modeling capacities, we prefer with independent domain speciﬁc metamodels and link them together. In this

paper, we show how to use a coordinated metamodel approach as a systematic way to gather diverse domain

models and cross-cutting concerns. Thus, the paper proposes a set of transformation operators to manipulate

(AADL and SysML) metamodels. We show that we can thus enrich platform capacities by blending different

languages seamlessly, as well as perform the functional and scheduling analysis respectively through concrete

models. A train traction controlling system serves as a case study.

1 INTRODUCTION

Developers of Cyber-Physical Systems (CPSs) have

to deal with different domains, each of them hav-

ing different characteristics. It is seldom the case

that one development platform or a single language

can adapt to all aspects with assumption one-size-ﬁts-

all. Therefore developers have to rely on domain-

speciﬁc languages to handle the different domains

problem. This results not only in a proliferation of

languages but also increases the design complexity

of CPS. Meanwhile, the gaps between languages and

platforms brought additional problems such as co-

herency and consistency problems, which are exposed

at integration and simulation stages. This also further

exacerbates the complexity, make the complexity sky-

rocketing.

To tackle these problems, engineers need an ap-

proach which can efﬁciently combine already existing

languages. The goal is not only to combine the dif-

ferent languages seamlessly but also to beneﬁt from

the advantages of each language. Two solutions are

possible. (i) A ﬁrst solutions is to continuously inte-

grate the necessary languages into an existing devel-

opment platform, thus leading to progressively build a

comprehensive development platform. However, this

could lead to a never ending process resulting in a

This work was ﬁnancially Supported by the CLAR-

ITY project and by a UCN@Sophia Labex scholarship.

gigantic framework, which would be difﬁcult to use,

maintain, etc. (ii) A second solution is keeping each

language (or tool) isolated, and relate some of the

elements of each language (sub) meta-model in or-

der to conduct the different analysis offered by each

approach (e.g. scheduling analysis, safety analysis,

etc.). In this second solution, each domain expert can

work independently. Yet, since each language has its

own characteristic such as syntax and semantics, we

have to eliminate the gaps between them and handle

the consistency issues. Therefore, our contribution is

to propose a formal combining approach to link two

modeling languages. To do so, we deﬁne how to re-

late two (sub-)metamodels. Then, once two models

, m

has been performed in the two languages, m

can automatically be augmented with some of the in-

formation of m

in order to perform veriﬁcation on en-

riched models (e.g., scheduling, timing, safety), and

then to backtrace the veriﬁcation results to m

In this paper, we selected SysML and AADL to

demonstrate the relevance of our approach. These

languages are supported by the tools Capella/Arca-

dia and OSATE2

, respectively. The paper is orga-

nized as follows. We present our contribution with

ﬁrst our workﬂow and then with the formal deﬁnition

of a set of combination rules and operators. Then,

in section 3, we apply these operators on functional

and physical views. In section 4, train traction con-

http://osate.org/index.html

Zhao, H., Apvrille, L. and Mallet, F.

Meta-models Combination for Reusing Veriﬁcation Techniques.

DOI: 10.5220/0007261000370048

In Proceedings of the 7th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2019), pages 37-48

ISBN: 978-989-758-358-2

trolling systems are used to demonstrate architecture

and scheduling analysis. Section 5 presents the re-

lated work. Finally, section 6 concludes the paper and

gives our future work.

Some special notes for this paper are: 1) When we

mentioned Arcadia, it means SysML-based method-

ology, the language is SysML. 2) In sections 2, 3

and 4, all elements on the left of transformation rules

belong to metamodels of Arcadia and all elements on

the right are from the AADL metamodels. The two

metamodels have been imported by default, and we

thus omitted the preﬁx (e.g., MM.Arcadia.function)

for pithiness.

2 APPROACH

2.1 Workﬂow

The workﬂow of our approach is shown in ﬁgure 1.

While Arcadia is well adapted to describe allocations

of functions, AADL rather focuses on the concrete

execution behaviors of components. In this paper,

we use transformation to enhance Arcadia with the

scheduling analysis features of AADL. To do so, we

propose a set of rules and operators to specify the re-

lationships at the M2 level. These rules — deﬁned in

a Transformation Rule Library or TRL for short — an

establish a relationship between Arcadia and AADL

metamodels. For instance, Arcadia and AADL deﬁne

concepts that can be put in relation with our rules. For

example, an Arcadia function allocated to a proces-

sor can be related to a ”thread” in AADL, as shown

as green part in the ﬁgure. When a feature has no

equivalence in Arcadia, additional attributes must be

added (e.g., period and execution time, shown as red

part). We manually choice the elements of meta-

model depend on requirements of the project. Once

the equivalence relations between the two metamod-

els have been settled, we can get a temporary com-

binational metamodel (TCM) at run time by using

TRL (step 1). Then, the TCM can be used to en-

hance an AADL model with elements of an Arcadia

model (step 2). Then, the new AADL model can be

exported into OSATE for further editing. Next, it can

be used to perform the scheduling simulation in the

Cheddar (Singhoff et al., 2004) analysis tool (step 3).

This tool can be used to detect design ﬂaws, conﬂicts

of time and resources. We then expect to trace back

the results to the Arcadia model in order to help the

designer enhancing the performance of his/her model

(step 4).

2.2 Operators and Rule Expression

Metamodels can be manipulated with formal writing

rules built upon operators e.g. transform, create, ig-

nore. In the following parts of the paper, several op-

erators and their semantics are deﬁned (see table 1).

Table 1: Symbols of transformation rule expression.

Symbol of operator Meaning

Γ Transformation Rule

; End of rule

: Separate elements

Transfer

<> Parent node

{ } Attribute

[ ] Optional element

| Separation of elements

{ }+ Attribute to be created

¬ Ignore

2.2.1 Structure of Rule

A rule begins with ”Γ” and ends with ”;”. A transfer

symbol contains a source object in its left side and

one or more target objects in its right side. The parent

node is enclosed within the angle brackets ”<>” (if it

has one parent node). Finally, a rule is as below:

Γ < parent > source target;

Each part of an object is separated by ”:”. The

attribute group is enclosed with parentheses ”{ }”.

square braces ”[ ]” delimit optional elements and the

alternatives are separated by a pipe ”|”. For example,

The port has a directional attribute called Direction

which could be in or out. Shown as below:

ort

: {Direction[in|out]}

2.2.2 Creating Operator

In the case of creating a new attribute, put the name

of an attribute in the parentheses with plus ”{ }+”, is

used to present the option is to be created. An exam-

ple as below, an attribute type of component port will

be created with three optional values (data, event, data

and event):

Port : {Type[data|event|dataevent]}+

2.2.3 Ignoring Operator

For some ignored attributes and objects are denoted

with ”¬” which is in front of the ignored object.

An example of transformation rule expressions is

in listing 1. In particular, the number of attributes of

the target object may be greater than the number of

attributes of the source object in the case of a new

object created.

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

Import

Transformation Rule

LIB

Import

Arcadia Models

Functional

Design/Analysis

Temporary AADL Models

Architectural + Timing

Design/Analysis

Simulation

schedule 1

schedule 2

Simulate

Traceback

conform to

correspondingcorresponding

Legend

conform to

Export

corresponding

to be implemented

conform to

Metamodels of AADL

Metamodels of ARCADIA

Temporary combinational Metamodel

conform to

Figure 1: Overview of Workﬂow.

2.3 Arcadia2AADL Model

Transformation

Based on the deﬁned transformation rules, The Ar-

cadia2AADL transformation can create a temporary

metamodel according to original metamodels and

TRL. The ATL serves as a transformation engine. For

more detailed information of ATL, the reader is re-

ferred to (Jouault et al., 2006)(Jouault et al., 2008).

The Structure of Arcadia2AADL model transforma-

tion is shown in Fig 2. AADL metamodels (de-

noted as MMb) and Arcadia metamodels (denoted

as MMa) are imported (input) into ATL engine, and

the engine is going to read transformation rules li-

brary and then the transformation engine exports (out-

put) a temporary metamodel (denoted as metamodel

MMb’) which is a union subset of AADL and Arca-

dia and conform to AADL metamodel. The generated

metamodel is then further post-processed as a DSML

(domain-speciﬁc modeling language) in ecore format

Meta-models Combination for Reusing Veriﬁcation Techniques

Listing 1: An example of transformation rules.

1 ΓP

ort

: { D i r e c t i o n [ i n | o u t ]} < f e a t u r e >:

P o r t : { D i r e c t i o n [ i n |o u t ] } : { Type [

d a t a | e v e n t | d a t a e v e n t ] } + ;

2 ΓPP < f e a t u r e >: P o r t : { D i r e c t i o n [ i n |

o u t ] } + : { Type [ d a t a | e v e n t | d a t a e v e n t

] } + ;

3 ΓP

ort

: ¬{ o r d e r i n g } ) ;

4 ΓEx

f un

: { S o u r c e } : { T a r g e t } <

c o n n e c t i o n s >: c o n n e c t i o n : { s o u r c e

} : { t a r g e t } ;

input

Arcadia Metamodel

(MMa)

AADL Metamodel

(MMb)

Generated Metamodel

(MMb’)

Transformation rules

Lib

ATL Engine

input

Arcadia(SysML)

AADL&HA

conform to

corresponding

output

DSML

Instance

models

post-processing

create

input

Figure 2: Structure of Arcadia2AADL model transforma-

tion.

which can be used to create instance models. There-

fore, all instance models afterward are conformed to

this metamodel and will be used for further simulation

and analysis.

3 TRANSFORMATION RULE

LIBRARY

As we described in the above section, the Transfor-

mation Rule Library (TRL) play an important role in

the transformation process. Hence, in this section,

we present how to construct a TRL from the follow-

ing three views, functional view and physical view.

Each view contains the metamodels which are from

the subset of AADL and Arcadia.

3.1 Functional View

3.1.1 Logical Components in Arcadia

The logical components in Arcadia contain a set of

member elements, such as logical component con-

tainers, functions, ports, and functional exchanges.

In the Arcadia, Functional diagrams consist of a set

of SysML blocks and its interactions, named Logical

components; The notion of Logical components en-

ables better expression of system engineering seman-

tics compared to SysML, and particularly, reduces the

bias towards software. SysML block deﬁnition di-

agrams (BDDs) and internal block diagrams (IBDs)

are assigned to different abstract and reﬁned layers,

respectively. The deﬁnition of a block in SysML can

be further detailed by specifying its parts; ports, spec-

ifying its interaction points; and connectors, specify-

ing the connections among its parts and ports. This

information can also be visualized using logical com-

ponents in Arcadia. In the deﬁnition 3.1.1, we present

a metamodel of an instance of logical components.

Deﬁnition 3.1.1. (Logical Component) A logical

component (LC) is 5 tuples,

LC =< C

omp

, F

, P

ort

, Ex

f un

, M

c f

where, C

omp

= {

} is a logical component con-

tainer which contains a set of functional elements. F

is a ﬁnite set of functional block include their name

and id attributes. P

ort

is a ﬁnite set of functional

ports including directions and allocation attributes.

f un

⊆ P

ort

× P

ort

denotes a ﬁnite set of functional

exchange (connection) between two functional ports,

it must be pair, one is source, another is target. M

c f

: ΣF

→ C

omp

allocate functions to a logical compo-

nent container.

Figure 3: An example of functional view of vehicle traction

control unit in ARCADIA.

In the ﬁgure 3, there is a functional instance model

of a part of a vehicle traction control unit in ARCA-

DIA as an example. The blue rectangle is named log-

ical component in Arcadia, but we consider it as a

function’s container, we thus call it logical compo-

nent container C

omp

in this paper. The green rectangle

are functions F

which are contained by C

omp

. The

element M

c f

has represented this allocation relation-

ship between logical component containers and func-

tions M

c f

: ΣF

→ C

omp

. The deep green square with

the white triangle is the outgoing port (P

ort

), which

connects to an incoming port (P

ort

) that is drawn as

a red square with white triangle and the green line is

the functional exchange between two functional ports

(Ex

f un

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

3.1.2 The Metamodels of Software in AADL

AADL is able to model a real-time system as a hi-

erarchy of software components, predeﬁned software

component types in the category of the components

such as thread, thread group, process, data, and sub-

program are used to model the software architecture

of the system.

Deﬁnition 3.1.2. (Software Composition) A SC is a

4-tuples:

S C =< Type, Port,Connection, Annex >

where Type speciﬁes the type of components (e.g,

system, process, thread). Port is a set of communi-

cation point of component. Port could be different

types such as data port, event port and data event

port. And, port can specify the direction such as in

port, out port, in out port. Connection is used to con-

nect ports in the direction of data/control ﬂow in uni-

or bi-directional. Annex is deﬁned for the reﬁnement

of component, in this paper, we used hybrid annex to

explicitly describe the both discrete and continuous

behavoir of train traction control system.

3.1.3 Hybrid Annex

We use the HA to declare both discrete and continu-

ous variables in the Variables section, and the initial

values of constants are given in constant section. As-

sert is used to declaring predicates which may be used

with invariants to deﬁne a condition of operation. The

behavior section is used to specify the continuous be-

havior of the annotated AADL component in terms

of concurrently executing processes, and use contin-

uous evolution — a differential expression to specify

the behavior of a physical controlled variable of a hy-

brid system. The communication between computing

units and physical components are an essential part

of a hybrid system, Communication between physi-

cal processes uses the channels declared in the chan-

nel section, and communicate with an AADL com-

ponent relies on ports that are declared in the com-

ponent’s type. Continuous process evolution may be

terminated after a speciﬁc time or on a communica-

tion event. There are invoked through timed and com-

munication interrupt, respectively. A timed interrupt

preempts continuous evolution after a given amount

of time. A communication interrupt preempts contin-

uous evolution whenever communication takes places

along any one of the named ports or channels. The

deﬁnition 3.1.3 gives a metamodel of Hybrid Annex

which does not exist in SysML-based environment.

Deﬁnition 3.1.3. (Hybrid Annex) A Hybrid Annex is

a 8-tuples:

H A =< Ass, Ivar,Var

,Cons

, P

roc

,ChP, Itr, B

itr

where Ass is a ﬁnite set of assert for declaring pred-

icates applicable to the intended continuous behavior

of the annotated AADL component. Ivar is associ-

ated with assert to deﬁne a condition of operation that

must be true during the lifetime. Var

is a ﬁnite set

of discrete and continuous variables. Cons

is a ﬁnite

set of constants which must be initiated at declaration.

roc

is a ﬁnite set of processes that are used to spec-

ify continuous behaviors of AADL components. ChP

is a ﬁnite set of channels and ports for synchronizing

processes. Itr is a ﬁnite set of time or communication

interrupts. B

itr

: Itr → P

roc

binds interrupts to related

processes.

3.1.4 Functional Elements Transformation

Rules

The table 2 shows the correspondence between

AADL and Arcade elements. The Additional at-

tributes column are the attributes to be created dur-

ing the transformation. According to this table, we

can easily write the transformation rules to transform-

ing Arcadia to AADL on functional parts, denoted

LC S C + H A. An example as below (listing 2):

Listing 2: Functional elements transformation rules exam-

ple.

1 ΓC

omp

Type [ system|process ] : {

R u n t i m e P r o t e c t i o n [ t r u e | f a l s e ] } + ;

2 ΓF

Type [ abstract|thread ] : { D i s p a t c h \

P r o t o c o l [ P e r i o d i c | A p e r i o d i c |

S p o r a d i c |B ac kg ro un d|Timed|H ybr i d

] } + ;

3 . . .

3.2 Physical View

3.2.1 Execution Platform in AADL

Processor, memory, device, and bus components are

the execution platform components for modeling the

hardware part of the system. Ports and port con-

nections are provided to model the exchange of data

and event among components. Functional and non-

functional properties like scheduling protocol and ex-

ecution time of the thread can be speciﬁed in compo-

nents and their interactions.

Deﬁnition 3.2.1. (Execution Platform) A EP compo-

nent is deﬁned as a 3-tuples:

EP =< EC, BA,C

onn

where,EC deﬁnes the execution component such as

processor, memory, bus and device. BA deﬁnes the

BusAccess which is interactive approach between bus

Meta-models Combination for Reusing Veriﬁcation Techniques

Table 2: Functional and Physical elements correspondence table.

Arcadia AADL Additional attributes

Logical component container (C

omp

) System,Process {Runtime Protection[true|false]}+

Function (F

) Abstract, Thread {Dispatch Protocol[Periodic|Aperiodic|Sporadic|Background|

Timed|Hybrid]}+

Port (P

ort

) Port {Type[data|event|data event]}+

Functional Exchange (Ex

f un

) Connection 

 Annex {Type[abstract| thread]}:{annex}+

Physical Node (N

ode

) Device,Memory,Processor,Bus {Dispatch Protocol}+:{Period}:{Deadline}+:{priority}+

Physical Port (PP)  ¬PP

Physical Link (PL) Bus/BusAccess {Allowed Connnection Type}+:{Allowed Message Size}+:

{Allowed Physical Access}+:{Transmission Time}+

component and other execution platform components.

onn

⊆ EC ×EC denotes a ﬁnite set of connection be-

tween two components via bus device.

3.2.2 Physical Components in Arcadia

The physical component in Arcadia consists of phys-

ical Node, Port and Link. The Physical Port and

Link correspond to port and bus connection in AADL.

There are some choices when the physical Node is

translated to AADL such as device, memory, and pro-

cessor, hence the designer has to point out what type

of target component during transformation by using

transformation rule express.

Deﬁnition 3.2.2. (Physical Components) A Physical

components is 3-tuples,

P C =< N

ode

, PP, PL >

where, N

ode

is a execution platform, named node in

Arcadia, it could be different type of physical compo-

nent (e.g, processor, board). PP is the physical com-

ponent port. PL is physical link, it could be assigned

a concrete type such as bus.

Figure 4 is shown as a part of physical instance

model of vehicle traction control unit in ARCADIA.

We can see the yellow parts are the physical node

ode

) and the red line is the physical link (PL) named

bus in this case which connects to two physical ports

(PP), the small square in dark yellow.

3.2.3 Physical Elements Transformation Rules

According to the table 2, we can easily write the

transformation rules for physical elements. Listing 3

shown as a part of the code to transform the physical

component from Arcadia to AADL.

What we have to especially explain is the physical

link part (see line 3). The Bus device could be a log-

ical resource or hardware component. Hence, the bus

device has different properties depending on the role.

When the bus is considered as a logical resource, it

contains the properties Allowed

connection type and

Allowed Message Size. When the bus is hardware,

Figure 4: An example of physical view of vehicle traction

control unit in ARCADIA.

Listing 3: Physcial elements transformation rules example.

1 ΓN

ode

[ Device|Process|Memory|Bus ] : {

D i s p a t c h P r o t o c o l } + :{ P e r i o d } : {

D e a d l i n e } + :{ p r i o r i t y }+;

2 ΓPP ¬PP ;

3 ΓPL Bus / Bu sA cc es s : [ {

A l l o w e d C o n n n e c t i o n Ty pe }+ :{

A l l o w e d M e s s a g e S i z e }+|{

A l l o w e d P h y s i c a l A c c e s s } + : {

T r a n s m i s s i o n T i m e } + ] ;

it contains Allowed Physical Access and Transmis-

sion Time. Therefore, we write the rules that either

{Allowed Connnection Type}+ : {Allowed Message Size}+

{Allowed Physical Access}+ : {Transmission Time}+

4 CASE STUDY

To show the efﬁcacy of our approach in transform-

ing and using produced AADL models to analyze the

properties, this section presents the experimental re-

sults of analyzing the traction controlling unit of rail-

way signaling system. By using our proposed ap-

proach, we transfer and extend Arcadia metamodel,

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

Figure 5: Arcadia model of TCU system.

and design AADL using OSATE2 with the gener-

ated metamodel. once the concrete models have been

created, the scheduling property is chosen to show

analysis ability through Cheddar tool (Singhoff et al.,

2004).

4.1 Train Traction Control System

Train movement is the calculation of the speed and

distance proﬁles when a train is traveling from one

point to another according to the limitations im-

posed by the signaling system and traction equip-

ment characteristics. As the train has to follow the

track, the movement is also under the constraints of

track geometry, and speed restrictions and the calcu-

lation becomes position-dependent. The subsystem

of calculating the traction effective and speed restric-

tions is therefore critical to achieving train safe run-

ning. Nowadays, Communication Based Train Con-

trol (CBTC) system is the main method of rail tran-

sit (both urban and high-speed train) which adopts

wireless local area networks as the bidirectional train-

ground communication (Zhu et al., 2009). To increase

the capacity of rail transit lines, many information-

based and digital components have been applied for

networking, automation and system inter-connection,

including general communication technologies, sen-

sor networks, and safety-critical embedded control

system. A large number of subsystems consisting

of modern signaling systems of railways, therefore,

system integration is one of the key technologies of

signaling systems; it plays a signiﬁcant role in main-

taining the safety of the signaling system (Wang and

Wang, ).

This paper uses a subsystem which called Trac-

tion Control Unit system (TCU) from signaling sys-

tem of high-speed railway. We use this TCU system to

illustrate the model transformation from engineering

level to detailed architectural level and veriﬁed the in-

stance models. The functional modules such as calcu-

lation and synchronization will be transformed using

our approach, and then non-functional properties such

as timing correctness and resource correctness will be

veriﬁed by schedule analysis tool Cheddar (Singhoff

et al., 2004).

First, we start with component functional views

and physical view analysis by designing system mod-

els in Arcadia (shown in ﬁgure of TCU 5). The

functions of the traction control system are to col-

lect the external data by sensors such as a speed sen-

sor. The data from Balise sensors is used to determi-

nate the track block, and then it is going to seek the

speed restriction conditions by matching accurate po-

sitioning (if the track blocks are divided ﬁne enough)

and digital geometric maps data. Meanwhile, calcu-

lating speed unit received the speed data from GPS

and speed control commands from HMI (Human-

Machine Interface) periodically. GPS data provides

speed value periodically (we set a period of 30 sec-

onds in this case), and HMI data sustainedly send the

Meta-models Combination for Reusing Veriﬁcation Techniques

operation command with the period of 20 seconds till

the value changed (e.g., expected speed value), then

the calculating unit has to output an acceleration value

and export to the locomotive mechanical system. Al-

though they are periodic, the external data do not al-

ways arrive on time due to transmission delay or jitter.

Therefore, we should use a synchronizer to make sure

they are synchronized. Otherwise, the result would be

wrong with asynchronous data. Similarly, to ensure

the correctness of the command of acceleration (or

deceleration), we applied a voting mechanism which

can ensure the result is correct as much as possible.

The voter must have the synchronized signal and re-

striction condition to dedicate to output the accelera-

tion coefﬁcient request to the locomotive system. The

AADL diagram is shown in ﬁgure 6.

4.2 Model Transformation

Using the Arcadia2AADL tool, the metamodel of the

TCU system in Capella is translated into the corre-

sponding AADL metamodel with the rules and ap-

proach which describes in section 3. For instance,

on the one hand, the function class is translated into

the thread in AADL. To analyze the timing proper-

ties, several attributes also have been added such as

protocol type, deadline, execution time, period.

On the other hand, the physical part element Node

translates to the processor in this case. Differ from

simple physical Node in Arcadia; the processor ele-

ment attaches rich properties such as scheduling pro-

tocol (scheduler type), process execution time. The

allocation relationships on both physical and func-

tional parts are translated into AADL as well.

4.3 Schedule Veriﬁcation

The external data and internal process work sequen-

tially is an essential safety requirement of the system,

and each task should be scheduled properly. How-

ever, in real-world, the risk of communication quality

and rationality of scheduling must be taken into ac-

count. Therefore, the schedule veriﬁcation is a way

to evaluate system timing property. An Ada frame-

work called Cheddar which provides tools to check if

a real-time application meets its temporal constraints.

The framework is based on the real-time schedul-

ing theory and is mostly written for educational pur-

poses (Marc

e et al., 2005).

Listing 4 shows a set of 4 periodic tasks (cal, pos,

sync and setting) of TCU respectively, deﬁned by the

periods 100, 100, 40 and 30, the capacities 60, 40, 30

and 20, and the deadlines 100, 100, 40 and 30. These

tasks are scheduled with a preemptive Rate Mono-

Listing 4: Setting of scheduling properties.

1 t h r e a d i m p l e m e n t a t i o n s y n c h r o n i z e r .

imp l

2 p r o p e r t i e s

3 D i s p a t c h P r o t o c o l =>

p e r o d i c ;

4 P e r i o d => 100 ms ;

5 D e a d l i n e => 100 ms ;

6 Co m put e Exe c u t io n Tim e =>

5 0 . . 6 0 ms ;

7 end s y n c h r o n i z e r . i m p l ;

9 t h r e a d i m p l e m e n t a t i o n c a l a l c u l a t i n g

. i mpl

10 p r o p e r t i e s

11 D i s p a t c h P r o t o c o l =>

p e r o d i c ;

12 P e r i o d => 100 ms ;

13 D e a d l i n e => 100 ms ;

14 Co m put e Exe c u t io n Tim e =>

30ms . . 4 0 ms ;

15 end c a l a l c u l a t i n g . imp l ;

17 t h r e a d i m p l e m e n t a t i o n g ps . p o s i t i o n

18 p r o p e r t i e s

19 D i s p a t c h P r o t o c o l =>

p e r o d i c ;

20 P e r i o d => 40 ms ;

21 D e a d l i n e => 40 ms ;

22 Co m put e Exe c u t io n Tim e =>

30ms . . 4 0 ms ;

23 end gp s . p o s i t i o n ;

25 t h r e a d i m p l e m e n t a t i o n HMI . s e t t i n g

26 p r o p e r t i e s

27 D i s p a t c h P r o t o c o l =>

p e r o d i c ;

28 P e r i o d => 30 ms ;

29 D e a d l i n e => 30 ms ;

30 Co m put e Exe c u t io n Tim e =>

20ms . . 3 0 ms ;

31 end HMI . s e t t i n g ;

tonic scheduler (the task with the lowest period is the

task with the highest priority).

For a given task set, if a scheduling simulation dis-

played XML results in the Cheddar. One can ﬁnd the

concurrency cases or idle periods (see left of ﬁgure 7,

comprise the software part and physical device part).

People change the parameters directly and reload sim-

ulation; a feasible solution can be applied instead.

After tuning, ﬁnally, the appropriate setting has dis-

played as in right of ﬁgure 7. According to this sim-

ulation result, people can correct the properties value

in AADL, thereby ensure the correctness of system

behavior timing properties.

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

Traction Control Unit

Alarm

Tractional coeﬃcient

GeoMaps

GPS value

Setting value

Maps

Position

HMI

Locomotive

Operation Display

GPS

BaliseSensor

20ms

30ms

Voter

Acc/Dec value

status

sync

msg

coeﬃcient

Restriction

Restricted

condition

c_mrin

c_prin

c_rout

status

c_cv

c_sv

c_rv

calculating speed value

Calculating Acc/DecSynchronizer

sync

c_cc

c_scc

c_cs

Expected speed

c_sec

c_cs

Current speed

60ms

Acc/Dec value

40ms

Figure 6: AADL model of TCU system.

5 RELATED WORK

We have presented our approach to extending SysML-

based engineering framework Capella to AADL and

analyzed the relationships among Arcadia and AADL

models in different view at the metamodel level. Like-

wise, a considerable number of studies have been pro-

posed on ”language extension, modeling languages

integration and composable language components”.

This section provides a brief introduction to these

works.

The complexity of the development of CPS has

been the signiﬁcant problems which puzzle the de-

velopers. It is not only from the nature of problems

but also from the develop languages. Elaasar et al.

has discussed (Elaasar et al., 2018) about the limit of

UML which exacerbate the complexity of develop-

ment, and proposed an approach to reduce the com-

plexity of UML tools by implementing and adapting

the ISO 42010 standard on architecture description.

Efﬁcient integration of different heterogeneous

modeling languages is essential. Modeling language

integration is onerous and requires in-depth concep-

tual and technical knowledge and effort. Tradi-

tional modeling language integration approaches re-

quire language engineers to compose monolithic lan-

guage aggregates for a speciﬁc task or project. Adapt-

ing these aggregates to different contexts requires vast

effort and makes these hardly reusable. Arne Haber

et al (Haber et al., 2015) presented a method for the

engineering of grammar-based language components

that can be independently developed, are syntactically

composable, and ultimately reusable.

In despite of existing a lot of studies on the com-

bining SysML and AADL (De Saqui-Sannes and

Hugues, 2012) or on the extending SysML with

AADL (Behjati et al., 2011). Differ from the above

studies, our approach dedicates to smoothly combine

engineering platform Capella/Arcadia, AADL and its

annex, and our approach can be easily applied to other

languages through ﬁne-tuning. In practice, one could

design global system at a high level and then seam-

lessly reﬁne the models within AADL and its an-

nex for further analysis such as scheduling. In other

words, our approach can properly extend Arcadia’s

design and analysis capabilities to AADL, while es-

sentially keeping its independence.

An approach for translating UML/MARTE de-

tailed design into AADL design has proposed by Brun

et al. (Brun et al., 2008). Their work focuses on the

transformation of the thread execution and commu-

nication semantics and does not cover the transfor-

mation of the embedded system component, such as

device parts. Similarly, in (Turki et al., 2010), Turki

Meta-models Combination for Reusing Veriﬁcation Techniques

(a) Schedule 1 with idel time (b) Schedule 2 with compact time

Figure 7: Simulation results of tasks schedule.

et al. proposed a methodology for mapping MARTE

model elements to AADL component. They focus on

the issues related to modeling architecture, and the

syntactic differences between AADL and MARTE are

well handled by the transformation rules provided by

ATL tool, yet they did not consider issues related to

the mapping of MARTE properties to AADL prop-

erty. In (Ouni et al., 2016), Ouni et al. presented

an approach for transformation of Capella to AADL

models target to cover the various levels of abstrac-

tion, they take into account the system behavior and

the hardware/software mapping. However, the for-

mal deﬁnition and rigorous syntactic of transforma-

tion rules are missed.

Behjati et al. describe how they combined SysML

and AADL in (Behjati et al., 2011) and provided

a standard modeling language (in the form of the

ExSAM proﬁle) for specifying embedded systems at

different abstraction levels. De Saqui-Sannes et al.

(De Saqui-Sannes and Hugues, 2012) presented an

MBE with TTool and AADL at the software level

and demonstrated with the ﬂight management system.

Both of their works do not provide the description in

a formal way.

In industrial domain applications, Suri et al (Suri

et al., 2017) proposed a model-based approach for

complex systems development by separating the be-

havior model and execution logic of the system.

Moreover, they used UML based languages to model

system behavior and connected the behavior models

to external physical API of CPS. It focuses on provid-

ing a solution for the modularity and interoperability

issues related to Industry 4.0 from a systems integra-

tion viewpoint.

S. Apel et al (Apel et al., 2016) also studied on

different model driven methods for heterogenic sys-

tems for Electric vehicle. They have tried to evaluate

how model-driven engineering (MDE) combined with

generative frameworks can support the transfer from

platform independent models to deployable solutions

within the logistical domain.

The work of Kurtev (Kurtev et al., 2017) is used

in the x-ray machine, it provided a family of domain-

speciﬁc languages that integrate existing techniques

from formal behavioral and time modeling. F. Scip-

pacercola (Scippacercola et al., 2015) have explored

the application of model-driven engineering on the in-

terlocking system (a subsystem of signaling system

of the railway). They discussed how to reduce efforts

and costs for development, veriﬁcation, and valida-

tion in a critical system.

The modeling language scientists have proposed

some speciﬁc methods to weave the models as well

as metamodels formally such as (Jezequel, 2008),

Degueule has proposed Melange, a language dedi-

cated to merging languages (Degueule et al., 2015),

and similar works like (Ramos et al., 2007). How-

ever, the structural properties are not supported.

Compared with current studies, the approach pro-

posed in this paper has the following features:

1. A proper subset of AADL has been chosen as the

transformation target including functional soft-

ware composition, execution platform. We use

it to describe continuous behaviors of Cyber-

Physical System.

2. All of the transformations is considered at meta-

model level, and then a synthesized metamodel

can be used to create concrete AADL models for

further analysis.

3. Transformation rules are formally deﬁned, and

then it is readable by human and easier to verify

the correctness of transformation.

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development

6 CONCLUSIONS AND FUTURE

WORK

This paper describes a collaborative design approach

between system engineering methodology Arcadia

(based on SysML) and architectural design language

AADL using transformation at metamodel level. We

ﬁrst present our approach and implementation proce-

dures using ATL. Then, we give a formal description

of the key modeling elements of Arcadia and AADL,

respectively. Then translation rules from these Arca-

dia metamodels to AADL are formally deﬁned. Fi-

nally, a case study of train traction controlling system

is used to demonstrate the transformation from en-

gineering concerned design into an architectural re-

ﬁnement design which can be further analyzed by

scheduling properties. There are some drawbacks to

use our approach, i) people has to spent times to learn

the syntax of rules, and the writing of rule is error-

prone. ii) the traceback function is not yet imple-

mented automatically.

In our future work, we will try to build a graphic

interface to write rules, and the writing errors of rule

can be detected. We also have to implement the

traceback of simulation results which is sketched in

our workﬂow with the arrow in dotted line. The re-

sults must be used automatically by upstream model-

ing framework. To this end, we have to extract the

critical information from cheddar outputting ﬁle and

transform to an appended ﬁle of modeling tool which

can be recognized by the tool and hint user in some-

how. Secondly, we will study the translation rules

for more elements of Arcadia and also for compre-

hensive SysML elements, even for others UML-like

proﬁles such as MARTE. At the same time, we will

continue to explore the AADL and its annex to sup-

port more analysis and formal veriﬁcation of system

design. Besides, the safety-critical systems have be-

come a trend in industrial ﬁles. We will study the

extension of AADL with veriﬁcation of safety prop-

erties with transformation methodology.

REFERENCES

Apel, S., Mauch, M., and Schau, V. (2016). Model-

driven engineering tool comparison for architectures

within heterogenic systems for electric vehicle. In

2016 4th International Conference on Model-Driven

Engineering and Software Development (MODEL-

SWARD), pages 671–676.

Behjati, R., Yue, T., Nejati, S., Briand, L., and Selic,

B. (2011). Extending SysML with AADL concepts

for comprehensive system architecture modeling. In

European Conference on Modelling Foundations and

Applications, pages 236–252. Springer.

Brun, M., Vergnaud, T., Faugere, M., and Delatour, J.

(2008). From UML to AADL: an Explicit Execution

Semantics Modelling with MARTE. In ERTS 2008.

De Saqui-Sannes, P. and Hugues, J. (2012). Combining

SysML and AADL for the design, validation and im-

plementation of critical systems. In ERTS2 2012.

Degueule, T., Combemale, B., Blouin, A., Barais, O., and

Jezequel, J.-M. (2015). Melange: A meta-language

for modular and reusable development of dsls. In

Conf on Software Language Engineering, pages 25–

36. ACM.

Elaasar, M., Noyrit, F., Badreddin, O., and G

erard, S.

(2018). Reducing uml modeling tool complexity with

architectural contexts and viewpoints. In MODEL-

SWARD, pages 129–138.

Haber, A., Look, M., Perez, A. N., Nazari, P. M. S., Rumpe,

B., V

olkel, S., and Wortmann, A. (2015). Integra-

tion of heterogeneous modeling languages via ex-

tensible and composable language components. In

2015 3rd International Conference on Model-Driven

Engineering and Software Development (MODEL-

SWARD), pages 19–31.

Jezequel, J.-M. (2008). Model driven design and aspect

weaving. Software and Systems Modeling, 7(2):209–

218.

Jouault, F., Allilaire, F., B

ezivin, J., and Kurtev, I. (2008).

ATL: A model transformation tool. Science of Com-

puter Programming, 72(1-2):31–39.

Jouault, F., Allilaire, F., B

ezivin, J., Kurtev, I., and Val-

duriez, P. (2006). a QVT-like transformation lan-

guage. ACM, New York, USA.

Kurtev, I., Schuts, M., Hooman, J., and Swagerman, D.-J.

(2017). Integrating interface modeling and analysis in

an industrial setting. In MODELSWARD, pages 345–

352.

Marc

e, L., Singhoff, F., Legrand, J., and Nana, L. (2005).

Scheduling and Memory Requirements Analysis with

AADL. In SIGAda, pages 1–10. ACM.

Ouni, B., Gauﬁllet, P., Jenn, E., and Hugues, J. (2016).

Model Driven Engineering with Capella and AADL.

Ramos, R., Barais, O., and Jezequel, J.-M. (2007). Match-

ing model-snippets. In Conf on Model Driven En-

gineering Languages and Systems, pages 121–135.

Springer.

Scippacercola, F., Pietrantuono, R., Russo, S., and Zentai,

A. (2015). Model-driven engineering of a railway in-

terlocking system. In 2015 3rd International Confer-

ence on Model-Driven Engineering and Software De-

velopment (MODELSWARD), pages 509–519.

Singhoff, F., Legrand, J., Nana, L., and Marc

e, L. (2004).

Cheddar - a ﬂexible real time scheduling framework.

SIGAda, pages 1–8.

Suri, K., Cuccuru, A., Cadavid, J., G

erard, S., Gaaloul,

W., and Tata, S. (2017). Model-based development

of modular complex systems for accomplishing sys-

tem integration for industry 4.0. In MODELSWARD,

pages 487–495.

Turki, S., Senn, E., and Blouin, D. (2010). Mapping the

MARTE UML proﬁle to AADL. In ACES-MB, pages

11–20.

Meta-models Combination for Reusing Veriﬁcation Techniques

Wang, J. and Wang, J. A New Early Warning Method of

Train Tracking Interval Based on CTC. IEEE Trans-

actions on Intelligent Transportation Systems, pages

1–7.

Zhu, L., Zhang, Y., Ning, B., and Jiang, H. (2009). Train-

ground communication in CBTC based on 802.11 b:

Design and performance research. In CMC’09, pages

368–372. IEEE.

MODELSWARD 2019 - 7th International Conference on Model-Driven Engineering and Software Development