Introducing the Modeling and Verification process in SysML
Marcos V. Linhares
∗
, R
ˆ
omulo S. de Oliveira, Jean-Marie Farines
DAS – UFSC
Campus Universit
´
ario – Trindade
88040-900 Florian
´
opolis/SC – Brazil
{marcos, romulo, farines}@das.ufsc.br
Franc¸ois Vernadat
LAAS – CNRS
University of Toulouse
7, avenue du Colonel Roche
31077 Toulouse – France
francois@laas.fr
Abstract
The development process of complex systems needs to
take in account differents domains and aspects. SysML
(Systems Modeling Language) is a new modeling lan-
guage that allows a system description with various inte-
grated diagrams (as structure, behavior and requirements
diagrams), but SysML lacks formality for the requirement
verification. The aim of this paper is to propose an ap-
proach to verify complex systems using SysML as a lan-
guage which describes the system structure and require-
ments. Petri nets and temporal logic LTL are used respec-
tively to formalize the system behavior and requirements.
The benefit of such formalization is to allow an automatic
formal verification. In order to demonstrate this method-
ology, it will be used a factory automation system, mod-
eled by SysML and Petri nets, and verified by the TINA
toolbox.
1. Introduction
With the increase of the complexity and diversity of
the industrial applications, the need for collaboration ap-
pears in the development process, since it involves knowl-
edge in the areas of software, mechanical, electrical and
electronic engineering. The integration of these areas will
result in a complex system product. However, each area
uses different methodologies and development tools. That
makes difficult the understanding of each part of the sys-
tem development by project collaborators of different ar-
eas. System engineering has to use a shared methodology
to integrate the products of different engineering areas.
The System Modeling Language (SysML) is a semi-
formal language that intend to support the specification,
analysis, design and verification of complex systems [9].
It allows to capture informations in a precise and efficient
way, so as to facilitate integration and reuse in a larger
context. It should also support several activities such as:
to analyze and to evaluate the specified systems, to iden-
∗
This author is supported by CAPES/COFECUB and CNPq.
tify and to provide requirements of the system, to dis-
tribute projects and to support exchange among them; to
communicate system informations, correctly and consis-
tently among several participants of the same project (soft-
ware, mechanical, electrical and other engineers).
A semi-formal modeling is easy to use and permits to
quickly obtain a preliminar specification of a complex sys-
tem including architecture, behavioral and requirements
aspects. The counterpart of this kind of modeling is the
lack of formalization. In the other hand the formal models
that make a well defined behavior modeling, system prop-
erties specification, and allows verification, but requires
some expertise.
An early stage in the development of any complex sys-
tem is to specify its requirements. For example, several
conceptual models can be used in order to understand and
to organize the requirements in a systematic way. Also,
there are several ways of describing the behavior of a sys-
tem. The description in natural language may contain am-
biguities. It is essential to insert formal or semi-formal
models, that are capable of specifying the requirements,
making it possible the use of system design automated
methods [7]. The SysML requirements diagram provides
a way to make that. But, the semi-formality of this dia-
gram does not allow the verification task of systems. Al-
though a verify stereotype is used in the SysML require-
ments diagram, it is not well adapted for requirement ver-
ification.
The modeling and verification process, proposed in this
paper, gets the better of the two worlds (semi-formal and
formal). This process is shown in the figure 1, it is based
on a first semi-formal modeling task before a formal mod-
eling and verification task. This paper intends to be more
clear about this process by using a factory example.
The aim of this paper is not to give a formal semantics
of various SysML diagrams but focusses on the SysML
framework proposed to capture, refine and trace require-
ments. We use temporal logic to progressively formalize
SysML requirement diagrams. We illustrate the whole ap-
proach by considering a factory automation system. As
formal verification also requires a formal description of
the component behaviours, we use Petri nets instead of
ETFA'2007 - 12th IEEE Int. Conf. on Emerging Technologies and Factory Automation
Informal
System Description
System
Properties
Behavioral
Modeling
Formal Modeling
Requirements
Modeling
Structural
Modeling
Semi−formal Modeling
VerificationnotSatisfied
Figure 1. Modeling and Verification process.
standard activity diagrams. The global behaviour of the
system is obtained by composing elementary components
according the system architecture. System description, in-
cluding behavioural aspects and requirements expression,
is analysed using the TINA toolbox [4].
In section 2, the SysML language is briefly presented
and especially, the requirement diagram is described. In
section 3, some concepts of formal modeling (with Petri
nets) and verification (with LTL formulas) are presented
and the TINA toolbox is described. The approach joining
the SysML language and Petri nets is presented and ap-
plied in a factory automation example in section 4. Sec-
tion 5 presents the final considerations and future works.
2. The SysML Language
SysML is a general purpose modeling language for
system engineering applications. It establishes a descrip-
tion pattern for a great variety of complex systems. These
systems may include hardware, software, data, methods,
personal and instruments.
It was being defined based on UML 2.0, using its syn-
tax and semantics. That will improve the communication
among the several designers that participate in the devel-
opment of the system, promoting interoperability among
modeling tools, not only for software and hardware design
but also for the other parts of the system, as electrical, me-
chanical ones and so on [10].
Figure 2 shows the modifications in the diagrams
reused from UML 2.0 as well as the new diagrams of
SysML. The specification of SysML is classified in three
basic model types: the structure models, the behavior
models and the requirement models. For each one there
are defined constructions that are used in a specific model.
Some constructions can be used together with several
model types (called cross-cutting constructions).
The SysML diagrams represent the model elements
such as packages, blocks and associations. They allow
to reuse UML diagrams without modification. Moreover,
the extensions of these diagrams aim at meeting the spe-
cific requirements of system engineering [10]. The fol-
lowing UML behavior diagrams are included in SysML
without modifications: state machines, interactions (se-
quences) and use cases. Other UML diagrams such as
SysML
Diagrams
Behavior
Diagrams
Diagram
Structure
Activity
Diagram
Diagram
Sequence
State Machine
Diagram
Diagram
Use Case
Requirement
Diagram
Package
Diagram
Block Definition
Diagram
Diagram
Parametric
Internal Block
Diagram
Modified from UML2.0
New diagram
Same as UML2.0
Figure 2. SysML diagrams [10]
activities, classes are reused with the addition of some ex-
tensions. Some new diagrams as requirements, parametric
and allocation diagrams were also added.
The structural constructions define the static and struc-
tural elements used in SysML. The diagrams that include
the structural constructions are: Package Diagram (to par-
tition the system), Block Definition Diagram (to define the
block features and relationships), Internal Block Diagram
(to show the internal structure of a block) and the Paramet-
ric Diagram (a restricted form of internal block diagram
containing constraint properties and parameters). Despite
of some similarities with the UML models these contruc-
tions brought several improvements.
The behavioral constructions specify the dynamic parts
used in the behavior diagrams of SysML, including: the
Activity Diagram (used to describe the control flow), the
Sequence Diagram, the State Machine Diagram and the
Use Case Diagram, the same ones used in UML with little
or none modification. The most important improvement
in the behavioral models is to make possible the modeling
of continuous time by the activity diagram.
Finally, another diagram which does not exist in UML,
the Requirement Diagram allows the system requirement
description.
2.1. SysML diagrams for the proposed approach
This approach uses SysML to perform the structural
(block definition diagram and internal block diagram) and
requirement modeling (requirement diagram).
The block definition diagram (BDD) and the internal
block diagram (IBD) describe the external and internal
system or subsystem structure using a block as its basic
unit. They allow the description of which elements are in-
terconnected and how they are interconnected. They also
allow a top-down and/or a bottom-up modeling while giv-
ing an abstract/concrete system level to different system
elements.
The relationships among the BDD elements (composi-
tion, inheritance, aggregation and others) and the diagram
format are the same ones used in the UML class diagram.
With this diagram it is possible to visualize all the parts
2
ETFA'2007 - 12th IEEE Int. Conf. on Emerging Technologies and Factory Automation
that compose the system and the relationship among them
in an abstract way. The IBD describes the internal struc-
ture of a block, its parts and the connections among them.
The connections are made through the use of flow ports,
where matter, energy or data may flow, and service ports
that connect the services provided and/or requested by a
block.
Unfortunately, to describe a complex system a better
organization is necessary because the number of BDD and
IBD diagrams and model elements (blocks, ports, ...) can
increase very quickly, depending on the system to model,
and the view to show.
The requirement diagram is developed from system en-
gineer needs and they present an important role during the
system modeling. It shows how the requirements are sat-
isfied by the system elements. Those requirements may be
provided by the user, the environment, or by the system it-
self. Requirements are described through sentences based
on natural language. In this diagram they can be grouped
in a clear way, also documenting their origin (standards
or more detailed specifications) and tracing their destina-
tion. The requirements also can be used to provide useful
acceptance tests before the system deployment.
However, the requirements diagram is very abstract.
Requirements are inserted in the model as text using nat-
ural language. It presents the same problems of an in-
formal specification. Moreover, the sentences in natural
language can describe structural or non-structural require-
ments, which directly affect the system architecture and
behavior characteristics. It presents a high degree of in-
formality and consequently the verification of those re-
quirements becomes a very hard task. Misunderstandings
and inconsistencies can happen during the extraction of
information from this diagram.
3. The Petri Net Model and Tool
Petri nets and Time Petri nets [8] are one of the most
widely used model for the specification and verification of
real-time systems. Time Petri nets are Petri nets in which
a nonnegative real interval I
s
(t), with rational end-points,
is associated with each transition t of the net [2]. Function
I
s
is called the Static interval function.
R
+
and Q
+
are the sets of nonnegative reals and ratio-
nals, respectively. Let I
+
be the set of nonempty real in-
tervals with nonnegative rational end-points. For i ∈ I
+
,
↓ i denotes its left end-point, and ↑ i its right end-point
(if i bounded) or ∞. For any θ ∈ R
+
, i −
.
θ denotes the
interval {x − θ |x ∈ i ∧ x ≥ θ}.
Definition A Time Petri net (or TPN) is a tuple
hP, T, Pre, Post, m
0
, I
s
i, in which hP, T, Pre, Post,
m
0
i is a Petri net, and I
s
: T → I
+
is a function called the
static interval function. Where, P is the set of places, T is
the set of transitions, Pre, Post : T × P → N
+
are the
precondition and postcondition functions, m
0
: P → N
+
is the initial marking.
Time Petri nets add to Petri nets the static in-
terval function I
s
, that associates a temporal interval
I with every Petri net transition t (with t ∈ T ),
where I
s
(t) ∈ I
+
. A Time Petri net example is
shown in Figure 3. This TPN represents a production
worker (a worker that works in a production line) with
P = {W i
idle, W i
work, W i
workExcess} (places)
and T = {Li
startLine, Li
endLine, Wi
workT ime}
(transitions). The Pre and Post functions place the
arrows as it is showed in the figure 3 (for example,
Pre = (Li
endLine, Wi
idle) = 1 and Post =
(Li
startLine, Wi
idle) = 1). His initial marking (m
0
)
is W i
idle when he is able to go to work. His work-
ing time depends on the line working time (between
Li
startLine and Li
endLine, more detailled in the sec-
tion 4) but, if he works more than 35 minutes in a pro-
duction line (I
s
(W i
workT ime) = [35, 35]) the transi-
tion W i
workT ime is fired and the worker go to the state
W i
workExcess. The verification phase will allow to
check if this property hold or not.
Wi_idle
Li_startLine
Li_endLine
Wi_work
Wi_workTime
[35,35]
Wi_workExcess
Figure 3. A Petri net example.
States, and the temporal state transition relation
t@θ
−→,
are defined as follows:
Definition A state of a TPN is a pair (m, I) in which m is
a marking (m ∈ P ) and I is a function called the interval
function. Function I : T → I
+
associates a temporal
interval with every transition t (t ∈ T ) enabled at m. We
write (m, I)
t@θ
−→ (m
′
, I
′
) iff θ ∈ R
+
and:
1. m ≥ Pre(t) ∧ θ ≥ ↓I(t) ∧ (∀k ∈
T )(m ≥ Pre(k) ⇒ θ ≤ ↑ I(k))
2. m
′
= m − Pre(t) + Post(t)
3. (∀k ∈T )(m
′
≥ Pre(k) ⇒
I
′
(k) = if k 6= t ∧ m − Pre(t) ≥
Pre(k) then I(k) −
.
θ else I
s
(k))
Definition The state graph of a TPN is the structure
SG = (S
t@θ
−→ s
0
), where:
S = {s|s
0
∗
→ s} is the set of states reach
able from the initial state s
0
s
0
= (m
0
, I
0
), where I
0
(t) = I
s
(t) for
any t enabled at m
0
.
3
ETFA'2007 - 12th IEEE Int. Conf. on Emerging Technologies and Factory Automation
Many techniques for analysis of Time Petri nets pro-
ceed by building a labeled transition system (LTS) pre-
serving the properties of interest (e.g. reachability set,
deadlocks), in a first step, and then checking on this LTS
the properties to be satisfied. Considering Time Petri nets,
the main difficulty concerns the obtention of a finite state
space.
Transitions may fire at any time in their temporal inter-
vals, so states typically admit an infinity of successors. As
with many formal models for realtime systems, the state
spaces of Time Petri nets are typically infinite. Model
checking Time Petri nets first requires to produce finite
abstractions for their state spaces. Labeled transition sys-
tems that preserve some classes of properties of the state
space, are so built.
Different state class constructions have been proposed
and are available in TINA, preserving different families
of properties of the state space. State class graph con-
struction [3] preserves markings of the TPN and all its
properties one can express in linear time temporal logics
like LT L. [5] presents alternatives preserving states and
bisimilarity with the state graph.
3.1. Model-Checking
We use State/Event − LT L [6], a linear time tem-
poral logic supporting both state and transition properties.
The modeling framework consists of labeled Kripke struc-
tures (the state class graph in our case), which are directed
graphs in which states are labeled with atomic proposi-
tions and transitions are labeled with actions. Formulae
Φ of State/Event − LT L are defined according the fol-
lowing grammar (here p ranges over P and a ranges over
Σ):
Φ ::= p | a | ¬Φ | Φ ∨
Φ | Φ | Φ | ♦ Φ | Φ U Φ
Example Example of State/Event − LT L formulae :
(For all paths)
P P holds at the beginning of the path,
P P holds at the next step,
P P globally holds,
♦ P P holds in a future step,
P U Q P holds until a step is reached where Q holds
3.2. Tina toolbox for Time Petri Nets Verification
TINA (TIme Petri Net Analyzer
1
) is a software envi-
ronment to edit and analyze Petri nets and Time Petri
nets. This paper overviews its capabilities, architecture,
and main applications. More details can be found in [4].
In addition to the usual editing and analysis facilities of
similar environments, TINA offers various abstract state
space constructions that preserve specific classes of prop-
erties of the state spaces of nets, like absence of deadlocks,
linear time temporal properties, or bisimilarity. For un-
timed systems, abstract state spaces helps to prevent com-
binatorial explosion. For timed systems, abstractions are
1
http://www.laas.fr/tina
mandatory as their state spaces are typically infinite, TINA
implements various abstractions based on state classes.
The TINA toolbox offers the capacity to construct com-
plex specification in a compositional manner. Each transi-
tion or place may be labelled and a Petri net composition
is performed according the transitions or places merging
with the same label. This facility allows to a modular
specification for each part of the system. The figures 4(a)
and 4(b) show the Petri nets used to compound the Petri
net ilustrated before in figure 3, it can be observed a place
merging labeled as Wi
work.
Wi_idle
Li_startLine
Li_endLine
Wi_work
Wi_workTime
[35,35]
Wi_work
Wi_workExcess
(a) (b)
Figure 4. Petri nets composition.
The different tools constituting the environment can be
used alone or together:
• nd (NetDraw): is an editing tool for automata and
time Petri nets, under a textual or graphical form. It
integrates a “step by step” time Petri nets simulator.
• tina: this tool builds the state space of a Petri nets,
timed or not. TINA can perform classical constructs
(marking graphs, covering trees) and also allows ab-
stract state space construction, based on partial order
techniques.
• selt: to check more specific properties than the gen-
eral ones such as boundedness, deadlocks, pseudo
liveness and liveness already checked by TINA. The
selt tool is a model-checker for temporal logic exten-
sion formulae (State/Event LT L - seltl) [6].
Realtime properties, like those expressed in Timed
Computation Tree Logic T CT L [1] could be checked by
using the standard technique of observers. The technique
is applicable to a large class of realtime properties and can
be used to analyze most of the “timeliness” requirements
found in practice. This facility is used later in order to al-
low the verification of deadline properties. For example,
looking to the figure 3 it is necessary to know if there is
a moment that the production worker works more than 35
minutes; in this case, it is possible to use the following
LTL formula: 2¬W i
workExcess. In case of non satis-
fiability, selt is able to build a readable counter-example
sequence which presents an execution violation of the re-
quirement.
4
ETFA'2007 - 12th IEEE Int. Conf. on Emerging Technologies and Factory Automation
4. A Modelling and Verification Example
We used a simple factory plant example to show how
to join these two modeling languages in a single approach
that allows the high level modeling with both semi-formal
and formal modeling language. The aim is to use part of
SysML language to model structure and requirements, to-
gether with Petri net to describe the behavioral part. After
that, the formal requirement verification was performed.
4.1. Structural modeling
The example is based on a simple factory plant. The
factory plant objective is to manufacture products and, for
that, workers and machines are available. The products
(P
x
) are made by the production lines (L
x
) that put the
machines (M
x
) in a specific production order. The work-
ers are divided in two types: a) the production workers
(W
x
), that use the machines and work in the production
lines and; b) the technicians (T
x
), that make the machine
maintenance.
Figure 5 illustrates the SysML block definition diagram
for the factory plant. It shows the factory structure in an
abstract way. Looking to this figure, it is possible to know
the elements that compose the factory and their relation-
ship with each other without too many details. For ex-
ample, a factory is composed by one or more machines
(composition relationship); the production lines use the
machines and the production workers in the product man-
ufacturing task (dependency relationship).
<<block>>
Worker
<<block>>
Machine
<<block>>
Product
<<block>>
Factory Plant
∗1..∗1..∗1..
∗1..
<<block>>
Technician
<<block>>
Production Worker
<<block>>
Production Line
<<use>>
<<use>> <<use>> <<use>>
Figure 5. Factory structure.
Figure 6 shows the internal block diagram, in this case
the internal factory structure. It can be noticed the inter-
connection points among all factory elements. Those in-
terconnection points are performed by flow ports. Like
a block definition diagram, that is based on a high level
structure specification, the internal block diagram shows a
more detailed structure specification. The factory manu-
factures a product (P
1
) and uses two production lines (L
1
and L
2
) to perform it. There are four machines (M
1
, M
2
,
M
3
and M
4
) and each production line uses three machines
in its production task, respectively L
1
(M
1
, M
2
, M
3
) and
L
2
(M
2
, M
3
, M
4
). The production worker W
1
works on
L
1
and the W
2
works on L
2
. The technician T
1
makes the
maintenace on all machines.
L1 L2
Li_Mi_startMachine / Li_Mi_endMachine
T1
M1 M4M2 M3
Mi_startMachineMnt / Mi_endMachineMnt
W2W1 P1
Li_startLine / Li_endLine
Figure 6. Factory internal structure.
4.2. Requirements modeling
There are some requirements that should be satisfied
by the factory. The SysML requirement diagram de-
scribes the requirements hierarchy and creates a require-
ment traceability matrix. Figure 7 shows the requirement
diagram with the properties that we need to verify in the
system. For example, it is important the norms and the
work legislation to be satisfied by the factory. The work
legislation requires that the production workers have a
pause after a continuous work and any worker does not
work more than 35 minutes on a production line. The fac-
tory norms require that the machine maintenance is en-
sured during the manufacturing process.
Factory Requirements
<<requirement>>
Laws and Norms
<<requirement>>
Usine Norms
<<requirement>>
Maintenance Norms
<<requirement>>
Work Legislation
<<requirement>>
Health and Safety
<<requirement>>
Employment Rights
<<requirement>>
Work Pause
<<requirement>>
MachineMaintenance
MachineMnt
<<testCase>>
WorkerPause
<<testCase>>
<<requirement>>
WorkContinuousTime
WorkExcess
<<testCase>>
<<deriveReqt>>
<<deriveReqt>>
<<deriveReqt>>
<<verify>>
<<verify>>
<<verify>>
Figure 7. Factory requirements diagram.
5
ETFA'2007 - 12th IEEE Int. Conf. on Emerging Technologies and Factory Automation
![Figure 2. SysML diagrams [10]](/figures/figure-2-sysml-diagrams-10-1acpmm40.webp)