Co-Simulation of Cyber Physical Systems with Stochastic Behavior

(1)

with Stochastic Behaviour

Candidate:

Viviana CRESCITELLI

Supervisors: Prof. Cinzia BERNARDESCHI

Ing. Andrea DOMENICI

Ing. Maurizio PALMIERI

Master of Science in Embedded Computing Systems

(2)

(3)

(4)

(5)

Abstract

Cyber-Physical Systems (CPSs) are characterized by digital components control-ling physical equipment. Since physical systems often exhibit stochastic behavior, it is desirable to analyze such systems with tools capable of characterizing their dy-namics with statistical methods.

Co-simulation is the joint simulation of independent sub-models each repre-senting a component or subsystem of the overall system. The main advantage of co-simulation with respect to traditional single paradigm simulation lies in the mo-deling flexibility it affords in composing large models out of sub-models, each ex-pressed in the most appropriate formalism.

This thesis presents a methodology to include subsystems of Cyber-Physical Sy-stems represented as Stochastic Activity Networks into the INTO-CPS co-simulation framework. Stochastic Activity Network features related to stochastic models are studied in order to allow a complete integration of Stochastic Activity Networks into a co-simulation framework. In particular, this methodology has been used to study statistical properties of a system where a component is subject to random failure.

(6)

(7)

Acknowledgements

I would like to express my sincere gratitude to my supervisors Cinzia Bernarde-schi, Andrea Domenici and Maurizio Palmieri for the continuous support, patience, and motivation (even with 8 different time zones between us).

Thanks to my family, for keeping encouraging me to follow my passions and dreams.

Thanks to who is teaching me that the world is not so fearful. I am so happy that our paths finally crossed.

Thanks to Masunaga san, Sato san, Matsumoto san, Tanaka san and all the Hi-tachi Central Research Laboratory people, for being my family on the other side of the world before being my coworkers.

Thanks to my professors at King’s College London for opening my eyes and my mind.

Thanks to Jay and Xiaosung from Chongqing University for helping me chang-ing until the point of not recognizchang-ing me anymore.

Thanks to Kristoff, Joseph, Stefan and all the people I met at Aquibix for the good memories in the happy island.

Thanks to the mayor of Muide, because our meeting was the beginning of some-thing.

Thanks to Mariangela, Luis and Nisar, because without you it would not have been the same.

Thanks to all the people I met at the Department of Information Engineering, for sharing coffees and ideas.

Thanks to every person I met, from the biggest cities of the world until the bor-ders of the geographic maps, for inspiring me and for your part in my journey.

(8)

(9)

List of Figures

2.1 Activity Network . . . 5

2.2 SAN: Generic Component Module . . . 7

2.3 Möbius Tool Architecture . . . 9

2.4 Möbius: Composed Model . . . 11

2.5 Möbius: Reward Model . . . 12

2.6 Möbius: Study Model . . . 12

2.7 Example of XML File . . . 15

2.8 Overview of the structure of the INTO-CPS tool chain . . . 19

2.9 dseConfig file Example . . . 20

3.1 Extended SAN Model . . . 24

3.2 Extended Möbius model . . . 25

3.3 Data transmission trough UNIX pipes . . . 26

3.4 Calling Sequence between the Master to the SAN Slave . . . 27

3.5 Setting of the duration of the timed activity in Möbius . . . 29

3.6 Duration of the timed activity in Möbius as parameter of the Model.xml file . . . 30

3.7 Simulation Parameters tab on the Simulator editor in Möbius . . . 31

3.8 Command line options for the Möbius simulator. . . 32

3.9 Variables reset at the beginning of each batch . . . 33

3.10 Variables reset error at the beginning of each batch. . . 35

3.11 Accessing simulation time in Möbius . . . 35

4.1 Variables setting in Möbius: extended places example . . . 38

4.2 How to define global variables in Möbius . . . 38

4.3 Variables setting in Möbius: global variables . . . 39

4.4 Variables setting in the modelDescription.xml file . . . 39

4.5 Definition of the PV (Performance Variables . . . 40

4.6 Launch of the executable file . . . 41

4.7 fmi2Instantiate Example . . . 42

4.8 fmi2DoStep Example . . . 43

4.9 fmi2Terminate Example . . . 43

4.10 Functional Mock-up Unit (FMU) . . . 44

4.11 Connection between FMU instances in INTO-CPS . . . 44

4.12 Setting the value of the parameters in the INTO-CPS Application . . . 45

4.13 Processing of the file binary.dat . . . 46

4.14 Setting of the probabilities using the DSE . . . 47

5.1 Case study: Single Water Tank . . . 50

5.2 Architecture Structure Diagram defining the Single-tank Water Tank system composition . . . 51

5.3 Water Tank Extended Möbius model . . . 51

(12)

xii

5.7 Case Study: Single Water Tank Validation Model . . . 54

5.5 Case Study: Co-simulation Results p = 0.7 . . . 55

5.6 Case Study: Example of results obtained by processing the file bi-nary.dat . . . 56

5.8 Co-Simulation Results (1 batch) . . . 57

5.9 SAN Simulation Results (1 batch) . . . 58

(13)

List of Tables

5.1 Water tank Extended SAN Model: Gate functions. . . 52 5.2 Validation SAN Model: Gate functions. . . 55 5.3 Test Table . . . 57

(14)

(15)

List of Abbreviations

FMI Functional Mock-up Interface

FMU Functional Mock-up Unit

AN Activity Networks

SAN Stochastic Activity Networks

(16)

(17)

(18)

(19)

Chapter 1

Introduction

Cyber-Physical Systems (CPSs) integrate computation, networking, and physical processes. CPSs can be considered as the new generation of Embedded Systems [16] and require an interdisciplinary approach, merging theory of cybernetics, mecha-tronics, design, process and computer science. The design of such systems requires understanding the joint dynamics of computers, software, networks, and physical processes [24].

In particular, CPSs require advanced integration of abstractions and techniques that have been developed over the past years in disparate areas such as computer systems, that rely heavily on computation and networking, and physical systems that employ various engineering methods in domains such as mechanical, electrical, electronic, hydraulic, thermal, biological, and acoustic [23].

It is commonly acknowledged that integrating large heterogeneous systems is a challenging task [19] [20]. A major source of difficulties lies in premature assum-ptions about other components of the system that nevertheless have to be made early in the development [30].

Modeling and simulation techniques are used to mitigate these issues, since soft-ware models of components can be created and simulated before any physical pro-totype is built. The simulation of interactions between heterogeneous models, pos-sibly specified in different languages, is an open challenge [15], mostly dealt with on a case-by-case basis, making it difficult to reuse the models in other scenarios. To worsen the problem, suppliers of components are often interested in protecting their intellectual property, leading to the situation where the simulation needs to be made without access to the full models [29].

Co-Simulation (Co-operative Simulation) is a method that permits simulation of individual components by using different simulation tools simultaneously and collaboratively. Individual simulation tools exchange information such as system variables, time steps for synchronization, and control signals for orchestrating the co-operative simulation. This allow engineers to use different simulation tools to-gether to create virtual prototypes of entire cyber-physical systems.

Recent effort by the MODELISAR project developed a tool-independent stan-dard called Functional Mock-up Interface (FMI) [29] that has gained significant in-fluence. The FMI standard provides a well-defined specification and Application Programming Interface (API) to integrate simulated components.

The key idea is to have only a discrete set of synchronization points, at which times the subsystems exchange data. Between these points, the sub-systems are executed independently.

The data exchange is controlled by a master system that also manages time syn-chronization of sub-systems. Each sub-system is represented by a component called Functional Mockup Unit (FMU), which supports the FMI Standard.

(20)

2 Chapter 1. Introduction The strength of FMI lies in the fact that all simulation tools participating in the co-simulation follow the defined standard and as such provides for standardized access to model equations [23]. This permits coupling of continuous-time, discrete-time, and discrete-event aspects that are part of a cyber-physical system.

The foundations of FMI-based co-simulation for simple models are well establi-shed [10]. Simulation tool vendors are rapidly integrating FMI export and/or import functionality to support flexible multi-domain solutions. However, not all simula-tion tools can easily support the strictly specified FMI funcsimula-tion calls.

A well known co-simulation frameworks is INTO-CPS [18], developed by a project that aims to realize an integrated tool chain for the collaborative and multidisci-plinary engineering of cyber-physical systems.

1.1 Contribution

At the moment the INTO-CPS project presents some unexplored issues for cyber-physical systems. In particular, there is currently no support for the simulation of cyber-physical systems with stochastic behavior, although it is often important to analyze statistical properties related to stochastic behaviors, such as the probability of failure.

One formalism to specify these systems are Stochastic Activity Networks (SANs) [26], that allow formal modeling and statistical analysis via tools such as Möbius [14], a powerful tool for building performance and dependability models of stochas-tic systems.

This thesis is focused on integrating a simulator for stochastic systems in the INTO-CPS framework. Namely, a method to design an FMU for the Möbius simula-tor within the INTO-CPS framework is proposed. Allowing the simulation of a sub-model with stochastic behavior extends the analysis capabilities of co-simulation with statistical analysis, which provide accurate assessment of important system properties, such as dependability.

This thesis also presents a practical application to a case study and the validation of the results through the comparison of the co-simulation results with a system entirely modeled in Möbius.

1.2 Thesis organization

This thesis is organized as follows:

• Chapter 2 focuses on background notions. First, Stochastic Activity Networks and the Möbius tool are introduced. Then a presentation of the FMI Standard and the INTO-CPS framework is given.

• Chapter 3 covers the design of a SAN model to use in a co-simulation.

• Chapter 4 presents the implementation of the FMU for the model designed in the previous chapter and how it can be used for data analysis.

• Chapter 5 presents a case study that examines the integration of a water tank sub-model built as Stochastic Activity Network in the INTO-CPS co-simulation environment.

• Chapter 6 summarizes the thesis’ contribution and offers recommendations for improvements.

(21)

Chapter 2

Background

2.1 The SAN Formalism and the Möbius Tool

Model-based methods for evaluating computer systems can provide valuable in-sights into non-functional properties of a CPS, such as its performance, dependability and performability.

One approach in this regard has been the development of stochastic extensions to Petri nets.

These extensions permit the representation of timeliness (real-time constraints) as well as parallelism in a stochastic setting. As models for performability eval-uation [21], they also permit the representation of fault tolerance and degradable performance. Use of these nets was facilitated by the early recognition (see [22] and [9][1], for example) that, with an appropriate definition, their behavior could be represented as discrete-state Markov processes. Motivated by this representational power and solution capability, researchers sought to define particular variants of stochastic Petri nets well-suited to particular application needs or solution methods (DSPNs, GSPNs, SANs, and SRNs, for example).

One stochastic extension of these nets, known as “Stochastic Activity Networks”, was defined with the express purpose of facilitating unified performance and de-pendability (performability) evaluation, as well as more traditional performance and dependability evaluation.

Stochastic activity networks have been used since the mid- 1980s for performance and dependability [26]. They have been used as a modeling formalism in three mod-eling tools (METASAN [27] ,UltraSAN [28] and Möbius [7]) , and have been used to evaluate a wide range of systems.

This chapter provides the formal definitions and basic concepts associated with SANs and introduces the Möbius modeling tool. SANs are supported in the Möbius multi-paradigm modeling framework.

2.1.1 Activity Network

The desire to represent system characteristics of parallelism and timeliness, as well as fault tolerance and degradable performance, precipitated the development of gen-eral network-level performability models known as stochastic activity networks.

Stochastic activity networks are probabilistic extensions of “Activity Networks”; the nature of the extension is similar to the extension that constructs stochastic Petri nets from (classical) Petri nets.

(22)

4 Chapter 2. Background

Definitions

Activity Networks were defined by Sanders and Meyer in [26] as generalized Petri nets with the following primitives:

• Activities, can be of two types: timed activities and instantaneous activities. Each activity has a non-zero integral number of cases.

Timed activities represent the activities of the modeled system whose durations impact the system’s ability to perform. On the other hand, Instantaneous ac-tivities represent system acac-tivities that, relative to the performance variable in question, are completed in a negligible amount of time.

Cases associated with activities permit the realization of two types of spatial uncertainty. Uncertainty about which activities are enabled in a certain state is realized by cases associated with intervening instantaneous activities. Un-certainty about the next state assumed upon completion of a timed activity is realized by cases associated with that activity.

• Places, as in Petri nets.

• Input Gates, each of which has a finite set of inputs and one output. • Output Gates, each of which has a finite set of outputs and one input.

Each input or output gate is connected to a single activity. In addition, each input of an input gate or output of an output gate is connected to a unique place.

To define formally Activity Networks, Sanders and Meyer defined formally se-veral related concepts:

• P denote the set of all places of the network. • S is a set of places (S ⊆P)

• a marking of S is a mapping µ : S→ N.

• the set of possible markings of S is the set of functions M = {µ|µ: S→ N}.

With these definitions in mind, Sanders and Meyer defined formally the follow-ing primitives:

• An input gate is defined to be a triple,(G, e, f), where G ⊆ P is the set of input places associated with the gate; e : MG → {0, 1}is the enabling predicate of the

gate, and f : MG →MGis the input function of the gate.

• An output gate is defined to be a pair: (G, f),where G ⊆ P is the set of output places associated with the gate and f : MG→ MGis an output function of the gate.

• an Activity Network can be formally defined at this point in terms of allowable interconnections between these model primitives.

In [26], Sanders and Meyer defined an Activity Network(AN)as an eight-tuple: AN = (P, A, I, O, γ, θ, ι, o)where P is some finite set of places, A is a finite set of activities, I is a finite set of input gates, and O is a finite set of output gates.

Furthermore, γ : A → N+ specifies the number of cases for each activity, and

θ: A→ {Timed, Instantaneous}specifies the type of each activity.

The net structure is specified via the functions ι and o. ι : I→ A maps input gates to activities, while o : O → {(a, c)|a ∈ A and c ∈ {1, 2, ..., γ(a)}} maps output gates to cases of activities.

(23)

Graphical Representation

To aid in the modeling process, a graphical representation for AN is typically em-ployed. The graphical representation is not only more compact, but it also provides greater insight into the behavior of the network.

FIGURE2.1: Graphical Activity Network Representation

Fig. 2.1 shows a graphical representation of an activity network and it is taken from [26]. In the Figure:

• Places are represented by circles(A, B, C).

• Timed activities(T1 and T2)are represented as hollow ovals. • Instantaneous activities are represented by solid bars(I1).

• Cases associated with an activity are represented by small circles on one side of the activity (as on T1).

• An activity with only one case is represented with no circles on the output side (as on T2).

• Gates are represented by triangles. G2 is an example of an input gate, while G1 is an example of an output gate.

Definition of a Stochastic Activity Network

A Stochastic Activity Network (SAN) was defined formally in [26] as a five-tuple: SAN= (AN, µ0, C, F, G)where:

(24)

6 Chapter 2. Background 1. AN= (P, A, I, O, γ, τ, ι, o)is an AN.

2. µ0is the initial marking and is a stable marking in which AN is stabilizing.

3. C is the case distribution assignment, an assignment of functions to activities such that for any activity a, C{a} : MIP(a)∪OP(a)× {1, ..., γ(a)} → [0, 1]. Furthermore,

for any activity a and marking µ ∈ M_IP(a)∪OP(a)in which a is enabled, Ca(µ,·)

is a probability distribution called the case distribution of a in µ.

4. F is the activity time distribution function assignment, an assignment of con-tinuous functions to timed activities such that for any timed activity a, Fa :

MP×IR → [0, 1]. Furthermore, for any stable marking µ ∈ MP and timed activity a that is enabled in µ, Fa(µ,·)is a continuous probability distribution

function called the activity time distribution function of a in µ; Fa(µ, τ) =0 if τ≤0.

5. G is the reactivation function assignment, an assignment of functions to timed activities such that for any timed activity a, Ga : MP →P(MP), where P(MP)

denotes the power set of MP.

2.1.2 SAN: Graphical Representation

SANs are directed graphs with four disjoint sets of nodes: places, input gates, output gates, and activities.

Places are drawn as circles, input gates as left-pointing triangles, output gates as right- pointing triangles, instantaneous activities as narrow vertical bars, and timed activities as thick vertical bars. Cases are drawn as small circles on the right side of activities. Gates with default (standard PN) enabling predicates and firing rules are not shown.

The topology of a SAN is defined by its input and output gates and by two func-tions that map input gates to activities and pairs (activity, case) to output gates, respec-tively.

Each input (output) gate has a set of input (output) places. Each SAN activity may be:

• instantaneous; • timed.

Timed activities represent actions with a duration affecting the performance of the modeled system, e.g., message transmission time, recovery time, time to fail.

The duration of each timed activity is expressed via a time distribution function. Any instantaneous or timed activity may have mutually exclusive outcomes, called cases, chosen probabilistically according to the case distribution of the activity. Cases can be used to model probabilistic behaviors, e.g., the failure probability of a component.

An activity completes when its (possibly instantaneous) execution terminates [5]. The state of a SAN is defined by its marking, i.e., a function that, at each step of the net’s evolution, maps the places to non-negative integers (called the number of tokens of the place). SANs enable the user to specify any desired enabling condition and firing rule for each activity. This is accomplished by associating an enabling predicate and an input function to each input gate, and an output function to each output gate.

(25)

The enabling predicate is a Boolean function of the marking of the gate’s input places. The input and output functions compute the next marking of the input and output places, respectively, given their current marking.

An example of a SAN is shown in 2.2.

FIGURE2.2: SAN: Generic Component Module

In the Figure, ioports, computer_failed, memory_failed, cpus and errorhandlers are places. Each place contains a certain number of tokens, which represents the marking of the place. The set of all place markings represents the marking of the stochastic ac-tivity network. The meaning of the marking of a place can be arbitrary. For example, the number of tokens in a place could represent a number of objects, or an object of a certain type.

In the figure, io_port_failure is a timed activity. Each timed activity has an ac-tivity time distribution function associated with its duration. In particular, acac-tivity io_port_failure has three cases (circles on the right side of the activity). Cases model uncertainty associated with the completion of an activity. Each case stands for a possible outcome, such as a failure mode in a faulty system.

Stochastic Activity Network Behavior

The evolution of a SAN [4], starting from a given marking µ , may be described as follows:

• The instantaneous activities enabled in µ complete in some unspecified order; • if no instantaneous activities are enabled in µ , the enabled (timed) activities

(26)

8 Chapter 2. Background • the completion times of each active (timed) activity are computed stochasti-cally, according to the respective time distributions; the activity with the earli-est completion time is selected for completion;

• when an activity (timed or not) completes, one of its cases is selected according to the case distribution, and the next marking µ0is computed by evaluating the input and output functions;

• if an activity that was active in µ is no longer enabled in µ0 , it is removed from the set of active activities.

2.1.3 The Möbius Tool

A popular tool to build and analyses SANs is Möbius [7]. The tool offers a hierar-chical modeling paradigm, allowing one to build complex models by specifying the behavior of individual components and combining them to create a complete system model through the Rep and Join operators. The Rep operator constructs a number of replicas of an individual component while the Join operator groups individual and/or replicated components [3].

Möbius [7] is a software tool that provides a comprehensive, easy-to-use and flexible graphical environment for model-based system analysis. The main features of the tool include:

• Multiple high-level modeling formalisms, including, among others, Stochastic Activity Networks (SANs) [28] and PEPA fault trees .

• The possibility of extending the behavior of a SAN model by attaching C++ functions to input and output gates.

• A hierarchical modeling paradigm, allowing one to build complex models by first specifying the behavior of individual components and then by combining the components to create a model of the complete system;

• Customized measures of system properties;

• Distributed discrete-event simulation, to evaluate measures using efficient sim-ulation algorithms.

The Möbius tool introduces two extensions to the SAN formalism:

1. extended places: places whose marking is a complex data structure instead of a non-negative integer (graphically represented as orange circles to distinguish from places that are instead blue).

2. shared variables: (possibly complex) data structures that are shared between different SANs, thus enabling them to communicate.

Enabling predicates and input and output functions of the gates are specified as C++ code. Models composed with Join and Rep operators interact via place sharing. Properties of interest are specified with reward functions. A reward function spec-ifies how to measure a property on the basis of the SAN marking. Measurements can be conducted at specific time instants, over periods of time, or when the system reaches a steady state. Möbius provides an infrastructure to support multiple inter-acting modeling formalisms and solvers [14]. It is also extensible in that new for-malisms and solvers can be added to the tool without changing existing forfor-malisms

(27)

or solvers. It provides this capability through the use of an abstract functional inter-face (AFI [8]) that uses abstract classes to provide a formalism-independent interinter-face that allows models expressed in multiple formalisms to interact with one another and with multiple solvers.

Architecture

The various components of the Möbius tool are divided into two categories: model specification components and model solution components. Models are specified through a front-end, which consists of a set of graphical user interfaces running within a main Java interface. The tool is organized as a series of editors, classified according to model types. Each formalism or solver supported by Möbius has a corresponding editor in the main interface. The Möbius tool is designed so that new formalisms can be implemented and employed if they adhere to the AFI [14]. To accommodate new formalisms, the Möbius application loads every formalism-specific editor dy-namically from a Java archive (jar file). This design allows new model editors to be incorporated without modification of the existing code, supporting the extensibil-ity of the Möbius tool. Models can be solved either analytically/ numerically or by simulation. From each model, C++ source code is generated and compiled, and the object files are linked together to form a library archive. These libraries are linked together along with the Möbius base libraries to form the executable for the solver. The Möbius base libraries implement the base components of the particular model formalism, the AFI, and the solver algorithms. The organization of Möbius com-ponents to support this model construction procedure is shown in Fig. 2.3, that is taken from the Möbius user manual. The components of the main application will be described at the end of this subsection.

(28)

10 Chapter 2. Background The front-end is used to launch the solvers and view the generated results. For example, if a simulation is being conducted, the model is compiled and linked to the Möbius simulation libraries, and the front end may launch multiple processes on multiple remote and local machines. Each executable simulates the model and reports its observations back to the front-end using UNIX sockets. The AFI views models as consisting of two sets of components: state variables, which store model state, and actions, which change model state. The Möbius framework [14] specifies additional characteristics of models, such as properties, that are used to preserve specialized model features that may be exploited in composition or solution (such as the property that allows a model to feature only exponentially distributed activities). The core of the AFI is built from three base classes: one class for state variables, one for actions, and one defining behavior that the model as a whole should be able to provide. Each of these classes defines a minimal set of methods that are used by Möbius when building composed models, specifying reward variables, and solving models.

Project Elements

Every Möbius project is made of 6 kind of elements :

Atomic Model Each model is composed of one or more sub-models, also re-ferred to as atomic models.

Atomic models are the basic building blocks of a model. Since multiple for-malisms can be supported in Möbius, the user can use different forfor-malisms to model different aspects of his/her model. New formalisms are constantly added into the tool as needed. These models also allow the definition of global variables, usually used to represent rate of events. An example of Atomic Model is shown in Fig. 2.2.

Composed Model The Möbius framework allows the construction of composed models from previously defined atomic models. This allows the modeler to adopt a hierarchical approach to modeling, by constructing sub-models as meaningful units and then placing them together in a well-defined manner to construct a model of a system. This is accomplished by the state-sharing approach, which links submodels together by identifying sets of state variables.

Currently, the Möbius tool features two composed model formalisms that use equivalence sharing:

• the Join operator is used to compose different sub-models; • the Rep operator is used to compose copies of a same sub-model. An example of Composed Model is shown in Fig. 2.4.

(29)

FIGURE2.4: Möbius Tool: Composed Model Example

Reward Model A reward model (see Fig. 2.5) is a set of Performance Variable (PV) that describe system properties. A PV is computed by performing certain op-erations (e.g. mean) on the set of values returned by an associated Reward Function (RF).

The values of the RF can be evaluated: • at specified times (Instant of time PV’s)

• accumulated over a specified interval of time (Interval of time PV’s)

• averaged over a specified interval of time (Time averaged interval of time PV’s) • evaluated when the system has reached a steady state (Steady state PV’s).

Once the rate and impulse rewards are defined, the desired statistics on the measure must be specified. The options include solving for the mean, variance, or distribution of the measure, or for the probability that the measure will fall within a specified range.

(30)

12 Chapter 2. Background

FIGURE2.5: Möbius Tool: Reward Example

Study During the specification of atomic, composed, and reward models in the tool, global variables can be used to parameterize model characteristics. A global variable is a variable that is used in one or more models, but not given a specific value. Models are solved after each global variable is assigned a specific value. One of such assignments forms an experiment. Experiments can be grouped together to form a study.

A study defines sets of values that will be assigned to each global variable. In a range study, experiments are generated for all possible combinations of variable values, while in a set study only user-defined combinations are used. An example of range study is shown in Fig. 2.6.

FIGURE2.6: Möbius Tool: Study Example

Transient Solver The transient solver (trs) solves for instant-of-time variables with t < ∞ using randomization. It calculates the mean and variance of each

per-formability variable for the time points defined for the reward variable within the reward model. The means and variances are given in textual format in an output

(31)

file. In order to solve a model, its state space must be generated by a transformer. We are going to use the State Space Generator.

2.2 The FMI Standard and INTO-CPS

This section reports on the FMI standard and the INTO-CPS project.

2.2.1 The FMI Standard

FMI (Functional Mock-up Interface)[13] is an open standard for the co-simulation of dynamic systems.

The standard specifies an interface for exporting and importing simulation mod-els.

This means that the user can select the tool best suited for each type of sub-system before integrating the different components that form the CPS in a co-simulation framework. FMI allows also to share models promoting their reuse for other pur-poses, using tools that match different needs, skills, and preferences.

The goal of this interface is to be able to fully represent the models (physical, me-chanical, electrical, etc.) used for the simulation through functions, structures and predefined data. In this way it is provided great ease of interaction with the simula-tion tools, as well as between different models in a co-simulasimula-tion environment.

The vision of FMI is to support this approach: "if the real product is to be assem-bled from a wide range of parts interacting in complex ways, each controlled by a complex set of physical laws, then it should be possible to create a virtual product that can be assembled from a set of models that each represents a combination of parts assembled digitally" [13].

FMI was initially developed as part of the MODELISAR European project [11], started in 2008. This project focused on using the standard FMI in the field of au-tomotive engineering, and partly on the AUTOSAR standard [2]. For these reasons, FMI is more widely used within industrial development tools of the partner compa-nies of the MODELISAR project (DassaultSystemes, Daimler AG, Qtronic, Simpack-GmbH, Trialog, Volkswagen A.G, Volvo, to name a few).

However, the specification of the FMI standard is not strictly linked with the models of car simulations, and therefore the use of this standard can also be found in other areas, such as energy, rail, aeronautical, aerospace [11].

As reported in [6], "the number of simulation tools based on FMI is growing rapidly, thanks to some features, such as the ease of use they confer to simulation platforms, the ability to protect intellectual property and to guarantee licenses in a very facilitated way to the developed simulators".

The FMI standard is composed of two main parts: FMI for Model Exchange and FMI for Co-Simulation. FMI for Model Exchange is about the creation of models that implement the interface, while FMI for Co-Simulation is used to define the interac-tions between models, when they are put in the same simulation environment.

In the next sections these two main components of the standard will be explained more in details.

2.2.2 FMI for Model Exchange

This first part of the FMI standard defines an interface to model a dynamic system described by differential, algebraic and discrete-time equations and to evaluate these equations as needed in different simulation environments. The interface allows the

(32)

14 Chapter 2. Background user to create executable models that represent simple sub-systems of different dis-ciplines, or dynamic compound systems directly simulable [11]. The models thus generated are called FMU (Functional Mock-Up Unit). The interface consists of the following parts:

• Model interface: all the functions necessary for the description of the model are processed by performing standardized functions in the ’C’ language. The use of this programming language is due to its high portability between vari-ous systems (note that the ’C’ language is used in almost all embedded control systems), and has greater efficiency compared with other languages;

• Model description scheme: illustrates the structure and content of an XML file (Extensible Markup Language) generated by the modeling tools. The XML file contains the definitions of the model variables in a standard form. In this way it is possible to separate these definitions from the actual running instances of the model. This leads to a reduction the costs of obtaining such information, since the opposite would result in a redundancy of information on variables. The graphical representation of the model description is carried out by mod-elling tools that implement the FMI interface.

Description Schema of the Model

All the information of a model, excluding its equations, are saved in a files in XML format following a well-defined structure in a schema XSD (XML Schema Defini-tion). In particular, the description contains the variables of the model and their attributes, such as the name, the unit of measurement, the initial value of default and so on. Fig. 2.7 is an example of the XML file that describes the model, extracted from [12].

The firt part of the file (fmiModelDescription) contains general information like the fmi version (fmiVersion) and the model name (modelName).

The XML element that describes the model variables, ModelVariables, is the cen-tral part of the description of the model. It consists of an ordered set of elements ScalarVariable, that represents a single variable, of a single type between real, in- te-ger, Boolean, string, or a type defined within the TypeDefinitions element.

Some of the attributes of a ScalarVariable element are:

• name: the full and univocal name of the variable (the variables are identified from the name in an FMU)

• variability: defines how the values for this variable can change. It can take only some values including:

– "constant": the value is fixed and does not change.

– "parameter": the value does not change after the initialization of the model.

– "discrete": the value can change during initialization and with i events.

– "continuous": there are no restrictions, but only real variables can have this value.

• causality: defines how the variable is made visible outside the model. It is a necessary information when there are different connections FMU models. It can only take the following values:

(33)

FIGURE2.7: Example of XML File

– "input": the value can be given from outside, initially it takes the value assigned to the start attribute.

– "output": the value can be used in a connection.

– "internal": to the variable you can only ask the value to save it as result, and it is possible to assign a value only before the end of initialization.

– "none": the variable does not affect the model equations, and only serves to the tools that perform the simulation.

Finally, the ScalarVariable element can contain a DirectDependency element, which defines the dependence of an output variable from the inputs. This element is only present in the variables that have the causality attribute equal to "Output". If not present, it implies that the (output) variable depends directly from all input vari-ables. If present, list the names of all the input variables (with causality = "input") on which it depends directly, each represented by a Name element.

2.2.3 FMI for Co-Simulation

(34)

16 Chapter 2. Background The standard defines that in a co-simulation environment the exchange of data between two subsystems only takes place in some discrete points of communica-tion (communicacommunica-tion point). Subsystems in the period between two communicacommunica-tion points are executed independently each with its own solver.

The algorithm for controlling the exchange of data between the subsystems is called Master Algorithm and takes care of the synchronization of communication be-tween the solver of the simulations, which in this hierarchy are better known as Slaves. FMI for Co-Simulation provides an interface for communication between the master and the slaves, and supports an extended and generic class of master algo-rithms. Note however that the definition of the master algorithms is not part of interface.

The model description presented in the previous section contains information that can help the master to specify how the communication between models takes place in a co-simulation environment. In addition to that information, the interface FMI for Co-Simulation adds other specifications to the slaves, which are of the capa-bilities indicators (capability flags) to characterize the ability of supporting advanced algorithm masters, such as the possibility of using variable duration steps.

The interface supports all the phases of the simulation process, starting from the setting and initialization of the models, where the master analyzes the connections between the various models, load the necessary FMUs into memory, creates all the instances and assigns their initial values. The next step is time integration, in which each model is simulated individually in time intervals and data exchange is orches-trated by the master algorithm in communication points defined before. Finally, the data are processed retrospectively and the results are displayed, each in independent order for any subsystem, and the memory used by the FMUs is freed.

The interface, similar to FMI for Model Exchange, consists of two parts: co-simulation interface and the co-co-simulation description scheme. The first consists of a series of functions in the ’C’ language for the exchange of values between input and output, and for the exchange of information related to the status (status) of the in-stances.

The second defines the schema of a file in XML format, which contains, in addi-tion to the model informaaddi-tion of the Model Exchange interface, addiaddi-tional informa-tion related to the simulainforma-tion.

The description of the co-simulation interface is given in the next section.

2.2.4 Description of an FMU

The FMI (Functional Mock-up Interface) defines an interface to be implemented by an executable called FMU (Functional Mock-up Unit). The FMI functions are used (called) by a simulation environment to create one or more instances of the FMU and to simulate them, typically together with other models. The goal of this inter-face is that calling an FMU in a simulation environment is reasonably simple. No provisions are provided in this thesis how to generate an FMU from a modeling environment.

An FMU model is a file with the extension .fmu, which actually consists of a zip file that "packs" the following components:

• The C sources of the FMU, including the needed run-time libraries used in the model, and/or binaries for one or several target machines, such as Windows dynamic link libraries (.dll) or Linux shared object libraries (.so). The latter solution is especially used if the FMU provider wants to hide the source code

(35)

to secure the contained know-how or to allow a fully automatic import of the FMU in another simulation environment. An FMU may contain physical pa-rameters or geometrical dimensions, which should not be disclosed. On the other hand, some functionality requires source code.

• An XML-file contains the definition of all variables of the FMU that are ex-posed to the environment in which the FMU shall be used, as well as other model information. It is then possible to run the FMU on a target system. • Other files with additional information for the model (documentation

integra-tive, images, other).

All relevant files are stored in a zip file with a pre-defined structure. The imple-mentation must implement all the functions of FMI for Model Exchange or all the functions of FMI for Co-Simulation or both. The extension of the zip file must be “.fmu”, for example “HybridVehicle.fmu”.

The compression method used for the zip file must be “deflate” [(most free tools, for example zlib, offer only the common compression method "deflate")]. Every FMU is distributed with its own zip file.

2.2.5 Description of a model using the FMI interface

For the description of a model using the FMI interface, it is sufficient to define only the main source of the model and the model description file (in XML format). For this reason, this source is a fundamental element for the representation of the model where the main characteristics are defined through variables and functions that will be described. Initially, within this file, variables are defined, which they represent information also contained in the description of the model, to create a defined con-nection between the two files, creating a single representation of the template. These variables are the model identifier, MODEL IDENTIFIER, and the unique identifier GUID (GloballyUniqueIDentifier). Later, they are defined parameters that indicate the number of variables for each type, the number of states, and the number of event indicators. The values of these parameters are used from the functions inside the fmuTemplate.c file. Subsequently, the model variables are defined, each represented by a unique name, to which it is associated a value, which is the reference value of the variables within the array of type of membership (valuereference). The variables which serve to represent the state of the simulation are inserted into the STATES array. The following functions are implemented: setStartValues, initialize, getReal, getEventIndicator and eventUpdate.

These functions are fundamental for the description of the model and its dynam-ics:

• setStartValues: is called by instantiateModel, and serves to establish good val-ues for all the variables of the instance that admit an initial value.

• initialize: called by init when the co-simulations starts.

• getReal: called from more than one function, it is used to return the values for all the variables of the instance. The returned values are the result of a calculation made with the linear or differential formulas of the system written in ’C’ language.

• getEventIndicator: is called by fmiGetEventIndicators and fmi2DoStep, and serves to indicate event indicators.

(36)

18 Chapter 2. Background • eventUpdate: is called by more than one function, when an event is encoun-tered. It is used to execute the functionalities implemented inside and to decide the next event.

2.2.6 INTO-CPS

INTO-CPS [18] is a project that aims to realize the goal of integrated tool chains for the collaborative and multidisciplinary engineering of dependable cyber-physical systems.

As stated in [18]: "The CPS engineer faces a large design space that is pro-hibitively expensive to explore with physical prototypes, while the need for depend-ability of the CPS as a whole, means that there is a need for well-founded validation and verification techniques. The vision of the INTO-CPS consortium is that CPS engineers should be able to deploy a wide range of tools to support model-based design and analysis, rather than relying on a single factotum."

Existing tools in their application domains are integrated using Functional Mockup Interface (FMI)-compatible co-simulation.

In addiction, Test Automation (TA) and Design Space Exploration (DSE) of CPSs are supported.

In the following, an overview of the INTO-CPS project objectives, reported from [17], is provided:

1. Build an open, well-founded tool chain for multidisciplinary model-based design of CPS that covers the full development life cycle of CPS. The tool chain aims to sup-port multiple modelling paradigms and covers multiple development activi-ties, including requirements modelling, analysis, simulation, validation, verifi-cation, and traceability of artifacts throughout all development activities across disciplinary boundaries.

2. To provide a sound semantic basis for the tool chain. One of the objectives of the project is to produce mathematical foundations to support CPS multi-modelling and to underpin the tool chain. This will include semantics for FMI co-simulation, as well as SysML, discrete-event and continuous-time paradigms.

3. To provide practical methods in the form of guidelines and patterns that support the tool chain. The INTO-CPS methodology is developed to ensure that adoption of the tool chain is cost-effective, providing industrial users with pragmatic guidance to help them determine the best modelling technologies and patterns to meet their needs.

4. To demonstrate in an industrial setting the effectiveness of the methods and tools in a variety of application domains. Four complementary industry case studies have been selected from four distinct domains that currently experience pressure to develop reliable CPSs (automotive, agricultural, railways and building au-tomation).

5. To form an INTO-CPS Association to ensure that project results extend beyond the life of the project. Membership of the Association allows future case study owners access to information, training, and competitively priced licenses at various levels of support. Tool vendors will be offered services to help integrate their products into the tool chain.

(37)

Workflow in the INTO-CPS Tool Suite

The INTO-CPS tool chain consists of several special-purpose tools from a number of different providers. Fig. 2.8 shows an overview of the INTO-CPS toolchain, from the INTO-CPS web page [18].

The INTO-CPS Application is the main interface to INTO-CPS and represents an easy way to configure and to run co-simulations.

It allows the user to:

• design co-simulations from scratch;

• assemble co-simulations using existing FMUs; • configure how simulations are executed.

FIGURE2.8: Overview of the structure of the INTO-CPS tool chain [from http://into-cps.org/]

The first step to run a co-simulation is the design of a multi-model. At this stage it is possible to define a multi-model from scratch and to specify the characteristics and the connection topology of FMUs yet to be developed, as well as importing existing FMUs. The result of the overall design is a multi-model, that can then be analyzed through co-simulation.

In the case where no FMUs exist yet, a number of model Description.xml files are generated from this multi-model.

Once a multi-model has been designed and populated with FMUs, theCo-simulation Orchestration Engine (COE) is invoked to execute a co-simulation run.

The INTO-CPS Application allows the user to configure a co-simulation by run-ning it with different simulation parameter values and observing the effect of the different values on the co-simulation outcome.

(38)

20 Chapter 2. Background It also gives the user the option of looking for optimal simulation parameter values by entering a Design Space Exploration (DSE) phase. At this stage, ranges are defined for various parameters that will be explored, in an intelligent way, by a design space exploration engine that searches for optimal parameter values based on defined optimization conditions. The DSE engine interacts directly with the COE and controls the conditions under which the co-simulation is executed (parameters, searching algorithm, etc). The Design Space Exploration will be described more in details in the next subsection.

Design Space Exploration (DSE)

The Design Space Exploration is a module that comprises configuration files, python scripts, analysis files and other files used to store DSE progress and results.

In a project folder, the primary element is the dseConfig which contains details defining the design space to be searched, how to search it, how to measure the results and how to compare results.

Fig. 2.9 is an example of dseConfig file relative to the water tank case study used in this thesis. The case study concern the control of water level in a tank where the level sensor is subject to faults.

FIGURE2.9: dseConfig file Example

As shown in the figure, the search algorithm is of type exhaustive, and two objec-tive functions are defined, cumulaobjec-tiveDeviation and vCount. The former is a measure of the level deviation from the reference value specified in the model, and the latter is the number of times that the tank valve is opened or closed.

(39)

The experiment varies the two design parameters of the study, that are minlevel and maxlevel. The analysis uses the Pareto method for ranking.

The COE_handler.py script sends the contents of the dseConfig files to the COE, launches the simulation, retrieves the results and saves them in a results.csv file.

The search algorithm (in this case of type "exaustive") then invokes the analysis defined in the dseConfig file on the raw results. It makes use of objective scripts that can be already built-in and/or user-defined (represented in this example by analy-sis.py). Both types of analysis store their results (objective values) in a objectives.json file appropriate for the simulation.

The results in the objectives.json files are used by the ranking script ("pareto" in the figure), to compare all results. The resulting rankings over the whole DSE exper-iment are then stored in a ranking file. Finally the stored rankings are used by the output scripts which generate the dseResult that is presented to the user in .txt and .html format.

(40)

(41)

Chapter 3

Design of a SAN Model for

Co-Simulation

3.1 Introduction

The aim of this study is to present the implementation of a co-simulation methodol-ogy to define the integration of a sub-model built as a Stochastic Activity Network and simulated on Möbius in the INTO-CPS co-simulation environment.

Cyber-physical systems integrate the physical world and the cyber world. Nowa-days it is still a challenging problem to model and to analyze these systems be-cause of their intrinsic stochastic behaviors. In fact, for communication with physical world, a large number of computational units often need to be deployed in uncon-trollable open environments with uncertain behaviors of human, or in environments that can influence the computation of systems.

To date, the Stochastic Activity Networks features related to stochastic models have never been integrated in a co-simulation framework.

A stochastic simulation is a simulation that traces the evolution of variables that can change stochastically with certain probabilities.

Notice that performing a stochastic simulation requires running multiple batches in the same co-simulation run. This issue implies that the state of the FMUs has to be reset at the beginning of each new batch.

As first approach to facilitate the co-simulation of stochastic CPSs, we consider a solution for a restricted class of systems, characterized by the assumption that all the FMUs interacting with the SAN sub-model are stateless.

Moreover, to support the integration of the sub-model built as a Stochastic Activ-ity Networks in the INTO-CPS framework, the time elapsed in each execution path must be equal to the co-simulation step.

We consider that the SAN Model is provided with only one timed activity with duration equal to the duration of the co-simulation step and that all the other activities of the model are of type instantaneous.

Our objective in this work is to leave Möbius the task to perform all the stochastic analysis, without changing the rest of the co-simulation environment.

For this reason our methodology relies on using the off-line simulation capabili-ties offered by Möbius to generate the simulation results.

These points will be clarified in the next sections.

This chapter describes the overall setup used to integrate, a sub-model built as a Stochastic Activity Network and simulated on Möbius in the INTO-CPS co-simulation environment.

(42)

24 Chapter 3. Design of a SAN Model for Co-Simulation

3.2 Design of the extended Möbius model

This section describes the method used to design an FMU for a Stochastic Activity Network Simulator (Möbius [14]) and to integrate it in a co-simulation environment (INTO-CPS [18]).

3.2.1 Description Schema

Our approach in this work was to consider the overall SAN model (Extended SAN Model) as divided in two parts:

1. The SAN Model of the sub-system (SAN Model);

2. A Synchronization Block that enables/disables the SAN Model and that is responsible for the synchronization process between the Extended SAN Model and the Core Orchestration Engine of the co-simulation tool.

The scheme is shown in Fig. 3.1.

FIGURE3.1: Extended SAN Model

The SAN model is enabled/disabled by a signal (enable in Fig 3.1) that is sent from the synchronization block.

On the other hand, the synchronization block takes as input a synchronization signal (synch in Fig. 3.1) that the SAN model sends at the end of each model simula-tion step.

The Stochastic Activity Networks Model of the scheme in Fig. 3.1 is given in Fig. 3.2: In Fig. 3.2, timed activity synch_block models the behaviour of the block synchronization block, while the block SAN Model models the behavior of the SAN Model of Fig. 3.1:

(43)

FIGURE3.2: Extended Möbius model

• place synch: synch→Mark() =1 as initial value. • place enable: enable→ Mark() =0 as initial value.

• input gate ig_synch: it is enabled when synch → Mark() = 1. This input gate enables the timed activity ta_synch and sets synch → Mark() =0.

• timed activity ta_synch: timed activity with deterministic duration equal to the co-simulation step used in the INTO-CPS simulation. Explanation of the mean-ing of this design choice will be given in the next section (Model Constraints). • output gate og_synch: The output function of gate og_synch reads the control

signal from standard input, stores its value in an extended place, and enables the block SAN Model (by setting enable → Mark() = 1 ) to start a simulation step.

The synchronization block receives as input the outputs of the other FMUs that are necessary for the simulation of the SAN Model. The synchronization block im-plements the mechanism that makes possible the synchronization between the SAN Model, the other FMUs that compose the overall system and the COE of INTO-CPS.

The sub-model is represented here with:

• input gate ig_SAN_Model: it is enabled when enable→ Mark() =1. The firing of this input activity enables the block SAN_Model and sets enable→ Mark() =

0.

• SAN Model SAN_Model: Models the behaviour of SAN Model block in Fig. 3.1. • output gate og_SAN_Model: at each simulation step computes the outputs that are needed by the other FMUs that compose the overall CPS and re-enables the synchronization block by setting synch →Mark() =1.

3.2.2 Data transmission through UNIX pipes

In the FMI standard, the models to be co-simulated are exported by their tools as Functional Mockup Units (FMUs) – compiled C code and XML-based model de-scriptions - that specify the inputs and outputs of the model, thus abstracting away

(44)

26 Chapter 3. Design of a SAN Model for Co-Simulation the internal complexity and domain-specificity of the model. A master algorithm is responsible for executing the co-simulation by coordinating the exchange of data between FMUs and advancing overall co-simulation time. In the INTO-CPS project, the implementation of the master algorithm and execution of co-simulations are han-dled by a tool called Co-simulation Orchestration Engine (COE) from the INTO-CPS project.

The extended SAN Model has to receive inputs from the other FMUs and has to provide the results of the simulation to the other components of the system through the COE of INTO-CPS.

In this work we simulated the system under the Linux environment (for com-patibility with previous work) and we handled all the communications between the extended SAN Model and the FMI interface of the FMU with UNIX pipes.

We exploited the capability of executing C code in input gates and output gates of the SAN Model and of reading/writing from file (pipes).

The Möbius process is launched with the stdin and stdout streams on the Unix pipes used for the communication processes.

FtS(Father to Son) indicates the UNIX pipe used to send data from the Main Process to the child process.

Similarly, StF (Son to Father) indicates the UNIX pipe used to send data from the child Process to the main process.

More details are described in the next Chapter (see Fig. 4.6).

FIGURE3.3: Data transmission trough UNIX pipes

3.3 Model Constraints

This section gives details about the constraints that the SAN model has to respect in order to be exported as an FMU and the challenges faced in the implementation

(45)

of an FMU for a Stochastic Activity Networks Simulator that motivated our design choices.

3.3.1 FMI Interface

The integration of a sub-system simulated in Möbius in the INTO-CPS co-simulation tool is achieved in this work via the FMI standard, namely FMI for Co-simulation.

According to the FMI Standard, variables of the FMU are stored in buffers (FMU buffers) that can be accessed by the COE using the FMI functions fmi2Set() and fmi2Get(), invoked by the fmi2DoStep().

Thus, the first task is to provide an FMI-compliant interface to the SAN executable. Fig. 3.4 shows the calling Sequence between the Master and the SAN Slave :

FIGURE3.4: Calling Sequence between the Master and the SAN Slave

This is done by a software component (skeleton.cpp) that implements the FMI interface, and in particular the operations fmi2Instantiate() and fmi2DoStep() [4] pro-vided by the FMI standard:

• fmi2Instantiate(): this function call performs all actions of the SAN slave (the Möbius model) which are necessary before a simulation run starts (loading the model file, compilation...).

At this stage, must launch Möbius with the stdin and stdout streems on the Unix pipes used for the communication streams.

In order to launch the Möbius process we need to know the path where the resources folder has been placed and we need to guarantee the permission of execution. For this reason at this stage the URL path of the directory where resources folder has been unzipped has to be specified.

The actions that have to be implemented in the fmi2Instantiate can be summa-rized as follows:

(46)

28 Chapter 3. Design of a SAN Model for Co-Simulation 1. Loading the Möbius model file, compilation of the model.

2. Creation of UNIX pipes (FtS, StF)

3. Writing the initial values of the model on the FMU buffer. 4. Launching the Möbius executable file.

• fmi2DoStep(): The function fmi2DoStep() controls the execution of simulation steps.

This function, at each time step, has to send a string to and to receive the an-swer from the Möbius application.

In particular at each co-simulation step, the Möbius application has to receive as input the outputs of the other FMUs that it needs for the simulation, to simulate the model and to make its results available to the other parts of the co-simulation environment.

The actions that have to be implemented in the fmi2DoStep can be summarized as follows:

1. Reading the results produced at the previous step by the other FMUs that Möbius needs for the simulation from the FMU buffers.

2. Writing results produced by the others FMUs in the UNIX pipe FtS. 3. Möbius reads these values from the pipe FtS and simulate the model. 4. Writing results of the solution of the Möbius sub model in the UNIX pipe

StF.

5. Reading the results from the pipe StF.

6. Writing the results of the solution of the Möbius sub model on the buffers of the other FMUs that need them.

The function returns:

– fmi2OK if the communication step was computed successfully until its end.

– fmi2Discard if the SAN Slave computed successfully only a subinter-val of the communication step (the master can also call the FMI function fmi2GetXXXStatus functions to get further information).

3.3.2 Time Coherence

Another issue in the implementation of an FMU for a Stochastic Activity Network simulator is to guarantee time coherence between the INTO-CPS co-simulation en-vironment and the Möbius simulator.

As explained in the background section, FMI for Co-Simulation provides a stan-dard interface for the solution of time dependent coupled systems: during time in-tegration, the simulation is performed independently for all subsystems (FMUs) re-stricting the data exchange between subsystems to discrete communication points (co-simulation step). For each time-step, the simulator executes the same series of tasks:

1. read inputs 2. solve model

(47)

3. generate outputs

4. exchange results with other FMUs 5. wait for the start of the next step.

On the other hand, in a stochastic activity network model simulated in Möbius, Activities represent actions in the modeled system that take some specified amount of time to complete. They are of two types: timed and instantaneous. Timed activi-ties represent activiactivi-ties of the modeled system whose durations impact the system’s ability to perform (e.g., a packet transmission time or the time associated with a re-transmission timer).

Having said that, in order to guarantee coherence between the co-simulation time in the INTO-CPS environment and the simulation in Möbius, it is necessary that in the SAN model simulated in Möbius the sum of the duration of all the timed activities on any execution path equals the duration of the co-simulation step.

As introduced in the previous section, in this work we are considering the SAN model as divided in two parts: the SAN sub-model and a control block that enables the SAN sub-model.

We are considering that all the activities in the SAN Model are of type instanta-neous (we are not interested, for the moment, in the impact of their durations on the system’s performances).

For this reason, in order to guarantee time coherence between the INTO-CPS environment and Möbius, at this stage a timed activity (ta_synch in Fig. 3.2) with deterministic duration equal to the co-simulation step must be present .

The setting of the duration of this timed activity can be done:

1. manually from the Möbius graphical editor, when the duration of co-simulation step is known a priori, as a shown in Fig. 3.5.

2. from the INTO-CPS Application, when the duration of co-simulation step is not known a priori or when the user wants to change it. Notice that for this rea-son the duration of the timed activity must be set as parameter of the Model.xml file, as shown in Fig. 3.6. This aspect will be clarified in the next Chapter.

(48)

30 Chapter 3. Design of a SAN Model for Co-Simulation This timed activity is enabled by an extended place (that we call synch). At each step, the firing of the transition provides the reading of the inputs that come from the other FMUs and the enabling of the model.

FIGURE3.6: Duration of the timed activity in Möbius as parameter of the Model.xml file

Notice that the adoption of this approach relies on the assumption that all the other activities in the SAN model are instantaneous activities. At the end of the co-simulation step the SAN model provides the outputs to the other FMUs and puts a token in the extended place synch in order to re-enable the transition (synch →

Mark() =1).

In general more sophisticated solutions could be provided. For example, the timed activity might be preceded by other activities that guarantee that the time elapsed in each execution path is equal to the co-simulation step. This is an interest-ing topic for future work.

3.3.3 Simulation Options for statistical analysis in Möbius

The next step to achieve our final goal is to find the way to specify some simulation options, like the maximum/minimum number of batches that we want to run or the type of random number generator, during the execution of the co-simulation run.

For instance, we would like to allow the FMU generated from the SAN Model to run multiple batches in a single co-simulation run, or to specify a random number generator different from the generator used as default (Lagged Fibonacci).

At this point it is convenient to analyze more in details how simulations can be performed in Möbius.

As introduced in Chapter 2, the simulator component in Möbius can be used to solve models using discrete event simulation. It takes the model and parameters specified by a study, links the libraries for those models together with the simulator library, and runs the executable.

The Simulation Parameters tab on the Simulator editor allows the user to specify all of the simulation parameters.

The Start Simulation button starts the simulator. Any files that should be recom-piled are recomrecom-piled, and experiments are assigned to the selected machines. This process is called on-line simulation.

The simulator is normally run from the simulator editor. However, it can also be run from the command line. The simulator executable resides in the project tree, in a path following this pattern: Möbius Project Root/Project Name/Solver/Solver Name/. It can be run with the command line options listed in < xrid = ”tab :

Co-Simulation of Cyber Physical Systems with Stochastic Behavior

with Stochastic Behaviour

Master of Science in Embedded Computing Systems

Abstract

Acknowledgements

Contents

List of Figures

List of Tables

List of Abbreviations

Chapter 1

Introduction

1.1

Contribution

1.2

Thesis organization

Chapter 2

Background

2.1

The SAN Formalism and the Möbius Tool

2.2

The FMI Standard and INTO-CPS

Chapter 3

Design of a SAN Model for

Co-Simulation

3.1

Introduction

3.2

Design of the extended Möbius model

3.3

Model Constraints