Direct Model-checking of SysML Models

Alessandro Tempia Calvino

1,2

and Ludovic Apvrille

LTCI, Telecom Paris, Institut Polytechnique de Paris, Sophia-Antipolis, France

Ecole Polytechnique Federale de Lausanne, Lausanne, Switzerland

Keywords:

SysML, Model-checking, Formal Veriﬁcation, Embedded Systems.

Abstract:

Model-checking intends to verify whether a property is satisﬁed by a model, or not. Model-checking of

high-level models, e.g. SysML models, usually ﬁrst requires a model transformation to a low level formal

speciﬁcation. The present papers proposes a new model-checker that can be applied (almost) directly to the

SysML model. The paper ﬁrst explains how this model-checker works. Then, we explain how it can efﬁciently

check CTL-like properties. Finally, the paper discusses the performance of this model-checker integrated in

the TTool framework.

1 INTRODUCTION

Tools for designing critical systems with

UML/SysML usually offer a way to either sim-

ulate the model or to perform veriﬁcation from

the models. Simulation helps understanding and

debugging the model, while formal veriﬁcation offers

strong guarantees on the system. Typical properties

that are veriﬁed are the absence of deadlocks, the non

reachability of error states, and the reachability or

liveness of all expected model elements.

UML/SysML tools usually rely on external veri-

ﬁcation tools (e.g. model-checkers) to perform for-

mal proofs. Commonly, the model to verify is ﬁrst

translated to an intermediate formal speciﬁcation (e.g.

in UPPAAL

) before being checked against proper-

ties, also expressed in a formal language (e.g. CTL).

Finally, results are traced back to the model. The

transformation to a formal speciﬁcation impacts the

performance, raises semantic issues, and makes the

backward transformation less obvious. For instance,

UPPAAL supports only 16-bit integer, so if the origi-

nal model relies on 32-bit integer, there is a seman-

tic gap between the original model and the formal

speciﬁcation. Similarly, communication semantics of

the model (inﬁnite/ﬁnite FIFO, synchronization, etc.)

sometimes force to ignore some operators or to trans-

late them in an approximate way.

To tackle this issue, we introduce in this paper

a new model-checker that can directly work from a

SysML model. We assume the structure of the sys-

http://www.uppaal.org/

tem is described with block deﬁnition diagrams and

internal block diagrams. The behavior of each block

is described with SysML state machines. Our model-

checker is SysML-aware in the sense that it directly

works with blocks, ports of blocks, connectors be-

tween ports, states, guards, actions, etc. The pa-

per shows how the model-checker works, and how it

can prove CTL-like properties (reachability, liveness,

leads to, deadlock freeness) from a SysML model,

and outputs counterexamples when a property is not

satisﬁed. We also show that our model-checker com-

pares to UPPAAL in terms of performance, while

avoiding model transformations.

Section 2 presents similar contributions. Sec-

tion 3 introduces the SysML proﬁle (AVATAR) at the

root of the present work. Section 4 introduces the

model-checker and explains its main features. Then,

section 5 shows how properties can be described in

SysML and evaluated with the model-checker. Sec-

tion 6 presents the main implementation tricks to en-

hance performance, and compares our model-checker

to UPPAAL. Section 7 concludes the paper.

2 RELATED WORK

2.1 Systems Analysis

Systems analysis can be performed using different

techniques. The latter can be classiﬁed into dif-

ferent categories, including emulation (Thiele et al.,

216

Calvino, A. and Apvrille, L.

Direct Model-checking of SysML Models.

DOI: 10.5220/0010256302160223

In Proceedings of the 9th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2021), pages 216-223

ISBN: 978-989-758-487-9

2007), implementation (Thiele et al., 2007), simula-

tion (Stemmer et al., 2019) (Thiele et al., 2007) or hy-

brid analysis which combines formal and simulation

approaches (Stemmer et al., 2019).

Simulation and formal approaches are the most

used ones in the domain of performance estimation of

embedded systems (Thiele et al., 2007) (Viehl et al.,

2006). Simulation tools and industrial frameworks

e.g. Koski (Kangas et al., 2006) can only consider

a limited set of execution traces and corner cases are

usually unknown (Thiele et al., 2007). Formal ap-

proaches like timed automata are usually limited in

scope to the model under analysis where sharing of re-

sources, leading to complex interactions among com-

ponents, is difﬁcult to take into consideration.

To overcome the limitations encountered when us-

ing either methods, (Thiele et al., 2007) and (Viehl

et al., 2006) combined simulation and formal ap-

proaches to analyze system performance.

2.2 Formal Veriﬁcation of UML/SysML

Models

Transforming UML/SysML models to a formal spec-

iﬁcation is a very popular (and old) way to ensure

the (formal) veriﬁcation of these models, as ﬁrst dis-

cussed in (Bruel, 1998), and more recently in (Gab-

meyer, 2019) where they have proposed a taxonomy

of formal veriﬁcation techniques for software models

with a focus on recent papers addressing simulation

and formal veriﬁcation in the context of SysML.

Delatour et al. were among the ﬁrst to pro-

pose a formal way to verify UML models with Petri

Nets (Delatour and Paludetto, 1998). Laleau et al.

discussed in (Laleau and Mammar, 2000) the use of

annotations in UML so as to generate a B speciﬁ-

cation. Also, in (Sch

afer et al., 2001), Sch

afer et

al. proposed a translator from UML state machines

to UPPAAL. Time was also addressed in (Apvrille

et al., 2004) with a transformation from UML to RT-

LOTOS. The model-based environment TimeSquare

(DeAntoni and Mallet, 2012), supporting the Clock

Constraint Speciﬁcation Language (CCSL), provides

facilities for (formal) performance analysis, in partic-

ular for the analysis of execution traces. In (Ouchani

et al., 2013), Ouchani et al. presented a formal veri-

ﬁcation framework for checking SysML activity di-

agrams. The latter are mapped into the input lan-

guage of the probabilistic model checker PRISM. A

calculus dedicated to activity diagrams is proposed

and the mapping to PRISM is formalized. The ap-

proach is applied to an online shopping system and to

real time streaming protocols. (Ando et al., 2013) pro-

posed to formalize SysML state machines with CSP#.

(Wang et al., 2019) et al. explored the transforma-

tion of SysML models to NuSMV for safety analysis.

They applied their approach to a ﬂap control system.

Yet, they did not propose any backtracing way. In

the present paper, model checking is applied to block

and state machine diagrams: block diagrams capture

the architecture of the system while state machine di-

agrams model the inner behavior of blocks.

3 CONTEXT: TTOOL, AVATAR

3.1 TTool

TTool is a free and open source framework targeting

the design of embedded systems with UML/SysML.

It supports different methodological stages, including

system analysis (requirements, fault and attack trees,

use cases, sequence diagrams, . . . ), system hardware

/ software partitioning with the DIPLODOCUS pro-

ﬁle (Apvrille et al., 2006), and embedded software de-

sign with the AVATAR SysML environment (Apvrille

et al., 2020). SysML-Sec (Apvrille and Li, 2019)

is also supported by TTool. SysML-Sec gathers

together all methodological stages and adds secu-

rity features (operators, formal proof) to diagrams.

The model-checker presented in this paper concerns

AVATAR models. Yet, we intend to extend it to the

DIPLODOCUS environment.

3.2 AVATAR

In this paper, by AVATAR, we mean the design part

of AVATAR. A design is built upon 3 diagrams:

• A block deﬁnition diagram.

• A internal block diagram. To make the structure

of the design easier to visualize, block deﬁnition

and internal block diagrams can be showed in the

same view.

• State machine diagrams are used to give a behav-

ior to each block.

3.2.1 Extensions to SyML

AVATAR extends standard SysML as follows:

• Block diagrams support synchronous and asyn-

chronous communications with different ﬂavors

(lossy, non lossy, etc.).

• State machines are extended with an after(min,

max) clause, with timer operators (set, expire, re-

set), and with a “x = random(min, max)” operator.

Direct Model-checking of SysML Models

217

block

EReaderController

- currentDocument : Document;

- currentPage : int;

- page : Page;

~ out displayPage(Page page)

~ in openDocument(Document doc)

~ in flipNextPage()

~ in flipPreviousPage()

~ in goToPage(int index)

~ in home()

~ out loadPage(Document doc, int pageid)

~ in getPage(Page aPage)

block

DisplayDriver

- page : Page;

- data : int;

- printPage(int data)

~ in displayPage(Page page)

block

UserModel

- doc1 : Document;

- doc2 : Document;

- index : int;

block

PageLoader

- doc : Document;

- page : Page;

- pageid : int;

- minPageLoadingTime = 10 : int;

- maxPageLoadingTime = 34 : int;

- x : int;

<<datatype>>

Document

- id : int;

- nbOfPages : int;

<<datatype>>

Page

- data : int;

<<datatype>>

MemoryForPages

- index1 : int;

- data1 : int;

- index2 : int;

- data2 : int;

- index3 : int;

- data3 : int;

Safety Pragmas

T UserModel.FlipPage --> DisplayDriver.NewPage

F A[] PageLoader.x<12

T A[] PageLoader.x<13

T E[] PageLoader.x==12||PageLoader.x==0

T A<> EReaderController.currentPage==0&&DisplayDriver.NewPage

F E<> PageLoader.x == 13

Figure 1: Block diagram with safety CTL properties.

Figure 1 shows a block diagram and the safety CTL

properties to be veriﬁed on the model. The state ma-

chine of block eReaderController is shown in Figure

3.2.2 fUML, PSSM and SysML v2

fUML

, lastest version 1.4, is an OMG standard

deﬁning a formal semantics for a subset of UML. Un-

fortunately, this subset does not consider state ma-

chines (but rather activities), so we could not rely on

the fUML standard. Also, types such as String or Real

are not handled by our model-checker. Once they

have been released, the Precise Semantics of UML

State Machines standard

or SysML v2 may offer new

perspectives to the work described in this paper.

4 MODEL-CHECKER

The main contribution of this paper is the develop-

ment of an open-source model-checker that works al-

most directly on SysML models without a low-level

transformation. Our principal goal is to obtain a ﬂexi-

ble and easily upgradable veriﬁcation engine that can

be used efﬁciently to analyze and verify the correct

behavior of a model. Properties are proven with an

on-the-ﬂy method while exploring the state space.

The heart of the model-checker is the construction

of the reachability graph of a model. A reachabil-

ity graph is a directed cyclic graph where each node

represents a possible state of the model. A node de-

pends on the current pointed states, one for each state

machine, the blocks attribute values, and the time

progress. Each edge (a,b) represents a direct reacha-

bility connection from node a to node b. Any subtree

starting from a node a shows the states which are di-

rectly reachable from a. Moreover, analyzing one or

https://www.omg/org/spec/fUML

https://www.omg.org/spec/PSSM

multiple paths that may connect two nodes, it is pos-

sible to ﬁnd the sequence of actions that, if executed,

connect the two. The graph is created by combining

the state machines belonging to different blocks in the

SysML model. In this paper we refer to a reachabil-

ity graph node also using the term “r-state”. In this

context, it has to be interpreted as a state of the reach-

ability graph and not a local state of a state machine.

The reachability graph is constructed using a for-

ward traversal BFS (Breadth-First Search) or DFS

(Depth-First Search) strategy. Algorithm 1 shows a

simpliﬁed pseudo-code of the main loop. The algo-

rithm starts from the given initial states (one for each

state machine) creating a r-state S

. A map STATES

keeps track of the visited r-states. PENDING works

as a queue (breadth priority) or a stack (depth prior-

ity). Then, every cycle, it extracts a r-state S from the

pending queue and it looks for all the available tran-

sitions which are currently executable from S. Each

of them is executed and leads to a new r-state. If a

new r-state is equal to another already visited, it is re-

dundant and only a new link connection is created. If,

instead, it is not equal to any other, it is also added to

the pending queue in order to be later explored. This

procedure cannot be directly used for model-checking

but it can be adapted as it will be explained in the next

section.

Algorithm 1: Reachability graph algorithm.

1: S

= {s

,..., s

}  Initial r-state

2: STATES={S

}, PENDING={S

}

3: while PENDING6= {} do

4: Extract a state S from the PENDING queue

5: T = set of executable transitions from r-state S

6: for each transition t

in T do

7: Execute t

obtaining a r-state P

8: if P /∈ STATES then  New r-state

9: Add P to STATES

10: Append P to PENDING

11: end if

12: Add a new edge S → P

13: end for

14: end while

MODELSWARD 2021 - 9th International Conference on Model-Driven Engineering and Software Development

218

Each r-state in the reachability graph is uniquely

represented by a tuple called r-state context

,··· ,B

) where each B

refers to a particular

block. The behavior of a block is represented by a

state machine. B

is the state machine context which

is also a tuple (p,clock

min

,clock

max

,··· ,a

)

where:

• p is the current state pointer

• clock

min

is the minimum clock value

• clock

max

is the maximum clock value

• a

is the value of j-th attribute of the block

From the context deﬁnition, a r-state in the reacha-

bility graph contains a pointer for each state machine

to keep track of the current state in each of them. It

saves also the internal minimum and maximum clocks

which are used to select the executable transitions in

time dependency order. Two r-states are considered

equivalent if their contexts are equal.

Several important information must to be consid-

ered when fetching and executing new transitions.

Checking for acceptable transitions involves check-

ing conditions on attributes (guards), on time (e.g.

after(min, max) clause) and on signals (signal send-

ing/receiving).

State machines in different blocks have communi-

cation channels so that different blocks can exchange

information or synchronize their execution. For sig-

nal communications, our model-checker transforms

asynchronous channels into synchronous ones adding

channel queues as a bridge between connected blocks.

Transitions with signal communications are executed

only when at least a sender and a receiver are active

on the same channel. A channel queue acts as either a

sender or a receiver depending on the type of request.

Transitions between states can have conditions

and actions. Our model-checker solves guards (i.e.

boolean conditions on attributes) to activate a transi-

tion and actions to modify attributes values. This is

achieved by temporarily saving the attributes value of

each block in the context of a r-state.

SysML models are usually also timed state ma-

chines. In fact, transitions may have a time dura-

tion and a deﬁned uncertainty (i.e. after(min, max)).

Thus, each transition is associated with a time in-

terval (t

min

max

) where t

min

is the shortest execution

time and t

max

is the longest one. The execution may

happen any time inside that interval

. The model-

checker must keep track of the time to select exe-

cutable transitions. Block clocks are used for this

A transition may occur also after max clock value has

elapsed in case the action of the transition is not possible,

e.g. waiting for a signal that is not yet available.

purpose. Time is not saved in absolute value, as it

would be quite inefﬁcient, but in relative value with

respect to the block time progress. Moreover, sav-

ing time in absolute value would not allow to detect

easily when some states, at different time periods are

actually equivalent. By saving the clock in a rela-

tive value, equivalent states encountered at a different

time period have the same clock values. Transitions

in different blocks must be converted into the same

timeline. This is achieved by subtracting the block

clock interval from the transitions in the respective

block. The executable transitions are extracted do-

ing the intersection with the ﬁrst smallest time domain

(min

∀t∈T

min

,min

∀t∈T

max

). For instance, if we are

at clock (0, 0) and we have three available transitions

a : (0,3), b : (1,2), c : (3,5), the ﬁrst smallest time

domain would be (0,2). Thus, the two possible tran-

sitions that can be executed are a with the new inter-

val (0, 2) and b : (1,2). Transition c could never be

executed since it lies outside the maximum execution

time limit of other transitions. The same thing hap-

pens for a at time 3.

Finally, the following operations are applied to

transitions in order to extract the executable ones:

• for a transition acting on a channel, check for an

active sender or receiver

• solve transitions guards

• update transitions clock w.r.t. the local clock

• select the executable transitions in the ﬁrst small-

est clock interval (i.e. the time domain).

The execution of a transition creates a new r-state

with an updated context. In the block of the just exe-

cuted transition, the state pointer is updated with the

new one and the internal clock is reset. For the other

blocks, the internal clock is incremented by the tran-

sition interval (clock

min

,clock

max

)

The reachability problem is covered on-the-ﬂy

with the construction of the reachability graph. In

fact, all the reachable states and properties are en-

countered during its creation. If at the graph creation,

or at a given depth bound, a state is not traversed, or a

property is not satisﬁed, their reachability is false.

5 PROPERTIES

The reachability check, presented at the end of the

previous section, allows only a basic veriﬁcation of

a model. Several other checks like liveness, safety

properties, deadlocks, livelocks, etc. are necessary to

max

considers the maximum time limited at

min

∀t∈T

max

Direct Model-checking of SysML Models

219

have a clear idea if the behavior of the SysML model

is as expected. The reachability algorithm shown in

the previous section can be used as a basis for generic

formal veriﬁcation on SysML models. Our model-

checker framework can also prove CTL formulae and

the general checks as: liveness and safety properties,

reachability, and deadlock freedom.

Most of these properties are way more challeng-

ing to prove than reachability. Usually, the standard

approach consists in detecting execution cycles that

present speciﬁc conditions. Loops are usually found

using the strong connected components (SCC) algo-

rithm. In our case, loops can be found while con-

structing the reachability graph. Every time a new

r-state P in the reachability graph is equivalent to

another S that has been already found, a depth ﬁrst

search from S to f ather(P)

is used to ﬁnd if a path

that connects them exists. If it exists, a cycle is de-

tected. This is true by construction of the reachabil-

ity graph since state P is equivalent to S and reach-

able from it. Some properties may require the model-

checker to execute to completion or until a deadlock

is detected.

Deadlocks can be easily detected while building

the reachability graph. Every time a reachable r-state

has not enabled transitions, that r-state is a deadlock.

The supported CTL formulae are deﬁned accord-

ingly to the UPPAAL standard syntax:

• A[] p: property p is always true for all r-states of

each path (other notation AG p)

• A<> p: for all the paths, property p will eventu-

ally be true for some r-states (other common no-

tation AF p)

• E[] p: there exists at least one path for which

property p is always true for each r-state in that

path (other common notation EG p)

• E<> p: there exists a path in which property p

will eventually be true for some r-states of that

path (other common notation EF p)

• p → q: for all the paths and r-states on that

paths, if p becomes true then for all the paths and

some r-states on these paths, q will eventually be-

come true (other common notation AG(p ⇒ AFq)

called leadsTo)

with p and q boolean properties. A property can test

states of state machines, variables or a mix of them

using standard arithmetic and boolean operators.

Figure 2 shows how CTL formulae are expressed

in TTool and their result after the veriﬁcation has run.

Before a property, an expected value (T for True, or F

f ather(P) is the father from which P has just been dis-

covered

for false) may be expressed in order to show the veri-

ﬁcation result accordingly. The model corresponds to

the one shown in Figure 1. A green tick is displayed

when the property is satisﬁed, while a red cross is dis-

played in the opposite case. If the answer is unknown,

in case of a timeout in the execution or if the veriﬁ-

cation is terminated by the user, a question mark is

displayed.

Safety Pragmas

T UserModel.FlipPage --> DisplayDriver.NewPage

F A[] PageLoader.x<12

T A[] PageLoader.x<13

T E[] PageLoader.x==12||PageLoader.x==0

T A<> EReaderController.currentPage==0&&DisplayDriver.NewPage

F E<> PageLoader.x == 13

Figure 2: CTL properties after veriﬁcation.

Figure 3 shows how reachability and liveness prop-

erties are backtracked and displayed in the state ma-

chines for each state element, using green or red ”R”

and ”L” attached to states.

Here we show some examples of possible CTL

properties on SysML models and their meaning:

• A<> Controller.Received: tests if the Controller

block on all the paths will eventually reach a ”Re-

ceived” state, e.g. once an information from a sen-

sor has been received.

• A[] SpeedSensor.sampledSpeed <= SpeedCon-

troller.speedLimit + SpeedController.tolerance:

checks that the measured speed of a vehicle never

exceeds the deﬁned limit

• WatchDog.Timer == 0 → System.Restart: checks

that every time a watchdog timer reaches zero, the

system goes to the Restart state

Given a test on property p, we deﬁne a true (false)

loop as a loop with condition on property p satisﬁed

(unsatisﬁed). In the same manner, we deﬁne also a

true (false) deadlock as a deadlock where the con-

dition on property p is satisﬁed (unsatisﬁed). These

properties are now described in the model-checking

context that has been presented using a combination

of reachability and cycles detection:

• A[] p: if during the reachability graph creation a

new r-state has p false, then the property is false

(reachability of ¬p)

• A<> p: if p is true for a r-state, stop the search

on that path as it is already valid. If a false loop or

a false deadlock are found, the property is false.

If no false loops or false deadlocks are found, the

property is true.

• E[] p: if p is false for a r-state, stop the search on

that path as it is invalid. If a true loop or a true

deadlock are encountered, the property is true. If

MODELSWARD 2021 - 9th International Conference on Model-Driven Engineering and Software Development

220

WaitingForDocument

openDocument(currentDocument)

home()

openDocument(currentDocument)

PageLoadingManagement

loadPage(currentDocument, currentPage)

WaitingForPageBeingLoadedOrUserEvent

flipPreviousPage()

goToPage(currentPage)

PageLoadingManagement

flipNextPage()

getPage(page)

displayPage(page)

currentPage = currentDocument.currentPage

[currentPage < currentDocument.nbOfPages ]

currentDocument.currentPage = currentDocument.currentPage + 1

[ not(currentPage == 0) ]

currentDocument.currentPage = currentDocument.currentPage + 1

[(currentPage > 0) and (currentPage < currentDocument.nbOfPages) ]

currentDocument.currentPage = currentPage

[ else ]

Figure 3: State machine with reachability and liveness information for each state element.

no true loops or false deadlocks are found, the

property is false.

• E<> p: if during the reachability graph creation,

p is true in a new r-state, then the property is true.

• p → q: every time p is reached, save the r-state

context. Then, for each saved r-state, start a live-

ness check A<> q with that r-state as a starting

state

. If the liveness of q is true for all the saved

r-states or p is always false, the property is true,

else it is false.

Thanks to the integration of a cycle detection algo-

rithm and an expression solver to test the proper-

ties while building the reachability graph, our model-

checker can effectively prove the correctness of a

model allowing a breadth set of tests that are gener-

ally used in this ﬁeld.

When proving properties, it is a good practice to

provide a report trace which is reported as a list of

r-states and actions, extracted as a sub-path from the

reachability graph. Our model-checker can generate

such a trace, but techniques to do so are not explained

in this paper.

6 IMPLEMENTATION AND

EVALUATION

The main issue model-checking faces is probably the

combinatorial explosion. Optimizing the computation

power and memory size necessary for a given SysML

This process of saving the context when a ﬁrst property

is satisﬁed and iterate to the next ones, is valid and can be

adopted for generic nested properties.

model is therefore of prime importance. In this sec-

tion we present some of the techniques that we have

used to limit the exploration space and to enhance per-

formance.

6.1 State and Transition Merging

Since even reasonably small models may have a huge

number of r-states, it is important to adopt state merg-

ing techniques both as a pre-computation process and

on-the-ﬂy. The ﬁrst step is to merge states which

are linked by empty transitions

. A second step, on-

the-ﬂy, merges non-empty transitions with no mul-

tiple choice and time dependencies. Each transition

is associated with an unique ID. The merge is exe-

cuted in ascending order by ID. This operation sup-

ports a notable reduction in the number of r-states

without changing the veriﬁcation result. There is an

exception. This optimization approximates the con-

currency since it merges by ID some possible con-

current r-states. On nested properties, like the lead-

sTo, the result may change since a second pass it-

eration could check for a concurrency on a merged

r-state. The merging order cannot be reconstructed

backwards since old transitions are not saved (to save

memory). However, the veriﬁcation does not nor-

mally depend on these cases since the nested prop-

erties are usually not concurrency related. In fact, the

idea behind nested properties is to check something in

the future. Anyway, with an option this optimization

can be disabled. On the leadsTo property, a further

optimization is also active. When a r-state at the ﬁrst

With empty transitions we refer to state machine transi-

tions with no actions, no time dependency, no multiple valid

choices transitions.

Direct Model-checking of SysML Models

221

iteration has a true property, available non-concurrent

transitions are continuously merged if they keep the

property satisﬁed. In this way, the number of nodes

for the second pass iteration is notably reduced.

6.2 Impact of the Exploration Approach

The reachability graph algorithm could be used in a

multi-thread BFS or DFS mode. For some proper-

ties, such as liveness, we noticed that a DFS explo-

ration is generally more effective than a BFS one as

the main proof of unsatisﬁability is given by loops or

deadlocks. A search in depth increases the odds to

ﬁnd quickly those features.

6.3 State Encoding

The context of a r-state is necessary to save the ba-

sic local information. It is also needed to fetch the

transitions starting from the current state in order to

search for new reachable nodes. The context deﬁnes

uniquely a r-state and it is used to generate an hash

value. All the r-states are inserted in an hash table us-

ing the context hash as a key. To ﬁnd if a new r-state

has already been discovered, its context hash is gen-

erated. Then, the hash table is accessed checking if

it contains the generated hash. To save memory, once

a node generates all its subsequent next reachable r-

states, its context can be freed.

The r-state context saves also the values for each

attribute of each block in the model. It is necessary

so that, when a guard is evaluated, the attribute cur-

rent value is read directly from the context. Those

values are usually updated by the model during its ex-

ecution using signals or assignment actions. If this

update never occurs, the attribute is a constant. In pre-

computation, constants are removed from the context

and they are directly substituted as immediate val-

ues into the expressions they are involved. Moreover,

boolean attributes are grouped and represented on 1-

bit while integers can be represented on 8, 16 or 32

bits.

6.4 Handling of Properties

Expressions and properties are constructed as a syntax

tree. Each node is an operator while each leaf is an at-

tribute or an immediate value. By vising the tree from

the root, the result of the expression can be easily and

efﬁciently retrieved. Leaves have a direct pointer to

their corresponding location in the r-state context to

have fast access to their values. Leaves containing at-

tributes are saved in a hash table so that leaves can be

shared among different expressions or properties.

6.5 Overall Performance

Before developing this framework, TTool relied on

UPPAAL to verify its models. Thus, the perfor-

mance of the new internal model-checker is evalu-

ated by comparing the two. Table 1 shows some

results comparing our model-checker to UPPAAL.

Time values for UPPAAL don’t include the transla-

tion time of a model which takes around 225 ms. The

properties are tested on various SysML models, most

of them available in the public TTool repository

The ebook, telecom ﬁnal, and CoffeeMachine async

(CM async) models contain asynchronous channels

while AirbusDoor V2 (AD V2), UAV, and Pressure-

Controller (PC) contain only synchronous channels.

R, L, and D refer in order to reachability, liveness, and

deadlock freedom.

Our model-checker allows to build a reachability

graph (1386541 r-states in ebook model) that can be

opened for a visual representation that captures the

global model behavior. Moreover, the reachability

graph can be minimized to represent only the states

chosen by the user. This feature is not available in

UPPAAL.

Generally, our model-checker is faster than UP-

PAAL over synchronous channels and for short time

veriﬁcation over asynchronous channels. UPPAAL

performs generally better in expensive and hard ver-

iﬁcation, like the leadsTo property, and over asyn-

chronous channels. As a future work, we plan to im-

prove the performance using additional optimization

techniques, especially on asynchronous communica-

tions, and moving our implementation from Java to

C++ since memory management is one of the main

bottlenecks. There is still margin for improvement.

Nevertheless, our implementation obtains good re-

sults while being able to link the veriﬁcation to the

model representations, traces and simulation.

7 CONCLUSION

The paper introduces a model-checker directly work-

ing from SysML model, thus without a prior trans-

formation to a formal speciﬁcation. Our model-

checker can handle CTL-like properties. Our eval-

uation shows that it compares to a state-of-the-art

model-checker.

This model-checker is already available in TTool.

All properties described in this paper can be directly

captured in the AVATAR block diagrams. Once the

Some models have been modiﬁed to increase the com-

binatorial space of the veriﬁcation.

MODELSWARD 2021 - 9th International Conference on Model-Driven Engineering and Software Development

222

Table 1: Model-checker timing results (low values are bet-

ter).

Model Property Time MC (ms) Time UPPAAL (ms)

ebook RG 3832 /

ebook D 14 755

ebook LeadsTo 5659 2235

ebook A[]x<12 (BFS) 10 287

ebook A[]x<13 (BFS) 3478 1303

ebook E[] (BFS) 14 282

ebook A<>(DFS) 29 279

ebook E<>(BFS) 3604 1292

ebook R, L, D, CTL 17529 12068

telecom ﬁnal R, L 1242 2927

AD V2 R, L, D 82 433

CM async R, L, D 126 393

CM async CTL 2776 1328

UAV R, L, D, CTL 688 2505

PC R, L, D, CTL 198 748

model-checker has veriﬁed them, a green check or a

red cross indicates for each property whether they are

satisﬁed or not. Additionally, a counter example can

be generated in some situations. We now intend to im-

prove this trace generation facility. We also intend to

extend this model-checker to other proﬁles supported

by TTool. Furthermore, we plan to tackle new opti-

mization techniques to make our model-checker even

more competitive among the available ones. Linking

this model-checker to other UML/SysML framework

is also part of our future work.

ACKNOWLEDGEMENTS

The AQUAS project is funded by ECSEL JU under

grant agreement No 737475.

REFERENCES

Ando, T., Yatsu, H., Kong, W., Hisazumi, K., and Fukuda,

A. (2013). Formalization and model checking of

sysml state machine diagrams by csp#. In Murgante,

B., Misra, S., Carlini, M., Torre, C. M., Nguyen,

H.-Q., Taniar, D., Apduhan, B. O., and Gervasi, O.,

editors, Computational Science and Its Applications

– ICCSA 2013, pages 114–127, Berlin, Heidelberg.

Springer Berlin Heidelberg.

Apvrille, L., Courtiat, J. ., Lohr, C., and de Saqui-Sannes,

P. (2004). Turtle: a real-time uml proﬁle supported

by a formal validation toolkit. IEEE Transactions on

Software Engineering, 30(7):473–487.

Apvrille, L., de Saqui-Sannes, P., and Vingerhoeds, R.

(2020). An educational case study of using sysml

and ttool for unmanned aerial vehicles design. IEEE

Journal on Miniaturization for Air and Space Systems,

1(2):117–129.

Apvrille, L. and Li, L. W. (2019). Harmonizing safety,

security and performance requirements in embedded

systems. In Design, Automation and Test in Europe

(DATE’2019), Florence, Italy.

Apvrille, L., Muhammad, W., Ameur-Boulifa, R., Coud-

ert, S., and Pacalet, R. (2006). A uml-based environ-

ment for system design space exploration. In 2006

13th IEEE International Conference on Electronics,

Circuits and Systems, pages 1272–1275.

Bruel, C. (1998). Integrating formal and informal spec-

iﬁcation techniques. why? how? In Industrial-

Strength Formal Speciﬁcation Techniques, Workshop

on, page 50, Los Alamitos, CA, USA. IEEE Computer

Society.

DeAntoni, J. and Mallet, F. (2012). Timesquare: Treat your

models with logical time. In International Conference

on Modelling Techniques and Tools for Computer Per-

formance Evaluation, pages 34–41. Springer.

Delatour, J. and Paludetto, M. (1998). Uml/pno: A way

to merge uml and petri net objects for the analysis

of real-time systems. In Demeyer, S. and Bosch,

J., editors, Object-Oriented Technology: ECOOP’98

Workshop Reader, pages 511–514, Berlin, Heidel-

berg. Springer Berlin Heidelberg.

Gabmeyer, Sebastian, K. P. S. M. G. M. K. G. (2019).

A feature-based classiﬁcation of formal veriﬁcation

techniques for software models. Software & Systems

Modeling.

Kangas, T., Kukkala, P., Orsila, H., Salminen, E.,

annik

ainen, M., H

ainen, T. D., Riihim

aki, J.,

and Kuusilinna, K. (2006). Uml-based multiprocessor

soc design framework. ACM Transactions on Embed-

ded Computing Systems (TECS), 5(2):281–320.

Laleau, R. and Mammar, A. (2000). An overview of a

method and its support tool for generating b speci-

ﬁcations from uml notations. In Proceedings ASE

2000. Fifteenth IEEE International Conference on Au-

tomated Software Engineering, pages 269–272.

Ouchani, S., Ait Mohamed, O., and Debbabi, M. (2013). A

probabilistic veriﬁcation framework for sysml activity

diagrams. volume 246, pages 165–170.

Sch

afer, T., Knapp, A., and Merz, S. (2001). Model check-

ing uml state machines and collaborations. Electronic

Notes in Theoretical Computer Science, 55:357–369.

Stemmer, R., Schlender, H., Fakih, M., Gr

uttner, K., and

Nebel, W. (2019). Probabilistic state-based rt-analysis

of sdfgs on mpsocs with shared memory communica-

tion. In 2019 Design, Automation Test in Europe Con-

ference Exhibition (DATE), pages 1715–1720.

Thiele, L., Wandeler, E., and Haid, W. (2007). Performance

analysis of distributed embedded systems. In Interna-

tional Conference On Embedded Software: Proceed-

ings of the 7 th ACM & IEEE international conference

on Embedded software, volume 30, pages 10–10. Cite-

seer.

Viehl, A., Sch

onwald, T., Bringmann, O., and Rosenstiel,

W. (2006). Formal performance analysis and simu-

lation of uml/sysml models for esl design. In Pro-

ceedings of the conference on Design, automation and

test in Europe: Proceedings, pages 242–247. Euro-

pean Design and Automation Association.

Wang, H., Zhong, D., Zhao, T., and Ren, F. (2019). Inte-

grating model checking with sysml in complex system

safety analysis. IEEE Access, 7:16561–16571.

Direct Model-checking of SysML Models

223