Meta-models Combination for Reusing Verification Techniques
*
Hui Zhao
1
, Ludovic Apvrille
2
and Fr
´
ed
´
eric Mallet
1
1
Universit
´
e C
ˆ
ote d’Azur, I3S, INRIA, France
2
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-specific 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 specific 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-fits-
all. Therefore developers have to rely on domain-
specific 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 efficiently combine already existing
languages. The goal is not only to combine the dif-
ferent languages seamlessly but also to benefit from
the advantages of each language. Two solutions are
possible. (i) A first 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 financially Supported by the CLAR-
ITY project and by a UCN@Sophia Labex scholarship.
gigantic framework, which would be difficult 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 define how to re-
late two (sub-)metamodels. Then, once two models
m
1
, m
2
has been performed in the two languages, m
2
can automatically be augmented with some of the in-
formation of m
1
in order to perform verification on en-
riched models (e.g., scheduling, timing, safety), and
then to backtrace the verification results to m
1
.
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
1
, respectively. The paper is orga-
nized as follows. We present our contribution with
first our workflow and then with the formal definition
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-
1
http://osate.org/index.html
Zhao, H., Apvrille, L. and Mallet, F.
Meta-models Combination for Reusing Verification 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
Copyright
c
2019 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
37
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 prefix (e.g., MM.Arcadia.function)
for pithiness.
2 APPROACH
2.1 Workflow
The workflow of our approach is shown in figure 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 defined in
a Transformation Rule Library or TRL for short — an
establish a relationship between Arcadia and AADL
metamodels. For instance, Arcadia and AADL define
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 figure. 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 flaws, conflicts
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 defined (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:
P
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
38
Import
Transformation Rule
LIB
Import
Arcadia Models
Functional
Design/Analysis
M2
M1
Temporary AADL Models
Architectural + Timing
Design/Analysis
Simulation
schedule 1
schedule 2
Simulate
Traceback
1
2
3
4
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 Workflow.
2.3 Arcadia2AADL Model
Transformation
Based on the defined 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-specific modeling language) in ecore format
Meta-models Combination for Reusing Verification Techniques
39
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
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 definition di-
agrams (BDDs) and internal block diagrams (IBDs)
are assigned to different abstract and refined layers,
respectively. The definition 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 definition 3.1.1, we present
a metamodel of an instance of logical components.
Definition 3.1.1. (Logical Component) A logical
component (LC) is 5 tuples,
LC =< C
omp
, F
un
, P
ort
, Ex
f un
, M
c f
>
where, C
omp
= {
S
F
un
} is a logical component con-
tainer which contains a set of functional elements. F
un
is a finite set of functional block include their name
and id attributes. P
ort
is a finite set of functional
ports including directions and allocation attributes.
Ex
f un
P
ort
× P
ort
denotes a finite set of functional
exchange (connection) between two functional ports,
it must be pair, one is source, another is target. M
c f
: ΣF
un
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 figure 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
un
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
un
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
40
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, predefined 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.
Definition 3.1.2. (Software Composition) A SC is a
4-tuples:
S C =< Type, Port,Connection, Annex >
where Type specifies 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 flow in uni-
or bi-directional. Annex is defined for the refinement
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 define 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 specific 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
definition 3.1.3 gives a metamodel of Hybrid Annex
which does not exist in SysML-based environment.
Definition 3.1.3. (Hybrid Annex) A Hybrid Annex is
a 8-tuples:
H A =< Ass, Ivar,Var
hd
,Cons
hd
, P
roc
,ChP, Itr, B
itr
>
where Ass is a finite 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 define a condition of operation that
must be true during the lifetime. Var
hd
is a finite set
of discrete and continuous variables. Cons
hd
is a finite
set of constants which must be initiated at declaration.
P
roc
is a finite set of processes that are used to spec-
ify continuous behaviors of AADL components. ChP
is a finite set of channels and ports for synchronizing
processes. Itr is a finite 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
un
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 specified in compo-
nents and their interactions.
Definition 3.2.1. (Execution Platform) A EP compo-
nent is defined as a 3-tuples:
EP =< EC, BA,C
onn
>
where,EC defines the execution component such as
processor, memory, bus and device. BA defines the
BusAccess which is interactive approach between bus
Meta-models Combination for Reusing Verification Techniques
41
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
un
) 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.
C
onn
EC ×EC denotes a finite 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.
Definition 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
(N
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}+
or
{Allowed Physical Access}+ : {Transmission Time}+
4 CASE STUDY
To show the efficacy 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
42
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 profiles 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 significant 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 verified 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
verified 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 figure 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 fine 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 Verification Techniques
43
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 coefficient request to the locomotive system. The
AADL diagram is shown in figure 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 Verification
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 verification 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, defined 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 ;
8
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 ;
16
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 ;
24
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 find the
concurrency cases or idle periods (see left of figure 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, finally, the appropriate setting has dis-
played as in right of figure 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
44
Traction Control Unit
Alarm
Tractional coecient
GeoMaps
GPS value
Setting value
Maps
Position
HMI
Locomotive
Operation Display
GPS
BaliseSensor
20ms
30ms
Voter
Voter
Acc/Dec value
status
sync
msg
coecient
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 significant 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.
Efficient 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 specific 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 fine-tuning. In practice, one could
design global system at a high level and then seam-
lessly refine 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 Verification Techniques
45
(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 definition 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 profile) 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 flight 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-
specific 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, verification, and valida-
tion in a critical system.
The modeling language scientists have proposed
some specific 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 defined, 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
46
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
first 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 defined. 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-
finement 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 workflow 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 file and
transform to an appended file 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
profiles such as MARTE. At the same time, we will
continue to explore the AADL and its annex to sup-
port more analysis and formal verification of system
design. Besides, the safety-critical systems have be-
come a trend in industrial files. We will study the
extension of AADL with verification 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., Gaufillet, 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 flexible 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 profile to AADL. In ACES-MB, pages
11–20.
Meta-models Combination for Reusing Verification Techniques
47
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
48