On formal cyber physical system properties modeling: A new temporal logic language and a Modelica-based solution

Abstract

Modeling and Simulation methods, tools and techniques aim at supporting the different phases of the lifecycle of modern systems, going from requirements analysis to system design and operation. However, their effective application requires investigating several aspects such as the formal modeling of system requirements and the binding and automated composition between heterogeneous models (e.g. requirements models, architectural models, behavioral models). In this context, the paper presents a new formal requirement modeling language based on temporal logic, called FORM-L, and a software library, based on the Modelica language, that implements the constructs provided by FORM-L so as to enable the visual modeling of system properties as well as their verification through simulation. The effectiveness of the proposal is shown on a real case study concerning an Intermediate Cooling System.

Full text

On formal cyber physical system properties
modeling: a new temporal logic language and a
Modelica-based solution
Alfredo Garro, Andrea Tundis
Department of Informatics, Modeling, Electronics and
Systems Engineering (DIMES), University of Calabria, Via
Ponte P. Bucci 41C, Rende (CS), 87036 Italy
alfredo.garro@unical.it, andrea.tundis@dimes.unical.it
Martin Otter
Institute of System Dynamics and Control, DLR German
Aerospace Center, Oberpfaffenhofen
Münchener Str. 20, Wessling, 82234 Germany
martin.otter@dlr.de
Wladimir Schamai
Airbus Group Innovations, Hamburg, Germany,
wladimir.schamai@airbus.com
Daniel Bouskela, Audrey Jardin, Nguyen Thuy
R&D Division, Electricité de France (EDF), 6 quai Watier,
Chatou Cedex, 78401 France
{daniel.bouskela, audrey.jardin, n.thuy}@edf.fr
Lena Buffoni, Peter Fritzson, Martin Sjölund
Department of Computer and Information Science (IDA),
Linköping University, SE-58183 Linköping, Sweden
{lena.buffoni, peter.fritzson, martin.sjölund}@liu.se
Hans Olsson
Dassault Systèmes AB, Sweden,
hans.olsson@3ds.com
Abstract— Modeling and Simulation methods, tools and
techniques aim at supporting the different phases of the lifecycle
of modern systems, going from requirements analysis to system
design and operation. However, their effective application
requires investigating several aspects such as the formal
modeling of system requirements and the binding and automated
composition between heterogeneous models (e.g. requirements
models, architectural models, behavioral models). In this context,
the paper presents a new formal requirement modeling language
based on temporal logic, called FORM-L, and a software library,
based on the Modelica language, that implements the constructs
provided by FORM-L so as to enable the visual modeling of
system properties as well as their verification through simulation.
The effectiveness of the proposal is shown on a real case study
concerning an Intermediate Cooling System.
Keywords— Formal Languages, Properties Modeling,
Requirements Engineering, Model-Based Systems Engineering,
Modeling and Simulation, Modelica, System Verification.
I. I
NTRODUCTION
Models allow for an abstract representation of systems.
They are able to capture, represent and communicate concepts,
make implicit information explicit, and act as a repository for
knowledge and rationale. System modeling is a major area of
study in software and systems engineering with the purpose of
facilitating requirements elicitation and understanding as well
as system design, implementation and verification [1, 2, 3].
Different modeling languages are currently used in software
and systems engineering; as an example, UML provides a wide
set of diagrams for modeling both the structure and behavior of
systems [4, 5]. Entity-Relationship diagram is another example
of widely used notation for modeling static views of entities in
a system and their relationships. Agent and goal-oriented
modeling notations [6] capture the “why” aspects in additions
to the “what” and “how”, thus enabling to model and analyze
the goal oriented behaviors of system stakeholders.
Properties Modeling is a topic that falls in the above
introduced field [7, 8]. It deals with formally expressing
constraints and requirements that the behavior of the system
should comply with and that can be verified through real or
simulated experiments. Although several research activities are
focused on the system design phases, there is still a lack of
practices and approaches that specifically deal with the
analysis, modeling, and verification of requirements in an
integrated framework that goes from system design to system
operation. Indeed, it is not sufficient to support the verification
and validation of the system under consideration during its
design but such activities should be also performed and
supported during system operation by following the dynamic
evolution of the system during its whole lifecycle. In modern
cyber-physical systems, it is even crucial to ensure the proper
operation of the overall system and of each individual
component to guarantee their functional correctness in
compliance with the requirements. Besides, in order to have
optimal system design, it is of prime interest to include
operational constraints since the beginning of the design stage.
To this aim, the adoption of model-based methods and tools for
supporting the design and the analysis of cyber-physical
systems, combined with innovative simulation techniques, able
to evaluate functional and non-functional requirements, can
represent a viable solution [9].
978-1-5090-0793-6/16/$31.00 ©2016 IEEE

In this context, the paper presents a new formal requirement
modeling language based on temporal logic, called FORM-L
(FOrmal Requirements Modelling Language) [10], and a
software library, based on the Modelica language [11, 12], that
implements a subset of the constructs provided by FORM-L so
as to enable the visual modeling of system properties as well as
their verification through simulation. The presented results
have been developed in the context of the ITEA 3 – MODRIO
(MOdel DRIven physical systems Operation) European Project
[13] that aims at extending modelling and simulation languages
and tools based on open standards from system design to
system operation. The expected outcome of the project is a
holistic modeling and simulation framework for physical
system design, diagnosis and operation assistance.
The rest of the paper is structured as follows: Section 2
presents an overview on the main issues and available solutions
for properties modeling; then the FORM-L language is
introduced in Section 3. A Modelica library for properties
modeling based on the FORM-L language is presented in
Section 4. A case study concerning the simulation-based
verification of an Intermediate Cooling System (SRI, Système
de Réfrigération Intermédiaire) is described in Section 5,
whereas some solutions for binding a requirement model,
obtained by the exploitation of the proposed approach, with a
Modelica-based system design model, are briefly introduced in
Section 6. Finally, conclusions and future works are delineated
in Section 7.
II. R
ELATED
W
ORK ON
P
ROPERTIES
M
ODELING
Dealing with system properties involve several systems
engineering aspects to be considered (including functional
behavior, timing behavior, performance characteristics, or
internal structure), ranging from the need for reference models
able to catch the necessary characteristics to define
requirements, constraints and their relationships, to
mechanisms to link them not only with the system architecture
but also with the system behavior so as to support the
verification of system against requirements [14]. According to
the definition given in [8] a property is an expression that
specifies a condition that must hold true at given times and
places. Although several modeling languages can be effectively
exploited for modeling the structure of system and its expected
behavior, several issues, within the properties modeling field,
have to be properly faced [7].
A first research challenge is about conceptual properties
representation, which aims at dealing with properties
extraction, representations, management, analysis [15, 16, 14,
10, 3]. In particular, there is the need to understand how to
identify system properties and what characteristics must be
considered. Then, it is necessary to define rules, best practices
or guidelines for moving from an informal/textual
representation towards a formal property model. Consequently,
an appropriate approach to define properties along with the
possibility to retrieve information about their status is crucial
for the overall system development process.
A second research challenge concerns tracing and
verification which aims at monitoring specific properties of the
system under consideration as well as at exploiting simulation
techniques for supporting and verifying their fulfillment [17,
18]. Verification is the confirmation process, through the
provision of objective evidence that specified requirements
have been fulfilled; its purpose is to ascertain that each level of
the implementation meets its specified requirements. As a
consequence, it is essential to utilize tools that are able to
guarantee an objective checking of the models and of their
generated values.
A third issue concerns binding and automated model
composition which has to deal with connecting models and
provide mechanisms for enabling their composition [19, 20,
21]; i.e. the possibility to establishing a matching among
different system models (such as architectural model,
behavioral model, property model) and enabling their
composition for obtaining, as an example, the automatic
generation of verification models.
Some works are currently available that address the
modeling of system properties as it is explained in [7]; as an
example: (i) in [22] a representation of the properties that is
closely bounded to the exploitation of an ad-hoc software
library is presented; (ii) in [23] communication processes
along with an evaluation mechanism among properties have
been defined in order to enable the propagation of assessments
among them; (iii) in [6] safety properties are conceived as
invariants and expressed by safety expressions stating that
“nothing bad happens”, that is, that an acceptable state of
affairs is maintained during the operation of the system. Other
research efforts are directed to the possibility of graphically
represent the concepts related to the modeling of systems and
properties. Indeed, graphical modeling languages use diagram-
based techniques with named symbols that represent concepts
and lines that connect the symbols and represent relationships
and various other graphical notations to represent constraints.
An important result, reached so far by OMG [24], concerns
the definition of the SysML profile, a UML-based visual
language for modeling cyber-physical systems [25].
Formal verification and model checking are discussed in
[26] by highlighting the limitations in their applicability.
These approaches combine the ability to: (i) describe and
follow the life cycle of a property, in both a forward and
backward direction, through the whole systems life cycle, with
varying degrees of fulfillment [17]; (ii) exploit simulation
techniques by benefiting of modern model-driven simulation
tools for automating the verification of system requirements
into an integrated framework.
Other research efforts that aim to face with properties
modeling aspects are accomplished by jointly addressing some
challenges and providing software modeling tools or by
exploiting simulation platforms and related simulation
techniques. For example, Mathworks MATLAB-Simulink [27]
provides assertions and bound checking blocks [28] as
configurable components. Whereas DOORS (Dynamic Object
Oriented Requirements System), developed by IBM, provides
requirements support throughout the whole lifecycle of the
project [29]. Another important tool is the Model Center tool,
from Phoenix Integration company [30], which is a software
solution that enables users to create model-based engineering
frameworks to integrate simulation tools in order to define and

automate simulation workflows, set simulation parameters and
run multidisciplinary simulation processes.
In general, current requirements specification approaches
are based on high-level, application friendly, behavioral
modeling languages. Simulation can be used to verify that what
has been specified is indeed what was intended. However,
since these languages specify precise behaviors, they nearly
always lead to over specification. Thus, it is preferable to rely
on constraint-based languages that specify the envelopes of
acceptable behaviors (see Fig. 1).
Fig. 1. Individual behavior and Envelope of acceptable behaviors
Different constraint-based languages for requirements
specification have been proposed, such as PSL (Property
Specification Language IEEE 1850) [9], OCL (Object
Constraint Language), AADL (Architecture Analysis and
Design Language), MARTE (Modelling and Analysis of Real-
Time and Embedded systems), ARTiMon (A Real-Time
Monitor). However, all these languages address computer-
based or electronic systems: the survey did not identify any
language suitable for cyber-physical systems (CPS), and even
worse let alone socio-cyber-physical systems (SCPS, i.e., CPS
with significant human aspects).
Starting from the above mentioned open issues and by
taking into account the needs of the industrial partners involved
in the MODRIO project (such as EDF, Dassault Aviation, DLR
and Airbus), a specific solution that is based on a formal
requirement modeling language for properties modeling has
been defined and is described in the following sections.
III. FORM-L:
A
F
ORMAL
R
EQUIREMENT
M
ODELING
L
ANGUAGE FOR
P
ROPERTIES
M
ODELING
The primary objective of a formal requirements
specification language is to ensure freedom from: (i) wishful
thinking, i.e. requirements specified without any objective
acceptance criteria; (ii) ambiguity, due to the precise syntax
and semantics of the language; (iii) contradiction, with the
help of static analysis tools; (iv) over specification, i.e.
specification of solutions rather than requirements). Another
objective is to support tool-based optimization and verification
approaches, of the engineering process.
The above introduced needs led to the development of the
new language FORM-L. Its objective is to allow the formal
modeling of requirements regarding a SCPS and assumptions
regarding its environment. A requirement or an assumption is
a particular case of the more general notion of property. In its
most general form, the specification of a property in FORM-L
addresses four questions:
- WHAT is to be satisfied;
- WHEN in time that is to be satisfied;
- WHERE in the system that is to be satisfied;
- HOW WELL that is to be satisfied (given the fact
that a real life SCPS can and will fail).
A. WHEN
WHEN is specified with time locators. There are two main
types of time locators: continuous time locators (CTL) and
discrete time locators (DTL). A CTL defines one or more time
periods that have a certain duration and that may overlap. A
DTL defines one or more instants in time, with no duration. It
is worth noting that CTL here is not related to the
Computational Tree Logic of temporal logic. In fact, the
FORM-L temporal logic is close to LTL (Linear Temporal
Logic). As an example, the following CTL specifies the time
periods where the system is in the maintenance state:
during state == maintenance
Whereas, in the following expression eNeeded is an event
that determines when the system needs to be operated, and
eReset is an event that signals that the system is no longer
needed. The CTL specifies the time periods that begin 60
seconds after eNeeded and ends with
eReset
:
after (eNeeded + 60*s) until eReset
FORM-L has one default continuous time domain, but allows
the definition of multiple discrete time domains and the
modeling of time domain interfaces, so that complex,
distributed control systems can be modeled with accuracy. As
an example, the following expression specifies the discrete
time domain of a synchronous digital control system: its
actions (including the reading of inputs) are performed only at
the instants specified by the DTL. That DTL is periodic with a
50 millisecond cycleTime whereas phase is fixed during a
use case but chosen randomly at the beginning of each case
(see Fig. 2):
timeDomain td
constant Duration cycleTime = 50*ms;
fixed Duration phase = random(0., cycleTime);
dtl = (every cycleTime) + phase;
end td;
Fig. 2. Phase and Cycle Time of a DTL
B. WHAT
In FORM-L, a WHAT can take three main forms:
- Satisfaction of a condition-based property;
- Satisfaction of an event-based property;
- Performance of one or more actions.

The simplest condition-based properties specify that a
given Boolean expression is to be true during the WHEN.
More complex condition-based properties place a constraint on
how long the Boolean expression is true during each time
period of a CTL. As an example, the following requirement
states that during maintenance, the system must not be
activated:
requirement r1 =
during state == maintenance // WHEN
check not active; // WHAT
An event-based property specifies a constraint on the
number of occurrences of an event during the time periods of a
CTL. As an example, the following assumption concerns a
circuit breaker. The breaker can receive two orders:
eOpenCmd and eCloseCmd. The assumption states that
within 2 seconds of receiving the eOpenCmd order, the
opening is complete (eOpeningCompleted) unless there
has been a counter order (eCloseCmd).
assumption a2 =
after eOpenCmd within 2*s // WHEN
check eOpeningCompleted or eCloseCmd; // WHAT
An action specifies both the value of a variable or signals
and the occurrence of an event. Variables are understood in a
wide sense and include Boolean, Integer or Real variables, and
Finite State Automata, which are variables whose values
belong to an enumerated set. FORM-L offers various ways of
coordinating multiple actions, including sequences of actions,
simultaneous actions, iterative actions and conditional actions.
A dummy example of mapping is reported in Fig. 3, where
each block (i.e. Start DG, Wait for DG Ready, etc.) represents
an action of a process, which is described through the FORM-L
language as below:
when state becomes active
then sequence
raise eStartDG;
wait eDGReady then raise eOpenMPSBrk;
wait eMPSBrkOpen then raise eShedAll;
simultaneous
wait 5*s then raise eReloadSequence;
wait 1*s then raise eCloseDGBrk;
end;
end;
Fig. 3. Sequence of actions
C. WHERE
In a normal model, the WHERE (the parts of the system
concerned by the property) can be specified in extension, by
naming all the individual components concerned. However, at
the time where the requirements are specified, there is usually
no system designed yet. Thus, its composition in terms of
components is unknown. In this case, FORM-L uses the notion
of set defined in intention, the membership of which will be
provided later by another model (e.g. an architectural design
model). In the following example, Component is a class that
has a single Boolean attribute named failed (if true the
component is no more able to perform its mission), sensors
is the set of all sensors, whereas nonSensors is the set of all
components that are not sensors. Since the membership of
these two sets is yet unknown, they are declared external and
will be defined later by an architectural design model.
tolerance is a Boolean condition that specifies the required
level of fault-tolerance: it is true when and only when there is
no component failure, or at most a single sensor failure:
external Component{} nonSensors;
external Component{} sensors;
Boolean tolerance =
card{e in nonSensors suchThat e.failed} == 0 or
card{e in sensors suchThat e.failed} ≤ 1;
D. HOW WELL
Quality of services (i.e. the acceptable level of system
failure) can be specified in FORM-L by using probabilities.
As an example, in the following expression, property p3 states
that the system should not be spuriously activated when it is
not needed. Requirement r3 states that when there are no
component failures, or at most one sensor failure, then p3
must be satisfied. Requirement r9 puts a limit on the
probability of spurious activation (due to components
failures). This probability must be lower than what it would be
if there was a constant occurrence rate of spurious activation,
equal to y:
property p3 = during not needed check not active;
requirement r3 = during tolerance check not
p3.violated;
requirement r9 = check probability(p3.violated)< 1.-
exp(-y*time);
In the following expression, property p8 states that within
60 seconds after power loss (mps.eLoss) when not in
maintenance, object sbc should be repowered.
Requirement r8 states that the probability of not providing
power to sbc when needed must be less than x1:
property p8 =
after mps.eLoss and not maintenance within 60*s
check sbc.powered;
requirement r8 = after p8.notTested becomes false
check probability p8.violated < x1
IV. A
M
ODELICA
R
EQUIREMETS
L
IBRARY BASED ON
FORM-L
Modelica is a language for equation-based object-oriented
mathematical modeling of physical systems (e.g., systems
containing mechanical, electrical, electronic, hydraulic,
thermal, control, electric power components) with acausal
features, which allows defining models in a declarative
manner [11].

A mapping of FORM-L to Modelica was developed, it utilizes
Modelica language elements to implement FORM-L features;
examples:
- FORM-L operations are mapped to Modelica blocks
if the FORM-L operation has memory and to
Modelica functions if the FORM-L operation has no
memory. For example, the FORM-L construct
during expr check property
is defined in Modelica with function
during
of the
Modelica_Requirements
library:
during(condition=expr, check=property)
- In FORM-L two- and three-valued logic is used. The
two-valued logic data type is mapped to the Modelica
Boolean
type, and the three-valued logic data type is
mapped to enumeration
Property
that has the three
values
Violated
,
Undecided
, and
Satisfied
.
- The FORM-L event type is mapped to a rising edge
of a
Boolean
(because Modelica has not explicit
event data type).
The
Modelica_Requirements
library, see screen shot of
the top level in Fig. 4, provides a subset of FORM-L
operations, as well as extensions, such as a graphical drag-and-
drop user-interface and additional operations (for example to
check if an (x,y) input is within a given area defined by a
closed polygon, or frequency properties based on FFT (Fast
Fourier Transformation) calculations). A short sketch of the
most important sub-packages is given below.
Fig. 4. Modelica_Requirements lib
The
Verify
package contains blocks having either a
Boolean
or a
Property
as an input. These blocks monitor the
input value and at the end of a simulation print an information
message if the
Boolean
input was
false
at least once, or the
Property
input was
Violated
at least once, or was
Undecided
all the time. In other words, these blocks check whether the
defined requirements are or are not fulfilled, or have not been
tested.
The
ChecksInFixedWindow
package contains blocks that
check FORM-L properties whenever the Boolean input
condition
is
true
. Every rising edge of
condition
starts the
check and every falling edge finishes it. For example block
MinDuration
checks that, in every
true
condition
phase,
input
check
is
true
for at least the defined
duration
.
The
ChecksInFixedWindow_withFFT
package contains
blocks that sample the Real inputs, compute an FFT once
“enough” sample points are available, and provide various
checks on the computed frequency-dependent amplitudes
(including a limit on the “total harmonic distortion”). These
blocks are a slightly improved version of the FFT check blocks
introduced in [31].
The
ChecksInSlidingWindow
package contains blocks that
check FORM-L properties in a sliding time window of a given
length. For example, block
MinDuration
checks that, in every
sliding time window of the given length, input
check
is
permanently
true
for at least the defined
duration
.
The
OverlappingTimePeriods
package is currently under
construction and contains blocks that check FORM-L
properties in overlapping time periods. An example is shown in
Fig. 5.
Fig. 5. Check minimum time duration in an overlapping time period
Fig. 6. Typical simulation results for the system of Fig. 5
The afterFor block defines that whenever Boolean
variable condition.y has a rising edge (= changes from
false to true) a time window of 3.5 s is defined. For every
such time window variable check.y must be true for at
least 1s. Since a new time window can start, before the
previous ended, a potentially growing set of time windows is
defined. For this, the afterFor block has a vector of
Boolean outputs and the minDuration block has a vector of
Boolean inputs. Whenever a new time window is started, the
afterFor block searches an element in the output vector
that was false at the last event instant and sets this element
to true for 3.5 s (see Fig. 6 for a case with two overlapping
time periods).

V. V
ERIFICATION OF AN
I
NTERMEDIATE
C
OOLING
S
YSTEM
BY EXPLOITING THE
M
ODELICA
_R
EQUIREMENTS
L
IBRARY
This section describes an application of the
Modelica_Requirements
library to a real case study
concerning an Intermediate Cooling System (SRI, Système de
Réfrigération Intermédiaire) along with the related main steps
and involved models in system requirements verification. The
purpose of the SRI is to provide clean, demineralized cooling
water to a number of heat producing 'client' systems. Fig. 7
shows the information and fluid flows between the SRI and
the entities constituting its environment. One can note that at
this stage, the SRI is considered as a black box.
Fig. 7. SRI Sequence of actions
In the limited space of this paper, not all assumptions and
requirements can be presented. As a first example, here are a
few assumptions and requirements regarding the clients. The
SRI has four clients. Each is composed of a heat source, a heat
exchanger and a control valve (under its control), and is
characterized by (i) the thermal power generated by its heat
source power, and the maximum powerMax;(ii) its specific
heat sH; (iii) its internal temperature tClient, and the
authorized maximum tClientMax. It is the SRI's duty to ensure
that the client can maintain its temperature below the
maximum, even when it must operate at full power; (iv) the
flow of water through its heat exchanger flow, and the
authorized maximum flowMax; (iv) its minimum acceptable
RW temperature tRWMin. If below, the client closes its valve.
Here is how that could be modeled in FORM-L. (keyword
specific means that each instance of class Client must
explicitly specify its own value):
class Client
// Power generated by the Client
Power power;
specific constant Power powerMax;
assumption a1 = check power isIn [0., powerMax];
// Client's specific heat
specific constant SpecificHeat sH;
// Client's internal temperature
Temperature tClient;
specific constant Temperature tClientMax;
requirement r1 = during operation check tClient ≤
tClientMax;
// Water flow through Client's heat exchanger
Flow flow;
specific constant Flow flowMax;
assumption a2 = check flow isIn [0., tFlowMax];
// Refreshed water temperature
specific constant Temperature tRWMin;
assumption a3 = during tRW < tRWMin check flow ==
0.*l/s;
end Client;
This Client class can also be implemented in Modelica via
the
Modelica_Requirements
library (see Fig. 8).
Fig. 8. Possible implementation of the Client class with the
Modelica_Requirements library
The second example concerns pumps and cavitation. At
the time when the SRI system requirements are specified,
there is no design yet. However, cooling systems are often
based on pumps. Also, the SRI must operate continuously for
long periods of time and is essential for the operation of the
overall installation. Thus, the installation architects require
that during normal operation, SRI pumps must not cavitate:
class Pump
external Boolean inOperation;
external Boolean cavitates;
end Pump;
object sri
...
external Boolean normalOp;
external Pump{} pumps;
requirement noCav =
forAll p in pumps // WHERE
during p.inOperation // WHEN
check not p.cavitates; // WHAT
...
end sri;
A. Verification of the system requirements model
Once the SRI system requirements are specified and
modeled in FORM-L, simulations can be used to verify that
the model correctly represents what is intended. As no
behavioral model is available yet, simulation is made using a
random generator of test cases consistent with the
assumptions. Normally, the assumptions are relative to the
environment of the system. To guide the test case generator to
produce particular test cases of interest, one can specify test
scenarios in the form of additional assumptions.

In the case of the SRI, the temperature of the cold source is
of particular importance. Thus, scenarios may be used to
generate cases with very cold CW (near freezing) and client
operating at low power, or CW at or near its maximum
expected (27.2°C), and clients are operating at full power.
B. Architectural models
The next step is for designers to determine one or more
architectures. An architecture is expressed in terms of
components constituting the system, and of assumptions
placed on the components and their interactions. In the first
design stages, the components are themselves considered as
black boxes, and the modeling is made with FORM-L.
In the case of the SRI, the architecture determines whether
pumps are used, and if so, their number (for example to
comply with fault-tolerance and availability requirements) as
shown in Fig. 9. The architectural model will be bound with
the requirements model (see following subsection), providing
it with information such as the effective set of pumps (here in
Fig. 9, pumps = {PO1, PO2, PO3}).
Fig. 9. Example of a possible architectural model
An architecture is verified in the same manner as the
requirements model: the random generator generates
components behaviors consistent with the assumptions placed
on each of them. The difference is that co-simulation of the
requirements and the architectural models can be used to
automatically verify whether the architecture violates
requirements. Thus, a large number of test cases can be
performed, and the test case generator can be guided to ensure
adequate test coverage. This facilitates the in-depth
examination (including dysfunctional analyses, such as failure
modes effects and criticality analysis) of many different
architectures.
C. Behavioral models
At some point in design refinement, it will be possible to
represent the design by a behavioral model, e.g. based on
Modelica and/or block diagrams as shown in Fig. 10. Again,
binding and co-simulation can be used to automatize the
verification that the initial requirements are satisfied.
Fig. 10. SRI behavioral model developed with EDF ThermoSysPro
VI. O
NGOING
W
ORK ON
B
INDING
M
ODELICA MODELS
:
C
ANDIDATE SOLUTIONS
In this section the binding problem is considered, i.e. the
possibility to establishing a matching among different system
models (such as architectural model, behavioral model,
property model) and enabling their composition obtaining, for
example, the automatic generation of verification models. In
particular, some possible binding solutions are briefly
described; further details could be provided in a possible
extension of the paper.
Bindings relate external variables, i.e. variables that are
used in a partial model but computed in another partial model
called an external model. Usually, different partial models use
different paradigms, because they are developed by teams of
different scope and expertise. Hence, the general relation
between an external variable y and the external model that
computes y is the following:
).
ˆ
(. xeHye
y
=
(6.1)
where e.y denotes the external variable y defined in object e,
and xe.
ˆdenotes the state(s)
x
of the object(s) e
ˆ in the
external model(s) that contain(s) sufficient information to
compute
ye.
. y
H
denotes the transformation to be applied to
the pieces of information
xe.
ˆ
provided by the external
model(s) in order to compute the external variable
ye
..
y
H
is
called the observation operator for
y
. The problem to be
solved is to construct (6.1) as automatically as possible
because there may be thousands of external variables to be
bound in a large model. To that end, the following types of
bindings are defined: (i) Class bindings (i.e. applicable to all
instances of the class); (ii) Instance bindings; (iii) Set bindings
for external variables that allow expressing generic
requirements on sets of objects using quantifiers. An algorithm
is needed to construct (6.1) automatically from the definition
of the bindings. The principle of the algorithm is given in
reference [16]; however, there are several possible ways to
implement it in Modelica For example, a scripting language
could be used to generate a Modelica model from a

description of the variable/model mapping (6.1). However, the
drawback is that typos or other errors are only detected when
translating the generated Modelica model. For this reason, it
seems useful to extend Modelica with appropriate language
elements [15]. A different approach for automating the
simulation model composition is proposed in [24] and refined
and evaluated in [21]. The focus of the proposed approach is
on maximizing information reuse, by defining the minimum
set of information necessary for enabling automated model
composition, and maximizing the decoupling by removing the
need for explicit interfaces. The approach is centered on the
concept of
mediator
that is an entity that relates a number of
clients
(model components that need certain input data or
parameters when simulated) to a number of
providers
(model
components that compute the required data).
VII.
C
ONCLUSION
The paper presented a perspective on the current status of
research in the field of system property modeling by focusing
on: (i) FORM-L, a new formal language based on temporal
logic for requirement modeling; (ii) a software library, based
on the Modelica language, that implements a subset of the
constructs provided by FORM-L so as to enable the visual
modeling of system properties as well as their verification
through simulation; (iii) a concrete exploitation of the proposal
for monitoring and assessing through simulation the behavior
of an Intermediate Cooling System (SRI). Ongoing works are
devoted to (i) evaluate, choose and refine one among the three
proposed solutions for the binding and automated composition
between requirements, structural, and behavioral models; (ii)
extend, improve and extensively experiment the presented
library in several application domains; (iii) allow to check the
consistency of the requirements among themselves.
A
CKNOWLEDGMENT
This paper is based on research performed within the
ITEA2 project MODRIO. Partial financial support of the
French DGE, the German BMBF, the Swedish VINNOVA are
highly appreciated.
R
EFERENCES
[1] International Council on Systems Engineering (INCOSE) -
http://www.incose.org/.
[2] ISO/IEC 15288:2008, “Systems and software engineering - System life
cycle processes,” International Organization for Standardization, 2008.
[3] Requirements Working Group INCOSE, “Guide for Writing
Requirements,” 2012.
[4] Object Management Group (OMG) - www.omg.org/.
[5] D.H. Rhodes and A.M. Ross, “Five Aspects of Engineering Complex
Systems,” Proceedings of the IEEE International Systems Conference
(SysCon), San Diego (CA), April 2010.
[6] F. Zambonelli, N.R. Jennings, and M. Wooldridge, “Developing
multiagent systems: the Gaia methodology,” ACM Transactions on
Software Engineering and Methodology, vol. 12(3), pp. 317-370, 2003.
[7] A. Garro, and A. Tundis, “Modeling of System Properties: research
challenges and promising solutions”, Proceedings of the 1st IEEE
International Symposium on Systems Engineering , Rome, Italy,
September 28-30, 2015.
[8] A. Jardin, D. Bouskela, T. Nguyen, N. Ruel, E. Thomas, R. Schoenig, S.
Loembé, and L. Chastanet. “Modelling of System Properties in a
Modelica Framework,” Proceedings of the 8th International Modelica
Conference, Dresden (TU), March 2011.
[9] Property Specification Language 1850, IEEE, 2010.
[10] T. Nguyen, “FORM-L: A MODELICA Extension for Properties
Modelling Illustrated on a Practical Example,” Proceedings of the 10th
International Modelica Conference, Lund (Sweden), March 2014.
[11] Modelica Association (2014): Modelica, A Unified Object-Oriented
Language for Systems Modeling. Language Specification, Version 3.3,
Revision 1. June 11.
[12] Modelica Association - https://www.modelica.org/.
[13] ITEA 3 MODRIO (Model Driven Physical Systems Operation) Project -
https://itea3.org/project/modrio.html.
[14] C.W. Johnson, “What are Emergent Properties and How Do They Affect
the Engineering of Complex Systems?” Journal of Reliability
Engineering & System Safety, vol. 91(12), pp. 1475–1481, 2006.
[15] H. Elmqvist, H. Olsson, and M. Otter, “Constructs for Meta Properties
Modeling in Modelica”, Proc. of the 11th International Modelica
Conference, Versailles (France), September 21-23, 2015.
[16] D. Bouskela, T. Nguyen, and A. Jardin, “Towards a Rigorous Approach
for Verifying Cyber-Physical Systems Against Requirements”, Proc. of
2015 IEEE Electrical Power and Energy Conference (EPEC), London,
Ontario, Canada, October 26-28.
[17] M. Jarke, “Requirement Tracing,” Association for Computing
Machinery. Communications of the ACM, vol. 41(12), December 1998.
[18] J. Wu, G Liu, and V. Lane, “Formal Verification,” CIS 841 Web Book,
1999.
[19] G. De Giacomo, M. Mecella, and F. Patrizi, “Automated Service
Composition Based on Behaviors: The Roman Model,” Web Services
Foundations, Springer, pp. 189-214, 2014.
[20] M. Rosenmüller, N. Siegmund, S. Apel, and G. Saake, “Flexible feature
binding in software products lines,” Journal of Automated Software
Engineering, vol. 18(2), pp. 163-197, June 2011.
[21] W. Schamai, L. Buffoni, and P. Fritzson, “An Approach to Automated
Model Composition Illustrated in the Context of Design Verification,”
Modeling, Identification and Control, vol. 35(2), pp. 79–91, 2014.
[22] M. Otter, N. Thuy, D. Bouskela, L. Buffoni, H. Elmqvist, P. Fritzson, A.
Garro, A.Jardin, H. Olsson, M. Payelleville, W. Schamai, E. Thomas,
and A.Tundis, “Formal Requirements Modeling for Simulation-Based
Verification,” Proceedings of the 11th International Modelica
Conference 2015, Paris (France), September 2015.
[23] L. Buffoni-Rogovchenko, P. Fritzson, M. Nyberg, A. Garro, and A.
Tundis, “Requirement Verification and Dependency Tracing during
Simulation in Modelica,” Proceedings of the 8th EUROSIM Congress
on Modelling and Simulation, Cardiff (United Kingdom), pp. 561-566,
September 2013.
[24] W. Schamai, Model-Based Verification of Dynamic System Behavior
against Requirements: Method, Language, and Tool. Ph.D. Thesis:
Linköping University Electronic Press, Dissertations, 1547, 2013.
[25] Systems Modeling Language (SysML) - www.omgsysml.org/.
[26] N. Shankar, “Combining theorem proving and model checking through
symbolic analysis,” In Catuscia Palamidessi, Concurrency Theory, vol.
1877, pp. 1-16, Springer-LNCS, 2000.
[27] Mathworks MATLAB-Simulink -
http://www.mathworks.com/products/simulink/.
[28] Mathworks Assertions and Check Dynamic Lower Bound -
http://it.mathworks.com/help/simulink/.
[29] IBM Rational DOORS - http://www-
03.ibm.com/software/products/en/ratidoor.
[30] Model Center -http://www.phoenix-int.com/modelcenter/integrate.php
[31] M. Kuhn, M. Otter, and T. Giese, “Model Based Specifications in
Aircraft Systems Design,” Proceedings of the 11th International
Modelica Conference, Versailles (France), September 21-23, 2015.