Paulo Carreira · Vasco Amaral · Hans Vangheluwe *Editors*

# Foundations of Multi-Paradigm Modelling for Cyber- Physical Systems

Foundations of Multi-Paradigm Modelling for Cyber-Physical Systems

Paulo Carreira • Vasco Amaral • Hans Vangheluwe Editors

# Foundations of Cyber-Physical Systems Multi-Paradigm Modelling for

*Editors*  Paulo Carreira INESC-ID & Instituto Superior Técnico Universidade de Lisboa Lisboa, Portugal

Hans Vangheluwe Department of Computer Science University of Antwerp - Flanders Make Antwerpen, Belgium

Vasco Amaral NOVA LINCS & Departamento de Informática Faculdade de Ciências e Tecnologia Universidade NOVA de Lisboa Caparica, Portugal

ISBN 978-3-030-43945-3 ISBN 978-3-030-43946-0 https://doi.org/10.1007/978-3-030-43946-0 (eBook)

© The Editor(s) (if applicable) and The Author(s) 2020. This book is an open access publication.

**Open Access** rnational License (http://creativecommons.org/ licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made. The images or other third party material in this book are included in the book's Creative Commons license, unless indicated otherwise in This book is licensed under the terms of the Creative Commons Attribution 4.0 Inte

a credit line to the material. If material is not included in the book's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

The use of general descriptive names, registered names, trademarks, service marks, etc. in this publication does not imply, even in the absence of a specific statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use. The publisher, the authors, and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication. Neither the publisher nor the authors or the editors give a warranty, expressed or implied, with respect to the material contained herein or for any errors or omissions that may have been made. The publisher remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.

Cover Photo: © 2018 by Donald Giannatti on Unsplash https://unsplash.com/photos/4qk3nQI3WHY

This Springer imprint is published by the registered company Springer Nature Switzerland AG The registered company address is: Gewerbestrasse 11, 6330 Cham, Switzerland

*In memory of our dearest friend and colleague Bernhard Schätz (1965–2017), an extraordinary scientist and one of the founders of the MPM4CPS network. He will be forever remembered for his remarkable work ethic—an inspiration for everyone around him. His enthusiasm and his always positive attitude are greatly missed.*

## **Foreword**

The explosion of desktop computing power that started in the Eighties made computational modeling available to engineers and scientists in exponentially increasing numbers. A key impediment to unlocking the potential, however, was the necessity to formulate models in programming languages, for instance, FORTRAN and Algol. Whereas organizations such as the national laboratories were able to employ software engineers who could program mathematical models, desktop users did not have access to like resources.

As a natural course, more accessible languages for computational modeling were developed that aligned with modeling practices and formalisms in various fields. To list a few examples, algorithmic array-based languages such as MATLAB® proved exceedingly useful in Signal Processing. In Controls, models were often preferred in the form of block diagrams. In Communications, protocols would be modeled well with Petri nets. Physics would be most conviniently represented by noncausal models such as bond graphs. Moreover, not any less important, intuitive environments for modeling were developed, oftentimes building on graphical user interface (GUI) technology that emerged.

While the democratization of computational modeling that desktop computing brought about was initially providing simulation as an aid in the work by engineers and scientists, in due time the computational artifacts became of additional value. Not only to the point where modeling and computational simulation became a critical step in individual analysis but also by an increasing value proposition in sharing models across teams, departments, and even organizations.

It is around the turn of the millennium when this trend of models as first-class artifacts in engineered system design starts to take shape. While I was employed by the DLR Oberpfaffenhofen, Hans Vangheluwe and I meet during one of the Modelica language design meetings and our discussions start to uncover the necessary research fundamental to addressing the growing need for model sharing and reuse. The magnificent challenge before us is in connecting, combining, and integrating models with different syntax (e.g., textual, different graphical elements, different types of relations), different semantics (e.g., imperative vs. declarative, data flow vs. control flow, time-based vs. untimed), different contexts (individual vs. team based, critical design artifact vs. one-off study, debugging vs. production), different perspectives (e.g., functional vs. performance, structure vs. behavior), different purposes (e.g., analysis vs. synthesis, safety vs. creativity), different processes (from mathematics to computation vs. computational semantics, first principle modeling vs. data-driven modeling), and different workflows (e.g.. top-down vs. bottom-up, continuous integration vs. periodic sharing, continuous refinement vs. back-to-back testing).

One day, the director of my group at the DLR Oberpfaffenhofen, Georg Gruebel and I are considering a special session on the topic at the IEEE Computer Aided Control System Design symposium (CACSD) in 2000. Our considerations of a title do not result in anything befitting and he leaves for home. Only to return to my office after about fifteen minutes with a name for the budding field that was developing: Computer Automated Multiparadigm Modeling (CAMPaM).

The CACSD 2000 initiative was successful enough that it required two conference sessions. We followed that up with special issues of SCS SIMULATION and IEEE Transactions on Control System Technology. In 2004 we started a Bellairs series of workshops on CAMPaM that is active to this day.

Over time, the computer automated ambition proved to be overly optimistic and we tempered our enthusiasm by extending the scope to multiparadigm modeling (MPM) in the large, including computer-aided approaches. Correspondingly, a series of MPM workshops were organized at the ACM/IEEE International Conference on Model Driven Engineering Languages and Systems (MODELS)from 2010 through 2015.

Today, the prescience of our observation at the turn of the millennium is reflected by the critical need for models in the emerging proliferation of Cyber-Physical Systems (CPS). CPS embed computation and communication as central to their physical operation. Most prominently, this enables a degree of flexibility or openness that is distinctly different from the rigidly singular operation of computation in the embedded systems paradigm that preceded CPS. CPS are open in a vertical sense such that compute platforms in hardware and software may change independent of the logic that the computations implement. CPS are open in a horizontal sense such that systems connect with other systems to achieve overall goals as a result of behavior that emerges post deployment. And it is precisely this trend toward ever more openness that necessitates an increasing use of models across paradigms, not limited to system design but just as much during operation (at run time).

And so the compilation of this textbook on Foundations of Multi-Paradigm Modelling for Cyber-Physical Systems is exceedingly timely. Much of the research efforts have solidified over the years while the underlying needs for multiparadigm modeling by the practitioner are still growing. This books provides an excellent collection of content that focuses on key aspects of CPS, ranging from modeling the physics, the computation and communication, control, performance characteristics, and system architecture. As an essential textbook on mutiparadigm modeling for Cyber-Physical Systems, all of these aspects are layered on top of foundations of multiparadigm modeling.

Over the years it has been a great pleasure working with all of the authors and editors of this collection. I am excited to see the field of CAMPaM coming into maturity as signified by this book. Many thanks to all involved for their time and effort to make this happen!

Natick, MA, USA, May 2019 *Pieter J. Mosterman* Chief Research Scientist and Director of the MathWorks Advanced Research & Technology Office

## **Preface**

Modelling and analysis are essential activities in the development of Cyber-Physical Systems. The inherent cross-disciplinary nature of CPS requires distinct modelling techniques related to different disciplines to be employed. At the same time, to enable communication between all specialities, common background knowledge of formalisms is expected.

An important realization is that distinct models need to be woven together consistently to form a complete representation of a system to enable, among other global aspects, performance analysis, exhaustive simulation and verification, hardware-in-the-loop simulation, determining the best overall parameters for the system, prototyping, and implementation. Conceivably, a unifying formalism would represent the connections between the mentioned distinct models to enable reasoning about them. Likewise, recent advances show that coupling disciplines by using co-simulation will allow them to cooperate without enforcing new tools or design methods.

As first, CPS is a relatively new field, with no established standards and with different actors, each of which adopts a slightly different definition and a different approach for the topic. While multi-paradigm modelling embraces a vast spectrum of distinct topics and has a very elastic and generic (informal) definition, the result is that existing tools were created from different directions, as the field spans from very theoretical to applicationoriented approaches.

The goal of this book volume is to serve as a reference text that compiles, in a coherent manner, wellestablished knowledge around fundamentals and formalisms for modelling of CPS. of-the-art solid knowledge and treatment of the crossfrom any of the related Though chiefly intended also serve as a reference text for practitioners at large. practice, or fundamentals (not research) and strives to provide a homogeneous disciplinary nature of CPS modelling. It can be used as a bridge for anyone entering CPS areas of engineering (e.g., electric engineering, mechanics, physics, computer science). for master and post-graduate level students in computer science and engineering, it can The book focuses on state-

## **Acknowledgements**

This book was supported by the COST Action IC1404 Multi-Paradigm Modelling for Cyber-Physical Systems (MPM4CPS), COST is supported by the EU Framework Programme Horizon 2020.

## **Contents**






## **List of Contributors**

#### Albin Linard

Computer Science Department, University of Geneva, 7 route de Drize, Bât. A, Office 217, CH-1227 Carouge, Switzerland, e-mail: albinalban.linard@unige.ch

#### Cláudio Gomes

University of Antwerp, Campus Middelheim, Middelheimlaan 1, M.G.028, 2020 Antwerpen, Belgium, e-mail: claudio.goncalvesgomes@uantwerpen.be

#### Didier Buchs

Computer Science Department, University of Geneva, 7 route de Drize, Bât. A, Office 217, CH-1227 Carouge, Switzerland, e-mail: Didier.Buchs@unige.ch

#### Dominique Blouin

COMELEC / INFRES, Telecom ParisTech, 46 rue Barrault, 75013 Paris, France, e-mail: dominique.blouin@ telecom-paristech.fr

#### Etienne Borde COMELEC / INFRES, Telecom ParisTech, 46 rue Barrault, 75013 Paris, France, e-mail: etienne.borde@ telecom-paristech.fr

#### Hans Vangheluwe

University of Antwerp, Campus Middelheim, Middelheimlaan 1, M.G.116 , 2020 Antwerpen, Belgium , e-mail: Hans.Vangheluwe@uantwerpen.be

#### Jan F. Broenink

University of Twente, Faculty EE-Math-CS, Department of Electrical Eng., Robotics and Mechatronics, Room Carre 3437, P.O. Box 217, NL-7500 AE Enschede, Netherlands, e-mail: j.f.broenink@utwente.nl

#### Joachim Denil

University of Antwerp, Campus Groenenborger,Groenenborgerlaan 171, G.U.135, 2020 Antwerpen, Belgium e-mail: Joachim.Denil@uantwerpen.be

#### Ken Vanherpen

University of Antwerp, Campus Groenenborger Groenenborgerlaan 171, G.U.123, 2020 Antwerpen , Belgium e-mail: ken.vanherpen@uantwerpen.be

#### Moharram Challenger

University of Antwerp, Campus Groenenborger Groenenborgerlaan 171, G.U.122, 2020 Antwerpen, Belgiume-mail: moharram.challenger@uantwerpen.be

#### Paulo Carreira

Instituto Superior Técnico, Universidade de Lisboa, and INESC-ID, Gab. 2N.5.17, DEI/IST Taguspark, Av. Prof Cavaco Silva, 2780-990, Porto Salvo, PORTUGAL e-mail: paulo.carreira@tecnico.ulisboa.pt

#### Peter Fritzson

Linköping University, 581 83 Linköping, Sweden e-mail: peter.fritzson@liu.se

#### Simon Van Mierlo

University of Antwerp, Campus Middelheim, Middelheimlaan 1, M.G.330 , 2020 Antwerpen, Belgium, e-mail: simon.vanmierlo@uantwerpen.be

#### Stefan Klikovits e-mail: stefan.klikovits@unige.ch

Computer Science Department, University of Geneva, 7 route de Drize, Bât. A, Office 217, CH-1227 Carouge, Switzerland,

#### Vasco Amaral

Departamento de Informática, Faculdade de Ciências e Tecnologia, Universidade NOVA de Lisboa,Quinta da Torre, 2829 -516 Caparica, Portugal e-mail: vasco.amaral@fct.unl.pt

#### Yentl Van Tendeloo

University of Antwerp, Campus Groenenborger,Groenenborgerlaan 171, G.U.135, 2020 Antwerpen, Belgium e-mail: yentl.vantendeloo@uantwerpen.be

## **Chapter 1 Multi-Paradigm Modelling for Cyber-Physical Systems: Foundations**

Paulo Carreira, Vasco Amaral, and Hans Vangheluwe

**Abstract** Modeling and analysis of Cyber-Physical Systems (CPS) is an inherently multi-disciplinary endeavour. Anyone starting in this field will unavoidably face the need for a literature reference that delivers solid foundations. Although, in specific disciplines, many techniques are used already as a matter of standard practice, their fundamentals and application are typically far from practitioners of another area. Overall, practitioners tend to use the technique that they are most familiar with, disregarding others that would be adequate for the problem at hand. The inherent cross-disciplinary nature of CPS requires distinct modelling techniques to be employed, thus prompting for a common background formalism that enables communication between all specialities. However, to this date, no such single super-formalism exists to support the multiple dimensions of the design of a CPS. Indeed, to effectively design a CPS, engineers (in the role of modellers) either need to be versed in multiple formalisms, or a fundamentally new modelling approach has to emerge. Herein, we motivate Multi-Paradigm Modelling of CPS (MPM4CPS), introducing fundamental definitions and terminology regarding CPS modelling and Multi-Paradigm, and finally, laying the ground for the rest of the book.

#### **1.1 Introduction**

Cyber-Physical Systems (CPS) refer to systems that consist of *cyber* (as computerised implementations) and *physical* components [130]. The general idea is that the cyber and physical components influence each other in such way that the cyber is able to cause the physical component to change state, and that the change, in turn, will feed-back, resulting in a change of state on the cyber component.

Having emerged from earlier concepts, among other, in the fields of mechatronics, embedded systems, and cybernetics, literature gives the coining of the term 'Cyber-Physical System' (CPS) to Hellen Guille in 2006 [130]. CPS are often regarded as networks of multi-physical (mechanical, electrical, biochemical, etc) and computational (control, signal processing, logical inference, planning, etc) processes, often interacting with a highly uncertain and adverse environment, including human actors and other CPS.

Example application domains of CPS include energy conservation, environmental control, avionics, critical infrastructure control (electric power, water resources, and communications systems), high confidence medical devices and systems, traffic control and safety, advanced automotive systems, process control, distributed robotics (telepresence, telemedicine), manufacturing, and smart city engineering. The design of CPS is currently a driver

Paulo Carreira

Hans Vangheluwe McGill University, Canada e-mail: hans.vangheluwe@uantwerp.be

Instituto Superior Técnico, Universidade de Lisbon, Portugal e-mail: paulo.carreira@tecnico.ulisboa.pt

Vasco Amaral FCT, Universidade NOVA de Lisboa, Portugal e-mail: vma@fct.unl.pt

for innovation across various industries, creating entirely new markets. More efficient and cheaper CPS will have a positive economic impact on any one of these applications areas.

CPS are notoriously complex to design and implement mostly because of their cross-discipline borders, leading to inter-domain interactions, in applications that are often safety-critical. Indeed, due to the nature of their application, failure or underperformance of CPS can have direct, measurable economic costs, can harm the environment or even directly affect humans. Expectably, engineering practice has, over the years, sought to address these concerns by improving the languages, frameworks, and tools used in the design and analysis of CPS. This effort led to the emergence and strong adoption of model-based design, in which systems are designed at a higher level of abstraction, and an implementation is then produced by automatic generation.

A striking aspect of CPS design is that it is inherently multi-disciplinary. One source of this multidisciplinarity arises from the domain of the application itself, such as e.g., medical, biological, or aeronautical industries. Another source is the heterogeneous nature of CPS, which consists of computerised, electronic, and mechanic parts. To design a CPS, engineers from various disciplines need to explore system designs collaboratively, to agree, to allocate responsibilities to software and physical elements, and to analyse trade-offs between them.

Originating from the Modelling and Simulation Community, the term *Multi-Paradigm-Modelling* (MPM) finds its origin in 1996, when the EU ESPRIT Basic Research Working Group 8467 formulated a series of simulation policy guidelines [286] identifying the need for *"a multi-paradigm methodology to express model knowledge using a blend of different abstract representations rather than inventing some new super-paradigm"*, and later on proposing a methodology focusing on combining multiple formalisms [294]. Since 2004, during the yearly Computer Automated Multi-Paradigm Modelling (CAMPaM) Workshop series at McGill University's Bellairs Research Institute, many ideas surrounding MPM were developed. Since then, MPM became a wellrecognised research field with a large body of research produced and published, in particular in the MPM Workshops co-located with MoDELS.

The recent COST Action IC1404 MPM4CPS (http://mpm4cps.eu) aimed at exploring how MPM can be employed to alleviate the engineering complexity surrounding the conception of CPS. Among other efforts, the scientific community gathered around this action surveyed existing languages, techniques, and tools commonly used for modelling CPS and organized them into an ontology [167].

This work identified the need come up with a theoretical foundation for MPM and identified useful language features. Among other, the most relevant can be summarised as follows: Closeness to the essential concepts that engineers use to reason about the behaviour of physical systems, in a computationally a-causal fashion (i.e., without the need to specify early on what are inputs and outputs); the ability to precisely describe computation, at different levels of detail of the time dimension; the ability to elegantly express concurrency, synchronisation and non-determinism and to reason about properties over all possible behaviours of a system; the ability to express modal, timed, reactive and autonomous behaviour and to synthesise code; suitability to model competition for shared resources, which leads to queueing, as a basis for quantitative performance analysis; suitability for easy and correct architectural composition; the ability to express workflows at a high level of abstraction and finally, the high-level feature of modularity, supporting re-use, compositional verification of properties and the integration of black-box components such as co-simulation units. The breath of the techniques is broad.

The results of the efforts held by the MPM community, mentioned above, culminated in a book that compiles in a coherent manner well-established knowledge around fundamentals and formalisms for modelling of CPSs with a particular focus on tools and techniques that are multi-paradigm.

#### **1.2 Understanding Cyber-Physical Systems**

We now turn to discussing which classes of systems can be considered a CPS, what are their properties, and the sources of engineering complexity worth solving using the so-called MPM approach. Before embarking in the discussion some preliminary concepts need to be made clear.

#### **1.2.1 Systems and their models**

The notion of *system* is a fundamental concept used in multiple disciplines. The term conceptualises a physical existence such as an ecosystem, an organism, a machine, or a purely *abstract existence*. The latter case refers to processes, rules (such as a socio-economic system), or mathematical models. Regardless, any conception of a system is understood *(i)* as a set of *components (ii)* identifiable as a *whole*, that *(iii) cooperate* (also said to *interact*) to *(iv)* perform a particular *function*. There is a distinction between the actual systems (physical or abstract) and the human understanding of them. The formalisation of this understanding, usually limited, is called a *model*. [308]

According to Systems Theory, a system can be understood in two ways. One way is the *black-box* approach that seeks to model the *external behaviour* of the system in terms of how it interacts with the environment. Here, the behaviour of the system is seen as the relationship between the evolution of the history of *manifestation*s (also said *output*s) and the history of *stimuli* (also said *input*s). Another way to understand the system is the *white-box* approach, that seeks to understand its *internal structure* in terms of *components* and *connectors* through which interaction occurs.

Both the black-box and the white-box approach formalise knowledge about the behaviour of the system with *models*1, which are simplified representations of the system.The utility of working representations is that they are cognitively effective means to reason about the actual system (or systems) they represent. By reasoning, we mean analysing properties of the system or predicting the future behaviour of the system. A system can thus have multiple models that cater to distinct requirements in terms of reasoning. Control Theory has historically taken the black-box approach where outputs are modelled in terms of inputs using differential equations; Computer Science has traditionally taken the white-box approach by modelling the internal structure of systems using object diagrams.

The driving idea behind understanding the internal structure is that components, bound through a certain arrangement of connections, display specific external behaviour. Moreover, the overall behaviour can be derived from *(i)* the known behaviour of the components and *(ii)* the characteristics of the connectors. Connections are abstract flows of information, or energy, that bind components through pre-designated points of interaction known as *ports*. Some component ports are *directional*, we can thus talk about *input ports (inputs)*, and *output ports (outputs)*. Other ports are *adirectional* in that they model an exchange and not necessarily a flow (consider a thermal coupler, for example).

A component can itself be seen as a system itself with its own components and connectors. The ability to continue composing systems from previously constructed ones is known as *hierarchical construction*. It is common also to model components with a *internal state* that reflects (partially and sometimes inaccurately) what the system knows about the surrounding environment and a *state-transition* mechanism typically referred to as *transition function* that is capable of producing new states from previous states upon receiving certain inputs and creating certain outputs.

#### **1.2.2 Types of systems**

Inputs, outputs and the state of the components are modelled in terms of *variables* that can take values from their corresponding support sets. These variables are said to be *continuous* or *discrete* if their support sets are, in a mathematical sense, dense or discrete, respectively. The behaviour of the system, as modelled in terms of internal state and outputs, evolves from a previous state according to some notion of time. Time can also be understood as continuous or discrete. In *continuous time*, it is possible to derive the new state and the new outputs for the system for an arbitrarily small time delta; whereas in *discrete time*, the new state and outputs can be derived only at predefined intervals, or upon the occurrence of a certain event.

Systems can be classified into distinct types depending on the nature of inputs, outputs, state variables, state transition function, and the notion of time. A well-accepted classification is as follows [308]:

• **Static vs Dynamic Systems.** A system is said to *static* if its output depends only on the present input. If the output of the system depends on the history of past inputs, then the system is said to be *dynamic*.

<sup>1</sup> The precise meaning of the term 'model' is discussed later in Section 1.3.1


A dynamic system that exhibits both continuous and discrete time behaviour is said to be an *hybrid system*. The study of hybrid systems is very important as they arise often in the composition of discrete with continuous components typical of cyber-physical systems.

#### **1.2.3 What are Cyber-Physical Systems?**

It is assumed that the cyber component *controls* the physical component in the sense that the cyber component has some 'intelligence' or, at least, some strategy to drive the physical to reach a predefined observable goal. The converse is not true, i.e., the physical does not aim at driving the cyber to reach a certain predefined goal. This formulation puts CPS in the realm of Control Systems theory. Despite de comprehensive nature of Control Systems theory, CPS are not a particular case of Control Systems.

In a *control system* one component, known as the *controller* realises a control model that acts upon the physical environment component known as *plant* by means of a *control action*. The controller knows the desired value of a variable and the current value of that variable in the physical component. The controller then creates a sequence of control actions to correct (i.e., to minimise the distance over time) of a variable (measured from the physical system) to the desired value (the goal). This arrangement is known as *control system*. It is, therefore, reasonable to ask: *"what distinguishes a control system from a CPS?"* Besides the very idea of a cyber control component—a discrete computer algorithm controlling continuous physical phenomena—it seems that there is no single characteristic that of itself defines a CPS. However, it is well-accepted that cyber-physical systems consist of a large number of interacting components and display a number of recurring characteristics that distinguish them from classic control systems. In particular:

	- **Human in the loop** offering specific provision for Human actors to consume outputs and give inputs. Human actors are often modelled as components with specific behaviour requirements. and assumptions.

The pervasiveness of IoT with a large number of connected devices has created an upsurge of interest in CPS. However, the term is somewhat overused, and it has now become an umbrella for any system that interacts with the physical environment. For instance, at the current state of practice, a developer of a temperature logger might as well claim that his device is a CPS. This raises the question of *what is the minimum requirements for a system to be considered a CPS?* One key observation is that having identifiable cyber and physical components are not enough for a system to be considered cyber-physical; the cyber and physical components must influence each other2. Another reasonable question is whether this relationship must be of mutual influence, or whether, instead, the cyber component may not be influenced by the physical component. It is clear that since the cyber controls the physical, *the cyber must have the means to influence (act upon) the physical.* It follows, that a system where the cyber component does not influence the physical component is not a CPS.

CPS also builds on *embedded systems*, which are self-contained systems that incorporate elements of control logic and real-world interaction. An embedded system is typically a single device, while CPS include many constituent systems. Further, embedded systems are specifically designed to achieve a limited number of tasks, often with limited resources. A CPS, in contrast, operates at a much larger scale, potentially including many embedded systems or other CPS elements including human and socio-technical systems.

It becomes clear from the above that having a cyber and a physical component is not a suficient condition for system to be considered cyber-physical systems. The example of the temperature logger system, which only reads from the physical system, despite having a cyber and a physical component, is not a CPS.

#### **1.2.4 Sources of Engineering Complexity**

Cyber-physical systems are complex to build due to the inherent complexity of the problems they solve that consist of coordinating action to optimise multiple (possibly contradicting) goals in systems with vast numbers of sensors and actuators. The other source of complexity is, more of accidental nature, and has to do with the heterogeneity of the components.

One starting source of complexity is that cyber components are discrete in nature but must act in a time-driven fashion and, for that matter, they must reason about time. Concepts of *duration*, *deadlines*, and *simultaneity*, must be dealt with and modelled explicitly. Yet, programming languages abstract away the notion of time and provide little or no support for time3. Timing behaviour is achieved through dedicated timing hardware, interrupt control routines, and timer libraries—in the words of Eduard Lee, *"programmers have to step out outside of the programming abstraction to specify timing behaviour."* Instead of being explicitly modelled, timing behaviour is obfuscated and buried under the complexity of the orchestration of these mechanisms making the *correctness* of the composition between the cyber and physical components very hard to achieve. The problem is exacerbated as more components are added onto the system.

Not only discrete components often display incorrect timing behaviour but interfacing discrete and continuous components poses another unexpected engineering challenge. The composition of a deterministic model of the cyber with a deterministic model of the physical results in a non-deterministic model that is very difficult to analyse. To understand why to consider that it is impossible, in practice, to guarantee that the components that implement the two models will be perfectly aligned, concerning time. This applies especially to the mechanism that they use to communicate and synchronise because this mechanism operates according to certain assumptions (constraints) of time.

The actual implementation of CPS is largely component-based. These components are multi-vendor and multi-technology and, as a result, they often have different communication protocols, response timings, distinct tolerances and operating conditions. One side of the problem is that some of these constraints are not known or accounted for upfront. Another side of the problem is that while constructing the system, these constraints are not modelled and handled explicitly. A lot of accidental complexity arises when trying to assemble components with such variability, especially because typical CPS consists of a large number of components.

<sup>2</sup> In terms of modelling, this means that they must be bound through at least one connector

<sup>3</sup> A rigorous semantics of time is absent from standard computer languages

Fig. 1.1: Illustration of the tale of the 6 blind men. Each blind man, from his own perspective, understands the elephant as a diferent object.

CPS also have stringent requirements that cannot be relaxed. Besides the usual guarantees of functional correctness that apply to any engineered object, CPS are especially known for their large number of extrafunctional (also known and 'non-functional') requirements that cover issues of reliability, performance, safety, security, among other. What is relevant to note is that extra-functional requirements are known to pose complex constraints to timing component design and to timing behaviour. Moreover, since these systems are critical, they often have to undergo strict qualification/testing processes. When changes to the system are needed, they are often discouraged due to the costs involved, making CPS difficult to adapt to changing requirements. There should be a reliable means to guarantee that certain aspects of a system remain untouched and therefore, do not need to be tested again.

Actual realisations of components sometimes interact in ways that were not designed upfront. Often physical components interfere due to electromagnetic or thermal interference. Emerging behaviour as of complex behaviour that arises from the interaction between components, which was not planned upfront. While developing CPS, it is important to have the means to explore alternative designs.

#### **1.3 Modeling of a Cyber-Physical System**

The engineering process of CPS requires distinct disciplines to be employed. Each discipline typically creates a design (also said to be a *view* or *understanding*) of the system for its own purposes in the form of a model. Models are created using abstractions, heuristics of decomposition, and tools of analysis typical of each discipline. Each discipline also brings along a body of knowledge that enables humans in charge of modelling the reality to critically assess the correctness and soundness of the model being produced. In this sense, the piecemeal approach of having distinct models organised by discipline is effective. Another motivation for having distinct models is that, even within the same discipline, they are required to answer distinct questions. Models also have to be produced with distinct levels of detail, and therefore, the modeller has to find the right balance and capture the right things creating a model adequate to the question being studied.

Modelling of a CPS system is inherently represented in multiple views of the system (most of the times following the principle of separation of concerns). As in the ancient tale of the six blind men (see Fig. 1.1), no single view (nor corresponding modelling formalism) can model all aspects of a system. Similarly, in CPS engineering, the results are models reflecting distinct views of the problem, expressed in multiple notations. One problem for the CPS engineer, as it is also for blind men, is *"how to integrate knowledge to form a more approximate model of the reality?"* Naturally, modelling of CPS systems calls for a trans-disciplinary approach that merges the different models into a unified abstraction of reality. An essential challenge of CPS is thus how

Fig. 1.2: Models of an airplane: The CAD model on the left to study volume; on the right side the model for studying gravity.

to conjoin abstractions of the various engineering disciplines and the models for physical processes including differential equations, stochastic processes, among others.

Currently, there is no standard design and modelling approach to integrate models produced by distinct disciplines of CPS. Indeed, the knowledge captured in models only comes together when assembling physical (prototype) implementations to evaluate some relevant properties of a given CPS. A more sophisticated approach is to avoid creating prototypical implementation altogether and (co-)simulate the models. This is a more generic approach as it enables verifying properties independently from the particularities of the implemented prototype.

Previously, we have mentioned the term *model* assuming some implicit notion of modelling based on abstraction, which is the process of removing details in the study of objects or systems in order to focus attention on details of higher importance. However, not all conceivable abstractions or representations of a system can be considered a model. Indeed, a more precise understanding of these concepts is required. Let us look at these in further detail.

#### **1.3.1 What is a Model?**

A model of a system is an abstraction (a representation) to make predictions or inferences [176] about a reality. More specifically, this reality is a system under study (SUS), whose governing rules and properties we want to understand, within the context of a given *experimental frame*. An experimental frame denotes the limited set of circumstances under which a system is to be observed or subject to experimentation.

According Stachowiak [256], three main properties should hold in a model. The first property is the *mapping feature*, which means that any model, to be called as such, should be faithful to or based on an original, that exists or simply be the formalisation of an idea to be realised at some point in the future. The second property is *reduction feature*. In this case, there is no model if it does not remove unnecessary detail, and select original properties useful to the purpose of the model in hands. The third is the *pragmatic feature*. In this last property, a model needs to be usable in place of an original with respect to some purpose. Other important, yet not fundamental characteristics of a model are *purposeful* [243], *understandable* and *cost-effective*.

To make the idea of models more concrete, let us illustrate these properties with a simple example. Consider the case of an aircraft where we are concentrating on the study of the single properties of mass and gravity. For this purpose, we can claim that a glass of water is a rough approximation of an aircraft (and it is chosen as a physical representation of the SUS). When it falls, it takes some time to reach the floor, and then it breaks. Can the glass be considered a model for the aircraft? For the purpose of evaluating the effects of gravity (our scope) we have *(i)* a mapping feature, as the object (glass) represents the original (the airplane); *(ii)* a reduction feature, as all the unnecessary details like shape, aerodynamics, architecture, among other, are removed, and *(iii)* it is pragmatic in terms that we can substitute the glass for the real airplane. Finally, it is*(iv)* purposeful, as it is meant to study gravity, *(v)* understandable, as it is a straightforward representation that everyone understands; and *(iv)* cost-effective, to study and substitute the real one during the fall it is several orders of magnitude cheaper and ethically acceptable. Another possible example of a model, for the same case study, can be the CAD drawing of the aeroplane for the goal of studying the volume of the machine, for purposes like studying how it fits in a hangar or what is the internal volume for the purpose of choosing the proper ventilation system.

#### **1.3.2 Multiple Formalisms in CPS**

As it became clear above, the engineering process of CPS results in a collection of models. Models are abstractions of a system (a reality) that has properties worth studying. It is well known as well that models, especially of distinct disciplines, are are expressed using correspondingly different modelling formalisms. A *modelling formalism* is a language that has formal syntax and semantics. The usual meaning of 'formal' is precisely and unambiguously defined, mathematically, in the form of Differential Equations, Finite State Automata, State Charts, Petri Nets, among others. Distinct formalisms exist because they are more concise and enable answering efficiently to distinct classes of questions. Indeed, no single formalism can be used to model all aspects of a system, as the formalism to be used depends on the nature of the problem to be solved.

Formalisms also enable the manipulation and re-writing of models, or parts of models, into other that are equivalent to the originals (for a given semantics), and whose realisations have more desirable properties. Such as, being less redundant, more compact, faster, or consuming less energy, for example.

In order to overcome the complexity of the problem, a common modelling practice, is to describe models of the same reality at different levels of abstraction (sometimes using correspondingly distinct formalisms.) Models expressed at distinct levels of abstraction are linked to one another through structure-preserving maps. Indeed, an overarching issue with distinct formalisms is merging models of the same system through these maps. There needs to be a notion of *consistency* among them.

These multiple formalisms are used to model a system interacting with its environment, its architecture and components, at different levels of detail, approximation and abstraction, and from different viewpoints, as well as the platforms the software components of the system will be deployed on. The integration of models produced according to distinct formalisms is achieved by mapping (compiling) the model into lower level *super formalisms* that integrate different domains such as Bond Graphs, or other formalisms to integrate discrete and continuous modelling constructs such as DEVS.

To support the design of CPS, not one single super-formalism, but rather of a multitude of modelling formalisms, chosen for their particular reasoning and analysis features need to be employed. These features make each of them most appropriate for a particular CPS design (sub-)goal. Pragmaticaly, the engineer (in the role of modeller) needs also to know the strategies (formalised as *processes*) to describe reality according to the formalism. The formalism together with these said processes and constraints form what is otherwise known and as a *modeling paradigm*—the object of study of Multi-Paradigm Modelling [286].

#### **1.4 Multi-Paradigm Modelling of CPS**

Multi-Paradigm Modelling (MPM) has been recognised as a powerful approach (a paradigm in its own right) that may be helpful in designing, as well as communicating and reasoning about CPS, which are notoriously complex because of their cross-discipline borders and inter-domain interactions.

To develop a CPS, project managers and engineers need to select the most appropriate development languages, software lifecycles and "interfaces" to specify the different views, components and their interactions of the system with as little "accidental complexity" [52] as possible. For example, when it is known that system/software requirements are likely to change frequently during the project's course, selecting an Agile development process may help to cope with evolution and change. If the system's behaviour requires that operations are triggered when data becomes available, similar to reactive systems, Data Flow languages may help to specify the most critical parts of the software behaviour in a precise way, making it amenable for timing analysis.

#### **1.4.1 What is a Paradigm?**

In Computer Science, general-purpose programming languages (GPLs) can be classified according to the paradigm(s) they support. For example, Eiffel is object-oriented and supports the contract-based-design paradigm, Prolog is declarative, and Lisp is functional. The paradigm characterises the underlying syntactic and semantic structures and principles that govern these GPLs. In particular, object orientation is imperative in nature and imposes viewing the world in terms of classes and communicating objects, whereas the declarative style relies on term substitution and rewriting. As a consequence, a statement in Eiffel has very little in common with a Prolog sentence due to the very different view supported by each language. A programming paradigm directly translates into different concepts encoded in the GPL syntax definition (known as a metamodel in the Model-Driven Engineering world). Very naturally, the idea of combining several paradigms at the level of GPLs led to more expressive, powerful programming languages such as Java (which is imperative, object-oriented, concurrent, and real-time and, recently, functional) and Maude (which is declarative, object-oriented and also concurrent and real-time).

What is a *paradigm* then? The science philosopher Kuhn [175], while investigating how science evolves through paradigm shifts, defines it as an open-ended contribution that frames the thinking of an object of study with concepts, results and procedures that structure future achievements. Though seemingly far from the concerns in the discipline of Computer Science, this definition does highlight the emergence of a *structure* (a formalism) that captures the object of discourse, and the notion of *procedures* (the processes) that guide achievements.

#### **1.4.2 The dimensions of Multi-Paradigm Modelling**

The application of MPM requires *modeling everything explicitly*, using the *most appropriate formalism(s)*, at the *most appropriate level(s) of abstraction* [266]. This suggests that a *paradigm* can be understood as an arrangement of the properties in each of the dimensions described above: the *formalisms* and the *levels of abstraction* in the modelling activities.

Oftentimes, formalisms are general-purpose, and hard to be used by modellers (domain users, or domain experts) who need to start by picking the most adequate formalism based on its well-known semantics, e.g., Petri Nets for workflows and concurrency, or Statecharts for describing event-based systems, among others. However, having to master mathematical notation poses a steep learning curve. To alleviate this problem, specialised languages, called *Domain-Specific Modelling Languages*, are created to simplify the act of expressing the modeller's specification intent. The constructs in these languages are designed to be closer to the way domain experts are used to conceptualize problems. The systematic approach of building new modelling languages, is called *Modelling Language Engineering* (MLE) and must, itself, follow an engineering process [**?**].

To tackle complexity during the course of system development, three basic abstraction approaches are commonly combined: *Abstraction/Refinement*, *Architectural decomposition*, and *View decomposition*.


• **View decomposition (and its dual, view merge)** is used to enable the collaboration between multiple stakeholders, each with different concerns. Each viewpoint allows the evaluation of a stakeholder-specific set of properties. When concrete views are merged, the conjunction of all the views' properties must hold. In the software realm, IEEE Standard 1471 defines the relationships between viewpoints and their realisations, views. Note that the views may be described in different formalisms.

One particular combination of the former approaches leads to Contract-Based System Design [84]. Indeed, modelling activities are combined into *processes*(or workflows) that relate the various MPM activities. Processes may be *descriptive*, charting the sequence of activities carried out as well as the artefacts involved, *proscriptive* by declaratively specifying constraints on the allowed activities and their combinations, and *prescriptive* allowing enactment. Processes are often supported by toolchains whereby different tools support different activities. It can be said that a MPM framework aims to support (meta-)tool builders who assist practitioners to reason about CPS and figure out which formalisms, abstractions, workflows and supporting methods, techniques and tools are *most appropriate* to carry out their task(s).

Ultimately, by selecting, organising and managing the three dimensions above (formalisms, abstractions, and processes), MPM facilitates the communication between experts to help them better grasp the essence of how their CPS are built. Moreover, it also facilitates a rigorous comparison of distinct approaches to MPM based on their core MPM components. The implications and challenges that MPM brings to formalisms and to abstraction mechanisms need to be discussed further.

#### **1.5 A foundation for MPM4CPS**

This book introduces a representative set of modelling formalisms, each with a characteristic collection of features. The set is by no means complete but rather intended to showcase the wide variety of features available in well-established formalisms, often supported by scale-able tools. These may be used to choose a most appropriate formalism for a particular task at hand, as a starting point for looking into more formalisms, with other desirable features (such as the inclusion of spatial distribution as found in Cellular Automata or Partial Differential Equations), or as a basis for the design of Domain-Specific Modelling Languages (DSMLs) to maximally constrain a modeller to a specific application domain.

The formalisms introduced in this book may also be combined, leading to "hybrid" languages, when a particular combination of features is required that is not available in a single formalism. Note, however, that some of the formalisms introduced in this book are already hybrid in the above sense. Bond Graphs, for example, unify modelling of systems in various physical domains by focusing on power flow, and Modelica combines features of Object-Orientation with those of computationally a-causal (equation-based) modelling. The Architecture Analysis and Design Language (AADL), which focuses on embedded systems, with architecture at its core, brings together different viewpoints, making it suitable for documentation, analysis and code synthesis.

The material is presented in a bottom-up fashion. Starts by presenting the formalisms to model physical components. Then mechanisms encapsulate and re-use description of CPS components are presented as a means to tame the complexity of large descriptions. We then present formalisms analyse the behaviour of CPS. Finally, these formalisms are put together through the use of architectural descriptions and processes.

#### **1.5.1 Modelling physical components**

When modelling a physical system, the first decision to make is whether the properties of interest of the system depend on the spatial dimension. The heating of a metal object due to an electrical current flowing through it, for example, is determined by the interaction between the electrical and thermal physical domains. It depends on the geometry of that object as well as on the object's material properties such as density, electrical conductivity, relative permittivity, heat capacity, and thermal conductivity, and their distribution across the entire object. The object's dynamics can then be described using the mathematical expression of the relationships between the physical quantities of interest. Due to the dependence on spatial coordinates, this requires the use of "distributed parameter" models. These are typically expressed using the Partial Differential Equation (PDE) formalism.

When the parameters of an object are sufficiently homogeneous over its geometry, the properties of interest may not depend on the spatial dimension. In that case, the parameters may be aggregated over an entire object, and it may be reduced to its dimensionless essence. A rigid body in the mechanical domain with a constant density over its geometry may, for example, be reduced to a simple "point mass". Its dynamics can be described using Newton's Laws or a Hamiltonian or Lagrangian formulation. Such "lumped parameter" models are typically expressed using the Ordinary Differential Equation (ODE) or Differential Algebraic Equation (DAE) formalisms.

Often, the physical components of a Cyber-Physical System span distinct physical domains (electrical, mechanical, thermodynamic, hydraulic, etc.). The Bond Graphs formalism described in Chapter 2 unifies the different domains at a "lumped parameter" level of detail. It recognises the analogy between physical processes in different physical domains, such as energy storage and dissipation. A system is modelled as a Bond Graph connecting nodes representing physical elements. These nodes encode how physical quantities such as voltage and current are related in, for example, a resistor. The Bond Graph's edges—called Power Bonds—denote the power flow between the nodes. Special nodes—junctions— encode conservation laws, generalisations of Kirchoff's current and voltage laws in the electrical domain. The chapter introduces a systematic procedure for modelling multi-domain physical systems. It starts from Idealised Physical Models and converts these into Bond Graph models. These Bond Graph models are computationally a-causal and can be translated to a set of Differential-Algebraic Equations (DAEs). Computational a-causal models consist of equations relating signals (variables, functions of continuous-time), without specifying which variables are known (inputs) and which are unknown (outputs), nor how these equations need to be solved (i.e., how the unknowns are computed from the knowns). Such DAEs can be represented in (mathematical) Equation-Based modelling languages such as Modelica. Modelica is described in Chapter 3 The Bond Graph chapter then shows how computational causality can be assigned, effectively converting to a Continuous-Time Causal Block Diagram (CT-CBD). Causal Block Diagrams are described in Chapter 4. Causality assignment on a Bond Graph model may give insight based on physics, into flaws in the model. This aid in "model debugging" is thanks to the (physical) domain-specificity of the Bond Graph formalism.

#### **1.5.2 Joining the 'Physical' with the 'Cyber'**

Cyber-Physical Systems are composed of networked physical and computational components. To allow for a modular and hierarchical design of such systems, maximising model re-use and enabling the construction of model libraries, the Modelica language, described in Chapter 3 combines features of Object-Orientation such as encapsulation and inheritance with those of computationally a-causal (equation-based) modelling. Computationally a-causal models allow the modeller to express the fundamental laws of physics using mathematical equations. The semantics of Modelica is given by expanding object-oriented constructs such as inheritance, by instantiating classes, and by flattening the hierarchy. This results in a set of (hybrid) Differential-Algebraic Equations. For each particular simulation experiment context, computational causality can be assigned by a Modelica compiler. This effectively generates a model in the Continuous-Time Causal Block Diagram formalism. Most Modelica compilers will further (time-)discretise these models, either symbolically through "inline integration" or by calling upon external numerical solvers. This ultimately leads to an executable simulation code. Note that it is possible to create a Modelica library with Bond Graph components. In this case, the Bond Graph causality assignment procedure will not be used. Rather, Modelica's causality assignment will be applied to the entire model, including non-Bond Graph parts. Through the code-based specification of functions, Modelica also allows traditional object-oriented code to be represented. It is this combination of code, equations, and hybrid constructs such as "when" (which allows the introduction of discrete events, so-called "state events", based on conditions over continuous behaviour such a crossing a threshold value) that makes Modelica suited to build models of Cyber-Physical Systems, spanning their physical, network and computational parts.

As mentioned earlier, declarative, computationally a-causal models need to ultimately be transformed into a causal form, which allows for their computational solution. In Chapter 4, a family of Causal Block Diagram (CBD) formalisms is introduced. Causal Block Diagrams consist of a network of computational blocks. Each block specifies the computationally causal relationship between its input and output signals. The block diagram network specifies how outputs of one block are connected to inputs of other blocks. Such a connection denotes that the values at connected output and input ports must at all times be equal. The three CBD variants are built up gradually. The Algebraic Causal Block Diagram (ALG-CBD) formalism has no notion of time: values are propagated through a CBD according to a computation "schedule" (i.e., the order in which block computations are invoked) derived from the dependency structure encoded in the block diagram network. Special care needs to be taken to detect and properly solve dependency cycles known as "algebraic loops". A discrete (Natural Number) notion of time is then added, as well as a delay/memory block, resulting in Discrete-Time Causal Block Diagrams (DT-CBDs). These are equivalent to Synchronous Data Flow (SDF) models. Finally, the Real Numbers are introduced as a time base to give Continuous-Time Causal Block Diagrams (CT-CBDs). These have the same expressiveness as mathematical equations and need to be discretised to allow for their computational solution. Numerical discretisation techniques are used to turn a CT-CBD into a DT CBD.

Very often, it is reasonable to abstract away many of the details of the behaviour of a system and to only focus on pertinent "events". Such Discrete-Event abstractions see a system as changing its internal state, either reacting to input events of autonomously changing its state after a certain time (due to an internal "time event") and possibly producing output events at certain times. As only the events are what changes the state of the system, and in between event instances, nothing pertinent is assumed to happen, the evolution of the state over time is piecewise constant. Unlike in Discrete-Time (DT) formalisms, in Discrete-Event (DE) formalisms, time advances in leaps and bounds, from pertinent event to pertinent event. One advantage of DE abstraction is performance: a simulator will directly step to the next time at which an event occurs whereas a DT simulator would have to step through time in fixed increments even if nothing noteworthy happens (i.e., the state remains unchanged). The DE abstraction is commonly used to study the competition of different processes for shared resources. If resources are constrained, this inevitably leads to queueing. The abstraction is hence useful for simulation-based performance analysis. Utilization of resources, time spent to complete an activity, the distribution of queue length and queueing time are all examples of the typical performance measures that are obtained from discreteevent simulations. Note that DE formalisms are often deterministic. Through the inclusion of distributions for parameter values such as Inter Arrival Time rather than unique values, and using Monte-Carlo simulation, distributions of performance measures are obtained. Thus, repeatable (as pseudo-random number generators – which are deterministic– are used to sample from distributions) stochastic simulations are obtained. Many DE formalisms were developed over the years. The Discrete EVent Specification (DEVS) formalism described in Chapter 5 is a DE formalism that is primitive and expressive enough to act as a DE "assembly language": models in all DE simulation formalisms can be mapped onto a DEVS equivalent. As such, it can be used to architecturally connect models in different formalisms by first mapping all components onto DEVS. The resulting architecture only contains DEVS components. As DEVS is modular and supports hierarchical architectural composition, the resulting model has a precise meaning. DEVS's support for hierarchy makes it suitable to build model libraries and to subsequently build up highly complex models.

A different way of modularly combining state automata is found in the Statecharts formalism described in Chapter 6. The Statecharts formalism consists of hierarchies of state automata, of parallel composition of these automata, of a notion of time, and an event broadcast mechanism. The popularity of Statecharts is partly due to its intuitive visual notation. The main purpose of Statecharts is to not only simulate models, but also to synthesise from them, autonomous, timed and reactive software and/or hardware.

When a parallel composition is made of state automata, many interleavings are possible. One option is to choose a unique interleaving, leading to a unique, deterministic behaviour trace. This is what is done in the DEVS and Statecharts formalisms. To model true concurrency, this artificial sequentialisation is not always appropriate. Rather, a non-deterministic choice should be allowed. This leads, not to a single behaviour trace, but to a collection of possible behaviour traces. This collection of traces may be summarised in a compact representation in the form of a state reachability graph. The satisfaction of interesting properties may then be checked over the collection of traces. An example is the reachability of a certain undesirable state. Such properties are also expressed in an appropriate property language. Non-deterministic languages, as described above, usually have a weak notion of time: not the Natural or Real numbers are used as a time basis, but only a (partial) ordering of event instants. The focus is on concurrency and synchronisation. Rather than simulation or synthesis, such formalisms are mostly used for the analysis of properties, across all possible behaviours of a system. This makes them suited for, for instance, safety analysis. One such formalism is Petri Nets, as described in Chapter 7. Petri Nets encode state as a "marking", an *n*-dimensional vector of Natural numbers. Each element of the vector corresponds to the number of "tokens" in a Petri Net Place. The evolution of the state is encoded in a Petri Net graph which, apart from Places, contains transitions and Arcs. Thanks to the use of Natural numbers, the number of possible states can be infinite (but countable). Petri Nets are a simple formalism that, like DEVS, is often used as a common semantic domain onto which to map diverse other, often domain-specific, formalisms. The chapter also demonstrates how Petri Nets can be combined with other formalisms. In particular, the co-simulation of Petri Nets with Functional Mockup Units (encoding discretised continuous models) is introduced. This effectively leads to non-deterministic hybrid models.

#### **1.5.3 Tooling support for MPM4CPS**

Complex engineered systems consist of heterogenous components arranged in an architecture. Furthermore, multiple viewpoints on the same system may be of interest and ultimately (part of) a system model needs to be "deployed" on an often embedded software/hardware architecture. The Architecture Analysis and Design Language (AADL) described in Chapter 8.1 is foremost an Architecture Description Language. It allows one to provide a description of the overall system and the environment into which it will operate. From such a description, other models in other formalisms such as those described in this book can be generated. These can be further augmented to study various aspects of the system, which is essential for its optimisation, verification and validation. After a brief introduction to ADLs and their role in MPM4CPS, the AADL is presented and its use illustrated through the modelling, analysis and code generation for a simple Lego Mindstorm robot for carrying objects in a warehouse. A simple top-down architecture-centric design process is followed, starting from the capture of stakeholder goals and system requirements, followed by system design, design analysis and verification and finally automated code synthesis.

It becomes apparent from the above that complex systems modelling involves not only different abstractions, architectures and views, modelled using varying formalisms but also complex development workflows. Chapter 9 looks into the topic of process (workflow) modelling. Often complex, concurrent development processes, modelled in the form of a Process Model (PM) are built up of primitive activities which take as input, modelling artefacts and produce modified or new modelling artefacts as output. The activities may require human or computer resources, possibly leading to delays as described in the chapter on DEVS. As the artefacts manipulated by activities are models in various formalisms, it makes sense to "type" them with the appropriate formalisms. To chart the many formalisms used, and to show how they are related, a Formalism Transformation Graph (FTG) is introduced. The FTG+PM, combining FTG with PM, allows one to characterise the essence of Multi-Paradigm Modelling solution patterns to CPS development problems. One advantage of the explicit representation of the FTG+PM is that is can be used as a basis for the synthesis of MPM tools.

#### **1.6 Summary**

The field of CPS is affected by the complexity of different approaches, processes, and modelling languages. Indeed, this field is well-known to have an inherently multi-displinary nature and, since there is no single well accepted modelling approach, multi-paradigm modelling has been advanced as a solution. Yet, to date, literature still lacks a solid reference that introduces distinct CPS modelling and analysis techniques towards a multi-paradigm approach.

This first chapter motivates Multi-Paradigm Modelling for CPS and the need for its clear foundations. Staring from an introduction to the concept of System, it introduces distinct classes of systems, discusses their characteristics, and then derives a definition of CPS. As CPS are complex to build, we dedicate part of the chapter to discussing and drilling down on their common sources of complexity. Overall, designing a system means that one has to make use of several kinds of abstractions to describe different properties and system's concerns, using languages (with existing, modelling formalisms and paradigms) and processes to be able to avoid unnecessary complexity. The chapter then defines what a model is, and what does it mean to use multiple formalisms when engaging in multi-paradigm modelling. Finally, a structure of the book is described, further explaining how the formalisms and techniques presented fit together.

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

## **Chapter 2 Bond Graphs: A Unifying Framework for Modelling of Physical Systems**

Jan F. Broenink

**Abstract** This chapter introduces a formalism to model the dynamic behaviour of physical systems known as bond graphs. A important property of this formalism is that systems from different domains (cf. electrical, mechanical, hydraulical, acoustical, thermodynamical, material) are described in the same way an integrated under the unifying concept of energy exchange. Bond graph models are directed graphs where parts are interconnected by bonds, along which exchange of energy occurs. We present a method to systematically build a bond graph starting from an ideal physical model and present methods to perform the causal analysis of bond graphs and procedures to generate equations to enable simulation.

#### **Learning Objectives**

After reading this chapter, we expect you to be able to:


#### **2.1 Introduction**

Bond graphs are a domain-independent graphical description of dynamic behaviour of physical systems. This means that systems from different domains (cf. electrical, mechanical, hydraulical, acoustical, thermodynamical, material) are described in the same way. The basis is that bond graphs are based on energy and energy exchange. Analogies between domains are more than just equations being analogous: the used *physical concepts* are analogous.

Bond-graph modelling is a powerful tool for modelling engineering systems, especially when different physical domains are involved. Furthermore, bond-graph submodels can be re-used *elegantly*, because bondgraph models are *non-causal*. The submodels can be seen as *objects*; bond-graph modelling is a form of *object-oriented* physical systems modelling.

Bond graphs are labelled and directed graphs, in which the vertices represent submodels and the edges represent an ideal energy connection between power ports. The *vertices* are idealised descriptions of physical phenomena: it are *concepts*, denoting the relevant (i.e. dominant and interesting) aspects of the dynamic behaviour of the system. It can be bond graphs itself, thus allowing hierarchical models, or it can be a set of

Jan F. Broenink University of Twente, Netherlands e-mail: j.f.broenink@utwente.nl

equations in the variables of the ports (two at each port). The *edges* are called *bonds*. They denote point-to-point connections between submodel ports.

When preparing for simulation, the bonds are embodied as two-signal connections with opposite directions. Furthermore, a bond has a power direction and a computational causality direction. Proper assigning the power direction resolves the sign-placing problem when connecting submodels structures. The internals of the submodels give preferences to the computational direction of the bonds to be connected. The eventually assigned computational causality dictates which port variable will be computed as a result (output) and consequently, the other port variable will be the cause (input). Therefore, it is necessary to rewrite equations if another computational form is specified then is needed. Since bond graphs can be mixed with block-diagram parts, bond-graph submodels can have power ports, signal inputs and signal outputs as their interfacing elements. Furthermore, aspects like the physical domain of a bond (energy flow) can be used to support the modelling process.

The concept of bond graphs was originated by [228]. The idea was further developed by Karnopp and Rosenberg in their textbooks ([161, 162, 160]), such that it could be used in practice [268, 86]. By means of the formulation by Breedveld [43, 44] of a framework based on thermodynamics, bond-graph model descriptions evolved to a systems theory.

In the next section, we will introduce the bond graph method by some examples, where we start from a given network composed of ideal physical models. Transformation to a bond graph leads to a domain independent model. In Section 3, we will introduce the foundations of bond graphs, and present the basic bond graph elements in Section 4. We will discuss a systematic method for deriving bond graphs from engineering systems in Section 5. How to enhance bond-graph models to generate the model equations and for analysis is presented in Section 6, and is called Causal Analysis. The equations generation and block diagram expansion of causal bond graphs is treated in Sections 7 and 8. Section 9 discusses simulation issues. In Section 10 we review this chapter, and also include some hints for further reading.

#### **2.2 Bond-Graph Examples**

To introduce bond graphs, we will discuss examples of two different physical domains, namely an RLC circuit (electrical domain) and a damped mass-spring system (mechanical domain, translation). The RLC circuit is given in Figure 2.1. Intro Bond Graphs

In electrical networks, the port variables of the bond graph elements are the Fig. 2.1: The RLC cicuit

element port and *electrical current* through the element port. Note that a *port*

In order to facilitate the conversion to bond graphs, we draw the different elements of the electric

domain in such a way that their ports become visible (Figure 2). To this port, we connect a *bond* or *bond* for short. This bond denotes the energy exchange between the elements. A bond is drawn as an edge with half an arrow. The direction of this half arrow denotes the positive direction of

∫

*L*

*tu*

Figure 1: The RLC circuit

element to other elements; it is the connection point of the bonds. The *power* port with the rest of the system is the product of voltage and current: *P* = *ui* resistor, capacitor and inductor are: In electrical networks, the port variables of the bond-graph elements are the electrical voltage over the element port and electrical current through the element port. Note that a port is an interface of an element to other elements; it is the connection point of the bonds. The power being exchanged by a port with the rest of the system is the product of voltage and current: *P* = *ui*. The equations of a resistor, capacitor and inductor are:

∫

<sup>d</sup> <sup>1</sup>

*dt di*

*L L*

=

*u*

*C*

*R*

*C*

*Lu*

=

*u iR*

= =

*ti*

*i*

<sup>d</sup> 1 or

In order to facilitate the conversion to bond graphs, we draw the different elements of the electric

*bond* or *bond* for short. This bond denotes the energy exchange between the elements. A bond is

*i*

∫ *dt <sup>L</sup>*

*i*

*u*

$$\begin{aligned} u\_R &= iR\\ u\_C &= \frac{1}{C} \int i\,\mathrm{d}t\\ i\_L &= \frac{1}{I} \int u\,\mathrm{d}t \end{aligned}$$

In order to facilitate the conversion to bond graphs, we draw the different elements of the electric domain in such a way that their ports become visible. For brevity, we only show this for the Capacitor Figure 2.2. To this port, we connect a power bond or bond for short. This bond denotes the energy exchange between the elements. A bond is drawn as an edge with half an arrow. The direction of this half arrow denotes the positive direction of the energy flow. In principle, the voltage source delivers power and the other elements absorb power. *R* \_ \_ *i i u u u R*

Figure 2: Electric elements with power ports Fig. 2.2: Electric Capacitor: Circuit (left) and with bond (right)

Considering the circuit of Figure 2, we see that the voltage over the elements are different and through

all elements flows the same current. We indicate this current with *i* and connect the bonds of all elements with this current *I* (Figure 3)*.* Changing the electric symbols into corresponding bond graph mnemonics, result in the bond graph of the electrical circuit. The common *i* is changed to a '1', a socalled *1-junction*. Writing the specific variables along the bonds makes the bond graph an electric bond graph. The voltage is mapped onto the domain–independent *effort* variable and the current maps onto the domain–independent *flow* variable (the current always on the side of the arrow). The 1 junction means that the current (flow) through all connected bonds is the same, and that the voltages (efforts) sum to zero, considering the sign. This sign is related to the power direction (i.e. direction of Considering the circuit of Figure 2.1, we see that the voltage over the elements are different and through all elements flows the same current. We indicate this current with *i* and connect the bonds of all elements with this current *i* (2.3). Changing the electric symbols into corresponding bond graph mnemonics, result in the bond graph of the electrical circuit. The common *i* is changed to a '1', a so-called *1-junction*. Writing the specific variables along the bonds makes the bond graph an electric bond graph. The voltage is mapped onto the domain-independent *effort* variable and the current maps onto the domain-independent *flow* variable (the current always on the side of the arrow). The 1-junction means that the current (flow) through all connected bonds is the same, and that the voltages (efforts) sum to zero, considering the sign. This sign is related to the power direction (i.e. direction of the half arrow) of the bond. This summing equation is the Kirchhoff voltage law.

the half arrow) of the bond. This summing equation is the Kirchhoff voltage law. Parallel connections, in which the voltage over all connected elements is the same, are denoted by a *u* in the port-symbol network. The bond–graph mnemonic is a 0, the so-called *0-junction*. A 0-junction means that the voltage (effort) over all connected bonds is the same, and that the currents (flows) sum to zero, considering the sign. This summing equation is the Kirchhoff current law.

> The second example is the damped mass-spring system, a mechanical system shown in 2.4. In mechanical diagrams, the port variables of the bond graph elements are the *force* on the element port and *velocity* of the element port. For the rotational mechanical domain, the port variables are the *torque* and *angular velocity*. Again, two variables are involved. The *power* being exchanged by a port with the rest of the system is the product of force and velocity: *<sup>P</sup>* <sup>=</sup> *<sup>F</sup>*<sup>v</sup> (*<sup>P</sup>* <sup>=</sup> *<sup>T</sup>*ω for the rotational case). The equations of a damper, spring and mass are (we use damping coefficient *a*, spring coefficient *K*<sup>s</sup> , mass m and applied force *F*a):

2 / 31

*i*

*u*

*L*

$$\begin{aligned} F\_d &= \alpha \upsilon \\ F\_s &= K\_s \int \upsilon \,\mathrm{d}t = \frac{1}{C\_s} \int \upsilon \,\mathrm{d}t \\ F\_m &= m \frac{d\upsilon}{dt} \qquad \text{or} \qquad \upsilon = \frac{1}{m} \int F\_m \,\mathrm{d}t \\ F\_a &= \,force \end{aligned}$$

*R*

Fig. 2.3: Bond graph with electrical symbols (left) and with standard symbols (right). The standard bond-graph symbols are defined in 2.4 means that the voltage (effort) over all connected bonds is the same, and that the currents (flows) sum to zero, considering the sign. This summing equation is the Kirchhoff current law.

in the port–symbol network. The bond–graph mnemonic is a *0*, the so–called

mechanical diagrams, the port variables of the bond graph elements are the

*mechanical domain*, the *torque* is mapped onto an effort and the *angular velocity*

implies that force is related to electric voltage and that velocity is related to

*tv*

*C*

*s*

The second example is the damped mass–spring system, a mechanical system shown in Fig. 2.4: The damped mass-spring system

Figure 4: The damped mass spring system

and *velocity* of the element port. For the rotational mechanical domain, the port variables are the *torque* and *angular velocity*. Again, two variables are involved. The *power* with the rest of the system is the product of force and velocity: *P* = *Fv* (*P* = The equations of a damper, spring and mass are (we use damping coefficient mass m and applied force *Fa*): In the same way as with the electrical circuit, we can redraw the element such that their ports become visible (2.5). The loose ends of the example all have the same velocity, which is indicated by a v. This junction element also implies that the forces sum up to zero, considering the sign (related to the power direction). The force is mapped onto an effort and the velocity onto a flow. For the rotational mechanical domain , the torque is mapped onto an effort and the angular velocity onto a flow. This implies that force is related to electric voltage and that velocity is related to electric current.

We see the following analogies between the mechanical and electrical elements:

*d*

=

α


*F force tF m v dt dv mF a m* = = = ∫ <sup>d</sup> 1 or m Besides points with common velocity, also points with common force exist in mechanical systems. Then forces are all equal and velocities sum up to zero, considering the sign (related to the power direction). These common force points are denoted as *0-junctions* in a bond graph (an example is a concatenation of a mass, a spring and a damper: the three elements are connected in 'series'). A further elaboration on analogies can be found in the next section, where the foundations of bond graphs are discussed.

In the same way as with the electrical circuit, we can redraw the element such that their ports become visible (Figure 5). The loose ends of the example all have the same velocity, which is indicated by a This junction element also implies that the forces sum up to zero, considering the sign (related to the power direction). The force is mapped onto an *effort* and the velocity onto a Through these two examples, we have introduced most bond graph symbols and indicated how in two physical domains the elements are transformed into bond graph mnemonics. One group of bond graph elements was not yet introduced: namely the *transducers*. Examples are the electric transformer, an electric motor and toothed wheels. In the next section, we will discuss the foundations of bond graphs.

Fig. 2.5: Bond graph with mechanical symbols (left) and with standard symbols (right)

#### **2.3 Foundation of Bond Graphs**

Analogies between different systems were shown in the previous section: Different systems can be represented by the same set of differential equations. These analogies have a *physical foundation*: the underlying physical concepts are analogous, and consequently, the resulting differential equations are analogous. The physical concepts are based on energy and energy exchange. Behaviour with respect to energy is domain independent. It is the same in all engineering disciplines, as can be concluded when comparing the RLC circuit with the damped mass spring system. This leads to identical bond graphs.

#### **2.3.1 Starting Points**

Before discussing the specific properties of bond graphs and the elementary physical concepts, we first recall the assumptions general for network like descriptions of physical systems, like electrical networks, mechanical or hydraulic diagrams:


This implies that it is possible to separate system properties from each other and to denote them distinctly, while the connections between these submodels are ideal. *Separate system properties* mean physical concepts and the ideal connections represent the energy flow, i.e. the bonds between the submodels. This *idealness* property of the connections means that in these connections no energy can be generated or dissipated. This is called *power continuity*. This structure of connections is a conceptual structure, which does not necessary have a size. This concept is called reticulation [228] or tearing [173]. See also [304].

The system's submodels are concepts, idealised descriptions of physical phenomena, which are recognised as the dominating behaviour in components (i.e. real-life, tangible system parts). This implies that a model of a concrete part is not necessary only one concept, but can consist of a set of interconnected concepts.

#### **2.3.2 Bonds and Ports**

The contact point of a submodel where an ideal connection will be connected to is called a power port or port for short. The connection between two submodels is called a power bond or bond; it is drawn as a single line (2.6). This bond denotes an ideal energy flow between the two connected submodels. The energy entering the bond on one side immediately leaves the bond at the other side (power continuity).

Fig. 2.6: The energy flow between two submodels represented by a bond.

The *energy flow* along a bond has the physical dimension of power, being the product of two variables. In each physical domain, there is such a combination of variables, for which a physical interpretation is useful. In electrical networks, the two variables are voltage and current. In mechanical systems, the variable pairs are force and velocity for translation and torque and angular velocity for rotation. In hydraulics, it is pressure and volume flow. For thermodynamic systems, temperature and entropy flow are used. These pairs of variables are called (power-) conjugated variables.

In order to understand the connection as established by a bond, this bond can be interpreted in two different ways, namely:

1. As an interaction of energy.

The connected subsystems form a load to each other by their energy exchange. A power bond embodies a connection where a physical quantity is exchanged.

2. As a bilateral signal flow.

The connection is interpreted as two signals, an effort and flow, flowing in opposite direction, thus determining the computational direction of the bond variables. With respect to one of the connected submodels, the effort is the input and the flow the output, while for the other submodel input and output are of course established by the flow and effort respectively.

These two ways of conceiving a bond is essential in bond graph modelling. Modelling is started by indicating the physical structure of the system. The bonds are first interpreted as interactions of energy, and then the bonds are endowed with the computational direction, interpreting the bonds as bilateral signal flows. During modelling, it need *not* be decided yet what the computational direction of the bond variables is. Note that, determining the computational direction during modelling restricts submodel reuse. It is however necessary to derive the mathematical model (set of differential equations) from the graph. The process of determining the computational direction of the bond variables is called *causal analysis*. The result is indicated in the graph by the so-called *causal stroke*, indicating the direction of the effort, and is called the causality of the bond (2.7).

In equation form, 2.7 can be written as:


#### **2.4 Bond-Graph Elements**

The constitutive equations of the bond graph elements are introduced via examples from the electrical and mechanical domains. The nature of the constitutive equations lay demands on the causality of the connected bonds. Bond graph elements are drawn as letter combinations (mnemonic codes) indicating the type of element. The bond graph elements are the following:

2 Bond Graphs: A Unifying Framework for Modelling of Physical Systems 21

Fig. 2.7: Determine the signal direction of the effort and flow (we do not use the power direction at the bonds, so it is not shown here)


**R** Resistor dissipating free energy, e.g. electric resistor, mechanical friction.

**Se, Sf** sources, e.g. electric mains (voltage source), gravity (force source), pump (flow source).

**TF** transformer, e.g. an electric transformer, toothed wheels, lever.

**GY** gyrator, e.g. electromotor, centrifugal pump.

**0, 1** 0- and 1-junctions, for ideal connecting two or more submodels.

#### **2.4.1 Storage Elements**

Storage elements store all kinds of free energy. As indicated above, there are two types of storage elements: C-elements and I-elements. The *q*-type and *p*-type variables are *conserved quantities* and are the result of an accumulation (or integration) process. They are the *(continuous) state variables* of the system.

In C-elements, like a capacitor or spring, the conserved quantity, *q*, is stored by accumulating the net flow, *f* , to the storage element. This results in the differential equation:

*q*˙ = *f*

which is called a *balance equation*, and forms a part of the constitutive equations of the storage element. In the other part of the constitutive equations, the state variable, *q*, is related to the effort,*e*:

$$e = e(q)$$

This relation depends on the specific shape of the particular storage element.

In 2.8, examples of C-elements are given together with the equivalent block diagram. The equations for a linear capacitor and linear spring are:

$$\begin{aligned} \dot{q} &= i, & \mu &= \frac{1}{C} q\\ \dot{x} &= \nu, & F &= Kx = \frac{1}{C} x \end{aligned}$$

For a capacitor, C [F] is the capacitance and for a spring, K [N/m] is the stiffness and C [m/N] the compliance. For all other domains, a C-element can be defined.

The effort variable is equal when two C-storage elements connected in parallel with a resistor in between are in equilibrium. Therefore, the domain-independent property of an effort is *determination of equilibrium*.

In I-elements, like a inductor or mass, the conserved quantity, *p*, is stored by accumulating the net flow, *e*, to the storage element. This results in the differential equation:

Fig. 2.8: Examples of C-elements

$$
\dot{p} = e
$$

which is called a *balance equation*, and forms a part of the constitutive equations of the storage element. In the other part of the constitutive equations, the state variable, *q*, is related to the effort,*e*:

$$f = f(q)$$

This relation depends on the specific shape of the particular storage element.

In 2.9, examples of I-elements are given together with the equivalent block diagram. The equations for a linear inductor and linear mass are:

$$
\dot{\lambda} = u, \text{ } i = \frac{1}{L}\lambda \tag{2.1}
$$

$$
\dot{p} = F, \; \nu = \frac{1}{m} p \tag{2.2}
$$

For an inductor, L [H] is the inductance and for a mass, m [kg] is the mass. For all other domains, an I-element can be defined.

The flow variable is equal when two I-storage elements connected in parallel with a resistor in between, are in equilibrium. Therefore, at I-elements, the domain-independent property of the flow is *determination of equilibrium*. F or example, when two bodies, moving freely in space each having a different momentum, are being coupled (collide and stick together), the momentum will divide among the masses such that the velocity of both masses is the same (this is the conservation law of momentum).

Note that when at the two types of storage elements, the role of effort and flow are exchanged: the C- element and the I-element are each other's *dual form*.

The block diagrams in 2.8 and 2.9, and also in the next Figures 10 to 16, show the computational direction of the signals involved. They are indeed the expansion of the corresponding causal bond graph. The equations are given in computational form, consistent with the causal bond graph and the block diagram.

#### **2.4.2 Resistors**

Resistors, R-elements, dissipate free energy. Examples are dampers, frictions and electric resistors (2.10). In real-life mechanical components, friction is always present. Energy from an arbitrary domain flows irreversibly to the thermal domain (and heat is produced). This means that the energy flow towards the resistor is always

Fig. 2.9: Examples of I-elements

positive. The constitutive equation is an algebraic relation between the effort and flow, and lies principally in the first or third quadrant.

$$e = f(f)$$

Fig. 2.10: Examples of resistors

An electrical resistor is mostly linear (at constant temperature), namely Ohm's law. The electrical resistance value is in [Ω].

$$u = Ri$$

Mechanical friction mostly is non-linear. The resistance function is a combination of dry friction and viscous friction. Dry friction is a constant friction force and viscous friction is the linear term. Sometimes, also stiction

*e*

Block diagram expansion

*f*

*e*

*<sup>f</sup> <sup>f</sup>*<sup>b</sup>

*e*b

is involved, a tearing-loose force only applicable when starting a movement. All these forms of friction can be modelled with the R-element. The viscous friction has as formula (*R* in [Ns/m]:

*F* = *R*v

If the resistance value can be controlled by an external signal, the resistor is a modulated resistor, with mnemonic MR. An example is a hydraulic tap: the position of the tap is controlled from the outside, and it determines the value of the resistance parameter.

If the thermal domain is modelled explicitly, the production of thermal energy should explicitly be indicated. Since the dissipator irreversibly produces thermal energy, the thermal port is drawn as a kind of source of thermal energy. The R becomes an RS.

#### **2.4.3 Sources**

Sources represent the interaction of a system with its environment. Examples are external forces, voltage and current sources, ideal motors, etc. (2.11). Depending on the type of the imposed variable, these elements are drawn as Se or Sf.

Besides as a 'real' source, source elements are used to give a variable a fixed value, for example, in case of a point in a mechanical system with a fixed position, a Sf with value 0 is used (fixed position means velocity zero). When a system part needs to be excited, often a known signal form is needed, which can be modelled by a modulated source driven by some signal form. An example is shown in Figure 2.12. University of Twente, Dept EE Intro Bond Graphs Besides as a 'real' source, source elements are used to give a variable a fixed value, for example, in

case of a point in a mechanical system with a fixed position, a Sf with value 0 is used (fixed position

Fig. 2.11: Examples of sources Angular velocity

Figure 11: Examples of sources

Velocity source

source

12 21 *f nf e ne* = =

Fig. 2.12: Example of a modulated voltage source

An ideal *transformer* is represented by TF and is power continuous (i.e. no power is stored or dissipated). The transformation can within the same domain (toothed wheel, lever) or between

Efforts are transduced to efforts and flows to flows. The parameter *n* is the *transformer ratio.* Due to the power continuity, only *one* dimensionless parameter, *n*, is needed to describe both the effort transduction and the flow transduction. The parameter *n* is *unambiguously* defined as follows: e

different domains (electromotor, winch), see Figure 13. The equations are:

Figure 12 : Example of a modulated voltage source

**4.4 Transformers and Gyrators**

#### **2.4.4 Transformers and Gyrators**

An ideal *transformer* is represented by TF and is power continuous (i.e. no power is stored or dissipated). The transformation can within the same domain (toothed wheel, lever) or between different domains (electromotor, winch), see Figure 13. The equations are:

$$e\_1 = ne\_2\tag{2.3}$$

$$f\_2 = nf\_1\tag{2.4}$$

Efforts are transduced to efforts and flows to flows. The parameter n is the *transformer ratio*. Due to the power continuity, only *one* dimensionless parameter, *n*, is needed to describe both the effort transduction and the flow transduction. The parameter *n* is unambiguously defined as follows: *e*<sup>1</sup> and *f*<sup>1</sup> belong to the bond pointing towards the TF. This way of defining the transformation ratio is standard in leading publications [160],[44],[269],[67]. If *n* is not constant, the transformer is a *modulated transformer*, a MTF. The transformer ratio now becomes an input signal to the MTF.

Fig. 2.13: Examples of transformers

An ideal *gyrator* is represented by GY, and is also power continuous (i.e. no power is stored or is dissipated. Examples are an electromotor, a pump and a turbine. Real-life realisations of gyrators are mostly transducers representing a domain-transformation (Figure 14). The equations are:

$$e\_1 = r f\_2 \tag{2.5}$$

$$e\_2 = r f\_1 \tag{2.6}$$

The parameter r is the *gyrator ratio*, and due to the power continuity, only one parameter to describe both equations. No further definition is needed since the equations are symmetric (it does not matter which bond points inwards, only that one bond points towards and the other points form the gyrator). *r* has a physical dimension, since *r* is a relation between effort and flow (it has the same dimension as the parameter of the R element). If *r* is not constant, the gyrator is a *modulated gyrator*, a MGY.

Fig. 2.14: Examples of gyrators

#### **2.4.5 Junctions**

Junctions couple two or more elements in a power continuous way: there is *no* energy storage or dissipation in a junction. Examples are a series connection or a parallel connection in an electrical network, a fixed coupling between parts of a mechanical system. Junctions are *port-symmetric*: the ports can be exchanged in the constitutive equations. Following these properties, it can be proven that there exist only two pairs of junctions: the 1-junction and the 0-junction.

The *0-junction* represents a node at which all efforts of the connecting bonds are equal (2.15). An example is a parallel connection in an electrical circuit. Due to the power continuity, the sum of the flows of the connecting bonds is zero, considering the sign. The power direction (i.e. direction of the half arrow) determines the sign of the flows: all inward pointing bonds get a plus and all outward pointing bonds get a minus. (Figure X). This summation is the Kirchhoff current law in electrical networks: all currents connecting to one node sum to zero, considering their signs: all inward currents are positive and all outward currents are negative.

We can depict the 0-junction as the representation of an effort variable, and often the 0-junction will be interpreted as such. The 0-junction is more than the (generalised) Kirchhoff current law, namely also the equality of the efforts (like electrical voltages being equal at a parallel connection).

The *1-junction* (2.16) is the dual form of the 0-junction (roles of effort and flow are exchanged). The 1-junction represents a node at which all flows of the connecting bonds are equal. An example is a series connection in an electrical circuit. The efforts sum to zero, as a consequence of the power continuity. Again, the power direction (i.e. direction of the half arrow) determines the sign of the efforts: all inward pointing bonds get a plus and all outward pointing bonds get a minus. This summation is the Kirchhoff voltage law in electrical networks: the sum of all voltage differences along one closed loop (a mesh) is zero. In the mechanical domain, the 1-junction represents a force balance (also called the principle of d'Alembert), and is a generalisation of Newton's third law, action = - reaction).

Just as with the 0-junction, the 1-junction is more than these summations, namely the equality of the flows. Therefore, we can depict the 1-junction as the representation of a flow variable, and often the 1-junction will be interpreted as such.

#### **2.4.6 Positive Orientation**

By definition, the power is positive in the direction of the power bond (i.e. direction of the half arrow). A port that has an incoming bond connected to, consumes power if this power is positive (i.e. both effort and flow are

Fig. 2.15: Examples of gyrators

Fig. 2.16: Examples of gyrators

either positive or negative, as the product of effort and flow is the power). In other words: the power flows in the direction of the half arrow if it is positive and the other way if it is negative.

R-, C- and I-elements have an incoming bond (half arrow towards the element) as standard, which results in positive parameters when modelling real-life components. For source elements, the standard is outgoing, as sources mostly deliver power to the rest of the system. A real-life source then has a positive parameter. For TF- and GY-elements (transformers and gyrators), the standard is to have one bond incoming and one bond outgoing, to show the 'natural' flow of energy. Furthermore, using the standard definition of the parameter at the transformer (incoming bond is connected to port 1 and the ratio *<sup>n</sup>* is *<sup>e</sup>*1/*e*2) positive parameters will be the result. Note that a gyrator does *not* need such a definition, since its equations are symmetric.

It is possible, however, that negative parameters occur. Namely, at transformers and sources in the mechanical domain when there is a reverse of velocity or the source acts in the negative direction.

Using the definitions discussed in this section, the bond-graph definition is unambiguous, implying that in principle there is no need for confusion. Furthermore, this systematic way will help resolving possible sign-placing problems often encountered in modelling, especially in mechanical systems.

#### **2.4.7 Duality and Dual Domains**

As indicated in 2.4.1, the two storage elements are each other's dual form. The role of effort and flow in a C-element and I-element are exchanged. Leaving one of the storage elements (and also one of the sources) out of the list of bond graph elements, to make this list as small as possible, can be useful from a mathematical viewpoint, but does not enhance the insight in physics.

Decomposing an I-element into a GY and a C, though, gives more insight. The only storage element now is the C-element. The flow is only a time derivative of a conserved quantity, and the effort determines the equilibrium. This implies that the physical domains are actually pairs of two dual domains: in mechanics, we have *potential* and *kinetic* domains for both rotation and translation), in electrical networks, we have the *electrical* and *magnetic* domains. However, in the thermodynamic domain, no such dual form exists (Breedveld, 1982). This is consistent with the fact that *no* thermal I-type storage exists (as a consequence of the second law of thermodynamics: in a thermally isolated system, the entropy never decreases).

#### **2.5 Systematic Procedure to Derive a Bond-Graph Model**

In the previsous section, we have discussed the basic bond-graph elements and the bonds, so we can transform a domain-dependent *ideal-physical model*, written in domain-dependent symbols, into a bond graph. For this transformation, there is a systematic procedure, which will be presented in the next section.

To generate a bond-graph model starting from an ideal-physical model, a *systematic method* exist, which we will present here as a procedure. This procedure consists roughly of the identification of the domains and basic elements, the generation of the connection structure (called the *junction structure*), the placement of the elements, and possibly simplifying the graph. The procedure is different for the mechanical domain compared to the other domains. These differences are indicated between parenthesis. The reason is that elements need to be connected to *difference variables* or *across variables*. The efforts in the non-mechanical domains and the velocities (flows) in the mechanical domains are the across variables we need.

#### **2.5.1 The Eight Steps of the Systematic Procedure**

Steps 1 and 2 concern the identification of the domains and elements.


Note that only the references in the mechanical domains have a direction.

Steps 3 through 6 describe the generation of the connection structure (called the *junction structure*).


The junction structure is now ready and the elements can be connected.


Fig. 2.17: Construction of effort differences (flow differences)


Fig. 2.18: Simplification rules for the junction structure: (a, b): elimination of a junction between bonds; (c, d): contraction of two the same junctions; (e,f): two separately constructed identical differences fuse to one difference.

#### **2.5.2 Illustration of the Systematic Procedure**

We will illustrate these steps with a concrete example consisting of an electromotor fed by electric mains, a cable drum and a load (2.19).

A possible ideal-physical model (IPM) is given in Figure 2.20. The mains is modelled as an ideal voltage source. At the electromotor, the inductance, electric resistance of the coils, bearing friction and rotary inertia are taken into account. The cable drum is the transformation from rotation to translation, which we consider as ideal. The load consists of a mass and the gravity force. Starting from the IPM of Figure 2.20, we will construct a bond graph using the 8 steps mentioned above.

15 / 31

bonds. (c, d) Contraction of two the same junctions. (e, f) Two separately constructed

*g*

mains, a cable drum and a load (Figure 19).

identical differences fuse to one difference.

Figure 19: Sketch of the hoisting device. A possible ideal–physical model (IPM) is given in Figure 20. The mains is modelled as an ideal voltage source. At the electromotor, the inductance, electric resistance of the coils, bearing friction and Fig. 2.19: Sketch of the hoisting device University of Twente, Dept EE Intro Bond Graphs

**Step 1** Fig. 2.20: Possible ideal-physical model augmented with the domain information of step 1 Electric domain Mechanic domain Rotation Translation

Figure 20: Possible ideal-physical model augmented with the domain information of step 1.

*Rbearing*

• An *electric domain* part with a voltage source (Se), a resistor (R), an inductor (I) and the electric

*m*

• A *rotation mechanic domain* part with the rotation port of the electromotor (GY port), bearing

v0

#### **Step 1**

This system contains: Figure 20: Possible ideal-physical model augmented with the domain information of step 1.

• A *translation mechanic domain* part with the cable of the cable drum (TF port), the mass of the load (I) and the gravity force acting on the mass (Se). • An electric domain part with a voltage source (Se), a resistor (R), an inductor (I) and the electric port of the electromotor (GY port). **Step 1** This system contains:

friction (R), inertia (I), and the axis of the cable drum (TF port).


In Figure 2.20, the domains are indicated and all elements have a unique name. • A *translation mechanic domain* part with the cable of the cable drum (TF port), the mass of the

Figure 21: References added to the IPM.

**Step3**

port of the electromotor (GY port).

This system contains:

#### **Step 2**

u0 The references are indicated in the ideal physical model: the voltage *<sup>u</sup>*0, the rotational velocity <sup>ω</sup><sup>0</sup> and the linear velocity v0. The two velocities also get a positive orientation (i.e. a direction in which the velocity is positive). This result is shown in Figure 2.21. **Step 2** The references are indicated in the ideal physical model: the voltage u0, the rotational velocity ω0 and the linear velocity v0. The two velocities also get a positive orientation (i.e. a direction in which the

In Figure 20, the domains are indicated and all elements have a unique name.

load (I) and the gravity force acting on the mass (Se).

velocity is positive). This result is shown in Figure 21.

The other voltages, angular velocities and linear velocities are sought for and are indicated in the IPM Fig. 2.21: References added to the IPM.

(Figure 22). These variables are respectively u1, u2, u3 , ω<sup>1</sup> , v1.

#### **Step 3**

Intro Bond Graphs Jan F. Broenink, © 1999

**Step 4** The variables found in step 3 are depicted with 0– respectively 1–junctions in Figure 23, in a layout Fig. 2.22: The IPM augmented with relevant voltages, velocities, and angular velocities.

(references have the value 0 and do not contribute to the dynamic behaviour).

<sup>1</sup> u3

Figure 22: The IPM augmented with relevant voltages, velocities and angular velocities.

compatible to the IPM. The references are not drawn, because they are so to speak eliminated

(references have the value 0 and do not contribute to the dynamic behaviour).

ω1

ω0

The difference variables are drawn in the bond graph, see Figure 24. After this step, the junction

mechanical domain elements are always connected to 0-junctions (efforts or effort differences) and

v1

1

Figure 23: First skeleton of the bond graph: Voltages are shown as 0–junctions and velocities as 1–

v1 1

v0

v1

When checking all ports of the elements found in step 1 for voltage differences, angular velocity differences and linear velocity differences, only u12 and u23 are identified. No velocity differences are

#### **Step 4**

Figure 23: First skeleton of the bond graph: Voltages are shown as 0–junctions and velocities as 1– v1 1 The variables found in step 3 are depicted with 0- respectively 1-junctions in Figure 2.23, in a layout compatible to the IPM. The references are not drawn, because they are so to speak eliminated (references have the value 0 and do not contribute to the dynamic behaviour). Figure 22: The IPM augmented with relevant voltages, velocities and angular velocities. **Step 4** The variables found in step 3 are depicted with 0– respectively 1–junctions in Figure 23, in a layout compatible to the IPM. The references are not drawn, because they are so to speak eliminated

junctions.

:U12 :U23

1 1

0 0

**Step 5**

needed.

**Step 7**

0 0 0 1

1 1

0 0

:U12 :U23

<sup>0</sup> u1 u2

u0

0 0

structure is generated and the elements can be connected. junctions. Fig. 2.23: First skeleton of the bond graph: Voltages are shown as 0-junctions and velocities as 1-junctions.

#### **Step 5**

u1 u2 u3 ω<sup>1</sup> **Step 6** The difference variables are drawn in the bond graph, see Figure 24. After this step, the junction structure is generated and the elements can be connected. When checking all ports of the elements found in step 1 for voltage differences, angular velocity differences and linear velocity differences, only *u*12 and *u*23 are identified. No velocity differences are needed.

#### **Step 6**

Figure 24: Difference variables (u12 and u23) shown in the bond graph. **Step 7** All elements are connected to the appropriate junctions, as shown in Figure 25. Note that non-The difference variables are drawn in the bond graph, see Figure 2.24. After this step, the junction structure is generated and the elements can be connected.

#### **Step 7**

Figure 24: Difference variables (u12 and u23) shown in the bond graph. v1 1 All elements are connected to the appropriate junctions, as shown in Figure 2.25. Note that non-mechanical domain elements are always connected to 0-junctions (efforts or effort differences) and that mechanical domain elements are always connected to 1-junctions.

that mechanical domain elements are always connected to 1–junctions.

u1 u2 u3 ω<sup>1</sup>

0 0 0 1

#### **Step 8**

16 / 31

All elements are connected to the appropriate junctions, as shown in Figure 25. Note that nonmechanical domain elements are always connected to 0-junctions (efforts or effort differences) and that mechanical domain elements are always connected to 1–junctions. As last action, the bond graph needs to be simplified, to eliminate superfluous junctions (according to the rules given in Figure 2.18). The resulting bond graph is the outcome of the systematic method, see Figure 2.26.

Obviously, this systematic method is not the *only* method for deriving bond graphs from ideal physical models (IPMs). Another method is the so-called *inspection method*, where parts of the IPM are recognised that can be

v1

1

I:*m*

TF:*D*/2

Se: -*mg*

structure is generated and the elements can be connected.

The difference variables are drawn in the bond graph, see Figure 24. After this step, the junction

**Step 7** F University of Twente, Dept EE ig. 2.24: Junction Structure ready: Difference variables (*u*<sup>12</sup> and *u*23) shown in the bond graph. Intro Bond Graphs R:*R*el I:*L*

**Step 8** As last action, the bond graph needs to be simplified, to eliminate superfluous junctions (according to Fig. 2.25: The IPM augmented with relevant voltages, velocities, and angular velocities. As last action, the bond graph needs to be simplified, to eliminate superfluous junctions (according to

the rules given in Figure 18). The resulting bond graph is the outcome of the systematic method.

models (IPMs). Another method is the so–called *inspection method*, where parts of the IPM are recognised that can be represented by one junction. An example is a series connection in an electrical

*Causal analysis* is the determination of the signal direction of the bonds. The energetic connection (bond) is now interpreted as a bi-directional signal flow. The result is a *causal bond graph*, which can be seen as a compact block diagram. Causal analysis is in general completely covered by modelling and simulation software packages that support bond graphs like Enport (Rosenberg, 1974), MS1 (Lorenz, 1997), CAMP (Granda, 1985) and 20- SIM (Broenink, 1990, 1995, 1997, 1999b; Broenink and Kleijn, 1999). Therefore, in practice, causal analysis need not be done by hand. Besides derivation of equations, causal analysis can give insight in the correctness and competency of the model. This last

Dependent on the kind of equations of the elements, the element ports can impose constraints on the connected bonds. There are four different constraints, which will be treated before a systematic

16 / 31

I:*L*

.. *Usource*

Figure 25: The complete bond graph.

**Step 8**

**Step 6**

Obviously, this systematic method is not the *only* method for deriving bond graphs from ideal physical models (IPMs). Another method is the so–called *inspection method*, where parts of the IPM are recognised that can be represented by one junction. An example is a series connection in an electrical Obviously, this systematic method is not the *only* method for deriving bond graphs from ideal physical Fig. 2.26: The simplified bond graph, the result of the systematic method.

Figure 26: The simplified bond graph, the result of the systematic method.

network, which is drawn as one 1–junction. This is the case in the example above: The voltage source,

Figure 26: The simplified bond graph, the result of the systematic method.

reason especially motivates the discussion of causal analysis in this chapter.

procedure for causal analysis of bond graphs is discussed.

inductor, electric resistor and electric port of the motor are directly connected to one 1–junction. Although the inspection method is shorter than the systematic method, it is rather error prone. **6 Causal analysis** *Causal analysis* is the determination of the signal direction of the bonds. The energetic connection network, which is drawn as one 1–junction. This is the case in the example above: The voltage source, inductor, electric resistor and electric port of the motor are directly connected to one 1–junction. Although the inspection method is shorter than the systematic method, it is rather error prone. **6 Causal analysis** represented by one junction. An example is a series connection in an electrical network, which is drawn as one 1-junction. This is the case in the example above: The voltage source, inductor, electric resistor and electric port of the motor are directly connected to one 1-junction. Although the inspection method is shorter than the systematic method, it is rather error prone.

(bond) is now interpreted as a bi-directional signal flow. The result is a *causal bond graph*, which can be seen as a compact block diagram. Causal analysis is in general completely covered by modelling and simulation software packages that support bond graphs like Enport (Rosenberg, 1974), MS1 (Lorenz, 1997), CAMP (Granda, 1985) and 20- SIM (Broenink, 1990, 1995, 1997, 1999b; Broenink and Kleijn, 1999). Therefore, in practice, causal analysis need not be done by hand. Besides derivation of equations, causal analysis can give insight in the correctness and competency of the model. This last

Dependent on the kind of equations of the elements, the element ports can impose constraints on the connected bonds. There are four different constraints, which will be treated before a systematic

reason especially motivates the discussion of causal analysis in this chapter.

#### **2.6 Causal Analysis**

*Causal analysis* is the determination of the signal direction of the bonds. The energetic connection (bond) is now interpreted as a bi-directional signal flow. The result is a causal bond graph, which can be seen as a compact block diagram. Causal analysis is in general completely covered by modelling and simulation software packages that support bond graphs like Enport [242], MS1 [191], CAMP [129] and 20-sim [46, 48, 49, 50]. Therefore, in practice, causal analysis need not be done by hand. Besides derivation of equations, causal analysis can give insight in the correctness and competency of the model. This last reason especially motivates the discussion of causal analysis in this chapter.

#### **2.6.1 Causal Constraints**

Dependent on the kind of equations of the elements, the element ports can impose constraints on the connected bonds. There are four different constraints, which will be treated before a systematic procedure for causal analysis of bond graphs is discussed.

#### **2.6.1.1 Fixed causality**

*Fixed causality* is the case, when the equations only allow one of the two port variables to be the outgoing variable. This occurs at sources: an effort source (Se) has by definition always its effort variable as signal output, and has the causal stroke outwards. This causality is called *effort-out causality* or *effort causality*. A flow source (Sf) clearly has a *flow-out causality* or *flow causality*.

Another situation where fixed causality occurs is at nonlinear elements, where the equations for that port cannot be inverted (for example, division by zero). This is possible at R, GY, TF, C and I elements. Thus, there are two reasons to impose a fixed causality:


#### **2.6.1.2 Constrained Causality**

At TF, GY, 0- and 1-junction, relations exist between the causalities of the different ports of the element. These relations are *causal constraints*, since the causality of a particular port imposes the causality of the other ports. At a TF, one of the ports has effort-out causality and the other has flow-out causality. At a GY, both ports have either effort-out causality or flow-out causality.

At a 0-junction, where all efforts are the same, *exactly one* bond must bring in the effort. This implies that 0-junctions always have exactly one causal stroke at the side of the junction. The causal condition at a 1-junction is the dual form of the 0-junction. All flows are equal, thus *exactly one* bond will bring in the flow, implying that *exactly one* bond has the causal stroke away from the 1-junction.

#### **2.6.1.3 Preferred Causality**

At the storage elements, the causality determines whether an integration or differentiation with respect to time will be the case. Integration has preference above a differentiation. At the integrating form, an initial condition must be specified. Besides, integration with respect to time is a process, which can be realised physically. Numerical differentiation is not physically realisable, since information at future time points is needed. Another drawback of differentiation occurs when the input contains a step function: the output will then become infinite. Therefore, integrating causality is seen as the *preferred causality*. This implies that a C-element has effortout causality and an I-element has flow-out causality at its preference. These preferences are also illustrated in Figure 2.8 and Figure 2.9, when looking at the block-diagram expansion.

#### **Effort-out vs. flow-out causality**

When a voltage *u* is imposed on an electrical capacitor (a C-element), the current *i* is the result of the constitutive equation of the capacitor:

$$i = C \frac{\mathrm{d}u}{\mathrm{d}t}$$

A differentiation is thus happening. We have a problem when the voltage instantly steps to another value, since the current will be infinite (the derivative of a step is infinite). This is not the case when the current is imposed on a capacitor. Now, an integral is used:

$$
\mu = \mu\_0 + \int i \mathbf{d} t
$$

The first case is flow-out causality (effort imposed, flow the result), and the second case is effort-out causality, which is the preferred causality. Furthermore, an effort-out causality also results in a state variable with initial condition *u*0. At an inductor, the dual form of the C-element is the case: flow-out causality will result in an integral causality, being the preference.

#### **2.6.1.4 Indifferent Causality**

*Indifferent causality* is used, when there are no causal constraints! At a linear R, it does not matter which of the port variables is the output. Consider an electrical resistor. Imposing a current (flow) yields:

$$u = Ri$$

It is also possible to impose a voltage (effort) on the linear resistor:

$$i = \frac{\mu}{\mathcal{R}}$$

There is no difference choosing the current as incoming variable and the voltage as outgoing variable, or the other way around.

#### **2.6.2 Causal Analysis Procedure**

In terms of causal constraints, we can say that the Se and Sf have a fixed causality, the C and I have a preferred causality, the TF, GY, 0 and 1 have constrained causality, and the R has an indifferent causality (provided that the equations of these basic elements all are invertible). These causal forms have been shown in 2.4. When the equations are not invertible, a fixed causality must be used.

The procedure for assigning causality on a bond graph starts with those elements that have the strongest causality constraint namely fixed causality (deviation of the causality condition cannot be granted by rewriting the equations, since rewriting is not possible). Via the bonds (i.e. connections) in the graph, one causality assignment can cause other causalities to be assigned. This effect is called *causality propagation*: after one assignment, the causality propagates through the bond graph due to the causal constraints.

The causality assignment algorithm is as follows:

	- 3 Chose a not yet causal port with indifferent causality, assign its causality, and propagate this assignment through the graph using the causal constraints. Go on until all ports with indifferent causality have their causalities assigned.

Often, the bond graph is completely causal after step 2, without any causal conflict (all causal conditions are satisfied). If this is *not* the case, then the moment in the procedure where a conflict occurs or where the graph becomes completely causal, can give insight in the correctness and competence of the model. Before discussing these issues, first an example will be treated.

#### **Causality algorithm**

To exemplify the causality algorithm, the same example as in 2.5 is used. In Figure 2.27, the completely causal bond graph of the hoisting device is shown. Numbers at the causal strokes indicate the order in which the bonds were made causal.

At step 1a, we assign causality 1 and 2. It does not matter with which source we start. No causality can be propagated. Step 1b is not applicable, since there are no ports of that category. At step 2, we started with the inductor. Propagation is from stroke 3 until stroke 6. The next storage element (preferred causality) is inertia J. Propagation of this causality (number 7), completes the causality of the graph, implying that we do not need step 3. However, the mass of the load does not get his preference. What the consequences are, is subject of the next section. Intro Bond Graphs Jan F. Broenink, © 1999

Fig. 2.27: The causal bond graph of the hoisting device.

We discuss here those situations whereby conflicts occur in the causal analysis procedure or when step 3 of the algorithm appears to be necessary. The place in procedure where a conflict appears or the bond graph becomes completely causally augmented, can give insight in the correctness of the model.

conditions are satisfied). Each storage element represents a state variable, and the set of equations is an

example is a diode or a valve having zero current resp. flow while blocking. Allowing a small

this storage element does *not* represent a *state variable*. The initial value of this storage element cannot be chosen freely. Such a storage element often is called a *dependent storage element*. This indicates that a storage element was *not* taken into account during modelling, which should be there

When a conflict arises at *step 2*, a storage element receives a *non*-–preferred causality. This means that

Figure 27: The causal bond graph of the hoisting device

**6.3 Model insight via causal analysis**

#### Often, the bond graph is completely causal after *step 2*, *without* any causal conflict (all causal **2.6.3 Model Insight via Causal Analysis**

explicit set of ordinary differential equations (not necessarily linear or time invariant). When the bond graph is completely causal after *step 1a*, the model does *not* have any dynamics. The We discuss here those situations whereby conflicts occur in the causal analysis procedure or when step 3 of the algorithm appears to be necessary. The place in procedure where a conflict appears or the bond graph becomes completely causally augmented, can give insight in the correctness of the model.

behaviour of all variables now is determined by the fixed causalities of the sources. Arises a causal conflict at *step 1a* or at *step 1b*, then the problem is ill posed. The model must be changed, by adding some elements. An example of a causal conflict at *step 1a* is two effort sources connected to one 0- Often, the bond graph is completely causal after *step 2*, without any causal conflict (*all* causal conditions are satisfied). Each storage element represents a state variable, and the set of equations is an explicit set of ordinary differential equations (not necessarily linear or time invariant).

junction. Both sources 'want' to determine the one effort variable. At a conflict at *step 1b*, a possible adjustment is changing the equations of the fixed–causality element such that these equations become *invertable*, and thus the *fixed*ness of the constraint disappears. An When the bond graph is completely causal after*step 1a*, the model does not have any dynamics. The behaviour of all variables now is determined by the fixed causalities of the sources. Arises a causal conflict at step 1a or at step 1b, then the problem is ill posed. The model must be changed, by adding some elements. An example of

resistance during blocking, the equations become invertable.

a causal conflict at step 1a is two effort sources connected to one 0-junction. Both sources 'want' to determine the one effort variable.

At a conflict at *step 1b*, a possible adjustment is changing the equations of the fixed-causality element such that these equations become invertible, and thus the fixedness of the constraint disappears. An example is a diode or a valve having zero current resp. flow while blocking. Allowing a small resistance during blocking, the equations become invertible.

When a conflict arises at *step 2*, a storage element receives a non-preferred causality. This means that this storage element does *not* represent a *state variable*. The initial value of this storage element cannot be chosen freely. Such a storage element often is called a *dependent storage element*. This indicates that a storage element was *not* taken into account during modelling, which should be there from physical systems viewpoint. It can be deliberately omitted, or it might be forgotten. At the hoisting device example, the load of the hoist (I-element) is such a dependent storage element. Elasticity in the cable was not modelled. If it had been modelled, a C-storage element connected to a 0-junction between the cable drum and load would appear, and would take away the causal conflict.

When *step 3* of the causality algorithm is necessary, a so-called *algebraic loop* is present in the graph. This loop causes the resulting set differential equations to be *implicit*. Often this is an indication that a storage element was not modelled, which should be there from a physical systems viewpoint.

In general, different ways to handle the causal conflicts arising at step 2 or step 3 are possible:

1. Add elements.

For example, you can withdraw the decision to neglect certain elements. The added elements can be parasitic, for example, to add elasticity (C-element) in a mechanical connection, which was modelled as rigid. Additionally adding a damping element (R) reduces the simulation time considerably, which is being advised.

2. Change the bond graph such that the conflict disappears.

For a step-2 conflict, the dependent storage element is taken together with an independent storage element, having integral causality. For a step-3 conflict, sometimes resistive elements can be taken together to eliminate the conflict. This can be performed via transformations in the graph. The complexity of this operation depends on the size and kind of submodels along the route between the storage elements or resistors under concern.

3. The bond graph is *not* changed.

For simulation a special (implicit) integration routine is needed. The implicit equations are computed using an iteration scheme, mostly as part of the numerical integration method.

Algebraic loops and loops between a dependent and an independent storage element are called *zero-order causal paths* (ZCPs). Besides these two kinds, there are three other kinds, having an increasing complexity and resulting in more complex equations. These occur for instance in rigid-body mechanical systems (van Dijk and Breedveld, 1991).

By interpreting the result of causal analysis, several properties of the model can be recognised, which could otherwise only be done after deriving equations.

#### **2.6.4 Order of the Set State Equations**

The causal analysis also gives information on the order of the set equations. The number of initial conditions equals the number of storage elements with integral causality, which was also the preference during causality assignment. This number is called the order of the system. In the example (2.28), the order of the system is 2.

The order of the set state equations is smaller than or equal to the order of the system, because storage elements can depend on each other. These kind of dependent storage elements each have their own initial value, but they together represent one state variable. Their input signals are equal, or have a factor in between (2.28).

A recipe exists to check whether this kind of dependent storage elements show up: Perform causal analysis again, but chose differential causality as preference. For the example, this is done in Figure 2.29.

Those storage elements that get both at differential preference and at integral preference their preferred causality are the *real* storage elements and contribute to the state of the system. The order of the set of state equations, is by definition the amount of storage elements that get in both cases their preferred causality. At

2 Bond Graphs: A Unifying Framework for Modelling of Physical Systems 37 factor in between (Figure 28).

a) b) c)

The *order of the set state equations* is smaller than or equal to the order of the system, because storage elements can depend on each other. These kind of dependent storage elements each have their own initial value, but they together represent *one* state variable. Their input signals are equal, or have a

Figure 28: System with order of state equations smaller than order of the system. a) IPM; b) causality using integral preference; c) causality using differential preference. Fig. 2.28: System with order of state equations smaller than order of the system. a) IPM; b) causality using integral preference; c) causality using differential preference. Intro Bond Graphs Jan F. Broenink, © 1999

Those storage elements that get both at differential preference and at integral preference their preferred Fig. 2.29: Differential causality as preference applied to the hoisting device.

Figure 29: Differential preference causality for the hoisting device

state equations, is by definition the amount of storage elements that get in both cases their preferred causality. At the hoisting device, this is 2 (namely *L* and *J*). The storage elements that get in both cases *not* their preferred causality, are the dependent storage elements. Those storage elements that get at the integral preferred causality case their preferred causality are called *semi-dependent storage elements*, to distinguish them from the dependent storage elements. This indicates that a storage element was not taken into account during modelling, which should be there from physical systems the hoisting device, this is 2 (namely L and J). The storage elements that get in both cases *not* their preferred causality, are the dependent storage elements. Those storage elements that get *only* at the integral preferred causality case their preferred causality are called *semi-dependent storage elements*, to distinguish them from the dependent storage elements. This indicates that a storage element was not taken into account during modelling, which should be there from physical systems viewpoint.

#### **2.6.5 Matrix Form of Linear Systems**

viewpoint.

29.

If the system is linear, we can write the resulting set of state equations in the standard form, namely, If the system is linear, we can write the resulting set of state equations in the standard form, namely,

**6.5 Matrix form (linear systems)**

**x**& = **Ax** +**Bu**

**Ex**& = **Ax** + **Bu**

$$
\dot{\mathbf{x}} = \mathbf{A}\mathbf{x} + \mathbf{B}\mathbf{u}
$$

where **A** is the *system matrix*, and **B** is the *input matrix*. The order of the system is the dimension of the square matrix **A** and the order of the set of state equations is the *rank* of **A**. where **A** is the system matrix, and **A** is the input matrix. The order of the system is the dimension of the square matrix **A** and the order of the set of state equations is the rank of **A**.

When dependent states or algebraic loops are present, the matrix description is as follows: When dependent states or algebraic loops are present, the matrix description is as follows:

**7 Generation of equations**

#### **E ˙x** = **Ax** + **Bu**

where **E** is a square matrix of size equal to the amount of storage elements plus the amount of algebraic loops. For each differential storage element and for each algebraic loop, **E** contains one row of zeros. The state vector **x** is extended with the algebraic loop variables, to enable implicit integration methods to solve these kinds of systems. The hoisting device gives such a set of equations. where **E** is a square matrix of size equal to the amount of storage elements plus the amount of algebraic loops. For each differential storage element and for each algebraic loop, **E** contains one row of zeros. The state vector **x** is extended with the algebraic loop variables, to enable implicit integration methods to solve these kinds of systems. The hoisting device gives such a set of equations.

step 2 of the procedure or step 3 is necessary, cf. section 6.2).

21 / 31

causality are the *real* storage elements and contribute to the state of the system. The order of the set of

A causal bond graph contains all information to derive the set of state equations. It is either a set of *ordinary first–order differential equations, ODEs*, when the model is explicit (*no* causal conflicts), or a set of *differential and algebraic equations, DAE*s, when the model is implicit (a causal conflict in

The procedure to derive the equations is covered by bond–graph software like Enport (Rosenberg, 1974), MS1 (Lorenz, 1997), CAMP (Granda, 1985) and 20- (Broenink, 1990, 1995, 1997, 1999b;

#### **2.7 Generation of Equations**

A causal bond graph contains all information to derive the set of state equations. It is either a set of ordinary first-order differential equations, ODEs, when the model is explicit (no causal conflicts), or a set of differential and algebraic equations, DAEs, when the model is implicit (a causal conflict in step 2 of the procedure or step 3 is necessary, cf. 2.6.2).

The procedure to derive the equations is covered by bond-graph software like Enport [242], MS1 [191], CAMP [129] and 20-sim [46, 48, 49, 50]. Therefore, in practice, generation of equations need not be done by hand. However, we do discuss the generation of equations on the one hand to be complete and on the other hand to indicate what exactly has to be done.

We use the following procedure to generate equations:


If we are going to generate the equations by hand, we can take the first elimination step into account while formulating the equations by, at the sources, directly use the signal function at the bond. Furthermore, we can write the variable determining the junction along all bonds connected to that junction. The *variable determining the junction* is that variable, which gets assigned to bond variables of all the other bonds connected to that junction via the identities of the junction equations. At a 0-junction, this is the effort of the only bond with its causal stroke towards the 0-junction. At a 1-junction, this is the flow of the only bond with its causal stroke away from the 1-junction.

In case of dependent storage elements, we have to take care that the accompanying state variable gets not eliminated. These are the so-called *semi state variables*. When we mark the state variables, including the semi state variables in this situation, on beforehand, we can prevent the wrong variable from being eliminated. In case of algebraic loops, implicit equations will be encountered. We choose one of the variables in these loops as *algebraic loop breaker* and that variable becomes a semi state variable. See also 2.6.5. The equation consisting the semi state variable of a storage element gets eliminated at the second elimination step: it is a multiplication. The semi state variable itself must *not* be eliminated.

#### **Deriving the diferential equations of the hoisting device**

The set of *mixed differential and algebraic equations* of the hoisting device is shown below. The efforts and flows are numbered in the same order as their causality was assigned. We have 22 equations, of which 11 compute a flow and 11 compute an effort. Since we want to generate the set of equations as differential equations, we write at the storage elements in integral form the equations as differential equations and not as integral equations. This is called *deferred integration*, see Figure 2.30.

As state variables, we have *f*<sup>3</sup> and *f*7, whereas *f*<sup>11</sup> is the semi state variable belonging to the mass having derivative causality (it is an I element). Note that the equation of the mass is written in causal form: *e*<sup>11</sup> is the output. After eliminating the identities at the junctions and sources, we have 12 equations. Note that the flows of the two effort sources ( *f*<sup>1</sup> and *f*2) are not used elsewhere, so we leave them out.

After substitution of the multiplication with resistors and transducers, our set of equations reduces to the following 6 equations: 2 differential equations, 1 constraint equation, computing the semi state variable *f*<sup>11</sup> and 4 junction equations. Now, only state variables, junction variables and input variables are used.

After substitution of the summations at the junctions into the differential equations and the constraint equations, the result is shown in Figure 2.31

This system is a linear system, so we can write the equations in matrix form (according to the second form of 2.6.5), shown in Figure 2.32.

7

37 7 10

*bearing*

2

7

*e*

1

11 7

*<sup>f</sup> <sup>D</sup> <sup>f</sup>*

= −

1

2

*f J K*

*u*

1

3

*e*

*e*

1

3

*e*

*eeue*

= −−

*source*

1

7

=

7

7

*t f*

d

d d

3

*f*

*Lt*

*f*

*Jt*

=

*Lt*

=

d d

3

*f*

d d

*f e Kf e Kf*

d d

are used.

3

*f*

*Lt*

=

d d

> 36 75

= =

*Jt*

=

d

4 3

*el*

*fRe Lt*

=

$$\begin{aligned} \text{Solution:}\\ e\_2 &= u\_{\text{maxar}}\\ \frac{df\_5}{dt} &= \frac{1}{L}e\_3\\ e\_4 &= R\_{cf}f\_4\\ f\_2 &= f\_3\\ f\_4 &= f\_3\\ f\_5 &= f\_3\\ e\_6 &= e\_2 - e\_4 - e\_5\\ e\_6 &= Kf\_6\\ e6 &= Kf\_5\\ \frac{df\_7}{dt} &= \frac{1}{J}e\_7\\ \varepsilon\_8 &= R\_{b\text{min}}f\_8\\ \varepsilon\_9 &= \begin{array}{c} \text{ ${}\_{h1}$ }\\ \text{ ${}\_{h1}$ }\\ \text{ ${}\_{h1}$ }\\ \end{array} \end{aligned} \qquad \begin{aligned} \text{for each other} \\ \text{ ${}\_{h1}$ }\\ \text{ ${}\_{h1}$ }\\ \text{ ${}\_{h1}$ }\\ \text{ ${}\_{h1}$ }\\ \text{ ${}\_{h1}$ }\\ \text{ ${}\_{h1}$ }\\ \text{ ${}\_{h1}$ }\\ \text{ ${}\_{h1}$ }\\ \text{ ${}\_{h1}$ }\\ \text{ ${}\_{h1}$ }\\ \text{ ${}\_{h1}$ }\\ \text{ ${}\_{h1}$ }\\ \text{ ${}\_{h1}$ }\\ \text{ ${}\_{h1}$ }\\ \text{ ${}\_{h1}$ }\\ \text{ ${}\_{h1}$ }\\ \text{ ${}\_{h1}$ }\\ \text{ ${}\_{h1}$ }\\ \text{ ${}\_{h1}$ }\\ \text{ ${}\_{h1}$ }\\ \text{ ${}\_{h1}$ } \end{aligned}$$

*eeee*

9867

= −−

2

efforts and flows are numbered in the same order as their causality was assigned. We have 22

9 10

= −

*eeee*

9867

2

*e*

equations, of which 11 compute a flow and 11 compute an effort. Since we want to generate the set of equations as differential equations, we write at the storage elements in integral form the equations as

*e D*

Fig. 2.30: Equations of the hoisting device. After substitution of the summations at the junctions into the differential equations and the constraint equations, the result looks like: After substitution of the summations at the junctions into the differential equations and the constraint

$$\begin{aligned} \frac{\mathrm{d}f\_3}{\mathrm{d}t} &= \frac{1}{L} \mu\_{\mathrm{source}} - \frac{R\_{el}}{L} f\_3 - \frac{K}{L} f\_\gamma\\ \frac{\mathrm{d}f\_\gamma}{\mathrm{d}t} &= \frac{K}{J} f\_3 - \frac{R\_{\mathrm{bearing}}}{J} f\_\gamma + \frac{D}{2} m \frac{\mathrm{d}f\_{11}}{\mathrm{d}t} + \frac{D}{2} m \mathrm{g}^{-1} \\ f\_{11} &= -\frac{D}{2} f\_\gamma \end{aligned}$$

form of section 6.5): Fig. 2.31: Differential and constraint equations of the hoisting device. This system is a linear system, so we can write the equations in matrix form (according to the second form of section 6.5):

This system is a linear system, so we can write the equations in matrix form (according to the second

$$
\begin{pmatrix} 1 & 0 & 0 \\ 0 & 1 & -\frac{D}{2} \\ 0 & 0 & 0 \end{pmatrix} \frac{d}{dt} \begin{pmatrix} f\_3 \\ f\_7 \\ f\_{11} \end{pmatrix} = \begin{pmatrix} -\frac{R\_{el}}{L} & -\frac{K}{L} & 0 \\ \frac{K}{J} & -\frac{R\_{bearing}}{J} & 0 \\ 0 & \frac{D}{2} & 1 \end{pmatrix} \begin{pmatrix} f\_3 \\ f\_7 \\ f\_{11} \end{pmatrix} + \begin{pmatrix} 1 & 0 \\ 0 & \frac{D}{2} \\ 0 & 0 \end{pmatrix} \begin{pmatrix} u\_{source} \\ mg \end{pmatrix}
$$

Fig. 2.32: DAE of hoisting device in matrix form

24 / 31

24 / 31

When the model first was made explicit by adding elements, according to alternative 1 of 2.6.3, the causal bond graph and the equations are given below. We add the elasticity of the rope: A C-element connected to a 0-junction is inserted on the bond between the TF of the cable drum and the 1-junction of the payload (see Figure 2.33). The efforts and flows are numbered in the same order as their causality was assigned. We have 26 equations, of which 13 compute a flow and 13 compute an effort.

 

 

 

*D u*

2

When the model first was made explicit by adding elements, according to alternative 1 of section 6.3, the causal bond graph and the equations are given below. We add the elasticity of the rope: A Celement connected to a 0-junction is inserted on the bond between the TF of the cable drum and the 1-

Fig. 2.33: Causal bond graph of hoisting device with elasticity added

The mixed set of differential and algebraic equations is:

3 3 1 d d *fRe e Lt f* = = 9 10 2 *e D e* = − As state variables, we have *f*3, *f*7, *e*<sup>11</sup> and *f*13. So *four* independent state variables. Applying the procedure of deriving equations leads to the set of state equations written in matrix form shown in Figure Intro Bond Graphs Jan F. Broenink, © 1999 2.34.

$$
\frac{d}{dt} \begin{pmatrix} f\_3 \\ f\_7 \\ e\_{11} \\ f\_{13} \end{pmatrix} = \begin{pmatrix} -\frac{\text{Re}\,l}{L} & -\frac{K}{L} & 0 & 0 \\ \frac{K}{J} & -\frac{R\_{bearing}}{J} & -\frac{D}{2} & 0 \\ -\frac{D}{2C\_{elasticity}} & -\frac{1}{C\_{elasticity}} & 0 & 0 \\ 0 & 0 & \frac{1}{m} & 0 \end{pmatrix} \begin{pmatrix} f\_3 \\ f\_7 \\ e\_{11} \\ f\_{13} \end{pmatrix} + \begin{pmatrix} 1 & 0 \\ \frac{1}{L} & 0 \\ 0 & 0 \\ 0 & -\frac{1}{m} \end{pmatrix} \begin{pmatrix} u\_{source} \\ m\mathbf{g} \end{pmatrix}
$$

As state variables, we have f*3*, f*7*, e*11* and f*13*. Applying the procedure of deriving equations leads to the **8 Expansion to block diagrams** Fig. 2.34: ODE of hoisting device in matrix form

following set of state equations written in matrix form:

13

*e mt*

10 9

*<sup>f</sup> <sup>D</sup> <sup>f</sup>*

= −

2

9867

= −−

*eeee*

13

=

d

To show that a causal bond graph is a compact block diagram, we treat in this section the expansion of a causal bond graph to a block diagram. Furthermore, a block diagram representation of a system might be more familiar than a bond graph representation. Thus this work might help understanding

#### The expansion of a causal bond graph into a block diagram consists of three steps: 1. Expand all bonds to *bilateral signal flows* (two signals with opposite directions). The *causal* **2.8 Expansion to Block Diagrams**

the block diagram.

bond graphs.

25 / 31 *stroke* determines in which direction the effort flows. The bond graph elements can be encircled to connect the signals to. 2. Replace the bond–graph elements by their block–diagram representations (see section 4). Deduce the signs of the summations of the junctions from the directions of the bond arrows (half arrows, To show that a causal bond graph is a compact block diagram, we treat in this section the expansion of a causal bond graph to a block diagram. Furthermore, a block diagram representation of a system might be more familiar than a bond graph representation. Thus this work might help understanding bond graphs.

see section 4.5). Often, it is efficient to determine those signs after all bond–graph elements are The expansion of a causal bond graph into a block diagram consists of three steps:

79

*ff*

=

32 4 4

*el*

*source*

*ff*

=

2

*ue*

=


2 Bond Graphs: A Unifying Framework for Modelling of Physical Systems 41

Since block diagrams represent mathematical operations, for which *commutative* and *associative* properties apply, these properties can be used to manipulate the block diagram such that the result looks appealing enough.

As an example, we show the block diagram of the hoisting device, using the three steps to construct the block diagram. In Figure 2.35 the result after step 2 is shown, and in Figure 2.36 the block diagram in standard form is presented. The block diagram of the model with elasticity is shown in Figure 2.37. University of Twente, Dept EE Intro Bond Graphs

shown in grey) *D/2* Fig. 2.35: Bond graph expanded to a block diagram in the layout of the bond graph (the bond graph is shown in grey).

*<sup>J</sup> <sup>K</sup>*

<sup>m</sup> <sup>+</sup>

Figure 32 Bond graph expanded to a block diagram in the layout of the bond graph (the bond graph is

∫ ∫ ∫ ∫ *Usource D/2* 1 1 *<sup>J</sup> <sup>K</sup>* 1/m <sup>+</sup> <sup>1</sup> + - + Fig. 2.36: The block diagram redrawn in standard form.


1

+ + +

Celasticity

ddt

*R*el *Rbearing*


∫ ∫

1 *L*

*Usource D/2*

+ -

*K*

*L*

#### Figure 34 The block diagram of the Hoist with elasticity (cf Figure 30) **2.9 Simulation**


27 / 31 The resulting set of equations coming from a bond-graph model is called the simulation model. It consists of first-order ordinary differential equations (ODEs), possibly extended with algebraic constraint equations (DAEs). Hence, it can be simulated using standard numerical integration methods. However, because numerical integration is an approximation of the actual integration process, it is useful to check the simulation model on

Fig. 2.37: The block diagram of the Hoist with elasticity

aspects significant for simulation. As a result, an appropriate integration method can be chosen: the computational work is minimal and the results stay within a specified error margin.

Since at causal analysis, one can decide whether or not to change the bond-graph model to obtain an explicit simulation model, it is useful to know about the consequences for simulation of relevant characteristics of the simulation model. The following 4 aspects of simulation models are relevant for choosing an numerical integration method:

1. Presence of implicit equations.

Implicit models (DAEs) can only be simulated with implicit integration methods. The iteration procedure of the implicit integration method is also used to calculate the implicit model. Explicit models (ODEs) can be simulated with both explicit as implicit integration methods. Sometimes, implicit integration methods need more computation time than explicit integration methods. During causal analysis, one can see whether a simulation model will be explicit or implicit, see 2.6.3.

2. Presence of discontinuities.

Integration methods with special provisions for events will perform best. If that is not available, variable step methods can be used. Multistep methods become less accurate, since they need information from the past, which is useless after a discontinuity. While constructing the model, presence of discontinuities can be marked.

3. Numerical stiffness.

*<sup>S</sup>*(*t*), the stiffness ratio, is a measure for the distance between real parts of eigenvalues, λ, namely

$$S(t) = \frac{\max(|\operatorname{Re}\lambda(t)|)}{\min(|\operatorname{Re}\lambda(t)|)}$$

Stiff models (large *S*) need stiff integration methods. The time step is now determined by the stability instead of the accuracy (namely, eigenvalues are now used to determine the step size). When the high frequency parts are faded out, they do not influence the step size anymore. Hence, the step size can grow to limits determined by the lower frequencies.

4. Oscillatory parts.

When a model has *no* damping, it should not be simulated with a stiff method. Stiff methods perform badly for eigenvalues on the imaginary axis (i.e. no damping) of the complex eigenvalue plane.

Eigenvalues can be localised in a causal bond graph, especially when all elements are linear. There is a bond graph version of Mason's Loop rule to determine the transfer function from a bond graph [53]. As a side effect, the eigenvalues can be calculated. We will not discuss the procedure to obtain eigenvalues from a causal bond graph by hand.

#### **2.10 Summary**

In this chapter, we have introduced bond graphs to model physical systems in a *domain independent* way. Only *macroscopic* systems are treated, thus *quantum effects* do not play a significant role. Domain independence has its basics in the fact that physical concepts are analogous for the different physical domains. Six different elementary concepts exist: storage of energy, dissipation, transduction to other domains, distribution, transport, input or output of energy.

Another starting point is that it is possible to write models as directed graphs: parts are interconnected by bonds, along which exchange of energy occurs. A bond represents the energy flow between the two connected submodels. This energy flow can be described as the product of 2 variables (effort and flow), letting a bond be conceived as a *bilateral signal* connection. During modelling, the first interpretation is used, while during analysis and equations generation the second interpretation is used.

Furthermore, we presented a method to systematically build a bond graph starting from an ideal physical model. Causal analysis gives, besides the computational direction of the signals at the bonds, also information about the correctness of the model. We presented methods to derive the causality of a bond graph. In addition, procedures to generate equations and block diagrams out of a causal bond graph are presented.

Due to the introductory nature of this text, some procedures presented, without a deep motivation and possible alternatives. It was also *not* the incentive to elaborate on physical systems modelling. We did not discuss multiple connections (arrays of bonds written as one multibond) and multiport elements (to describe transducers), neither different causal analysis algorithms. Those different causality algorithms give slightly different sets of DAEs especially when applied to certain classes of models (for instance multibody systems with kinematic loops).

Finally, bond-graph modelling is in fact a form of *object-oriented physical-systems modelling*, a term which is often used. This can be seen as follows: bond-graph models are declarative, they can be hierarchically structured, and fully support encapsulation (due to the non-causal way of specifying equations, and the notion of ports). Moreover, due to allowing hierarchy, the notion of definition and use of models are distinguished (i.e. the class concept and instantiation). Since bond graphs came into existence before the term object oriented was used in the field of physical systems modelling, bond graphs can be seen as an object-oriented physical-systems modelling paradigm avant-la-lettre.

A bond-graph library was written in Modelica, a contemporary object-oriented modelling language [47]. The basic bond-graph elements and block-diagram elements have been specified in Modelica, using the essential object-orientation features inheritance and encapsulation. Equations have been specified in an a-causal format. Thus, it can be said that the Modelica modelling concepts are consistent with bond-graph concepts. Furthermore, automatic Modelica code generation from bond graphs appeared to be rather straightforward [46].

#### **2.11 Literature and Further Reading**

For a more thorough analysis of bond graphs, see Paynter [228] and Breedveld [43, 44], while an extensive discussion on textbook level is given by Karnopp, Margolis and Rosenberg [160]. Cellier [67] wrote a textbook on continuous system modelling in which besides bond graphs also other modelling methods are used. Current research on bond graphs is reported at the International Conference on Bond Graph modelling, every two years (Granda and Cellier [129]). Journals regularly publishing bond graph papers are the Journal of the Franklin Institute, which also had special issues on bond graphs and the Journal of Dynamic Systems, Measurement and Control.

#### **2.12 Self-Assessment**


5. What properties of a causal bond-graph model (or any model written as differential equations) influence the choice of the numerical integration algorithm needed for simulation of that model?

#### **Acknowledgements**

Most of the inspiration for this chapter came from the Dutch course material of Breedveld and Van Amerongen (1994). I sincerely acknowledge Peter Breedveld and Job van Amerongen for their valuable suggestions and discussions.

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

## **Chapter 3 Modelica: Equation-Based, Object-Oriented Modelling of Physical Systems**

Peter Fritzson

**Abstract** The field of equation-based object-oriented modelling languages and tools continues its success and expanding usage all over the world primarily in engineering and natural sciences but also in some cases social science and economics. The main properties of such languages, of which Modelica is a prime example, are: acausal modelling with equations, multi-domain modelling capability covering several application domains, object-orientation supporting reuse of components and evolution of models, and architectural features facilitating modelling of system architectures including creation and connection of components. This enables ease of use, visual design of models with combination of lego-like predefined model building blocks, ability to define model libraries with reusable components enables. This chapter gives an introduction and overview of Modelica as the prime example of an equation-based object-oriented language.

#### **Learning Objectives**

After reading this chapter, we expect you to be able to:


## **3.1 Introduction**

Modelica is primarily a modelling language that allows specification of mathematical models of complex natural or man-made systems, e.g., for the purpose of computer simulation of dynamic systems where behaviour evolves as a function of time. Modelica is also an object-oriented equation-based programming language, oriented toward computational applications with high complexity requiring high performance. The four most important features of Modelica are:

• Modelica is primarily based on equations instead of assignment statements. This permits acausal modelling that gives better reuse of classes since equations do not specify a certain data flow direction. Thus a Modelica class can adapt to more than one data flow context.

Peter Fritzson

Linköping University, Department of Computer and Information Science, SE-58183 Linköping, Sweden e-mail: peter.fritzson@liu.se


These are the main properties that make Modelica both powerful and easy to use, especially for modelling and simulation. We will start with a gentle introduction to Modelica from the very beginning.

#### **3.2 Getting Started with Modelica**

Modelica programs are built from classes, also called models. From a class definition, it is possible to create any number of objects that are known as instances of that class. Think of a class as a collection of blueprints and instructions used by a factory to create objects. In this case the Modelica compiler and run-time system is the factory.

A Modelica class contains elements which for example can be variable declarations and equation sections containing equations. Variables contain data belonging to instances of the class; they make up the data storage of the instance. The equations of a class specify the behaviour of instances of that class.

There is a long tradition that the first sample program in any computer language is a trivial program printing the string "Hello World". Since Modelica is an equation-based language, printing a string does not make much sense. Instead, our HelloWorld Modelica program solves a trivial *differential equation*:

$$
\dot{\mathbf{x}} = -a.\mathbf{x} \tag{3.1}
$$

The variable *x* in this equation is a dynamic variable (here also a state variable) that can change value over time. The time derivative ˙*x* is the time derivative of *x*, represented as der(x) in Modelica. Since all Modelica programs, usually called *models*, consist of class declarations, our HelloWorld program is declared as a class:

```
class HelloWorld
   Real x ( start = 1) ;
   parameter Real a = 1;
   equation
   der( x ) = -a * x ;
end HelloWorld ;
```
Use your favorite text editor or Modelica programming environment to type in this Modelica code1, or open the DrModelica electronic document (part of OpenModelica) containing most examples and exercises in this book. Then invoke the simulation command in your Modelica environment. This will compile the Modelica code to some intermediate code, usually C code, which in turn will be compiled to machine code and executed together with a numerical ordinary differential equation (ODE) solver or differential algebraic equation (DAE) solver to produce a solution for *x* as a function of time. The following command in the OpenModelica environment produces a solution between time 0 seconds and time 2 seconds:

#### simulate(HelloWorld,stopTime=2)2

Since the solution for *x* is a function of time, it can be plotted by a plot command:

<sup>1</sup> There is a downloadable open source Modelica environment OpenModelica from OSMC at www.openmodelica.org, Dymola is a product from Dassault Systems www.dymola.com, see www.modelica.org for more products.

<sup>2</sup> Before simulating an existing model, you need to open it or load it, e.g. loadModel(HelloWorld) in OpenModelica. The Open-Modelica command for simulation is simulate. The corresponding using Dymola is simulateModel("HelloWorld", stopTime=2).

#### plot(x)3

(or the longer form plot(x,xrange={0,2}) that specifies the x-axis), giving the curve in Figure 3.31:

Fig. 3.1: Plot of a simulation of the simple HelloWorld model.

Now we have a small Modelica model that does something, but what does it actually mean? The program contains a declaration of a class called HelloWorld with two variables and a single equation. The first attribute of the class is the variable *x*, which is initialised to a start value of 1 at the time when the simulation starts. All variables in Modelica have a start attribute with a default value which is normally set to 0. Having a different start value is accomplished by providing a so-called modifier within parentheses after the variable name, i.e., a modification equation setting the start attribute to 1 and replacing the original default equation for the attribute.

The second attribute is the variable a, which is a constant that is initialised to 1 at the beginning of the simulation. Such a constant is prefixed by the keyword parameter in order to indicate that it is constant during simulation but is a model parameter that can be changed between simulations, e.g., through a command in the simulation environment. For example, we could rerun the simulation for a different value of a, without re-compilation if a is changed through the environment's parameter update facility.

Also note that each variable has a type that precedes its name when the variable is declared. In this case both the variable x and the "variable" a have the type Real.

The single equation in this HelloWorld example specifies that the time derivative of *x* is equal to the constant −*a* times *x*. In Modelica the equal sign **=** always means equality, i.e., establishes an equation, and not an assignment as in many other languages. Time derivative of a variable is indicated by the pseudo-function der( ). Our second example is only slightly more complicated, containing five rather simple equations:

$$m\dot{\nu}\_{\chi} = -\frac{\chi}{L}F\tag{3.2}$$

$$m\dot{\upsilon}\_{\text{y}} = -\frac{\text{y}}{L}F - mg\tag{3.3}$$

$$
\dot{\mathbf{x}} = \mathbf{v}\_{\mathbf{x}} \tag{3.4}
$$

$$
\mathbf{j} = \boldsymbol{\nu}\_{\mathbf{y}} \tag{3.5}
$$

$$\mathbf{x}^2 + \mathbf{y}^2 = L^2 \tag{3.6}$$

This example is actually a mathematical model of a physical system, a planar pendulum, as depicted in Figure 3.2.

<sup>3</sup> plot is the OpenModelica command for plotting simulation results. The corresponding Dymola command would be plot({"x"}) respectively.

Fig. 3.2: A planar pendulum.

v<sup>x</sup> (3.7)

$$\mathbf{x}^2 + \mathbf{y}^2 = L^2 \tag{3.8}$$

$$\mathbf{v}\_{\mathbf{y}}\tag{3.9}$$

The equations are Newton's equations of motion for the pendulum mass under the influence of gravity, together with a geometric constraint, the 5th equation *x* <sup>2</sup> + y <sup>2</sup> = *L* 2 , that specifies that its position (*x*,*y*) must be on a circle with radius *L*. The variables v<sup>x</sup> and v<sup>y</sup> are its velocities in the *x* and *y* directions respectively. A Modelica model of the pendulum appears below:

```
class Pendulum " Planar Pendulum "
 constant Real PI =3 .141592653589793 ;
 parameter Real m =1 , g =9 .81 , L =0 .5 ;
 Real F ;
 output Real x ( start =0 .5 ) ,y ( start =0) ;
 output Real vx , vy ;
equation
 m* der( vx ) = -( x / L ) * F ;
 m* der( vy ) = -( y / L ) *F - m * g ;
 der( x ) = vx ;
 der( y ) = vy ;
 x^2+ y ^2= L ^2;
end Pendulum ;
```
The interesting property of this model, however, is the fact that the 5th equation is of a different kind: a so-called *algebraic equation* only involving algebraic formulas of variables but no derivatives. The first four equations of this model are differential equations as in the HelloWorld example. Equation systems that contain both differential and algebraic equations are called *differential algebraic equation systems* (DAEs).

We simulate the Pendulum model and plot the *x*-coordinate, shown in Figure 3.3:

simulate(Pendulum, stopTime=4)

plot(x);

Fig. 3.3: Plot of a simulation of the Pendulum DAE model.

You can also write down DAE equation systems without physical significance, with equations containing formulas selected more or less at random, as in the class DAEexample below:

```
class DAEexample
  Real x ( start =0 .9 ) ;
  Real y ;
equation
  der( y ) + (1+0 .5 *sin( y ) ) * der( x ) = sin( time ) ;
  x- y = exp ( -0 .9 * x ) * cos( y ) ;
end DAEexample ;
```
This class contains one differential and one algebraic equation. Try to simulate and plot it yourself, to see if any reasonable curve appears. Finally, an important observation regarding Modelica models: The number of *variables* must be equal to the number of *equations*!

This statement is true for the three models we have seen so far, and holds for all solvable Modelica models. By variables we mean something that can vary, i.e., not named constants and parameters to be described in a section further below.

#### **3.2.1 Variables and Predefined Types**

This example shows a slightly more complicated model, which describes a Van der Pol4 oscillator. Notice that here the keyword model is used instead of class with almost the same meaning.

```
model VanDerPol " Van der Pol oscillator model "
  Real x ( start = 1) " Descriptive string for x "; // x starts at 1
  Real y ( start = 1) " Descriptive string for y "; // y starts at 1
parameter
  Real lambda = 0 .3 ;
equation
  der( x ) = y ; // This is the first equation
  der( y ) = -x + lambda *(1 - x * x ) * y ; // The 2 nd differential equation
end VanDerPol ;
```
This example contains declarations of two dynamic variables (here also state variables) x and y, both of type Real and having the start value 1 at the beginning of the simulation, which normally is at time 0. Then follows a declaration of the parameter constant lambda, which is a so-called model parameter.

A *parameter* is a special kind of constant which is implemented as a static variable that is initialised once and never changes its value during a specific execution. A parameter is a constant variable that makes it simple for a user to modify the behaviour of a model, e.g., changing the parameter lambda which strongly influences the behaviour of the Van der Pol oscillator. By contrast, a fixed Modelica constant declared with the prefix constant never changes and can be substituted by its value wherever it occurs.

<sup>4</sup> Balthazar van der Pol was a Dutch electrical engineer who initiated modern experimental dynamics in the laboratory during the 1920's and 1930's. Van der Pol investigated electrical circuits employing vacuum tubes and found that they have stable oscillations, now called limit cycles. The van der Pol oscillator is a model developed by him to describe the behaviour of nonlinear vacuum tube circuits

Finally, we present declarations of three dummy variables just to show variables of data types different from Real: the boolean variable bb, which has a default start value of false if nothing else is specified, the string variable dummy which is always equal to "dummy string", and the integer variable fooint always equal to 0.

```
Boolean bb ;
String dummy = " dummy string ";
Integer fooint = 0;
```
Modelica has built-in "primitive" predefined data types to support floating-point, integer, boolean, and string values. These predefined primitive types contain data that Modelica understands directly, as opposed to class types defined by programmers. There is also the Complex type for complex numbers computations, which is predefined in a library. The type of each variable must be declared explicitly. The predefined basic data types of Modelica are:


Finally, there is an equation section starting with the keyword equation, containing two mutually dependent equations that define the dynamics of the model. To illustrate the behaviour of the model, we give a command to simulate the Van der Pol oscillator during 25 seconds starting at time 0:

#### simulate(VanDerPol, stopTime=25)

A phase plane plot of the state variables for the Van der Pol oscillator model (Figure 3.4):

plotParametric(x,y, stopTime=25)

Fig. 3.4: Parametric plot of a simulation of the Van der Pol oscillator model.

The names of variables, functions, classes, etc. are known as *identifiers*. There are two forms in Modelica. The most common form starts with a letter, followed by letters or digits, e.g. x2. The second form starts with a single-quote, followed by any characters, and terminated by a single-quote, e.g. '2nd \* 3'.

#### **3.2.2 Comments**

Arbitrary descriptive text, e.g., in English, inserted throughout a computer program, are *comments* to that code. Modelica has three styles of comments, all illustrated in the previous VanDerPol example.

Comments make it possible to write descriptive text together with the code, which makes a model easier to use for the user, or easier to understand for programmers who may read your code in the future. That programmer may very well be yourself, months or years later. You save yourself future effort by commenting your own code. Also, it is often the case that you find errors in your code when you write comments since when explaining your code you are forced to think about it once more.

The first kind of comment is a string within string quotes, e.g., "a comment" , optionally appearing after variable declarations, or at the beginning of class declarations. Those are "definition comments" that are processed to be used by the Modelica programming environment, e.g., to appear in menus or as help texts for the user. From a syntactic point of view they are not really comments since they are part of the language syntax. In the previous example such definition comments appear for the VanDerPol class and for the x and y variables.

The other two types of comments are ignored by the Modelica compiler, and are just present for the benefit of Modelica programmers. Text following **//** up to the end of the line is skipped by the compiler, as is text between /\* and the next \*/. Hence the last type of comment can be used for large sections of text that occupies several lines.

Finally, we should mention a construct called annotation, a kind of structured "comment" that can store information together with the code, described in the section about annotations at the end of this chapter.

#### **3.2.3 Constants**

Constant literals in Modelica can be integer values such as 4, 75, 3078; floating-point values like 3.14159, 0.5,2.735E-10, 8.6835e+5; string values such as "hello world", "red"; and enumeration values such as Colors.red,Sizes.xlarge.

Named constants are preferred by programmers for two reasons. One reason is that the name of the constant is a kind of documentation that can be used to describe what the particular value is used for. The other, perhaps even more important reason, is that a named constant is defined at a single place in the program. When the constant needs to be changed or corrected, it can be changed in only one place, simplifying program maintenance.

Named constants in Modelica are created by using one of the prefixes constant or parameter in declarations, and providing a declaration equation as part of the declaration. For example:

```
constant Real PI = 3 .141592653589793 ;
constant String redcolor = " red ";
constant Integer one = 1;
parameter Real mass = 22 .5 ;
```
Parameter constants (often called *parameters*) can usually be accessed and changed from Modelica tool graphical user interfaces. Most Modelica tools support re-simulating a model without re-compilation after changing a parameter, which usually makes the time waiting for results much shorter.

Parameters can be declared without a declaration equation (but a default start value is recommended) since their value can be defined, e.g., interactively or by reading from a file, before simulation starts. This is not possible for constants with prefix constant. For example:

```
parameter Real mass , gravity , length ;
```
A parameter with a default start value as shown below means that the parameter has a value, but that this value is expected to be replaced by a more realistic value, e.g., by the user, at a real simulation:

```
parameter Real mass ( start =0) , gravity ( start =0) , length ( start =0) ;
```
Constants and parameters are very similar, but also have some differences. Parameters are typically much more common in application models. When in doubt whether to use constant or parameter, use parameter, except when declaring a constant in a package/library where constant is allowed but not parameter.

#### **3.2.4 Variability**

We have seen that some variables can change value at any point in time whereas named constants are more or less constant. In fact, there is a general concept of four levels of variability of variables and expressions in Modelica:


#### **3.2.5 Default Start Values**

If a numeric variable lacks a specified definition value or start value in its declaration, it is usually initialised to zero at the start of the simulation. Boolean variables have start value false, and string variables the start value empty string "" if nothing else is specified.

Exceptions to this rule are function *results* and *local* variables in functions, where the default initial value at function call is *undefined*.

#### **3.3 Object-Oriented Mathematical Modelling**

Traditional object-oriented programming languages like Simula, C++, Java, and Smalltalk, as well as procedural languages such as Fortran or C, support programming with operations on stored data. The stored data of the program include variable values and object data. The number of objects often changes dynamically. The Smalltalk view of object-orientation emphasises sending messages between (dynamically) created objects.

The Modelica view on object-orientation is different since the Modelica language emphasises *structured* mathematical modelling. Object-orientation is viewed as a structuring concept that is used to handle the complexity of large system descriptions. A Modelica model is primarily a declarative mathematical description, which simplifies further analysis. Dynamic system properties are expressed in a declarative way through equations.

The concept of *declarative* programming is inspired by mathematics, where it is common to state or declare what *holds*, rather than giving a detailed stepwise *algorithm* on *how* to achieve the desired goal as is required when using procedural languages. This relieves the programmer from the burden of keeping track of such details. Furthermore, the code becomes more concise and easier to change without introducing errors.

Thus, the declarative Modelica view of object-orientation, from the point of view of object-oriented mathematical modelling, can be summarised as follows:


However:

• Object-orientation in mathematical modelling is *not* viewed as dynamic message passing.

<sup>5</sup> Algorithms are also allowed, but in a way that makes it possible to regard an algorithm section as a system of equations.

The declarative object-oriented way of describing systems and their behaviour offered by Modelica is at a higher level of abstraction than the usual object-oriented programming since some implementation details can be omitted. For example, we do not need to write code to explicitly transport data between objects through assignment statements or message passing code. Such code is generated automatically by the Modelica compiler based on the given equations.

Just as in ordinary object-oriented languages, classes are blueprints for creating objects. Both variables and equations can be inherited between classes. Function definitions can also be inherited. However, specifying behaviour is primarily done through equations instead of via methods. There are also facilities for stating algorithmic code including functions in Modelica, but this is an exception rather than the rule.

#### **3.3.1 Classes and Instances**

Modelica, like any object-oriented computer language, provides the notions of classes and objects, also called instances, as a tool for solving modelling and programming problems. Every object in Modelica has a class that defines its data and behaviour. A class has three kinds of members:


```
class Point " Point in a three - dimensional space "
public
  Real x ;
  Real y , z ;
end Point ;
```
The Point class has three variables representing the x, y, and z coordinates of a point and has no equations. A class declaration like this one is like a blueprint that defines how instances created from that class look like, as well as instructions in the form of equations that define the behaviour of those objects. Members of a class may be accessed using dot (**.**) notation. For example, regarding an instance myPoint of the Point class, we can access the x variable by writingmyPoint.x.

Members of a class can have two levels of visibility. The public declaration of x, y, and z, which is default if nothing else is specified, means that any code with access to a Point instance can refer to those values. The other possible level of visibility, specified by the keyword protected, means that only code inside the class as well as code in classes that inherit this class, are allowed access.

Note that an occurrence of one of the keywords public or protected means that all member declarations following that keyword assume the corresponding visibility until another occurrence of one of those keywords, or the end of the class containing the member declarations has been reached.

#### **3.3.1.1 Creating Instances**

In Modelica, objects are created implicitly just by declaring instances of classes. This is in contrast to objectoriented languages like Java or C++, where object creation is specified using the new keyword when allocating on the heap. For example, to create three instances of our Point class we just declare three variables of type Point in a class, here Triangle:

```
class Triangle
  Point point1 ;
  Point point2 ;
  Point point3 ;
```
end Triangle ;

There is one remaining problem, however. In what context should Triangle be instantiated, and when should it just be interpreted as a library class not to be instantiated until actually used?

This problem is solved by regarding the class at the *top* of the instantiation hierarchy in the Modelica program to be executed as a kind of "main" class that is always implicitly instantiated, implying that its variables are instantiated, and that the variables of those variables are instantiated, etc. Therefore, to instantiate Triangle, either make the class Triangle the "top" class or declare an instance of Triangle in the "main" class. In the following example, both the classTriangle and the class Foo1 are instantiated.

```
class Foo1
  ...
end Foo1 ;
class Foo2
  ...
end Foo2 ; ...
class Triangle
  Point point1 ;
  Point point2 ;
  Point point3 ;
end Triangle ;
class Main
  Triangle pts ;
  Foo1 f1 ;
end Main ;
```
The variables of Modelica classes are instantiated per object. This means that a variable in one object is distinct from the variable with the same name in every other object instantiated from that class. Many objectoriented languages allow class variables. Such variables are specific to a class as opposed to instances of the class, and are shared among all objects of that class. The notion of class variables is not yet available in Modelica.

#### **3.3.1.2 Initialization**

Another problem is initialisation of variables. As mentioned previously in the section about variability, if nothing else is specified, the default start value of all numerical variables is zero, apart from function results and local variables where the initial value at call time is unspecified. Other start values can be specified by setting the start attribute of instance variables. Note that the start value only gives a suggestion for initial value the solver may choose a different value unless the fixed attribute is true for that variable. Below a start value is specified in the example class Triangle:

```
class Triangle
  Point point1 ( start = Point (1 ,2 ,3) ) ;
  Point point2 ;
  Point point3 ;
end Triangle ;
```
Alternatively, the start value of point1 can be specified when instantiating Triangle as below:

```
class Main
  Triangle pts ( point1.start = Point (1 ,2 ,3) ) ;
  Foo1 f1 ;
end Main ;
```
A more general way of initialising a set of variables according to some constraints is to specify an equation system to be solved in order to obtain the initial values of these variables. This method is supported in Modelica through the initial equation construct.

An example of a continuous-time controller initialised in steady-state, i.e., when derivatives should be zero, is given below:

```
model Controller
parameter
  Real a =1 , b =2;
  Real y ;
equation
  der( y ) = a * y + b * u ;
initial
  equation
     der( y ) =0;
end Controller ;
```
This has the following solution at initialization:

der( y ) = 0; y = -( b/ a ) \* u;

#### **3.3.1.3 Specialised Classes**

The class concept is fundamental to Modelica, and is used for a number of different purposes. Almost anything in Modelica is a class. However, in order to make Modelica code easier to read and maintain, special keywords have been introduced for specific uses of the class concept. The keywords model, connector, record, block, type, package, and function can be used to denote a class under appropriate conditions, called restrictions. Some of the specialised classes also have additional capabilities, called enhancements. For example, a function class has the enhancement that it can be called, whereas a record is a class used to declare a record data structure and has the restrictions that it may not contain equations and may only contain public declarations.

```
record Person
  Real age ;
  String name ;
end Person ;
```
A model is almost the same as a class, i.e., those keywords are completely interchangeable. A block is a class with fixed causality, which means that for each connector variable of the class it is specified whether it has input or output causality. Thus, each connector variable in a block class interface must be declared with a causality prefix keyword of either input or output.

A connector class is used to declare the structure of "ports" or interface points of a component, may not contain equations, and has only public sections, but has the additional property to allow connect(...) to instances of connector classes. A type is a class that can be an alias or an extension to a predefined type, enumeration, or array of a type. For example:

```
type vector3D = Real [3];
```
The idea of specialised classes has some advantages since they re-use most properties of the general *class concept*. The notion of specialised classes also gives the user a chance to express more precisely what a class is intended for, and requires the Modelica compiler to check that these usage constraints are actually fulfilled.

Fortunately, the notion of specialised class is quite uniform since all basic properties of a class, such as the syntax and semantics of definition, instantiation, inheritance, and generic properties, are identical for all kinds of specialised classes. Furthermore, the construction of Modelica translators is simplified since only the syntax and semantics of the general class concept has to be implemented along with some additional checks on restrictions and enhancements of the classes.

The package and function specialised classes in Modelica have much in common with the class concept but also have many additional properties, so called enhancements. Especially functions have quite a lot of enhancements, e.g., they can be called with an argument list, instantiated at run-time, etc. An operator class is similar to a package which is like a container for other definitions, but may only contain declarations of functions and is intended for user-defined overloaded operators.

#### **3.3.1.4 Reuse of Classes by Modifications**

The class concept is the key to reuse of modelling knowledge in Modelica. Provisions for expressing adaptations or modifications of classes through so-called modifiers in Modelica make reuse easier. For example, assume that we would like to connect two filter models with different time constants in series.

Instead of creating two separate filter classes, it is better to define a common filter class and create two appropriately modified instances of this class, which are connected. An example of connecting two modified low-pass filters is shown after the example low-pass filter class below:

```
model LowPassFilter
  parameter
    Real T =1 " Time constant of filter ";
    Real u , y ( start =1) ;
  equation
    T* der( y ) + y = u ;
end LowPassFilter ;
```
The model class can be used to create two instances of the filter with different time constants and "connecting" them together by the equation *F*2.*u* = *F*1.y as follows:

```
model FiltersInSeries
  LowPassFilter F1 (T =2) , F2 ( T =3) ;
equation
  F1.u = sin( time ) ;
  F2.u = F1.y ;
end FiltersInSeries ;
```
Here we have used modifiers, i.e., attribute equations such as T=2 and T=3, to modify the time constant of the low-pass filter when creating the instances F1 and F2. The independent time variable is a built-in predefined variable denoted time. If the FiltersInSeries model is used to declare variables at a higher hierarchical level, e.g., F12, the time constants can still be adapted by using hierarchical modification, as for F1 and F2 below:

```
model ModifiedFiltersInSeries
   FiltersInSeries F12 ( F1 (T =6) , F2.T =11) ;
end ModifiedFiltersInSeries ;
```
#### **3.3.1.5 Built-in Classes**

The built-in predefined type classes of Modelica correspond to the types Real, Integer, Boolean, String, enumeration(...), and Clock, and have most of the properties of a class, e.g., can be inherited, modified, etc. Only the value attribute can be changed at run-time, and is accessed through the variable name itself, and not through dot notation, i.e., use x and not x.value to access the value. Other attributes are accessed through dot notation.

For example, a Real variable has a set of default attributes such as unit of measure, initial value, minimum and maximum value. These default attributes can be changed when declaring a new class, for example:

class Voltage = Real ( unit = " V ", min = -220 .0 , max =220 .0 ) ;

#### **3.3.2 Inheritance**

One of the major benefits of object-orientation is the ability to extend the behaviour and properties of an existing class. The original class, known as the *superclass* or *base class*, is extended to create a more specialised version of that class, known as the *subclass* or *derived class*. In this process, the behaviour and properties of the original class in the form of variable declarations, equations, and other contents are reused, or inherited, by the subclass.

Let us regard an example of extending a simple Modelica class, e.g., the class Point introduced previously. First we introduce two classes named ColorData and Color, where Color inherits the data variables to represent the color from class ColorData and adds an equation as a constraint. The new class ColoredPoint inherits from multiple classes, i.e., uses multiple inheritance, to get the position variables from class Point, and the color variables together with the equation from class Color.

```
record ColorData
  Real red ;
  Real blue ;
  Real green ;
end ColorData ;
class Color
  extends ColorData ;
equation
  red + blue + green = 1;
end Color ;
class Point
  public
    Real x ;
    Real y , z ;
end Point ;
class ColoredPoint
   extends Point ;
   extends Color ;
end ColoredPoint ;
```
#### **3.3.3 Generic Classes**

In many situations it is advantageous to be able to express generic patterns for models or programs. Instead of writing many similar pieces of code with essentially the same structure, a substantial amount of coding and software maintenance can be avoided by directly expressing the general structure of the problem and providing the special cases as *parameter* values.

Such generic constructs are available in several programming languages, e.g., templates in C++, generics in Ada, and type parameters in functional languages such as Haskell or Standard ML. In Modelica the class construct is sufficiently general to handle generic modelling and programming in addition to the usual class functionality.

There are essentially two cases of generic class parameterisation in Modelica: *class parameters* can either be *instance parameters*, i.e., have instance declarations (components) as values, or be *type parameters*, i.e., have types as values. Note that by class parameters in this context we do not usually mean model parameters prefixed by the keyword parameter, even though such "variables" are also a kind of class parameter. Instead we mean *formal parameters to the class*. Such formal parameters are prefixed by the keyword replaceable. The special case of replaceable local functions is roughly equivalent to virtual methods in some object-oriented programming languages.

#### **3.3.3.1 Class Parameters Being Instances**

First we present the case when class parameters are variables, i.e., declarations of instances, often called components. The class C in the example below has three class parameters *marked* by the keyword replaceable. These class parameters, which are components (variables) of classC, are declared as having the (default) types GreenClass, YellowClass, and GreenClass respectively. There is also a red object declaration which is not replaceable and therefore not a class parameter (Figure 3.5).

Fig. 3.5: Three class parameters pobj1, pobj2, and pobj3 that are instances (variables) of class C. These are essentially slots that can contain objects of different colors.

Here is the class C with its three class parameters pobj1, pobj2, and pobj3 and a variable obj4 that is not a class parameter:

```
class C
```

```
replaceable GreenClass pobj1 ( p1 =5) ;
  replaceable YellowClass pobj2 ;
  replaceable GreenClass pobj3 ;
  RedClass obj4 ;
equation
```
... end C ;

Now a class C2 is defined by providing two declarations of pobj1 and pobj2 as actual arguments to class C, being red and green respectively, instead of the defaults green and yellow. The keyword redeclare must precede an actual argument to a class formal parameter to allow changing its type. The requirement to use a keyword for a redeclaration in Modelica has been introduced in order to avoid accidentally changing the type of an object through a standard modifier.

In general, the type of a class component cannot be changed if it is not declared as replaceable and a redeclaration is provided. A variable in a redeclaration can replace the original variable if it has a type that is a subtype of the original type or its type constraint. It is also possible to declare type constraints (not shown here) on the substituted classes.

```
class C2 = C ( redeclare RedClass pobj1 , redeclare GreenClass pobj2 ) ;
```
Such a class C2 obtained through redeclaration of pobj1 and pobj2 is of course equivalent to directly defining C2 without reusing class C, as below.

```
class C2
  RedClass pobj1 ( p1 =5) ;
  GreenClass pobj2 ;
  GreenClass pobj3 ;
  RedClass obj4 ;
equation
    ...
```
end C2 ;

#### **3.3.3.2 Class Parameters being Types**

A class parameter can also be a type, which is useful for changing the type of many objects. For example, by providing a type parameter ColoredClass in class C below, it is easy to change the color of all objects of type ColoredClass.

```
class C
  replaceable class ColoredClass = GreenClass ;
  ColoredClass obj1 ( p1 =5) ;
```

```
replaceable YellowClass obj2 ;
  ColoredClass obj3 ;
  RedClass obj4 ;
equation
  ...
```
end C ;

Figure 3.6 depicts how the type value of the ColoredClass class parameter is propagated to the member object declarations obj1 and obj3.

Fig. 3.6: The class parameter ColoredClass is a type parameter that is propagated to the two member instance declarations of obj1 and obj3.

We create a class C2 by giving the type parameter ColoredClass of class C the value BlueClass.

```
class C2 = C ( redeclare class ColoredClass = BlueClass ) ;
```
This is equivalent to the following definition of C2:

```
class C2
  BlueClass obj1 ( p1 =5) ;
  YellowClass obj2 ;
  BlueClass obj3 ;
  RedClass obj4 ;
equation
  ...
```
end C2 ;

#### **3.4 Equations**

As we already stated, Modelica is primarily an equation-based language in contrast to ordinary programming languages, where assignment statements proliferate. Equations are more flexible than assignments since they do not prescribe a certain data flow direction or execution order. This is the key to the physical modelling capabilities and increased reuse potential of Modelica classes.

Thinking in equations is a bit unusual for most programmers. In Modelica the following holds:


Equations are more powerful than assignment statements. For example, consider a resistor equation where the resistance *R* multiplied by the current *i* is equal to the voltage v:

$$R \times i = \nu \tag{3.10}$$

This equation can be used in three ways corresponding to three possible assignment statements: computing the current from the voltage and the resistance, computing the voltage from the resistance and the current, or computing the resistance from the voltage and the current. This is expressed in the following three assignment statements:

```
i := v / R ;
v := R * i ;
R := v / i ;
```
Equations in Modelica can be informally classified into four different groups depending on the syntactic context in which they occur:


As we already have seen in several examples, normal equations appear in equation sections started by the keyword equation and terminated by some other allowed keyword:

```
equation
... < equations > ...
<some other allowed keyword >
```
The above resistor equation is an example of a normal equation that can be placed in an equation section. Declaration equations are usually given as part of declarations of fixed or parameter constants, for example:

```
constant Integer one = 1;
parameter Real mass = 22 .5 ;
```
An equation always holds, which means that the mass in the above example never changes value during simulation. It is also possible to specify a declaration equation for a normal variable, e.g.:

Real speed = 72 .4 ;

However, this does not make much sense since it will constrain the variable to have the same value throughout the computation, effectively behaving as a constant. Therefore a declaration equation is quite different from a variable initialiser in other languages since it always holds and can be solved together with other equations in the total system of equations.

Concerning attribute assignments, these are typically specified using modification equations. For example, if we need to specify an initial value for a variable, meaning its value at the start of the computation, then we give an attribute equation for the start attribute of the variable, e.g.:

Real speed ( start = 72 .4 );

#### **3.4.1 Repetitive Equation Structures**

Before reading this section you might want to take a look at the section further down about arrays, and the section further down about statements and algorithmic for-loops.

Sometimes there is a need to conveniently express sets of equations that have a regular, i.e., repetitive structure. Often this can be expressed as array equations, including references to array elements denoted using square bracket notation. However, for the more general case of repetitive equation structures Modelica provides a loop construct. Note that this is not a loop in the algorithmic sense of the word it is rather a shorthand notation for expressing a set of equations.

For example, consider an equation for a polynomial expression:

3 Modelica: Equation-Based, Object-Oriented Modelling of Physical Systems 61

$$\mathbf{x} = a[1] + a[2] \times \mathbf{x} + a[3] \times \mathbf{x}^2 + \dots + a[n+1] \times \mathbf{x}^n \tag{3.11}$$

The polynomial equation Eq. 3.11 above can be expressed as a set of equations with regular structure in Modelica, with y equal to the scalar product of the vectors a and xpowers, both of length *n* + 1:

```
xpowers [2] = xpowers [1]* x ;
xpowers [3] = xpowers [2]* x ;
...
xpowers [ n +1] = xpowers [n ]* x;
y = a * xpowers ;
```
The regular set of equations involving xpowers can be expressed more conveniently using the for-loop notation:

```
for i in 1: n loop
  xpowers [ i +1] = xpowers [i ]* x;
end for;
```
In this particular case a vector equation provides an even more compact notation:

```
powers [2: n +1] = xpowers [1: n ]* x ;
```
Here the vectors x and xpowers have length *n* + 1. The colon notation 2:n+1 means extracting a vector of length *n*, starting from element 2 up to and including element *n* + 1.

#### **3.4.2 Partial Differential Equations**

Partial differential equations (abbreviated PDEs) contain derivatives with respect to other variables than time, for example of spatial Cartesian coordinates such as *x* and *y*. Models of phenomena such as heat flow or fluid flow typically involve PDEs. At the time of this writing PDE functionality is not yet part of the official Modelica language.

#### **3.5 Acausal Physical modelling**

Acausal modelling is a declarative modelling style, meaning modelling based on equations instead of assignment statements. Equations do not specify which variables are inputs and which are outputs, whereas in assignment statements variables on the left-hand side are always outputs (results) and variables on the right-hand side are always inputs. Thus, the causality of equation-based models is unspecified and becomes fixed only when the corresponding equation systems are solved. This is called *acausal modelling*. The term *physical modelling* reflects the fact that *acausal modelling* is very well suited for representing the *physical structure* of modelled systems.

The main advantage with acausal modelling is that the solution direction of equations will adapt to the data flow context in which the solution is computed. The data flow context is defined by stating which variables are needed as *outputs,* and which are external *inputs* to the simulated system.

The acausality of Modelica library classes makes these more reusable than traditional classes containing assignment statements where the input-output causality is fixed.

To illustrate the idea of acausal physical modelling we give an example of a simple electrical circuit (Figure 3.7). The connection diagram6 of the electrical circuit shows how the components are connected. It may be drawn with component placements to roughly correspond to the physical layout of the electrical circuit on a printed circuit board. The physical connections in the real circuit correspond to the logical connections in the diagram. Therefore the term *physical modelling* is quite appropriate.

<sup>6</sup> A connection diagram emphasises the connections between components of a model, whereas a composition diagram specifies which components a model is composed of, their subcomponents, etc. A class diagram usually depicts inheritance and composition relations.

The Modelica SimpleCircuit model below directly corresponds to the circuit depicted in the connection diagram of Figure 3.7. Each graphic object in the diagram corresponds to a declared instance in the simple circuit model. The model is acausal since no signal flow, i.e., cause-and-effect flow, is specified. Connections between objects are specified using the connect-equation construct, which is a special syntactic form of equation that we will examine later. The classes Resistor, Capacitor, Inductor, VsourceAC, and Ground will be presented in more detail later in this chapter.

Fig. 3.7: Connection diagram of the acausal SimpleCircuit model.

```
model SimpleCircuit
  Resistor R1 ( R =10) ;
  Capacitor C ( C =0 .01 ) ;
  Resistor R2 ( R =100) ;
  Inductor L ( L =0 .1 ) ;
  VsourceAC AC ;
  Ground G ;
equation
  connect ( AC.p , R1.p ) ;
  connect ( R1.n , C.p ) ;
  connect ( C.n , AC.n ) ;
  connect ( R1.p , R2.p ) ;
  connect ( R2.n , L.p ) ;
  connect ( L.n , C.n ) ;
  connect ( AC.n , G.p ) ;
end SimpleCircuit ;
```
As a comparison, we show the same circuit modelled using causal block-oriented modelling depicted as a diagram in Figure 3.8. Here the physical topology is lost–the structure of the diagram has no simple correspondence to the structure of the physical circuit board.

3 Modelica: Equation-Based, Object-Oriented Modelling of Physical Systems 63

Fig. 3.8: The simple circuit model using causal block-oriented modelling with explicit signal flow.

This model is causal since the signal flow has been deduced and is clearly shown in the diagram. Even for this simple example the analysis to convert the intuitive physical model to a causal block-oriented model is nontrivial. Another disadvantage is that the resistor representations are context dependent. For example, the resistors R1 and R2 have different definitions, which makes reuse of model library components hard. Furthermore, such system models are usually hard to maintain since even small changes in the physical structure may result in large changes to the corresponding block-oriented system model.

#### **3.6 The Modelica Software Component Model**

For a long time, software developers have looked with envy on hardware system builders, regarding the apparent ease with which reusable hardware components are used to construct complicated systems. With software there seems too often to be a need or tendency to develop from scratch instead of reusing components. Early attempts at software components include procedure libraries, which unfortunately have too limited applicability and low flexibility. The advent of object-oriented programming has stimulated the development of software component frameworks such as CORBA, the Microsoft COM/DCOM component object model, and JavaBeans. These component models have considerable success in certain application areas, but there is still a long way to go to reach the level of reuse and component standardisation found in hardware industry.

The reader might wonder what all this has to do with Modelica. In fact, Modelica offers quite a powerful software component model that is on par with hardware component systems in flexibility and potential for reuse. The key to this increased flexibility is the fact that Modelica classes are based on equations. What is a software component model? It should include the following three items:


Components are connected via the connection mechanism, which can be visualised in connection diagrams. The component framework realizes components and connections, and ensures that communication works and constraints are maintained over the connections. For systems composed of acausal components the direction of data flow, i.e., the causality is automatically deduced by the compiler at composition time.

#### **3.6.1 Components**

Components are simply instances of Modelica classes. Those classes should have well-defined interfaces, sometimes called ports, in Modelica called connectors, for communication and coupling between a component and the outside world.

A component is modelled independently of the environment where it is used, which is essential for its reusability. This means that in the definition of the component including its equations, only local variables and connector variables can be used. No means of communication between a component and the rest of the system, apart from going via a connector, should be allowed. However, in Modelica access of component data via dot notation is also possible. A component may internally consist of other connected components, i.e., hierarchical modelling.

#### **3.6.2 Connection Diagrams**

Complex systems usually consist of large numbers of connected components, of which many components can be hierarchically decomposed into other components through several levels. To grasp this complexity, a pictorial representation of components and connections is quite important. Such graphic representation is available as connection diagrams, of which a schematic example is shown in Figure 3.9. We have earlier presented a connection diagram of a simple circuit in Figure 3.7.

Fig. 3.9: Schematic picture of a connection diagram for components.

Each rectangle in the diagram example represents a physical component, e.g., a resistor, a capacitor, a transistor, a mechanical gear, a valve, etc. The connections represented by lines in the diagram correspond to real, physical connections. For example, connections can be realised by electrical wires, by the mechanical connections, by pipes for fluids, by heat exchange between components, etc. The connectors, i.e., interface points, are shown as small square dots on the rectangle in the diagram. Variables at such interface points define the interaction between the component represented by the rectangle and other components.

Fig. 3.10: A connection diagram for a simple car model.

A simple car example of a connection diagram for an application in the mechanical domain is shown in Figure 3.10.

The simple car model below includes variables for subcomponents such as wheels, chassis, and control unit. A "comment" string after the class name briefly describes the class. The wheels are connected to both the chassis and the controller. Connect-equations are present, but are not shown in this partial example.

```
class Car " A car class to combine car components "
  Wheel w1 , w2 , w3 , w4 " Wheel one to four ";
  Chassis chassis " Chassis ";
  CarController controller " Car controller ";
  ...
end Car ;
```
#### **3.6.3 Connectors and Connector Classes**

Modelica connectors are instances of connector classes, which define the variables that are part of the communication interface that is specified by a connector. Thus, connectors specify external interfaces for interaction.

For example, Pin is a connector class that can be used to specify the external interfaces for electrical components (Figure 3.11) that have pins. The types Voltage and Current used within Pin are the same as Real, but with different associated units. From the Modelica language point of view, the types Voltage and Current are similar to Real, and are regarded as having equivalent types. Checking unit compatibility within equations is optional.

```
type Voltage = Real ( unit =" V ") ;
type Current = Real ( unit =" A ") ;
```
Fig. 3.11: A component with one electrical Pin connector.

The Pin connector class below contains two variables. The flow prefix on the second variable indicates that this variable represents a flow quantity, which has special significance for connections as explained in the next section.

```
connector Pin
  Voltage v ;
  flow Current i ;
end Pin ;
```
#### **3.6.3.1 Connections**

Connections between components can be established between connectors of equivalent type. Modelica supports equation-based acausal connections, which means that connections are realised as equations. For acausal connections, the direction of data flow in the connection need not be known. Additionally, causal connections can be established by connecting a connector with an output attribute to a connector declared as input.

Two types of coupling can be established by connections depending on whether the variables in the connected connectors are potential (default), or declared using the flow prefix:


For example, the keyword flow for the variable i of type Current in the Pin connector class indicates that all currents in connected pins are summed to zero, according to Kirchhoff's current law.

Fig. 3.12: Connecting two components that have electrical pins.

Connection equations are used to connect instances of connection classes. A connection equation connect(R1.p,R2.p), with R1.p and R2.p of connector class Pin, connects the two pins (Figure 3.12) so that they form one node. This produces two equations, namely:

```
R1.p.v = R2.p.v ;
R1.p.i + R2.p.i = 0;
```
The first equation says that the voltages of the connected wire ends are the same. The second equation corresponds to Kirchhoff's second law, saying that the currents sum to zero at a node (assuming positive value while flowing into the component). The sum-to-zero equations are generated when the prefix flow is used. Similar laws apply to flows in piping networks and to forces and torques in mechanical systems.

We should also mention the concept of *implicit connections*, e.g. useful to model force fields, which is represented by the Modelica inner/outer construct.

#### **3.6.3.2 Implicit Connections with inner/outer**

So far we have focused on explicit connections between connectors where each connection is explicitly represented by a connect-equation and a corresponding line in a connection diagram. However, when modelling certain kinds of large models with many interacting components this approach becomes rather clumsy because of the large number of potential connections–a connection might be needed between each pair of components. This is especially true for system models involving *force fields*, which lead to a maximum of *n* × *n* connections between the *n* components influenced by the force field or 1 × *n* connections between a central object and *n* components if inter-component interaction is neglected.

For the case of 1× *n* connections, instead of using a large number of explicit connections, Modelica provides a convenient mechanism for *implicit connections* between an object and *n* of its components through the inner and outer declaration prefixes.

A rather common kind of implicit interaction is where a *shared attribute* of a single environment object is *accessed* by a number of components within that environment. For example, we might have an environment incl uding house components, each accessing a shared environment temperature, or a circuit board environment with electronic components accessing the board temperature.

A Modelica environment-component example model along these lines is shown below, where a shared environment temperature variable T0 is declared as a *definition declaration* marked by the keyword inner. This declaration is implicitly accessed by the *reference declarations* of T0 marked by the prefix outer in the components comp1 and comp2.

```
model Environment
  inner
    Real T0 ; // Definition of actual environment temperature T0
    Component comp1 , comp2 ; // Lookup match comp1.T0 = comp2.T0 = T0
  parameter
    Real k =1;
  equation
    T0 = sin( k * time ) ;
end Environment ;
```

```
model Component
  outer
     Real T0 ; // Reference to temperature T0 defined in the environments
         Real T ;
  equation
     T = T0 ;
end Component ;
```
#### **3.6.3.3 Expandable Connectors for Information Buses**

It is common in engineering to have so-called information buses with the purpose to transport information between various system components, e.g. sensors, actuators, control units. Some buses are even standardised (e.g., IEEE), but usually rather generic to allow many kinds of different components.

This is the key idea behind the expandable connector construct in Modelica. An expandable connector acts like an information bus since it is intended for connection to many kinds of components. To make this possible it automatically expands the expandable connector type to accommodate all the components connected to it with their different interfaces. If an element with a certain name and type is not present, it is added.

All fields in an expandable connector are seen as connector instances even if they are not declared as such, i.e., it is possible to connect to e.g. a Real variable.

Moreover, when two expandable connectors are connected, each is augmented with the variables that are only declared in the other expandable connector. This is repeated until all connected expandable connector instances have matching variables, i.e., each of the connector instances is expanded to be the union of all connector variables. If a variable appears as an input in one expandable connector, it should appear as a non-input in at least one other expandable connector instance in the connected set. The following is a small example:

```
expandable connector EngineBus
end EngineBus ;
block Sensor
  RealOutput speed ;
end Sensor ;
block Actuator
  RealInput speed ;
end Actuator ;
model Engine
   EngineBus bus ;
   Sensor sensor ;
   Actuator actuator ;
equation
    connect ( bus.speed , sensor.speed ) ; // provides the non - input
    connect ( bus.speed , actuator.speed );
end Engine ;
```
#### **3.6.3.4 Stream Connectors**

In thermodynamics with fluid applications where there can be bi-directional flows of matter with associated quantities, it turns out that the two basic variable types in a connector–potential variables and flow variables–are not sufficient to describe models that result in a numerically sound solution approach. Such applications typically have bi-directional flow of matter with convective transport of specific quantities, such as specific enthalpy and chemical composition

If we would use conventional connectors with flow and potential variables, the corresponding models would include nonlinear systems of equations with Boolean unknowns for the flow directions and singularities around zero flow. Such equation systems cannot be solved reliably in general. The model formulations can be simplified when formulating two different balance equations for the two possible flow directions. This is however not possible only using flow and potential variables.

This fundamental problem is addressed in Modelica by introducing a third type of connector variable, called *stream variable*, declared with the prefix stream. A stream variable describes a quantity that is carried by a flow variable, i.e., a purely convective transport phenomenon.

If at least one variable in a connector has the stream prefix, the connector is called a *stream connector*and the corresponding variable is called a *stream variable*. For example:

```
connector FluidPort ...
  flow Real m_flow " Flow of matter ; m_flow >0 if flow into component ";
  stream Real h_outflow " Specific variable in component if m_flow < 0 "
end FluidPort
```

```
model FluidSystem ...
   FluidComponent m1 , m2 , ... , mN ;
   FluidPort c1 , c2 , ... , cM ;
equation connect ( m1.c , m2.c ) ; ...
    connect ( m1.c , cM ) ; ...
end FluidSystem ;
```
#### **3.6.4 Partial Classes**

A common property of many electrical components is that they have two pins. This means that it is useful to define a "blueprint" model class, e.g., called TwoPin, that captures this common property. This is a *partial class* since it does not contain enough equations to completely specify its physical behaviour, and is therefore prefixed by the keyword partial. Partial classes are usually known as *abstract classes* in other object-oriented languages. Since a partial class is incomplete it cannot be used as a class to instantiate a data object.

```
partial class TwoPin8 " Superclass of elements with two electrical pins "
  Pin p , n ;
  Voltage v ;
  Current i ;
equation
  v = p.v - n.v ;
  0 = p.i + n.i ;
  i = p.i ;
end TwoPin ;
```
This TwoPin class is referred to by the name Modelica.Electrical.Analog.Interfaces.OnePort in the Modelica standard library since this is the name used by electrical modelling experts. Here we use the more intuitive name TwoPin since the class is used for components with two physical ports and not one. The OnePort naming is more understandable if it is viewed as denoting composite ports containing two subports.

The TwoPin class has two pins, p and n, a quantity v that defines the voltage drop across the component, and a quantity i that defines the current into pin p, through the component, and out from pin n (Figure 3.13). It is useful to label the pins differently, e.g., p and n, and using graphics, e.g. filled and unfilled squares respectively, to obtain a well-defined sign for v and i although there is no physical difference between these pins in reality.

3 Modelica: Equation-Based, Object-Oriented Modelling of Physical Systems 69

Fig. 3.13: Generic TwoPin class that describes the general structure of simple electrical components with two pins.

The equations define generic relations between quantities of simple electrical components. In order to be useful, a constitutive equation must be added that describes the specific physical characteristics of the component.

#### **3.6.5 Reuse of Partial Classes**

Given the generic partial class TwoPin, it is now straightforward to create the more specialised Resistor class by adding a constitutive equation:

R \* i = v ;

This equation describes the specific physical characteristics of the relation between voltage and current for a resistor (Figure 3.14).

Fig. 3.14: A resistor component.

```
class Resistor " Ideal electrical resistor "
  extends TwoPin ;
  parameter Real R ( unit =" Ohm ") " Resistance ";
equation
    R* i = v ;
end class
```
A class for electrical capacitors can also reuse TwoPin in a similar way, adding the constitutive equation for a capacitor (Figure 3.15).

Fig. 3.15: A capacitor component.

```
class Capacitor " Ideal electrical capacitor "
  extends TwoPin ;
  parameter Real C ( Unit =" F ") " Capacitance ";
equation
   C*der( v ) = i ;
end Capacitor ;
```
During system simulation the variables i and v specified in the above components evolve as functions of time. The solver of differential equations computes the values of v(*t*) and *i*(*t*) (where *t* is time) such that *C*. ˙v(*t*) = *i*(*t*) for all values of *t*, fulfilling the constitutive equation for the capacitor.

#### **3.7 Component Library Design and Use**

In a similar way as we previously created the resistor and capacitor components, additional electrical component classes can be created, forming a simple electrical component library that can be used for application models such as the SimpleCircuit model. Component libraries of reusable components are actually the key to effective modelling of complex systems.

Below, we show an example of designing a small library of electrical components needed for the simple circuit example, as well as the equations that can be extracted from these components.

#### **Resistor**

Fig. 3.16: Resistor component.

Four equations can be extracted from the resistor model depicted in Figure 3.14 and Figure 3.16. The first three originate from the inherited TwoPin class, whereas the last is the constitutive equation of the resistor.

0 = p.i + n.i v = p.v - n.v i = p.i v = R \* i

#### **Capacitor**

Fig. 3.17: Capacitor component.

The following four equations originate from the capacitor model depicted in Figure 3.15 and Figure 3.17, where the last equation is the constitutive equation for the capacitor.

0 = p.i + n.i ; v = p.v - n.v ; i = p.i ; i = C \* der( v ) ;

#### **Inductor**

Fig. 3.18: Inductor component

The inductor class depicted in Figure 3.18 and shown below gives a model for ideal electrical inductors.

```
class Inductor " Ideal electrical inductor "
  extensd TwoPin ;
  parameter Real L ( unit =" H ") " Inductance ";
equation
  v = L *der( i ) ;
end Inductor ;
```
These equations can be extracted from the inductor class, where the first three come from TwoPin as usual and the last is the constitutive equation for the inductor.

0 = p.i + n.i ; v = p.v - n.v ; i = p.i ; v = L \* der( i ) ;

#### **Voltage Source**

Fig. 3.19: Voltage source component VsourceAC, where v(*t*) = *V A* × *sin*(2 × *PI* × *f* × *time*).

A classVsourceAC for the sin-wave voltage source to be used in our circuit example is depicted in Figure 3.19 and can be defined as below. This model as well as other Modelica models specify behaviour that evolves as a function of time. Note that the built-in predefined variable time is used. In order to keep the example simple the constant PI is explicitly declared even though it is usually imported from the Modelica standard library.

```
class VsourceAC " Sin - wave voltage source "
  extends TwoPin ;
  parameter Voltage VA = 220 " Amplitude ";
  parameter Real f ( unit =" Hz ") = 50 " Frequency ";
  constant Real PI = 3 .141592653589793 ;
equation
  v = VA *sin (2* PI * f * time ) ;
end VsourceAC ;
```
In this TwoPin-based model, four equations can be extracted from the model, of which the first three are inherited from TwoPin:

0 = p.i + n.i ; v = p.v - n.v ; i = p.i ; v = VA \*sin (2\* PI \* f \* time ) ;

#### **Ground**

Fig. 3.20: Ground component.

Finally, we define a class for ground points that can be instantiated as a reference value for the voltage levels in electrical circuits. This class has only one pin (Figure 3.20).

```
class Ground " Ground "
  Pin p ;
equation
  p.v = 0;
end Ground ;
```
A single equation can be extracted from the Ground class.

p.v = 0

#### **3.7.1 The Simple Circuit Model**

Having collected a small library of simple electrical components, we can now put together the simple electrical circuit shown previously and in Figure 3.21.

Fig. 3.21: The SimpleCircuit model.

The two resistor instances R1 and R2 are declared with modification equations for their respective resistance parameter values. Similarly, an instance C of the capacitor and an instance L of the inductor are declared with modifiers for capacitance and inductance respectively. The voltage source AC and the ground instance G have no modifiers. Connect-equations are provided to connect the components in the circuit.

```
class SimpleCircuit
  Resistor R1 ( R =10) ;
  Capacitor C (C =0 .01 );
  Resistor R2 ( R =100) ;
  Inductor L (L =0 .1 ) ;
  VsourceAC AC ;
  Ground G ;
equation
  connect ( AC.p , R1.p ) ; // Wire1 , Capacitor circuit
  connect ( R1.n , C.p ) ; // Wire 2
  connect ( C.n , AC.n ) ; // Wire 3
  connect ( R1.p , R2.p ) ; // Wire4 , Inductor circuit
  connect ( R2.n , L.p ) ; // Wire 5
  connect ( L.n , C.n ) ; // Wire 6
  connect ( AC.n , G.p ) ; // Wire7 , Ground
end SimpleCircuit ;
```
#### **3.7.2 Arrays**

An array is a collection of variables all of the same type. Elements of an array are accessed through simple Integer indexes ranging from a lower bound of 1 to an upper bound being the size of the respective dimension, or by Boolean indexes from false to true, or by enumeration indexes. An array variable can be declared by appending dimensions within square brackets after a class name, as in Java, or after a variable name, as in the C language. For example:

```
Real [3] positionvector = {1 ,2 ,3};
Real [3 ,3] identitymatrix = {{1 ,0 ,0} , {0 ,1 ,0} , {0 ,0 ,1}};
Real [3 ,3 ,3] arr3d ;
```
This declares a three-dimensional position vector, a transformation matrix, and a three-dimensional array. Using the alternative syntax of attaching dimensions after the variable name, the same declarations can be expressed as:

```
Real positionvector [3] = {1 ,2 ,3};
Real identitymatrix [3 ,3] = {{1 ,0 ,0} , {0 ,1 ,0} , {0 ,0 ,1}};
Real arr3d [3 ,3 ,3];
```
In the first two array declarations, declaration equations have been given, where the array constructor **{ }** is used to construct array values for defining positionvector and identitymatrix. Indexing of an array A is written A[i,j,...], where 1 is the lower bound and size(A,k) is the upper bound of the index for the *k*th dimension. Submatrices can be formed by utilising the : notation for index ranges, for example, A[i1:i2, j1:j2], where a range i1:i2 means all indexed elements starting with i1 up to and including i2.

Array expressions can be formed using the arithmetic operators +, **-**, **\***, and **/**, since these can operate on either scalars, vectors, matrices, or (when applicable) multidimensional arrays with elements of type Real or Integer. The multiplication operator **\*** denotes scalar product when used between vectors, matrix multiplication when used between matrices or between a matrix and a vector, and element-wise multiplication when used between an array and a scalar. As an example, multiplying positionvector by the scalar 2 is expressed by:

positionvector \* 2

which gives the result:

```
{2 , 4 , 6}
```
In contrast to Java, arrays of dimensionality greater than 1 in Modelica are always rectangular as in Matlab or Fortran.

A number of built-in array functions are available, of which a few are shown in the table below.


A scalar Modelica function of a scalar argument is automatically generalised to be applicable also to arrays element-wise. For example, if A is a vector of real numbers, then cos(A) is a vector where each element is the result of applying the function cos to the corresponding element in A. For example:

cos ({ 1 , 2 , 3 }) = { cos (1) , cos (2) , cos (3) }

General array concatenation can be done through the array concatenation operator cat(k,A,B,C,...) that concatenates the arrays A,B,C,... along the *k*th dimension. For example, cat(1, {2,3}, {5,8,4}) gives the result {2,3,5,8,4}.

*m* × *n*

The common special cases of concatenation along the first and second dimensions are supported through the special syntax forms [A;B;C;...] and [A,B,C,...] respectively. Both of these forms can be mixed. In order to achieve compatibility with Matlab array syntax, being a *de facto* standard, scalar and vector arguments to these special operators are promoted to become matrices before performing the concatenation. This gives the effect that a matrix can be constructed from scalar expressions by separating rows by semicolons and columns by commas. The example below creates an matrix:

```
[expr11, expr12, ... expr1n;
```

```
expr21, expr22, ... expr2n;
```
. . .

exprm1, exprm2, ... exprmn]

It is instructive to follow the process of creating a matrix from scalar expressions using these operators. For example:

[1,2;

3,4]

First, each scalar argument is promoted to become a matrix, giving:

[ {{1}}, {{2}};

{{3}}, {{4}} ]

Since [... , ...] for concatenation along the second dimension has higher priority than [... ; ...], which concatenates along the first dimension, the first concatenation step gives:

[ {{1, 2}};

{{3, 4}} ]

Finally, the row matrices are concatenated giving the desired matrix:

{{1, 2},

{3, 4}}

1 × 1

The special case of just one scalar argument can be used to create a matrix. For example:

[1]

gives the matrix:

{{1}}

#### **3.8 Algorithmic Constructs**

Even though equations are eminently suitable for modelling physical systems and for a number of other tasks, there are situations where non-declarative algorithmic constructs are needed. This is typically the case for algorithms, i.e., procedural descriptions of how to carry out specific computations, usually consisting of a number of statements that should be executed in the specified order.

#### **3.8.1 Algorithm Sections and Assignment Statements**

In Modelica, algorithmic statements can occur only within algorithm sections, starting with the keyword algorithm. Algorithm sections may also be called algorithm equations, since an algorithm section can be viewed as a group of equations involving one or more variables, and can appear among equation sections. Algorithm sections are terminated by the appearance of one of the keywords equation, public, protected,algorithm, end, or annotation.

```
algorithm
  ...
  <statements >
  ...
  <some other keyword >
```
An algorithm section embedded among equation sections can appear as below, where the example algorithm section contains three assignment statements.

```
equation
  x = y *2;
  z = w ;
algorithm
  x1 := z + x ;
  x2 := y -5;
  x1 := x2 + y ;
equation
  u = x1 + x2 ;
  ...
```
Note that the code in the algorithm section, sometimes denoted algorithm equation, uses the values of certain variables from outside the algorithm. These variables are so called *input variables* to the algorithm–in this example x, y, and z. Analogously, variables assigned values by the algorithm define the *outputs of the algorithm*–in this example x1 and x2. This makes the semantics of an algorithm section quite similar to a function with the algorithm section as its body, and with input and output formal parameters corresponding to inputs and outputs as described above.

#### **3.8.2 Statements**

In addition to assignment statements, which were used in the previous example, a few other kinds of "algorithmic" statements are available in Modelica: if-then-else statements, for-loops, while-loops, return statements, etc. The summation below uses both a while-loop and an if-statement, where size(a,1) returns the size of the first dimension of array a. The elseif- and else-parts of if-statements are optional.

```
sum := 0;
n := size (a ,1) ;
while n >0 loop
  if a [ n ] >0 then
    sum := sum + a [n ];
  elseif a [ n ] > -1 then
    sum := sum - a [n ] -1;
  else
    sum := sum - a [n ];
  end if;
  n := n -1;
end while ;
```
Both for-loops and while-loops can be immediately terminated by executing a break-statement inside the loop. Such a statement just consists of the keyword break followed by a semicolon.

Consider once more the computation of the polynomial previously presented in the section on repetitive equation structures:

y := *a*[1] + *a*[2] ∗ *x* + *a*[3] ∗ *x*^1 + ... + *a*[*n* + 1] ∗ *x*^*n*;

When using equations to model the computation of the polynomial it was necessary to introduce an auxiliary vector xpowers for storing the different powers of x. Alternatively, the same computation can be expressed as an algorithm including a for-loop as below. This can be done without the need for an extra vector–it is enough to use a scalar variable xpower for the most recently computed power of x.

```
algorithm
  y := 0;
```

```
xpower := 1;
for i in 1: n +1 loop
  y := y + a [ i ]* xpower ;
  xpower := xpower * x ;
end for;
```
#### **3.8.3 Functions**

Functions are a natural part of any mathematical model. A number of mathematical functions like abs, sqrt, mod,sin, cos, exp, etc. are both predefined in the Modelica language and available in the Modelica standard math library Modelica.Math. The arithmetic operators +, -, ∗, / can be regarded as functions that are used through a convenient operator syntax. Thus it is natural to have user-defined mathematical functions in the Modelica language. The body of a Modelica function is an algorithm section that contains procedural algorithmic code to be executed when the function is called. Formal parameters are specified using the input keyword, whereas results are denoted using the output keyword. This makes the syntax of function definitions quite close to Modelica block class definitions.

Modelica functions are *mathematical functions*, i.e., without global side-effects and with no memory (except impure Modelica functions marked with the keyword impure). A Modelica function always returns the same results given the same arguments. Below we show the algorithmic code for polynomial evaluation in a function named polynomialEvaluator.

```
function polynomialEvaluator
  input Real a [:]; // Array , size defined at function call time
  input Real x := 1 .0 ; // Default value 1 .0 for x
  output Real y ;
protected
  Real xpower ;
algorithm
  y := 0;
  xpower := 1;
  for i in 1: size (a ,1) loop
     y := y + a [ i ]* xpower ;
     xpower := xpower * x ;
  end for;
end polynomialEvaluator ;
```
Functions are usually called with positional association of actual arguments to formal parameters. For example, in the call below the actual argument {1,2,3,4} becomes the value of the coefficient vector a, and 21 becomes the value of the formal parameter x. Modelica function formal parameters are read-only, i.e., they may not be assigned values within the code of the function. When a function is called using positional argument association, the number of actual arguments and formal parameters must be the same. The types of the actual argument expressions must be compatible with the declared types of the corresponding formal parameters. This allows passing array arguments of arbitrary length to functions with array formal parameters with unspecified length, as in the case of the input formal parameter a in the polynomialEvaluator function.

p = polynomialEvaluator ({1 , 2, 3, 4} , 21) ;

The same call to the function polynomialEvaluator can instead be made using named association of actual arguments to formal parameters, as in the next example. This has the advantage that the code becomes more self-documenting as well as more flexible with respect to code updates.

For example, if all calls to the function polynomialEvaluator are made using named parameter association, the order between the formal parameters a and x can be changed, and new formal parameters with default values can be introduced in the function definitions without causing any compilation errors at the call sites. Formal parameters with default values need not be specified as actual arguments unless those parameters should be assigned values different from the defaults.

p = polynomialEvaluator (a ={1 , 2 , 3, 4} , x =21) ;

Functions can have multiple results. For example, the function f below has three result parameters declared as three formal output parameters r1, r2, and r3.

```
function f
  input Real x ;
  input Real y ;
  output Real r1 ;
  output Real r2 ;
  output Real r3 ;
  ...
end f ;
```
Within algorithmic code multiresult functions may be called only in special assignment statements, as the one below, where the variables on the left-hand side are assigned the corresponding function results.

(a , b , c ) := f (1 .0 , 2 .0 );

In equations a similar syntax is used:

(a , b , c ) = f (1 .0 , 2 .0 ) ;

A function is returned from by reaching the end of the function or by executing a return-statement inside the function body.

#### **3.8.4 Operator Overloading and Complex Numbers**

Function and operator overloading allow several definitions of the same function or operator, but with a different set of input formal parameter types for each definition. This allows, e.g., to define operators such as addition, multiplication, etc., of complex numbers, using the ordinary + and ∗ operators but with new definitions, or provide several definitions of a solve function for linear matrix equation solution for different matrix representations such as standard dense matrices, sparse matrices, symmetric matrices, etc.

In fact, overloading already exists predefined to a limited extent for certain operators in the Modelica language. For example, the plus (**+**) operator for addition has several different definitions depending on the data type:


Overloaded operators for user-defined data types can be defined using operator record and operator function declarations. Here we show part of a complex numbers data type example:

```
operator record Complex " Record defining a Complex number "
  Real re " Real part of complex number ";
  Real im " Imaginary part of complex number ";
  encapsulated operator 'constructor '
    import Complex ;
    function fromReal
      input Real re ;
      output Complex result = Complex ( re = re , im =0 .0 );
         annotation ( Inline = true ) ;
    end fromReal ;
  end ' constructor ';
  encapsulated operator function '+'
    import Complex ;
    input Complex c1 ;
    input Complex c2 ;
    output Complex result " Same as : c1 + c2 ";
      annotation ( Inline = true ) ;
    algorithm
      result := Complex ( c1.re + c2.re , c1.im + c2.im );
    end '+';
  end Complex ;
```
In the above example, we start as usual with the real and imaginary part declarations of the re and im fields of the Complex operator record definition. Then comes a *constructor definition* fromReal with only one input argument instead of the two inputs of the default Complex constructor implicitly defined by the Complex record definition, followed by overloaded operator definition for **'+'**.

How can these definitions be used? Take a look at the following small example:

```
Real a ;
Complex b;
Complex c = a + b; // Addition of Real number a and Complex number b
```
The interesting part is in the third line, which contains an addition a+b of a Real number a and a Complex number b. There is no built-in addition operator for complex numbers, but we have the above overloaded operator definition of **'+'** for two complex numbers. An addition of two complex numbers would match this definition right away in the lookup process.

However, in this case we have an addition of a real number and a complex number. Fortunately, the lookup process for overloaded binary operators can also handle this case if there is a constructor function in the Complex record definition that can convert a real number to a complex number. Here we have such a constructor called fromReal.

Note that the Complex is already predefined in a Modelica record type called Complex. This is distributed as part of the Modelica standard library (MSL) but defined at the top-level outside of MSL. It is referred to as Complex or .Complex. and is automatically preloaded by most tools, enabling direct usage without the need for any import statements (except in encapsulated classes). There is a library ComplexMath with operations on complex numbers.

The following are some examples of using the predefined type Complex:

```
Real a = 2;
Complex j = Modelica.ComplexMath.j ;
Complex b = 2 + 3* j;
Complex c = (2* b + a ) /b ;
Complex d = Modelica.ComplexMath.sin (c ) ;
Complex v [3] = { b /2 , c , 2* d };
```
#### **3.8.5 External Functions**

It is possible to call functions defined outside of the Modelica language, implemented in C or Fortran. If no external language is specified the implementation language is assumed to be C. The body of an external function is marked with the keyword external in the Modelica external function declaration.

```
function log input
  Real x ;
  output Real y ;
  external
end log ;
```
The external function interface supports a number of advanced features such as in–out parameters, local work arrays, external function argument order, explicit specification of row-major versus column-major array memory layout, etc. For example, the formal parameter Ares corresponds to an in–out parameter in the external function leastSquares below, which has the value A as input default and a different value as the result. It is possible to control the ordering and usage of parameters to the function external to Modelica. This is used below to explicitly pass sizes of array dimensions to the Fortran routine called dgels. Some old-style Fortran routines like dgels need work arrays, which is conveniently handled by local variable declarations after the keyword protected.

```
function leastSquares " Solves a linear least squares problem " input
   Real A [: ,:];
  input Real B [: ,:];
  output Real Ares [ size (A ,1) ,size (A ,2) ] := A ;
  // Factorization is returned in Ares for later use
  output Real x [ size (A ,2) ,size (B ,2) ];
protected
  Integer lwork = min ( size (A ,1) ,size (A ,2) ) +
                    max ( max ( size (A ,1) ,size (A ,2) ) ,size (B ,2) ) *32;
  Real work [ lwork ];
  Integer info ;
  String transposed =" NNNN "; // Workaround for passing CHARACTER data to
                                // Fortran routine
  external " FORTRAN 77 "
```

```
dgels ( transposed , 100 , size (A ,1) , size (A ,2) , size (B ,2) , Ares ,
             size (A ,1) , B , size (B ,1) , work , lwork , info ) ;
end leastSquares ;
```
#### **3.8.6 Algorithms Viewed as Functions**

The function concept is a basic building block when defining the semantics or meaning of programming language constructs. Some programming languages are completely defined in terms of mathematical functions. This makes it useful to try to understand and define the semantics of algorithm sections in Modelica in terms of functions. For example, consider the algorithm section below, which occurs in an equation context:

algorithm y := x ; z := 2\* y ; y := z + y ; ...

This algorithm can be transformed into an equation and a function as below, without changing its meaning. The equation equates the output variables of the previous algorithm section with the results of the function f. The function f has the inputs to the algorithm section as its input formal parameters and the outputs as its result parameters. The algorithmic code of the algorithm section has become the body of the function f.

```
(y , z ) = f ( x ) ;
...
function f
  input Real x ;
  output Real y , z ;
algorithm
  y := x ;
  z := 2* y ;
  y := z + y ;
end f ;
```
#### **3.9 Discrete Event and Hybrid modelling**

Macroscopic physical systems in general evolve continuously as a function of time, obeying the laws of physics. This includes the movements of parts in mechanical systems, current and voltage levels in electrical systems, chemical reactions, etc. Such systems are said to have continuous dynamics.

On the other hand, it is sometimes beneficial to make the approximation that certain system components display discrete behaviour, i.e., changes of values of system variables may occur instantaneously and discontinuously at specific points in time.

In the real physical system the change can be very fast, but not instantaneous. Examples are collisions in mechanical systems, e.g., a bouncing ball that almost instantaneously changes direction, switches in electrical circuits with quickly changing voltage levels, valves and pumps in chemical plants, etc. We talk about system components with discrete-time dynamics. The reason to make the discrete approximation is to simplify the mathematical model of the system, making the model more tractable and usually speeding up the simulation of the model several orders of magnitude.

For this reason, it is possible to have variables in Modelica models of *discrete-time variability*, i.e., the variables change value only at specific points in time, so-called *events*. There are two kinds of discrete-time variables: *unclocked discrete-time variables* which keep their values constant between events and *clocked discrete-time variables* which are undefined between associated clock-tick events, see Figure 3.22. Examples of discrete-time variables are Real variables declared with the prefix discrete, clock variables and clocked variables, or Integer, Boolean, and enumeration variables which are discrete-time by default and cannot be continuous-time.

Fig. 3.22: Discrete-time variables *z1* and *z2* change value only at event instants, whereas continuous-time variables like *y* may change value both between and at events. An unclocked discrete-time variable *z1* is defined also between events, whereas a clocked discrete-time variable z*2* is defined only at associated clock-tick events.

Since the discrete-time approximation can only be applied to certain subsystems, we often arrive at system models consisting of interacting continuous and discrete components. Such a system is called a *hybrid system* and the associated modelling techniques *hybrid modelling*. The introduction of hybrid mathematical models creates new difficulties for their solution, but the disadvantages are far outweighed by the advantages.

Modelica provides four kinds of constructs for expressing hybrid models: conditional expressions or equations to describe discontinuous and conditional models, when-equations to express equations that are valid only at discontinuities (e.g., when certain conditions become true), clocked synchronous constructs, and clocked state machines. For example, if-then-else conditional expressions allow modelling of phenomena with different expressions in different operating regions, as for the equation describing a limiter below.

y = if v > limit then limit else v ;

A more complete example of a conditional model is the model of an ideal diode. The characteristic of a real physical diode is depicted in Figure 3.23, and the ideal diode characteristic in parameterized form is shown in Figure 3.24.

Fig. 3.23: Real diode characteristic.

Fig. 3.24: Ideal diode characteristic.

Since the voltage level of the ideal diode would go to infinity in an ordinary voltage-current diagram, a parameterised description is more appropriate, where both the voltage v and the current i, same as i1, are functions of the parameter s. When the diode is off no current flows and the voltage is negative, whereas when it is on there is no voltage drop over the diode and the current flows.

```
model Diode " Ideal diode "
  extends TwoPin ;
  Real s ;
  Boolean off ;
equation
  off = s < 0;
  if off
    then v = s ;
    else v =0; // conditional equations
  end if;
  i = if off then 0 else s ;
end Diode ;
```
When-equations have been introduced in Modelica to express instantaneous equations, i.e., equations that are valid only at certain points in time that, for example, occur at discontinuities when specific conditions become true, so-called *events*. The syntax of when-equations for the case of a vector of conditions is shown below. The equations in the when-equation are activated when at least one of the conditions becomes true, and remain activated only for a time instant of zero duration. A single condition is also possible.

```
when { condition1 , condition2 , ... } then
   <equations >
end when ;
```
A bouncing ball is a good example of a hybrid system for which the when-equation is appropriate when modelled. The motion of the ball is characterised by the variable height above the ground and the vertical velocity. The ball moves continuously between bounces, whereas discrete changes occur at bounce times, as depicted in Figure 3.25. When the ball bounces against the ground its velocity is reversed. An ideal ball would have an elasticity coefficient of1 and would not lose any energy at a bounce. A more realistic ball, as the one modelled below, has an elasticity coefficient of 0.9, making it keep 90 percent of its speed after the bounce.

Fig. 3.25: Trajectory of bouncing ball.

The bouncing ball model contains the two basic equations of motion relating height and velocity as well as the acceleration caused by the gravitational force. At the bounce instant the velocity is suddenly reversed and slightly decreased, i.e., velocity (after bounce) = -c\*velocity (before bounce), which is accomplished by the special reinit syntactic form of instantaneous equation for reinitialisation: reinit(velocity,-c\*pre(velocity)), which in this case reinitialises the velocity variable.

```
model BouncingBall " Simple model of a bouncing ball "
  constant Real g = 9 .81 " Gravity constant ";
  parameter Real c = 0 .9 " Coefficient of restitution ";
  parameter Real radius =0 .1 " Radius of the ball ";
  Real height ( start = 1) " Height of the ball center ";
  Real velocity ( start = 0) " Velocity of the ball ";
equation
  der( height ) = velocity ;
  der( velocity ) = -g ;
  when height <= radius then
    reinit ( velocity , - c *pre( velocity ) ) ;
  end when ;
end BouncingBall ;
```
Note that the equations within a when-equation are active only during the instant in time when the condition(s) of the when-equation become true, whereas the conditional equations within an if-equation are active as long as the condition of the if-equation is true.

If we simulate this model long enough, the ball will fall through the ground. This strange behaviour of the simulation, called shattering, or the Zeno effect is due to the limited precision of floating point numbers together with the event detection mechanism of the simulator, and occurs for some (unphysical) models where events may occur infinitely close to each other. The real problem in this case is that the model of the impact is not realistic the law new\_velocity = -c \* velocity does not hold for very small velocities. A simple fix is to state a condition when the ball falls through the ground and then switch to an equation stating that the ball is lying on the ground. A better but more complicated solution is to switch to a more realistic material model.

#### **Synchronous Clocks and State Machines**

Starting from Modelica version 3.3 two main groups of discrete-time and hybrid modelling features are available in the language: built-in synchronous clocks with constructs for clock-based modelling and synchronous clockbased state-machines.

As depicted in Figure 3.22, clocks and clocked discrete-time variable values are only defined at clock tick events for an associated clock and are undefined between clock ticks.

Synchronous clock-based modelling gives additional advantages for real-time and embedded system modelling in terms of higher performance and avoidance and/or detection of certain kinds of errors.

To give a very simple example, in the model below the clock variable clk is defined with an interval of 0.2 seconds. This clock is used for sampling the built-in time variable, with result put in x and defined only at clock ticks. Finally, the variable y is defined also between clock ticks by the use of the hold operator.

```
model BasicClockedSynchronous
  Clock clk " A clock variable ";
  discrete Real x " Clocked discrete - time variable ";
  Real y " Unclocked discrete - time variable ";
equation
  clk = Clock (0 .2 ) ; // Clock with an interval of 0 .2 seconds
  x = sample ( time , clk ) ; // Sample the continuous time at clock ticks
  y = hold ( x ) +1; // Hold value is defined also between clock ticks
end BasicClockedSynchronous ;
```
Fig. 3.26: Simulation of model BasicClockedSynchronous showing clocked discrete-time variable *x* and unclocked discrete-time variable y.

#### **3.10 Modularity Facilites**

#### **3.10.1 Packages**

Name conflicts are a major problem when developing reusable code, for example, libraries of reusable Modelica classes and functions for various application domains. No matter how carefully names are chosen for classes and variables it is likely that someone else is using some name for a different purpose. This problem gets worse if we are using short descriptive names since such names are easy to use and therefore quite popular, making them quite likely to be used in another person's code.

A common solution to avoid name collisions is to attach a short prefix to a set of related names, which are grouped into a package. For example, all names in the X-Windows toolkit have the prefix Xt, and most definitions in the Qt GUI library are prefixed with Q. This works reasonably well for a small number of packages, but the likelihood of name collisions increases as the number of packages grows.

Many programming languages, e.g., Java and Ada as well as Modelica provide a safer and more systematic way of avoiding name collisions through the concept of *package*. A package is simply a container or name space for names of classes, functions, constants, and other allowed definitions. The package name is prefixed to all definitions in the package using standard dot notation. Definitions can be *imported* into the name space of a package.

Modelica has defined the package concept as a restriction and enhancement of the class concept. Thus, inheritance could be used for importing definitions into the name space of another package. However, this gives conceptual modelling problems since inheritance for import is not really a package specialisation. Instead, an import language construct is provided for Modelica packages. The type name Voltage together with all other definitions in Modelica.SIunits is imported in the example below, which makes it possible to use it without prefix for declaration of the variable v. By contrast, the declaration of the variable i uses the fully qualified nameModelica.SIunits.Ampere of the type Ampere, even though the short version also would have been possible. The fully qualified long name for Ampere can be used since it is found using the standard nested lookup of the Modelica standard library placed in a conceptual top-level package.

```
package MyPack
  import MyTypes. *;
  import Modelica.SIunits. *;
  class Foo ;
    Voltage v;
    Modelica.SIunits.Ampere i;
  end Foo ;
end MyPack ;
```
Importing definitions from one package into another class as in the above example has the drawback that the introduction of new definitions into a package may cause name clashes with definitions in packages using that package. For example, if a type definition named Voltage is introduced into the package MyTypes, a compilation error would arise in the package MyPack since it is also defined in the package Modelica.SIunits.

An alternative solution to the short-name problem that does not have the drawback of possible compilation errors when new definitions are added to libraries, is introducing short convenient name aliases for prefixes instead of long package prefixes. This is possible using the renaming form of import statement as in the package MyPack below, where the package name SI is introduced instead of the much longer Modelica.SIunits.

Another disadvantage with the above package is that the Ampere type is referred to using standard nested lookup and not via an explicit import statement. Thus, in the worst case we may have to do the following in order to find all such dependencies and the declarations they refer to:


Instead, a *well-designed package* should state all its dependencies *explicitly* through import statements which are easy to find. We can create such a package, e.g., the package MyPack below, by adding the prefix encapsulated in front of the package keyword. This prevents nested lookup outside the package boundary (unfortunately with one exception, names starting with a dot **.**, ensuring that all dependencies on other packages outside the current package have to be explicitly stated as import statements. This kind of encapsulated package represents an independent unit of code and corresponds more closely to the package concept found in many other programming languages, e.g., Java or Ada.

```
encapsulated package MyPack
  import SI = Modelica.SIunits ;
  import Modelica ;
  class Foo ;
   SI.Voltage v ;
    Modelica.SIunits.Ampere i;
  end Foo ;
  ...
end MyPack ;
```
#### **3.10.2 Annotations**

A Modelica annotation is extra information associated with a Modelica model. This additional information is used by Modelica environments, e.g., for supporting documentation or graphical model editing. Most annotations do not influence the execution of a simulation, i.e., the same results should be obtained even if the annotations are removed–but there are exceptions to this rule. The syntax of an annotation is as follows:

```
annotation ( annotation_elements )
```
where annotation\_elements is a comma-separated list of annotation elements that can be any kind of expression compatible with the Modelica syntax. The following is a resistor class with its associated annotation for the icon representation of the resistor used in the graphical model editor:

```
model Resistor
  ...
  annotation ( Icon ( coordinateSystem ( preserveAspectRatio = true ,
  extent = {{ -100 , -100} ,{100 ,100}} , grid = {2 ,2}) ,
  graphics = {
    Rectangle ( extent = {{ -70 ,30} ,{70 , -30}} , lineColor = {0 ,0 ,255} ,
    fillColor = {255 ,255 ,255} ,
       fillPattern = FillPattern.Solid ) ,
    Line ( points = {{ -90 ,0} ,{ -70 ,0}} , color = {0 ,0 ,255}) ,
    Line ( points = {{70 ,0} ,{90 ,0}} , color ={0 ,0 ,255}) ,
    Text ( extent = {{ -144 , -40} ,{142 , -72}} , lineColor = {0 ,0 ,0} ,
    textString = " R =\% R ") ,
  ...
  ));
end Resistor ;
```
Another example is the predefined annotation choices used to generate menus for the graphical user interface:

annotation ( choices ( choice =1 " P ", choice =2 " PI ", choice =3 " PID ") ) ;

The annotation Documentation is used for model documentation, as in this example for the Capacitor model:

```
annotation (
  Documentation ( info = " < HTML >
    <p >
     The linear capacitor connects the branch voltage <i >v </ i > with
         the
     branch current <i >i </ i > by <i > i = C * dv / dt </ i >.
     The Capacitance <i >C </ i > is allowed to be positive , zero , or
         negative.
    </p >
   </ HTML >
 )
```
The external function annotation arrayLayout can be used to explicitly give the layout of arrays, e.g., if it deviates from the defaults rowMajor and columnMajor order for the external languages C and Fortran 77 respectively.

This is one of the rare cases of an annotation influencing the simulation results, since the wrong array layout annotation obviously will have consequences for matrix computations. An example:

```
annotation ( arrayLayout = " columnMajor ") ;
```
#### **3.10.3 Naming Conventions**

You may have noticed a certain style of naming classes and variables in the examples in this chapter. In fact, certain naming conventions, described below, are being adhered to. These naming conventions have been adopted in the Modelica standard library, making the code more readable and somewhat reducing the risk for name conflicts. The naming conventions are largely followed in the examples in this book and are recommended for Modelica code in general:


For more details on naming conventions see the documentation inside the package.

#### **3.11 Modelica Standard Library**

Much of the power of modelling with Modelica comes from the ease of reusing model classes. Related classes in particular areas are grouped into packages to make them easier to find.

A special package, called Modelica, is a standardised predefined package that together with the Modelica Language is developed and maintained by the Modelica Association. This package is also known as the *Modelica Standard Library*, abbreviated MSL. It provides constants, types, connector classes, partial models, and model classes of components from various application areas, which are grouped into sub-packages of the Modelica package, known as the Modelica standard libraries.

The following is a subset of the growing set of Modelica standard libraries currently available:


Additional libraries are available in application areas such as thermodynamics, hydraulics, power systems, data communication, etc.

The Modelica Standard Library can be used freely under an open source license for both noncommercial and commercial purposes. The full documentation as well as the source code of these libraries appear at the Modelica web site.

So far the models presented have been constructed of components from single-application domains. However, one of the main advantages with Modelica is the ease of constructing multidomain models simply by connecting components from different application domain libraries. The DC (direct current) motor depicted in Figure 3.27 is one of the simplest examples illustrating this capability.

Fig. 3.27: A multidomain DCMotorCircuit model with mechanical, electrical, and signal block components.

This particular model contains components from the three domains, mechanical, electrical, and signal blocks, corresponding to the libraries Modelica.Mechanics, Modelica.Electrical, and Modelica.Blocks.

Model classes from libraries are particularly easy to use and combine when using a graphical model editor, as depicted in Figure 3.28, where the DC-motor model is being constructed. The left window shows theModelica.Mechanics.Rotational library, from which icons can be dragged and dropped into the central window when performing graphic design of the model.

Fig. 3.28: Graphical editing of an electrical DC-motor model, with part of the model component hierarchy at the right and icons of the Modelica standard library in the left window.

#### **3.12 Implementation and Execution of Modelica**

In order to gain a better understanding of how Modelica works it is useful to take a look at the typical process of translation and execution of a Modelica model, which is sketched in Figure 3.29. Note that this is the typical process used by most Modelica tools. There are alternative ways of executing Modelica, some of which are currently at the research stage, that often keep more of the object-oriented structure at the later stages of translation and execution.

First the Modelica source code is parsed and converted into an internal representation, usually an abstract syntax tree. This representation is analysed, type checking is done, classes are inherited and expanded, modifications and instantiations are performed, connect-equations are converted to standard equations, etc. The result of this analysis and translation process is a flat set of equations, constants, variables, and function definitions. No trace of the object-oriented structure remains apart from the dot notation within names.

After flattening, all of the equations are topologically sorted according to the data-flow dependencies between the equations. In the case of general differential algebraic equations (DAEs), this is not just sorting, but also manipulation of the equations to convert the coefficient matrix into block lower triangular form, a so-called BLT transformation. Then an optimiser module containing algebraic simplification algorithms, symbolic index reduction methods, etc., eliminates most equations, keeping only a minimal set that eventually will be solved numerically, see also the chapter in this book about numerical approximation methods.

Then independent equations in explicit form are converted to assignment statements. This is possible since the equations have been sorted and an execution order has been established for evaluation of the equations in conjunction with the iteration steps of the numeric solver. If a strongly connected set of equations appears, this set is transformed by a symbolic solver, which performs a number of algebraic transformations to simplify the dependencies between the variables. It can sometimes solve a system of differential equations if it has a symbolic solution. Finally, C code is generated, and linked with a numeric equation solver that solves the remaining, drastically reduced, equation system.

The approximations to initial values are taken from the model definition or are interactively specified by the user. If necessary, the user also specifies the parameter values. A numeric solver for differential-algebraic equations (or in simple cases for ordinary differential equations) computes the values of the variables during the specified simulation interval [*t0*, *t1*]. The result of the dynamic system simulation is a set of functions of time, such as R2.v(t) in the simple circuit model. Those functions can be displayed as graphs and/or saved in a file.

Fig. 3.29: The typical stages of translating and executing a Modelica model.

In most cases (but not always) the performance of generated simulation code (including the solver) is similar to handwritten C code. Often Modelica is more efficient than straightforwardly written C code, because additional opportunities for symbolic optimization are used by the system, compared to what a human programmer can manually handle.

#### **3.12.1 Hand Translation of the Simple Circuit Model**

Let us return once more to the simple circuit model, previously depicted in Figure 3.7, but for the reader's convenience also shown below in Figure 3.30. It is instructive to translate this model by hand, in order to understand the process.

Fig. 3.30: The SimpleCircuit model once more, with explicitly labeled connection nodes N1, N2, N3, N4, and wires 1 to 7.

Classes, instances and equations are translated into a flat set of equations, constants, and variables (see the equations in Table 3.1), according to the following rules:


The equation v=p.v-n.v is defined by the class TwoPin. The Resistor class inherits the TwoPin class, including this equation. The SimpleCircuit class contains a variable R1 of type Resistor. Therefore, we include this equation instantiated for R1 as R1.v=R1.p.v-R1.n.v into the system of equations.

The wire labeled 1 is represented in the model as connect(AC.p, R1.p). The variables AC.p and R1.p have type Pin. The variable v is a *potential* variable representing voltage potential. Therefore, the equality equation R1.p.v=AC.p.v is generated. Equality equations are always generated when potential variables are connected.

Notice that another wire (labeled 4) is attached to the same pin, R1.p. This is represented by an additional connect-equation: connect(R1.p.R2.p). The variable i is declared as a flow variable. Thus, the equation AC.p.i+R1.p.i+R2.p.i=0 is generated. Zero-sum equations are always generated when connecting flow variables, corresponding to Kirchhoff's second law.

The complete set of equations (see Table 3.1) generated from the SimpleCircuit class consists of 32 differentialalgebraic equations. These include 32 variables, as well as time and several parameters and constants.

3 Modelica: Equation-Based, Object-Oriented Modelling of Physical Systems 91


Table 3.1: The equations extracted from the simple circuit model–an implicit DAE system.

Table 3.2 gives the 32 variables in the system of equations, of which 30 are algebraic variables since their derivatives do not appear. Two variables, C.v and L.i, are dynamic variables since their derivatives occur in the equations. In this simple example the dynamic variables are state variables, since the DAE reduces to an ODE.


Table 3.2: The variables extracted from the simple circuit model.

#### **3.12.2 Transformation to State Space Form**

The implicit differential algebraic system of equations (DAE system) in Table 3.1 should be further transformed and simplified before applying a numerical solver. The next step is to identify the kind of variables in the DAE system. We have the following four groups:


For our simple circuit model these four groups of variables are the following:

*p* = { R1.R, R2.R, C.C, L.L, AC.VA, AC.f }

$$\mu = \{ \text{ און און } \}$$

*x* = { C.v, L.i }

*y* = { R1.p.i, R1.n.i, R1.p.v, R1.n.v, R1.v, R1.i, R2.p.i, R2.n.i, R2.p.v, R2.n.v, R2.v, R2.i, C.p.i, C.n.i, C.p.v, C.n.v, C.i, L.n.i, L.p.v, L.n.v, L.v, AC.p.i, AC.n.i, AC.p.v, AC.n.v, AC.i, AC.v, G.p.i, G.p.v }

We would like to express the problem as the smallest possible ordinary differential equation (ODE) system (in the general case a DAE system) and compute the values of all other variables from the solution of this minimal problem. The system of equations should preferably be in an explicit state space form as below.

$$
\dot{\mathbf{x}} = f(\mathbf{x}, t) \tag{3.12}
$$

That is, the derivative ˙*x* with respect to time of the state vector *x* is equal to a function of the state vector *x* and time. Using an iterative numerical solution method for this ordinary differential equation system, at each iteration step, the derivative of the state vector is computed from the state vector at the current point in time.

For the simple circuit model we have the following:

$$\dot{\mathbf{x}} = \{C.v., L.\dot{\mathbf{i}}\}, \boldsymbol{\mu} = \{AC.v\} \quad \text{(with constants: } \mathbf{R1.R, R2.R, C.C., L.\bot, \mathbf{AC.VA, AC.f, AC.P1})\tag{3.13}$$

$$
\dot{\mathbf{x}} = \langle \mathbf{der}(C.v), \mathbf{der}(L.i) \rangle \tag{3.14}
$$

#### **3.12.3 Solution Method**

We will use an iterative numerical solution method. First, assume that an estimated value of the state vector *x* = {*C*.v, *L*.*i*} is available at *t* = 0 when the simulation starts. Use a numerical approximation for the derivative *x*˙ (i.e. **der**(*x*)) at time *t*, e.g.:

$$\mathbf{d}\mathbf{e}(\mathbf{x}) = (\mathbf{x}\_{l+h} - \mathbf{x}\_l)/h \tag{3.15}$$

giving an approximation of *x* at time *t* + *h*:

$$\mathbf{x}\_{l+h} = \mathbf{x}\_l + \mathbf{der}(\mathbf{x}) \times h \tag{3.16}$$

In this way, the value of the state vector *x* is computed one step ahead in time for each iteration, provided der(x) can be computed at the current point in simulated time. However, the derivative der(x) of the state vector can be computed from ˙*x* = *f* (*x*, *t*) , i.e., by selecting the equations involving der(x), and algebraically extracting the variables in the vector *x* in terms of other variables, as below:

$$\mathbf{\dot{d}er}(C.\nu) = C.\mathbf{i}/C.C\tag{3.17}$$

$$\mathbf{der}(L.i) = L.\mathbf{v}/L.L\tag{3.18}$$

Other equations in the DAE system are needed to calculate the unknowns C.i and L.v in the above equations. Starting with C.i, using a number of different equations together with simple substitutions and algebraic manipulations, we derive equations (3.19) through (3.21) below.

*<sup>C</sup>*.*<sup>i</sup>* <sup>=</sup> *<sup>R</sup>*1.v/*R*1.*<sup>R</sup>* using: *<sup>C</sup>*.*<sup>i</sup>* <sup>=</sup> *<sup>C</sup>*.*p*.*<sup>i</sup>* <sup>=</sup> <sup>−</sup>*R*1.*n*.*<sup>i</sup>* <sup>=</sup> *<sup>R</sup>*1.*p*.*<sup>i</sup>* <sup>=</sup> *<sup>R</sup>*1.*<sup>i</sup>* <sup>=</sup> *<sup>R</sup>*1.v/*R*1.*<sup>R</sup>* (3.19)

$$\begin{aligned} R1. \nu &= R1. p. \nu - R1. n. \nu = R1. p. \nu - C. \nu\\ \text{using: } \quad R1. n. \nu &= C. p. \nu = C. \nu + C. n. \nu = C. \nu + A C. n. \nu = C. \nu + G. p. \nu = C. \nu + 0 = C. \nu \end{aligned} \quad (3.20)$$

3 Modelica: Equation-Based, Object-Oriented Modelling of Physical Systems 93

$$\begin{aligned} R1. p.\nu &= AC. p.\nu = AC. V A \* \sin(\mathcal{Q} \* AC. f \* AC. PI \* t) \\ \text{using: } &AC. p.\nu = AC. \nu + AC. n.\nu = AC. \nu + G. p.\nu = AC. V A \* \sin(\mathcal{Q} \* AC. f \* AC. PI \* t) + 0 \quad (3.21) \end{aligned}$$

In a similar fashion, we derive equations (3.22) and (3.23) below:

$$\begin{aligned} L.\nu &= L.p.\nu - L.n.\nu = R1.p.\nu - R2.\nu\\ \text{using: } L.p.\nu &= R2.n.\nu = R1.p.\nu - R2.\nu \text{ and } L.n.\nu = C.n.\nu = AC.n.\nu = G.p.\nu = 0 \quad (3.22) \end{aligned}$$

*R*2.v = *R*2.*R* × *L*.*p*.*i* using: *R*2.v = *R*2.*R* × *R*2.*i* = *R*2.*R* × *R*2.*p*.*i* = *R*2.*R* × (−*R*2.*n*.*i*) = *R*2.*R* × *L*.*p*.*i* = *R*2.*R* × *L*.*i* (3.23)

Collecting the five equations together:

$$\begin{aligned} C.i &= R1.\upsilon/R1.R \\ R1.\upsilon &= R1.p.\upsilon - C.\upsilon \\ R1.p.\upsilon &= AC.VA \times \sin(2 \times AC.f \times AC.PI \times t) \\ L.\upsilon &= R1.p.\upsilon - R2.\upsilon \\ R2.\upsilon &= R2.R \times L.i \end{aligned}$$

By sorting the equations Eqs. 3.24 in data-dependency order, and converting the equations to assignment statements–this is possible since all variable values can now be computed in order–we arrive at the following set of assignment statements to be computed at each iteration, given values of C.v, L.i, and t at the same iteration:

```
R2.v := R2.R * L.i ;
R1.p.v := AC.VA * sin (2 * AC.f * AC.PI * time ) ;
L.v := R1.p.v - R2.v ;
R1.v := R1.p.v - C.v ;
C.i := R1.v / R1.R ;
der( L.i ) := L.v / L.L ;
der( C.v ) := C.i / C.C ;
```
These assignment statements can be subsequently converted to code in some programming language, e.g., C, and executed together with an appropriate ODE solver, usually using better approximations to derivatives and more sophisticated forward-stepping schemes than the simple method described above, which, by the way, is called the *Euler integration* method. The algebraic transformations and sorting procedure that we somewhat painfully performed by hand on the simple circuit example can be performed completely automatically, and is known as *BLT partitioning*, i.e., conversion of the equation system coefficient matrix into block lower triangular form (Table 3.3).


Table 3.3: TBlock lower triangular form of the SimpleCircuit example.

The remaining 26 algebraic variables in the equation system of the simple circuit model that are not part of the minimal 7-variable kernel ODE system solved above can be computed at leisure for those iterations where their values are desired–this is not necessary for solving the kernel ODE system.

It should be emphasised that the simple circuit example is trivial. Realistic simulation models often contain tens of thousands of equations, nonlinear equations, hybrid models, etc. The symbolic transformations and reductions of equation systems performed by a real Modelica compiler are much more complicated than what has been shown in this example, e.g., including index reduction of equations and tearing of subsystems of equations.

simulate(SimpleCircuit,stopTime=5)]

plot(C.v, xrange={0,5})

Fig. 3.31: Simulation of the SimpleCircuit model with a plot of the voltage C.v over the capacitor.

#### **3.13 Tool Interoperability through Functional Mockup Interface**

Even though Modelica is a universal modelling language that covers most application domains, there exist many established existing modelling and simulation tools in various application domains. There is a strong industrial need for interoperability and model interchange between tools. The Functional Mockup Interface standard (FMI, www.fmi-standard.org) has been developed to fulfil this need. It allows exporting models compiled into C-code combined with XML-based descriptors, which can be imported and simulated in other tools, both Modelica and non-Modelica tools. The standard also supports co-simulation between tools, and is already supported by a number of tool vendors.

#### **3.14 Summary**

This chapter has given a quick overview of the most important concepts and language constructs in Modelica. We have also defined important concepts such as object oriented mathematical modelling and acausal physical modelling, and briefly presented the concepts and Modelica language constructs for defining components, connections, and connectors. The chapter concludes with an in-depth example of the translation and execution of a simple model.

#### **3.15 Literature and Further Reading**

This chapter has given a short introduction to Modelica and equation-based modelling. A much more complete presentation of Modelica together with applications and the technology behind Modelica simulation tools can be found in [13].

The recent history of mathematical modelling languages is described in some detail in[14], whereas bits and pieces of the ancient human history of the invention and use of equations can be found in [122], and the picture on Newton's second law in latin in [144]. Early work on combined continuous/discrete simulation is described in [233] followed by [65]. A very comprehensive overview of numeric and symbolic methods for simulation is available in [68]. This author's first simulation work involving solution of the Schrödinger equation for a particular case is described in [113].

Current versions of several Modelica tools are described at www.modelica.org, including OpenModelica, Wolfram SystemModeler (before 2012 called MathModelica), and Dymola meaning the Dynamic modelling Laboratory. Several of the predecessors of the Modelica language are described in the following publications including Dymola meaning the Dynamic modelling Language [88, 89], Omola [203, 9], ObjectMath [119, 299, 120], NMF [248], Smile [93], etc.

Speed-Up, the earliest equation-based simulation tool, is presented in [251], whereas Simula-67–the first object-oriented programming language–is described in [35]. The early CSSL language specification is described in [258] whereas the ACSL system is described in [209]. The Hibliz system for an hierarchical graphical approach to modelling is presented in [89]. Software component systems are presented in [12, 260].

The Simulink system for block oriented modelling is described in [201], whereas the MATLAB language and tool are described in [202].

The DrModelica electronic notebook with the examples and exercises from this book has been inspired by DrScheme [102] and DrJava [8], as well as by Mathematica [306], a related electronic book for teaching mathematics [80], and the MathModelica (in 2012 renamed to Wolfram SystemModeler) environment [117, 229, 110]. The first version of DrModelica is described in [185, 186].

The OpenModelica version of notebook called OMNotebook is described in [103, 11]. Applications and extensions of this notebook concept are presented in [250, 210, 271].

General Modelica articles and books: [204, 117, 90], a series of 17 articles (in German) of which [225](Otter 1999) is the first, [270, 114, 91, 107, 111, 112].

The proceedings from the following conferences, as well as several conferences not listed here, which contain a number of Modelica related papers: the International Modelica Conference: [105, 226, 106, 255, 172, 18, 64, 75] and the Equation-Based Object-Oriented Languages and Tools (EOOLT) workshop series: [116, 115, 118, 66, 217]. the Scandinavian Simulation Conference, e.g.: [104] and some later conferences in that series, two special conferences with focus on biomedical [109] and safety issues [108], respectively.

#### **3.16 Self-assessment**

1. Create a class Add that calculates the sum of two parameters, which are Integer numbers with given values.

2. Create an instance of class Dog that overrides the default name with "Timmy"

```
class Dog
  constant Real legs = 4;
  parameter String name = " Scott ";
end Dog ;
```

```
record Bicycle
  Boolean hasWheels = true ;
  Integer nrOfWheels = 2;
end
```
Define a record ChildrensBike that inherits from the class Bicycle and is meant for kids. Give the variables values.

5. Write a class, Birthyear, which calculates the year of birth from this year together with a person's age. Point out the declaration equations and the normal equations. Write an instance of the class Birthyear above. The class, let's call it MartinsBirthyear, shall calculate Martin's year of birth, call the variable martinsBirthyear, who is a 29-year-old. Point out the modification equation. Check your answer, e.g. by writing as below:7

```
val ( martinsBirthday.birthYear ,0)
```
6. Consider the class Ptest below:

```
class Ptest
  parameter Real x ;
  parameter Real y ;
  Real z ;
  Real w ;
equation
    x + y = z ;
end Ptest ;
```
What is wrong with this class? Is there something missing?

7. Create the class Average that calculates the average between two integers, using an algorithm section. Make an instance of the class and send in some values. Simulate and then test the result of the instance class by writing:

```
instanceVariable.classVariable.
```

#### **Acknowledgements**

This work has been supported by Vinnova in the ITEA3 OPENCPS project and in the RTISIM project. Support from the Swedish Government has been received from the ELLIIT project, as well as from the European Union in the H2020 INTO-CPS project. The OpenModelica development is supported by the Open Source Modelica Consortium.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

<sup>7</sup> In OpenModelica, the expression val(martinsBirthday.birthYear,0) means the birthYear value at time=0, at the beginning of the simulation. Interpolated values at other simulated time points can also be obtained. Constant expressions such as 33+5, and function calls, can also be evaluated interactively.

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

## **Chapter 4 Causal-Block Diagrams: A Family of Languages for Causal Modelling of Cyber-Physical Systems**

Cláudio Gomes, Joachim Denil, and Hans Vangheluwe

**Abstract** The description of a complex system in terms of constituent components and their interaction is one of the most natural and intuitive ways of decomposition. Causal Block Diagram (CBD) models combine subsystem blocks in a network of relationships between input signals and output signals. Popular modelling and simulation tools such as Matlab/Simulink® implement different variants from the family of Causal Block Diagram formalisms. This chapter gives an overview of modelling and simulation of systems with software and physical components using Causal Block Diagrams. It describes the syntax and - both declarative and operational - semantics of CBDs incrementally. Starting from simple algebraic models (no notion of time), we introduce, first a discrete notion of time (leading to discrete-time CBDs) and subsequently, a continuous notion of time (leading to continuous-time CBDs). Each new variant builds on the previous ones. Because of the heavy dependency of CBDs on numerical techniques, we give an intuitive introduction to this important field, pointing out main solutions as well as pitfalls.

#### **Learning Objectives**

After reading this chapter, we expect you to be able to:


#### **4.1 Introduction**

The design process of complex systems, aided by the technology advances in the last century, is rapidly shifting from small scale development of isolated systems, to large scale development of integrated systems [15].

The graphical representation of such systems using blocks and arrows is one of the first methods used to represent systems. One of the benefits of this notation is that complex systems can be hierarchically decomposed

Joachim Denil Flanders Make, Belgium e-mail: joachim.denil@uantwerp.be

Hans Vangheluwe McGill University, Canada e-mail: hans.vangheluwe@uantwerp.be

Cláudio Gomes University of Antwerp, Belgium e-mail: claudio.gomes@uantwerp.be

into sub-systems, thus providing a way to deal with complexity. Causal Block Diagrams (CBD) is a formalisation of this intuitive graphical notation.

Originally, CBDs were used to represent and simulate analog circuits [15, 280, 28, 128], with the most commonly used blocks illustrated in Table 4.1. Nowadays, this formalism is widely used in the modelling and simulation of systems that comprise a physical and a controller component, as depicted in Figure 4.1.

In this kind of system, the controller, often implemented in software, monitors the activity of physical processes by means of sensors, takes appropriate decisions, and influences the physical processes through actuators. This architecture can be generalised to networked software and many other processes, not necessarily physical. Examples include cruise controllers, thermostats, robotic arms, and insulin pumps.

For the purposes of introducing the CBD formalism, we hold on to the traditional view of a physical process being controlled by a software component, also known as a feedback control system [16].


Table 4.1: Block representation for analog circuits. Reproduced from [45].

Fig. 4.1: Generic embedded system structure.

In the next section, a simple running example will be introduced, as well as some necessary background concepts. In the remaining sections, CBDs are introduced gradually in three different flavors: algebraic, discrete time, and continuous time CBDs. These are distinguished by the class of blocks at the disposal of the modeler. The gradual presentation allows for a deeper understanding of all the concepts related to modelling and simulation of CBDs. The last few sections of the chapter deal with advanced concepts, related to the simulation of CBDs.

#### **4.2 Background**

A dynamical system is characterised by a state and a notion of evolution rules. The state is a set of point values in a state space. The evolution rules describe how the state evolves over an independent variable, usually time.

The domain of the time variable dictates the kind of dynamical system: if time ranges over a continuous set, usually R, then the dynamical system is continuous time; if time ranges over a countable set, usually N, then the dynamical system is discrete time.

#### **Cruise Control System**

Fig. 4.2: Cruise control system.

Consider the cruise control system depicted in Figure 4.2. The car is a dynamical system whose state (e.g., the velocity) evolves continuously in time. The state of software controller, on the other hand, evolves discretely through time, as any software variable does, by consequence of assignment instructions.

The system in Figure 4.2 is an example of a feedback control system: the physical system – the car – is actuated by control inputs generated by control software – the cruise controller. The sensors are the tachometers that translate wheel revolutions per minute into instantaneous velocity. The actuators are the motor throttle and brakes. The cruise controller software decides, based on current speed of the car, which amount of thrust (throttle or brakes) should be applied to restore the car to a desired speed despite drag, weight, and other factors.

Obviously, it is not desirable to wait for a car prototype to be built, in order to test the control software. This motivates the use of two dynamical systems: *(a)* A continuous dynamical system which acts as a mock-up of a real car, and *(b)* A discrete time dynamical system which acts as a mock-up of the software unit.

With these models, early evaluation of many different control strategies can be performed, at a much lower cost. Furthermore, the chosen controller model can then be used to automatically generate the software code.

#### **4.2.1 Models of Physical Systems**

Physical systems are inherently continuous: their state evolves continuously through time. Ordinary Differential Equations (ODE) describe how physical quantities change continuously in time, and are thus ideal models to describe the behaviour of physical systems. Initial value problems are ODEs that have a constraint on the initial state. Together with the ODEs, extra equations can be added to represent the outputs of the system. Formally, we consider models of the form:

$$\begin{aligned} \mathbf{x}'(t) &= F(\mathbf{x}, \boldsymbol{\mu}, t), \\ \mathbf{y}(t) &= G(\mathbf{x}, \boldsymbol{\mu}, t), \\ \mathbf{x}(0) &= \mathbf{x}\_0, \end{aligned} \tag{4.1}$$

where *x*(*t*), *x* 0 (*t*), <sup>y</sup>(*t*), *<sup>u</sup>*(*t*) are vectors, *<sup>x</sup>*(*t*) <sup>=</sup> [*x*1(*t*), . . . , *<sup>x</sup>*<sup>n</sup> (*t*)] T represents the state vector, *u*(*t*) represents the input, and *x*<sup>0</sup> is the initial state. The state here denotes the minimal information required to determine, together with the input *u*(*t*) and function *F*(*x*, *u*, *t*), the complete future states of the system. Function *G* is the output function.

#### **Dynamic behavior model**

A possible model of the dynamic behavior of the car, to be used in the design of the cruise controller in the Cruise Controller example is:

$$\begin{aligned} \nu' &= \frac{1}{m} \left( T - k \nu \right) \\ \nu &= \nu \end{aligned} \tag{4.2}$$

where v is the velocity, v 0 , *T* is the thrust force and *k* depends on the air density and car shape. This model assumes that the car moves in a straight line and neglects any effects that gravity might induce. Reasonable assumptions for early experimentation.

#### **4.2.2 Discrete Time Models**

While the solution of ODEs is continuous, the state of the software unit, in the cruise control system presented in Example 4.2, can only evolve discretely, by the nature of the digital computer on which it runs. For mathematical treatment (e.g., proving that the cruise controller is correct), differential equations may be used for an early specification of the control software. However, when it comes to simulating those models in a digital computer, the only available option is to use discrete time models.

First order difference equations, and a constraint on their initial state, allow the specification of such models. They take the form

$$\begin{aligned} \mathbf{x}^{\{s+1\}} &= F(\mathbf{x}^{\{s\}}, \mathbf{u}^{\{s+1\}}), \\ \mathbf{y}^{\{s\}} &= G(\mathbf{x}^{\{s\}}, \mathbf{u}^{\{s\}}), \\ \mathbf{x}^{\{0\}} &= \mathbf{x}\_0, \end{aligned} \tag{4.3}$$

where *s* denotes the step, *x* [s] is the state vector at step *s*, *u* [s+1] is the input vector, y [s] the output vector, and *x*<sup>0</sup> the initial value of the state vector. The new vector *x* [s+1] is computed from the old one *x* [s] and input *u* [s+1] , according to the specification function *F*. The output function *G* allows values to be read from the dynamical system. The repeated application of functions *F* and *G* yields the discrete evolution of the state and output vectors. Difference equations are sometimes written as

$$\begin{aligned} x^{[s]} &= F(x^{[s-1]}, \mu^{[s]}) \\ y^{[s]} &= G(x^{[s]}, \mu^{[s]}) \\ x^{(0)} &= x\_0. \end{aligned}$$

#### **4.2.2.1 Discrete Control Systems**

#### **Software Controller**

The cruise control software can be described by the following difference equation:

#### 4 Causal-Block Diagrams 101

$$e^{\{s+1\}} = e^{\{s\}} + h\left(\nu\_{\mathcal{A}}^{\{s+1\}} - \nu^{\{s+1\}}\right)$$

$$\begin{cases} \mathbf{I} = \mathbf{c} & \mathbf{u} \in \left( \mathbf{v}\_d - \mathbf{v} \right) \\ \mathbf{T}^{\{s\}} = K\_p \left( \mathbf{v}\_d^{\{s\}} - \mathbf{v}^{\{s\}} \right) + K\_l \mathbf{e}^{\{s\}} \end{cases} \tag{4.4}$$

where v<sup>d</sup> is the velocity that the car should be kept at (input); v is the actual velocity (input) of the car; v [s+1] d − v [s+1] is the instantaneous error; *e* [s] denotes the accumulated error (state); *T* [s] is the thrust force to be transmitted to the car (output). Finally, *K*<sup>p</sup> and *K*<sup>i</sup> are constant parameters of the controller.

The controller in Example 4.2.2.1 gets the car velocity input v [s] from the readings of the tachometer (recall Figure 4.2). If the differential equation Eq. 4.2 is used to model the car, then v(*t*) is a continuous quantity and so we can relate it to the input of the controller by v [s] = v(*s* × ∆*t*), where ∆*t* denotes the constant interval of time between two successive tachometer readings. From now on, assume that Eq. 4.2 is coupled to Eq. 4.4 in this manner.

Intuitively, the thrust force *T* [s] is proportional to the instantaneous error v [s] d − v [s] and to the accumulation of errors *e* [s] from previous steps.

The following two paragraphs give an intuitive rationale for each component of Eq. 4.4.

*K*<sup>p</sup> v [s] d − v [s] component.

When the instantaneous error is large, the current velocity is far away from the desired one, so the thrust force should be large in order to ensure that the car quickly accelerates/brakes toward the desired speed. When the instantaneous error is small, the car is almost at the desired speed, so the thrust force should be smaller to avoid causing discomfort to the driver. For now, neglect the *K*<sup>i</sup> *e* [s] component in the thrust force calculation. After a while, if the thrust force given by *T* [s] = *K*<sup>p</sup> v [s] d − v [s] becomes symmetric (same magnitude, opposite direction) with the drag force in Eq. 4.2, the car acceleration will be null and its speed will be kept constant. However, that speed will not be exactly equal to the desired speed, because −*k*v , 0 =⇒ v [s] d − v [s] , 0. This is where the *K*<sup>i</sup> *e* [s] component, neglected until now, has its use.

#### *K*<sup>i</sup> *e* [s] component.

This component accumulates the instantaneous error over time, and contributes to the thrust force accordingly. Suppose that the thrust force is counteracted by the drag force and the car is kept at a constant speed, below the desired velocity, just like in the previous paragraph. Then, the accumulated error will keep growing, ensuring that the second component continues to increase the thrust force until it overcomes the drag force. Notice that this might cause the car to overshoot the desired speed, which can be dangerous. The accumulated error will start decreasing once that happens, decreasing the thrust force. The choice of parameters *K*<sup>p</sup> and *K*<sup>i</sup> is an important part of tuning the controller.

#### **4.2.2.2 Discretisation of Differential Equations**

The example introduced in this section represents a typical feedback control system, the majority of which are developed using CBDs. In the following sections it will become clear how this is achieved.

#### **4.3 Algebraic Causal Block Diagrams**

Algebraic CBDs are CBDs where the only atomic blocks permitted are algebraic ones: summation, negation, inversion, product, raise to power and roots. These can be used to represent systems where there is no notion of time and no evolving state. In other words, the time is a constant: *now*.

While it may seem restricted, these kind of systems arise in the study of the steady state behaviour of dynamic systems, and are used to represent algebraic functions.

#### **Steady State**

Consider the car dynamics in Eq. 4.2. The steady state behaviour of the car happens when it is not accelerating. That is, for known constants *T*, *k*:

$$0 = \frac{1}{m} \left( T - k\nu \right)$$

The equation gives insight about the torque required to keep the car at the same speed: *T* = *k*v. The larger the drag force, the larger the torque, and the more energy is required.

#### **4.3.1 Syntax**

The main constituents of a CBD are blocks and connections between blocks. Blocks can be atomic or composite. Composite blocks stand for an external CBD, specified elsewhere. These blocks will be drawn with a dashed contour. In algebraic CBDs, atomic blocks can be summation, negation, inversion, product, raise to power, and roots. These will be denoted with the appropriate mathematical symbol.

Since a block can have more than one input and more than one output, the notion of ports is essential to distinguish between inputs and between outputs. Atomic blocks have up to two input ports - depending on the operation - and one output port. Composite blocks can have any number of input and output ports.

Figure 4.3a shows an example of an Algebraic CBD, that calculates the drag force *d* affecting a car, as it moves with a velocity v, given as input. The composite block *c* refers to a CBD that calculates the drag coefficient, detailed in Figure 4.3b.

Fig. 4.3: Example Algebraic CBDs.

The ports associated with a block will not be drawn explicitly but they are part of the CBD and have identifiers (ids). The directed connections will make clear which input ports and output ports are associated with a block. When there is a need, the input port id is shown at the border of the associated block. In the specification of a composite block, the input and output ports are represented as triangles. Whether the port is input or output is clear from the context.

Blocks are also referred to by ids. The id of a port is comprised of the name of the port, and the id of the parent block. The id of a block is formed by its name, along with the id of its parent CBD. Note the recursive definition. While the id is almost never visible in the graphic representation, it is always defined.

Some of the uses of ids are: the unambiguous description of connections between ports and the unambiguous identification of individual blocks after the flattening process (Section 4.3.2).

More often, the names of the blocks will be depicted in the graphical representations, to enhance their readability. Names are not ids, they are a part of the id. For instance, the product blocks in Figure 4.3a have two ports with distinct ids, even though these are not depicted in the graphical representation. In the same picture, the name v of the input and the name *d* of the output port are shown. Similarly, the name *c* of the composite block is shown. Notice that in Figure 4.3b the same name *c* also denotes the output port. There is no ambiguity as the composite block and the output port have distinct ids, even though they have the same name.

Whenever a composite block is used, all its internal blocks adopt different ids, based on the id of the CBD where the composite block is used. For instance, the fact that the composite block *c* is used in the CBD of Figure 4.3a means that, when processing that CBD, the ids of the inner blocks/ports of *c* (detailed in Figure 4.3b) include the id of *c*. This has two important consequences:


#### **4.3.2 Semantics**

The meaning of an algebraic CBD is an association of a value to each of the ports in the CBD. It can be conveyed in two general ways: by writing the mathematical equations that correspond to the CBD (translational semantics), or by giving an algorithm which computes the value associated with each input/output port (operational semantics).

To simplify both these approaches, it is assumed that all composite blocks are replaced by their specification in a *flattening* process. This process is done recursively until all composite blocks have been replaced by their specification [232]. The following aspects are important to ensure the well-formedness of the flattened CBD:


Figure 4.4 shows the result of replacing the composite block *c* with its specification (in Figure 4.3b). The ids, shown explicitly in the picture, contain the ids of the composite block replaced. During the process, the port *c* of the composite block became redundant and thus was removed.

The meaning of a flattened CBD is the same as the original CBD. Every block/port has a unique id and every connection is between ports. The semantics of CBDs can be thus explained assuming they have been flattened.

#### **4.3.2.1 Translational Semantics**

Given a flattened algebraic CBD, the equations that it represents can be written down using the rules shown in Table 4.2.

The system of equations that results from applying the following rules to each port, block and connection, of an algebraic CBD, can then be solved for the unknowns to get the values associated with each port in the CBD. The flattened algebraic CBD depicted in Figure 4.4 is translated into the following set of algebraic equations:

	- a. If the block is a constant with value c, then it has no input ports and the resulting equation is var(q) = c;
	- b. If it is a summation, then the resulting equation is var(q) = var(p1) + var(p2);
	- c. If it is a product, then the resulting equation is var(q) = var(p1) × var(p2);
	- d. If it is a negation, then the resulting equation is var(q) = −var(p1); 1 ;
	- e. If it is an inversion, the resulting equation is var(q) = var(p<sup>1</sup> )
	- f. If it is a raise-to-power, the resulting equation is var(q) = var(p1) var(p<sup>2</sup> ) ; 1
	- g. If it is a root, the resulting equation is var(q) = var(p1) var(p2 ) ;

var(v) = var(*b*1.*i*1) var(v) = var(*b*1.*i*2) var(*b*1.*o*1) = var(*b*2.*i*1) var(*b*2.*o*1) = var(*d*) var(*c*.*b*3.*o*1) = var(*b*2.*i*2) var(*c*.*C*d.*o*1) = var(*c*.*b*1.*i*1) var(*c*.*b*1.*o*1) = var(*c*.*b*2.*i*1) var(*c*.*p*.*o*1) = var(*c*.*b*1.*i*2) var(*c*.*A*.*o*1) = var(*c*.*b*2.*i*2) var(*c*.*b*2.*o*1) = var(*c*.*b*3.*i*1) var(*c*.*b*3.*o*1) = var(*c*.*b*4.*i*1) var(*c*.*b*4.*o*1) = var(*c*.*b*3.*i*2) var(*c*.*C*d.*o*1) = *C*<sup>d</sup>

$$\begin{aligned} \text{var}(b\_1.o\_1) &= \text{var}(b\_1.i\_1) \times \text{var}(b\_1.i\_2) \\ \text{var}(b\_2.o\_1) &= \text{var}(b\_2.i\_1) \times \text{var}(b\_2.i\_2) \\ \text{var}(c.p.o\_1) &= p \\ \text{var}(c.b\_1.o\_1) &= \text{var}(c.b\_1.i\_1) \times \text{var}(c.b\_1.i\_2) \\ \text{var}(c.A.o\_1) &= A \\ \text{var}(c.b\_2.o\_1) &= \text{var}(c.b\_2.i\_1) \times \text{var}(c.b\_2.i\_2) \\ \text{var}(c.b\_3.o\_1) &= \text{var}(c.b\_3.i\_1) + \text{var}(c.b\_3.i\_2) \\ \text{var}(c.b\_4.o\_1) &= -\text{var}(c.b\_4.i\_1) \end{aligned} \tag{4.5}$$

The system in Eq. 4.5 can be simplified to a quadratic drag force var(*b*2.*o*1) = var(v) <sup>2</sup> × 1 2 × *C*<sup>d</sup> × *p* × *A*, where *p* is the air density, *C*<sup>D</sup> the drag coefficient, and *A* the cross sectional area of the car. Obviously, the value of the input port v has to be known in order to solve for the value of the output port *b*2.*o*1.

Any system of algebraic equations that uses operations supported by the atomic blocks of algebraic CBDs can be represented as an algebraic CBD. The CBD in Figure 4.3b can be drawn directly from the equation

$$c = C\_D \times p \times A - c \tag{4.6}$$

where *c* is the output, and *C*D, *A*, *p* constants.

#### **4.3.2.2 Operational Semantics**

Instead of deferring the responsibility of computing the values associated with each port, to an equation solver, it is possible to do so directly. Two such algorithms are presented.

Algorithm 1 presents the dataflow version of the operational semantics. A list of atomic blocks to be computed is revisited iteratively until no blocks remain. A block can be computed only after all the blocks it depends on have been computed. The algorithm terminates after O((#atomic blocks in *D*) 2 ) iterations.

The inefficiency of this algorithm lies in not taking advantage of the dependencies between blocks to come up with an optimal execution order for blocks. An improved algorithm will be presented later, after formalizing the dependency information between blocks.

```
Algorithm 1 Data-flow algorithm to evaluate an Algebraic CBD D.
```

```
function EvalAlgebraicCBD(D, v1, . . . , vn)
   Let val(p) be the computed value associated with port identified by p.
   Let i1, . . . , in be the ids of the input ports associated with the CBD D.
   Let o1, . . . , om be the ids of the output ports associated with the CBD D.
   Then, val(i1) := v1, . . . , val(in ) := vn are the values associated with each input ports of D.
   Let B denote the set of atomic blocks of D not yet computed.
   Initially, B := all atomic blocks in D.
   while B , { } do
       for bi ∈ B do
           Let p denote the single output port of bi
                                                     .
           Let P = {p1, p2, . . .} denote the inputs ports of bi
                                                                .
           Let Q = {q1, q2, . . .} denote the output ports connected to each input port pj ∈ P, respectively.
           Let B = block(q1)∪block(q2)∪. . . be the set of blocks that bi depends on, where block(qj ) is the block associated
with port qj or the empty set, if no such block exists.
           if B ∩ B = { } then
               Remark: val(q1), val(q2), . . . have been computed before.
               val(p) :=ComputeBlock(bi
                                             , val(q1), val(q2), . . .)
               Let P = {ρ1, ρ2, . . .} be the set of ports to which port p connects to.
               val(ρj ) := val(p), for ρ1 ∈ P
               B := B\ {bi }
           end if
       end for
   end while
   P = { }
   return val(o1), . . . , val(om )
end function
function ComputeBlock(b, val(q1), val(q2), . . .)
   if b is a summation block then
       return val(q1) + val(q2)
   end if
   if b is a Constant Block with value v then
       return v
   end if
   . . .
end function
```
The advantage of Algorithm 1 is its simplicity. It represents the execution model of the dataflow paradigm and, provided that no algebraic loops exist, it always finds the values associated with every port of a flattened CBD.

An algebraic loop arises when a block depends indirectly on itself. It is thus natural to think of the CBD in terms of a dependency graph and identify the cycles thereof. In the CBD of Figure 4.4, blocks *c*.*b*<sup>4</sup> and *c*.*b*<sup>3</sup> are part of one algebraic loop. Algebraic loops also happen in algebraic systems of equations. For example, in Eq. 4.6, the *c* variable depends on itself.

Both these loops where introduced artificially for the purposes of illustration. They can easily be removed by reformulating the mathematical expression that the CBD represents. However, in general, not all algebraic loops can be removed by this method and a way to detect them is required.

Given a flattened CBD, its corresponding dependency graph can be created applying the rules in Table 4.3. For example, Figure 4.5 shows the dependency graph of the flattened CBD shown in Figure 4.4.

Table 4.3: Rules for constructing the dependency graph.


Fig. 4.5: Dependency graph and strong components.

The dependency graph makes the detection of algebraic loops a simple matter of detecting the strong components in the graph. Formally, a strong component *<sup>S</sup>* <sup>=</sup> {*n*1, *<sup>n</sup>*2, . . .} of a graph *<sup>G</sup>* is a set of nodes where, between every *n*<sup>i</sup> , *n*<sup>j</sup> ∈ *S*, there are two different paths: *p*<sup>1</sup> : *n*<sup>i</sup> <sup>∗</sup><sup>⇒</sup> *<sup>n</sup>*<sup>j</sup> and *<sup>p</sup>*<sup>2</sup> : *<sup>n</sup>*<sup>j</sup> <sup>∗</sup><sup>⇒</sup> *<sup>n</sup>*<sup>i</sup> . This implies that every node in a strong component is either the only node in that strong component, or depends on itself, through some other node, also in the same strong component. Figure 4.5 illustrates the strong components of the dependency graph. As expected, the blocks *c*.*b*<sup>4</sup> and *c*.*b*<sup>3</sup> are part of the same strong component.

Tarjan's algorithm [262] accepts a graph and outputs a sorted list of strong components. The sort order of the strong components is a topological order according to the dependencies between strong components. For the example in Figure 4.5, one possible topological order is:

$$\left( \left\{ c.C\_{D} \right\}, \left\{ c.p \right\}, \left\{ c.A \right\}, \left\{ c.b1 \right\}, \left\{ c.b2 \right\}, \left\{ c.b3, c.b4 \right\}, \left\{ b\_{1} \right\}, \left\{ b\_{2} \right\} \right)$$

If no algebraic loops exist in the flattened graph, then the sorted list of strong components returned by the algorithm is just the topological sort of the nodes in dependency graph. In this list, a singleton strong component always appears after the nodes it depends on.

In the case where algebraic loops exist, all nodes belonging to the same algebraic loop will be in the same strong component. Regarding the sort order, non-singleton strong components appear after all components on which it depends on. A strong component depends on other if any one of its comprising nodes depends on at least one of the other's nodes.

These two facts about the sorted strong component list, given by Tarjan's algorithm [262], provide a basis for an improved algebraic CBD operational semantics, that not only can compute the values associated with all output ports much faster than Algorithm 1, but also detects algebraic loops. Algorithm 2 summarizes the steps for computing the values of all ports of a flattened CBD, under the improved algorithm.


The SolveLoop function computes the values of all unknown ports (whose value is unknown) associated with the blocks in the loop. A input port is unknown when an unknown output port is connected to it. An output port is unknown when the block it is associated with belongs to the strong component. Equivalently, an input port is known when a known output port is connected to it. A known output port is associated with a block that does not belong to the strong component.

Essentially, solving an algebraic loop amounts to computing the solution of a matrix equation of the form *X* = *F*(*X*,*U*):

$$\underbrace{\begin{bmatrix} \text{val}(p\_1) \\ \text{val}(p\_2) \\ \dots \\ \text{X} \end{bmatrix}}\_{\text{X}} \underbrace{\begin{bmatrix} F\_1(\text{val}(p\_1), \text{val}(p\_2), \dots, \text{val}(\bar{q}\_1^{(1)}), \text{val}(\bar{q}\_2^{(1)}), \dots, \text{val}(\bar{q}\_1^{(2)}), \dots) \\ F\_2(\text{val}(p\_1), \text{val}(p\_2), \dots, \text{val}(\bar{q}\_1^{(1)}), \text{val}(\bar{q}\_2^{(1)}), \dots, \text{val}(\bar{q}\_1^{(2)}), \dots) \end{bmatrix}}\_{F(\text{X},\text{U})} \tag{4.7}$$

Where *X* = - val(*p*1), val(*p*2), . . .<sup>T</sup> denotes the unknown values of the output ports of the strong component, and *U* = f val(*q*¯ (1) 1 ), val(*q*¯ (1) 2 ), . . . , val(*q*¯ (2) 1 ), . . .gT denote the known values of the input ports.

In Eq. 4.7, the unknown input ports are not considered because these depend directly, by algebraic equality, on the output ports connected to them. So finding the values of the unknown output ports is enough to be able to find the values of all unknown ports of the strong component.

The definition of *F* depends on the atomic blocks that belong to the strong component. If *F* is linear, then the above equation can be written in the form *AX* = *BU* and solved with any technique suitable to solve linear systems of equations (see [60, Chapter 6&7]). Matrices *A* and *B* depend on the blocks in the strong component, and the product *BU* is known.

If *F* is non-linear, successive substitution techniques ((see [60, Chapter 10])) can be used in an attempt to find *X*.

Caution has to be taken when non-linear loops are solved, as they might not have a solution, or a unique solution. The iterative methods require initial guess values to be provided for *X*, and depending on those initial guesses, different solutions might be attained. Both the initial guesses, and the solutions attained have to be physically meaningful, as the equations often represent the characteristics of physical systems (e.g., drag forces, concentrations, etc. . . ).

For the algebraic loop containing bocks *c*.*b*<sup>4</sup> and *c*.*b*<sup>3</sup> in Figure 4.5, the resulting linear system of equations and its analytical solution is:

$$\begin{cases} \text{val}(c.b\_3.o\_1) = \text{val}(c.b\_3.i\_1) + \text{val}(c.b\_3.i\_2) \\ \text{val}(c.b\_3.i\_2) = \text{val}(c.b\_4.o\_1) \\ \text{val}(c.b\_4.o\_1) = -\text{val}(c.b\_4.i\_1) \\ \text{val}(c.b\_4.i\_1) = \text{val}(c.b\_3.o\_1) \end{cases} \leftrightarrow$$

$$\begin{cases} \text{val}(c.b\_3.o\_1) - \text{val}(c.b\_4.o\_1) = \text{val}(c.b\_3.i\_1) \\ \text{val}(c.b\_3.o\_1) + \text{val}(c.b\_4.o\_1) = 0 \end{cases} \leftrightarrow$$

$$\underbrace{\begin{bmatrix} 1 - 1 \\ 1 \end{bmatrix}}\_A \underbrace{\begin{bmatrix} \text{val}(c.b\_3.o\_1) \\ \text{val}(c.b\_4.o\_1) \end{bmatrix}}\_X = \underbrace{\begin{bmatrix} 1 \\ 0 \end{bmatrix}}\_B \underbrace{\begin{bmatrix} \text{val}(c.b\_3.i\_1) \\ \text{val}(c.b\_3.i\_1) \end{bmatrix}}\_U \leftrightarrow$$

$$\begin{bmatrix} \text{val}(c.b\_3.o\_1) \\ \text{val}(c.b\_4.o\_1) \end{bmatrix} = \begin{bmatrix} \frac{1}{2} \text{val}(c.b\_3.i\_1) \\ -\frac{1}{2} \text{val}(c.b\_3.i\_1) \end{bmatrix}$$

In this section, the syntax and semantics of Algebraic CBDs were described. These are used in systems where there is no notion of evolving state and time. Any algebraic system of equations can be written as an algebraic CBD.

We described two equivalent approaches to obtain the meaning of an algebraic CBD, summarised in Figure 4.6. The solutions are only approximately equal because, in the presence of algebraic loops, these may have to be solved iteratively to get an approximate solution.

Fig. 4.6: Algebraic CBDs semantic equivalence (approximate).

In the next section, we expand the available atomic blocks to introduce the notion of evolving state via discrete jumps in time.

#### **4.4 Discrete-time CBDs**

In this section, the Discrete time (DT) CBDs are presented. Syntactically, the only difference to the Algebraic CBDs, is that the DT CBDs allow the modeler to use not only algebraic blocks, but also a step delay block. Because the Delay block has a state, which gets updated whenever the block is computed, the other blocks in a DT CBD no longer have static outputs (as in the algebraic CBDs case), but instead change whenever they are computed. DT CBDs share many similarities with discrete time dynamical systems, presented in Section 4.2.2.

#### **4.4.1 Syntax**

The step delay block has two inputs*i*1, *i*<sup>c</sup> and one output *o*1. It is represented with a D symbol, as highlighted in the DT CBD of Figure 4.7. The input port *i*<sup>c</sup> is called the initial condition and is distinguished by its subscript.

Fig. 4.7: Discrete-time CBD of the cruise controller with an highlighted Delay block D. Equivalent to Eq. 4.4.

#### **4.4.2 Semantics**

The fact that the output of the delay block changes whenever it is computed means that the output of any other block that depends on the delay will also be dynamic. To formalize the multiple different values that any single port can assume, the notion of step is necessary. A step is a natural index that allows the distinction between the different outputs of each block. It is no different than the index used in difference equations, presented in Section 4.2.2.

#### **4.4.2.1 Translational**

The output of the delay block is defined in terms of the input provided at the previous step. This is the essence of difference equations, where the current values are calculated from the previous ones. It is then natural that the meaning of a DT CBD is a set of difference equations.

Similarly to the algebraic CBD case, the flattening process ensures that only atomic blocks remain in the DT CBD. Given a flattened DT CBD, the difference equations that it represents can be written following the rules specified in Table 4.4.

Table 4.4: Translational semantics of a flattened DT CBD.

The result is a set of difference equations, along with initial conditions (see Rule 3(a) of Table 4.4), that can be solved, either to obtain a closed-form solution, or simulated, by an independent solver. As an example, the DT CBD represented in Figure 4.7 corresponds to, after simplification and renaming of variables, the software controller of Eq. 4.4.

Conversely, any difference equation written in the form of Eq. 4.3 can be represented as a DT CBD. This is illustrated in Figure 4.8.

Fig. 4.8: Difference equation (written in the form of Eq. 4.3) can be represented in a DT CBD. The i-th component of the vector *x* is represented as *x*<sup>i</sup> .

#### **4.4.2.2 Operational**

When compared to the algebraic CBDs operational semantics, in Algorithm 2, any algorithm that simulates DT CBDs has to compute not single values for variables, but discrete signals. A discrete signal is an ordered list of values, indexed by the step.

The operational meaning of the DT CBDs is thus the computation of the discrete time signal associated with each port. That can be done by fixing the step at 0, then computing all values in the CBD, as if it were an algebraic CBD. Then, step is incremented to 1, and the evaluation of all values is repeated, and so on. The fact that, within the same step, the DT CBD is evaluated as if it were an algebraic CBD, allows us to reuse the EvalAlgebraicCBD function, defined in Algorithm 2, with some minor changes:


```
val(p)
       (s)
           :=ComputeBlock(b, val(q1)
                                             (s)
                                                , val(q2)
                                                          (s)
                                                             , . . . , s);
```
Algorithm 3 summarizes the operational semantics. The definition of the ComputeBlock function is included, to specify the computation of the delay block. The computations of the remaining atomic blocks are trivial.

#### **Algorithm 3** Operational Semantics of an DT CBD *D*.

```
function EvalDiscreteTimeCBD(D, v1, . . . , vn, N)
   Let val(p) be the computed value associated with port identified by p.
   Let i1, . . . , in be the ids of the input ports associated with the CBD D.
   Let o1, . . . , om be the ids of the output ports associated with the CBD D.
   Then, val(i1) := v1, . . . , val(in ) = vn are the values associated with each input ports of D.
    s := 0
   while n ≤ N do
       EvalAlgebraicCBD(D, v
                                     (s)
                                    1
                                       , . . . , v
                                               (s)
                                               n , s)
       s := s + 1
   end while
   return val(o1), . . . , val(om )
end function
function ComputeBlock(b, val(q1), . . . , s)
   if b is a delay block then
       if s = 0 then
           return val(qc )
                            (0)
                              , where qc is the id of the initial condition port.
       else
           return val(qc )
                            (s−1)
                                 .
       end if
   end if
   if b is a summation block then
       return val(q1)
                       (s) + val(q2)
                                     (s)
   end if
   . . .
end function
```
If there are algebraic loops in the DT CBD, they are handled in the same as way in the algebraic CBDs. A note has to be made, however, about the dependencies of the delay block. At the first step (*s* = 0), the output of the delay block is equal to the input associated with its initial condition port (val(*q*<sup>c</sup> ) (0) in Algorithm 3). At any other step *<sup>s</sup>* > 0, the output is computed from the *previous* step *<sup>s</sup>* <sup>−</sup> 1. This means that, except for *<sup>s</sup>* <sup>=</sup> 0, the delay block has no algebraic dependencies. And at *s* = 0 it depends on whatever block is connected to its initial condition port. As a result, Rule 2 of Table 4.3 has to be adapted specifically for the Delay block and the current step being computed.

Following the same structure as Section 4.3, this section presented the syntax and semantics, both translational and operational, of DT CBDs. As with algebraic CBDs, the two semantics commute.

#### **4.5 Continuous-time CBDs**

The meaning of algebraic CBDs is a set of algebraic equations, and the meaning of Discrete time CBDs is a set of difference equations.

As shown in Section 4.2.1, differential equations are ideal to represent physical systems, whose state evolves continuously in time. By the end of this section, it will be clear that Continuous Time (CT) CBDs too, are suited to model these systems.

#### **4.5.1 Syntax**

Syntactically, CT CBDs include the standard algebraic blocks, a derivative, and an integral block. The Delay block is not included.

The derivative and integral blocks have two inputs *i*1, *i*<sup>c</sup> , and one output *o*1. The input subscripted by *c* denotes the initial condition. Both blocks will be denoted by the appropriate mathematical symbol: d dt and R .

#### **Continuous-time CBD**

Fig. 4.9: Example CT CBDs.

Figure 4.9a shows a CT CBD example, with the Drag block specified in Figure 4.9b.

#### **4.5.2 Semantics**

#### **4.5.2.1 Translational Semantics to Differential Equations**

The meaning of a flattened CT CBD is a system of Ordinary Differential Equations (ODEs). Table 4.5 shows the rules that build such system. The meaning of Figure 4.9a is represented, after simplification and renaming the variables, in Eq. 4.2.

Furthermore, any ODE written in the form of Eq. 4.1 can be translated to a CT CBDs as illustrated in Figure 4.10.

#### **4.5.2.2 Basics of ODE Discretization**

In many ODEs arising in science and engineering, and this includes, by the translational semantics, CT CBDs, a closed-form solution cannot be found. One of the possible ways to get insight into the solution is via simulation. Since most simulations are performed in a digital computer, solutions to ODE's obtained via simulation can only be approximate.

#### Table 4.5: Translational semantics of a flattened CT CBD.

	- a. If the block is an Integral block, then the resulting equation is var(q)(t) = R t 0 var(p1)(τ)d<sup>τ</sup> <sup>+</sup> var(p<sup>c</sup> )(0);
	- b. If the block is a Derivative block, then the resulting equations are var(q)(t) = var(p1) 0 (t) and var(q)(0) = var(p<sup>c</sup> )(0);
	- c. If the block is a summation block, then the resulting equation is var(q)(t) = var(p1)(t) + var(p2)(t);
	- d. . . .

In the following paragraphs, we show how to translate ODEs into difference equations, whose solution, obtained via simulation, approximate the solution of the ODEs. See [**?**, 60] for a more detailed exposition on numerical approximation methods. The method explained is then used in Section 4.5.2.3 as the basis to describe how a CT CBD is translated into discrete time CBDs, which approximate the solution to the original.

Consider a first order ODE without input:

$$\begin{aligned} \mathbf{x}'(t) &= F(\mathbf{x}, t) \\ \mathbf{x}(0) &= \mathbf{x}\_0 \end{aligned} \tag{4.8}$$

where

• *<sup>x</sup>*(*t*) <sup>=</sup> [*x*1(*t*), . . . , *<sup>x</sup>*<sup>n</sup> (*t*)] T is the state vector, and

• *<sup>F</sup>*(*x*, *<sup>t</sup>*) <sup>=</sup> [*F*1(*x*, *<sup>t</sup>*), . . . , *<sup>F</sup>*<sup>n</sup> (*x*, *<sup>t</sup>*)] T is the state derivative function, and *x*<sup>0</sup> the initial value of *x*.

Let *x*i(*t*) denote the i-th state trajectory and *x* 0 i (*t*) = *F*i(*x*, *t*) the i-th state derivative. Assuming that *x*i(*t*) and any of its derivatives are smooth, it can be approximated around any point *t* ∗ by the Taylor series [302]:

$$\ln \mathbf{x}\_i \left( t^\* + \Delta t \right) = \mathbf{x}\_i \left( t^\* \right) + \mathbf{x}\_i' \left( \mathbf{x} \left( t^\* \right), t^\* \right) \Delta t + \mathbf{x}\_i^{(2)} \left( t^\* \right) \frac{\Delta t^2}{2!} + \dots \tag{4.9}$$

Using Taylor's theorem, it is possible to write the Taylor series expansion in the finite form of a polynomial and a residual in Lagrange form [60]:

$$\mathbf{x}\_{i}(t^{\*}+\Delta t) = \mathbf{x}\_{i}(t^{\*}) + \mathbf{x}\_{i}'(\mathbf{x}(t^{\*}), t^{\*})\Delta t + \dots \\ \dots \\ + \mathbf{x}\_{i}^{(n)}(t^{\*})\frac{\Delta t^{n}}{n!} + \mathbf{x}\_{i}^{(n+1)}(\xi(t^{\*}))\frac{\Delta t^{n+1}}{(n+1)!}$$

where ξ(*<sup>t</sup>* ∗ ) is an unknown number between *t* ∗ and *t* <sup>∗</sup> + ∆*t*. The residual term *x* (n+1) i (ξ(*t* ∗ )) <sup>∆</sup><sup>t</sup> n+1 (n+1)! denotes the truncation error. It cannot be computed directly but, since any of the derivatives of *x*<sup>i</sup> are smooth in all points between *t* ∗ and *t* <sup>∗</sup> <sup>+</sup> <sup>∆</sup>*t*, there exists a maximum constant *<sup>K</sup>* < <sup>∞</sup>, such that, for any *<sup>t</sup>* ∗ and any *n*,

$$\frac{x\_i^{(n+1)}(\xi(t^\*))}{(n+1)!} \le K$$

An upper bound can then be written for the remainder term in the Big O notation:

$$\lim\_{\Delta t \to 0} \frac{x\_i^{(n+1)}(\xi(t^\*))}{(n+1)!} \Delta t^{n+1} \le K \Delta t^{n+1} = O(\Delta t^{n+1})$$

Notice that the Big O notation O(∆*t* n+1 ) highlights the dominant term as ∆*t* → 0.

Taylor theorem allows us to write the Taylor series taking into account the ODE of Eq. 4.8 and replacing the residual term by its order:

$$\times\_i \left( t^\* + \Delta t \right) = \chi\_i \left( t^\* \right) + F\_i \left( \ge \left( t^\* \right), t^\* \right) \Delta t + \mathcal{O}(\Delta t^2) \tag{4.10}$$

For small <sup>∆</sup>*<sup>t</sup>* < 1 we can neglect the <sup>O</sup> ∆*t* 2 term and approximate *x*<sup>i</sup> (*t* <sup>∗</sup> + ∆*t*) by:

$$\mathbf{x}\_{i}\left(t^{\*} + \Delta t\right) \approx \mathbf{x}\_{i}\left(t^{\*}\right) + F\_{i}\left(\mathbf{x}\left(t^{\*}\right), t^{\*}\right)\Delta t \tag{4.11}$$

Going back to the vector case, this suggests that we can approximate the solution vector *x* (*t*) by the following algorithm:

$$\begin{aligned} \mathbf{x}(\Delta t) & \approx \mathbf{x}(0) + F(\mathbf{x}(0), 0)\Delta t \\ \mathbf{x}(\Delta t + \Delta t) & \approx \mathbf{x}(\Delta t) + F(\mathbf{x}(\Delta t), \Delta t)\Delta t \\ \mathbf{x}(2\Delta t + \Delta t) & \approx \mathbf{x}(2\Delta t) + F(\mathbf{x}(2\Delta t), 2\Delta t)\Delta t \end{aligned} \tag{4.12}$$

Let *x* [s] = *x*(*s*∆*t*), we get the Forward Euler method to numerically approximate Eq. 4.8:

. . .

$$\mathbf{x}^{\{s+1\}} = \mathbf{x}^{\{s\}} + F(\mathbf{x}^{\{s\}}, \mathbf{s}\Delta t)\Delta t \tag{4.13}$$

The Taylor series, introduced in Eq. 4.9 also works backward from any point, including the point *x*<sup>i</sup> (*t* <sup>∗</sup> + ∆*t*):

$$\mathbf{x}((t^\* + \Delta t) - \Delta t) = \mathbf{x}(t^\* + \Delta t) - \mathbf{x}'(\mathbf{x}(t^\* + \Delta t), t^\*)\Delta t + \mathcal{O}(\Delta t^2) \tag{4.14}$$

Replacing the derivative by *F*, from Eq. 4.8, neglecting the residual term, and simplifying gives the Newton's Difference Quotient:

$$\frac{\mathbf{x}(t^\* + \Delta t) - \mathbf{x}(t^\*)}{\Delta t} \approx F(\mathbf{x}(t^\* + \Delta t))\tag{4.15}$$

Rewritten as a difference equation gives:

$$
\alpha^{\{s+1\}} = \alpha^{\{s\}} + F(\alpha^{\{s+1\}}) \Delta t \tag{4.16}
$$

Contrary to the Forward Euler, it is not possible to get an iterative algorithm immediately out of this method: the vector term *x* [s+1] depends on itself. This is an algebraic loop (recall Section 4.3.2.2). It requires that the matrix equation be solved for *x* [s+1] . The presence of these loops distinguishes implicit (with loops) from explicit (without loops) methods. The important point is that, as shown in Section 4.3.2.2, these loops can be solved at each simulation step.

#### **4.5.2.3 Translational Semantincs to Discrete-time CBDs**

As explained in the previous section, differential equations can be discretised to difference equations by means of numerical approximation techniques, which can then be easily simulated.

#### 4 Causal-Block Diagrams 115

Since any CT CBD can be translated into an ODE (by Table 4.5), and since the meaning of a discrete time CBD is a system of difference equations, it is natural to wonder whether a discrete time CBD can be transformed directly into a discrete time CBD, which realizes the approximation. The only blocks that need to be approximated are the derivative and the integral. All the other blocks are algebraic. The integral block is left as an exercise.

The derivative block outputs the derivative of its input *u*, at time *t*:

$$\mathbf{y}(t) = \boldsymbol{\mu}'(t)$$

except at time *t* = 0, where the output y(0) is given by the input initial condition *u*<sup>c</sup> , i.e., y(0) = *u*<sup>c</sup> (0). Applying the Newton's Difference Quotient, from Eq. 4.15, yields:

$$\frac{\mu(t+\Delta t) - \mu(t)}{\Delta t} \approx \mathbf{y}(t+\Delta t)$$

Solving for the output y(*t* + ∆*t*) and writing as a difference equation gives:

$$\mathbf{y}^{\{s\}} : \approx \frac{\boldsymbol{\mu}^{\{s\}} - \boldsymbol{\mu}^{\{s-1\}}}{\Delta t} \tag{4.17}$$

Since the input is not differentiable at time *t* = 0, the initial condition of the derivative block is provided with an initial value y(0) = *u*<sup>c</sup> (0).

It is easy to build a discrete time CBD equivalent to Eq. 4.17 using a delay and algebraic blocks. The delay block will ensure the delayed signal of the input (*u* [s−1] ) can be obtained. However, at the initial step, *s* = 0, the delay block has to have an initial condition defined because the value *u* [−1] , in Eq. 4.17, is unknown. Let *u*−<sup>1</sup> denote this unknown value. *u*−<sup>1</sup> cannot be equal to y [0] . That does not satisfy the initial condition of the derivative, expressed as:

$$\mathbf{y}^{[0]} \approx \frac{\boldsymbol{\mu}^{[0]} - \boldsymbol{\mu}\_{-1}}{\Delta t} = \boldsymbol{\mu}\_{c}^{[0]}$$

To find out the initial condition of the delay, one can rearrange the above equation to get *u*−<sup>1</sup> = *u* [0] − ∆*t* · *u* [0] c , which defines the initial condition of the delay. Figure 4.11 shows the transformation rule.

In this section, CT CBDs where introduced, and its meaning given as a translation to discrete time CBDs.

Until now, we have introduced the minimal set of concepts that allow one to use and understand the semantics of CBDs. We skipped over a few details which, to become a proficient user of CT CBDs, have to be covered in the next section. For example, we took for granted that the solution computed by the Forward Euler method is accurate. Furthermore, we have not introduced the operational semantics of continuous time CBDs. Such algorithm can be easily devised for the approximations of the integral and derivative blocks already given – Forward Euler and Newton's Difference Quotient – with special attention to the fact that the approximation of the derivative may introduce algebraic loops in the CBD. However, if those approximation methods are used, the algorithm will be hardly useful: the translation to discrete time CBDs is equivalent and already deals with the algebraic loops problem for free.

#### **4.6 Advanced Concepts and Extensions**

This section allows you to devise smarter approximation methods, that minimising the error in the approximation. We focus on numerical integration methods, that is, approximations of the integrator block, because these are the most commonly used when modelling physical systems (see Figure 4.10). Finally, we introduce an extension that is widely used in CBDs: logic blocks. These allow higher level reasoning to be used in CBDs, conveying more expressive power to the modeller, but introducing other interesting challenges when it comes to simulation.

Fig. 4.11: Sample CT CBD with a Derivative block (on the left) and the corresponding discrete time CBD (on the right).

#### **4.6.1 Approximation Error**

Consider the Forward Euler method in Eq. 4.13. To derive it, the term O(∆*t* 2 ) of the Taylor series was neglected (recall Eqs. 4.9, 4.10, and 4.11).

Let *x*(*t*) denote the solution to Eq. 4.8 approximated with Forward Euler, and let ˆ*x* denote the real solution. The first term (*x*(0) = *x*ˆ(0)) is known from the initial condition of Eq. 4.8. The second term (*x*(∆*t*) = *x*(0) + *F*(*x*(0))∆*t*) deviates from the true solution ˆ*x*(∆*t*) by an order O(∆*t* 2 ), which is the residual term ignored in the Taylor series (recall Eq. 4.10 and Eq. 4.11). Formally, that is,

$$\|\|\hat{\mathfrak{x}}(\Delta t) - \mathfrak{x}(\Delta t)\|\| = \left\|\hat{\mathfrak{x}}(0) + F(\hat{\mathfrak{x}}(0))\Delta t + \mathcal{O}(\Delta t^2) - \mathfrak{x}(0) - F(\mathfrak{x}(0))\right\| = \mathcal{O}(\Delta t^2)$$

The third term *x*(2∆*t*) deviates further from the true solution not only because of the residual – of order O(∆*t* 2 )– but also because *F*(*x*(∆*t*), ∆*t*) is evaluated with the approximated term *x*(∆*t*) (most likely *F*(*x*(∆*t*)) , *F*(*x*ˆ(∆*t*))). The iteration continues and it is easy to see that the error accumulates over the iterations.

In order to analyse the accumulation of errors, it is best to distinguish two kinds of errors: the local truncation error, due to the ignored residual term, and the derivative error, due to evaluating the derivative *F* at approximated points *x*. Both these errors contribute to the accumulation of error over time, that is, the global error.

The local truncation error denotes the deviation made by a single step of the numerical method, starting from accurate information, i.e., with no previously accumulated error.

Let

$$\left(\hat{\mathbf{x}}((\mathbf{s}+\mathbf{l})\cdot\Delta t) + \hat{\mathbf{x}}(\mathbf{s}\cdot\Delta t) + F\left(\hat{\mathbf{x}}(\mathbf{s}\cdot\Delta t)\right)\Delta t + \mathcal{O}\left(\Delta t^2\right)\right) \tag{4.18}$$

denote the real solution expanded with the infinite Taylor series, and let

$$\mathbf{x}((\mathbf{s}+\mathbf{l})\cdot\Delta t) \approx \hat{\mathbf{x}}(\mathbf{s}\cdot\Delta t) + F\left(\hat{\mathbf{x}}(\mathbf{s}\cdot\Delta t)\right)\Delta t$$

denote the solution computed across one step of the Forward Euler method, starting from accurate information. The local truncation error is thus given as

4 Causal-Block Diagrams 117

$$\|\|\hat{x}((\mathbf{s}+\mathbf{l})\cdot\Delta t) - \mathbf{x}((\mathbf{s}+\mathbf{l})\cdot\Delta t)\|\| = \mathcal{O}(\Delta t^2) \tag{4.19}$$

Studying the global error is more difficult as it depends on the derivative error, which, for a generic analysis, can be any function *F*. If any error in the parameter of *F* gets amplified, then the global error will grow faster. If it gets contracted, then the global error will grow in a slower fashion. To formalize, suppose that we know that *F* satisfies:

$$\|\|F(\hat{\mathbf{x}}(t)) - F(\mathbf{x}(t))\|\| \le K\_f \left\|\|\hat{\mathbf{x}}(t) - \mathbf{x}(t)\|\right\|, \text{ for all } t \in \mathbb{R},\tag{4.20}$$

where 0 <sup>≤</sup> *<sup>K</sup>*<sup>f</sup> <sup>&</sup>lt; <sup>∞</sup> is a constant. Then, the error at the second step of the Forward Euler can be derived as follows:

$$\begin{aligned} &\left\| \left\| \hat{\mathbf{x}} (2\Delta t) - \mathbf{x} (2\Delta t) \right\| \\ &= \left\| \hat{\mathbf{x}} (\Delta t) + F(\hat{\mathbf{x}}(\Delta t)) \Delta t + O(\Delta^2) - (\mathbf{x}(\Delta t) + F(\mathbf{x}(\Delta t)) \Delta t) \right\| \\ &= \left\| \hat{\mathbf{x}} (\Delta t) - \mathbf{x} (\Delta t) + (F(\hat{\mathbf{x}}(\Delta t)) - F(\mathbf{x}(\Delta t))) \Delta t + O(\Delta^2) \right\| \\ &\le \left\| \hat{\mathbf{x}} (\Delta t) - \mathbf{x} (\Delta t) \right\| + \left\| F(\hat{\mathbf{x}}(\Delta t)) - F(\mathbf{x}(\Delta t)) \right\| \Delta t + O(\Delta^2) \\ &\le \left\| \hat{\mathbf{x}} (\Delta t) - \mathbf{x} (\Delta t) \right\| + K\_f \left\| \hat{\mathbf{x}} (\Delta t) - \mathbf{x} (\Delta t) \right\| \Delta t + O(\Delta^2) \\ &= \left( 2 + K\_f \Delta t \right) O(\Delta^2) = O(2\Delta^2) \end{aligned} \tag{4.21}$$

Notice that, as ∆*t* → 0, the big O definition implies that

$$\left(2 + K\_f \Delta t\right) \mathcal{O}(\Delta t^2) = \mathcal{O}(2\Delta t^2 + K\_f \Delta t^3) = \mathcal{O}(2\Delta t^2).$$

Similarly, for the third step: k*x*ˆ(3∆*t*) − *x*(3∆*t*)k = O(3∆*t* 2 ). And after *s* steps, we have k*x*ˆ(*s*∆*t*) − *x*(*s*∆*t*)k = O(*s*∆*t* 2 ).

To run the simulation up to time *t* <sup>f</sup> the Forward Euler method performs *<sup>t</sup>* <sup>f</sup> /∆*<sup>t</sup>* steps, which gives

$$\left\| \left\| \hat{\boldsymbol{x}}(t\_f) - \boldsymbol{x}(t\_f) \right\| \right\| = O(\frac{t\_f}{\Delta t} \Delta t^2) = O(\Delta t)$$

Which says that the global error will be approximately linear in the size of ∆*t*, as ∆*t* → 0. For a more accurate expression of the global error of the Forward Euler method, see [60, 61].

An important conclusion is that, provided that function *F* obeys the condition in Eq. 4.20, the global error can be minimised by simply taking smaller ∆*t* at each step of the simulation using the Forward Euler method. This is called convergence, a property that any useful numerical method should satisfy.

Since there is a limit to how small ∆*t* can be made in a digital computer, a numerical method which has an higher order of accuracy than O(∆*t*), for example, O(∆*t* 2 ), will allow for larger steps to be taken. In the next section, we introduce other numerical methods.

#### **4.6.2 Other Numerical Methods**

#### **4.6.2.1 Backward Euler Method**

The Taylor series (Eq. 4.10) also works backward from any point, including the point (*t* <sup>∗</sup> + ∆*t*), as was done in Eq. 4.14. Neglecting the residual term, we get:

$$
\alpha\_i((t^\* + \Delta t) - \Delta t) \approx \alpha\_i(t^\* + \Delta t) - \alpha\_i'(\alpha(t^\* + \Delta t))\Delta t
$$

After some simplifications we get a method that resembles the Forward Euler method:

$$\mathbf{x}(t^\* + \Delta t) \approx \mathbf{x}\_l(t^\*) + F(\mathbf{x}(t^\* + \Delta t))\Delta t \tag{4.22}$$

This leads to the Backward Euler method:

$$\mathbf{x}^{\{s+1\}} = \mathbf{x}^{\{s\}} + F(\mathbf{x}^{\{s+1\}})\Delta t \tag{4.23}$$

When compared to explicit methods, the backward Euler requires the solution to an algebraic loop, so it will incur some extra computation at each simulation step. Furthermore, the global and local errors of the backward Euler are of the same order as the Forward Euler method. Their difference lies in the fact that the derivative used to make the estimation of *x* [s+1] is the closest to it. In the Forward Euler, the derivative is an *out-dated* one. This has benefits when dealing with stiff systems. See [61, 60, 69] for more details.

#### **4.6.2.2 Second Order Taylor Method**

Until now we have always neglected the term O(∆*t* 2 ) of the Taylor series. Let us see what happens when we neglect higher order terms. For example, the Taylor series, after neglecting the term O(∆*t* 3 ), becomes:

$$\mathbf{x}(t^\* + \Delta t) \approx \mathbf{x}(t^\*) + F(\mathbf{x}(t^\*), t^\*)\Delta t + \frac{dF\left(\mathbf{x}\left(t^\*\right), t^\*\right)}{dt}\frac{\Delta t^2}{2!}$$

The derivative dF(x(t ∗ ),t ∗ ) dt can be expanded with the chain rule 1:

$$\frac{dF(\mathbf{x}(t^\*), t^\*)}{dt} = \frac{\partial F(\mathbf{x}(t^\*), t^\*)}{\partial \mathbf{x}} F(\mathbf{x}(t^\*), t^\*) + \frac{\partial F(\mathbf{x}(t^\*), t^\*)}{\partial t}$$

The second order Taylor series method then becomes:

$$\begin{split} x^{\{s+1\}} &= x^{\{s\}} + F(x^{\{s\}}, s \cdot \Delta t) \Delta t \\ &\quad + \left( \frac{\partial F(x^{\{s\}}, s \cdot \Delta t)}{\partial x} F(x^{\{s\}}, s \cdot \Delta t) + \frac{\partial F(x^{\{s\}}, s \cdot \Delta t)}{\partial t} \right) \frac{\Delta t^2}{2!} \end{split} \tag{4.24}$$

The local truncation error of this method is the neglected term O(∆*t* 3 ), better than the Euler methods. The disadvantage of this method is that it requires the calculation (symbolically or numerically) of the partial derivatives of *F* – a costly operation. The global error is in the order of O(∆*t* 2 ).

Higher order Taylor methods require even more derivative calculations, making them impractical. There are methods that offer that same global error order with far less computation at each step. We show one next.

#### **4.6.2.3 Midpoint Method**

The backward Euler method makes use of the most up-to-date derivative to estimate the solution at *t* <sup>∗</sup> + ∆*t* with the disadvantage that it requires more computation to solve the implicit equation. To avoid this, but still trying to be better than Forward Euler, we can try to estimate the derivative at halfway between *t* ∗ and *t* <sup>∗</sup> + ∆*t* and use that derivative to compute *x*(*t* <sup>∗</sup> + ∆*t*):

$$\mathbf{x}(t^\* + \Delta t) = \mathbf{x}(t^\*) + F(\mathbf{x}(t^\* + \frac{\Delta t}{2})) \Delta t.$$

However, we do not know the value of *x*(*t* <sup>∗</sup> + ∆t 2 ). We can use Taylor series again to get

$$\propto (t^\* + \frac{\Delta t}{2}) = \propto (t^\*) + F(\propto (t^\*)) \frac{\Delta t}{2}$$

Thus we arrive at the midpoint method:

$$\mathbf{x}^{\{s+1\}} = \mathbf{x}^{\{s\}} + F\left[\mathbf{x}^{\{s\}} + F\left(\mathbf{x}^{\{s\}}, \mathbf{s} \cdot \Delta t\right) \frac{\Delta t}{2}, \left(s + \frac{1}{2}\right) \cdot \Delta t\right] \Delta t \tag{4.25}$$

The midpoint method, Eq. 4.25, can be generalised to

<sup>1</sup> Notice that, to be general, we represent the derivative F(x(t ∗ ), t ∗ ) as a function that depends directly on the time. If this is not the case, then <sup>∂</sup>F(x(<sup>t</sup> ∗ ),t ∗ ) ∂t = 0.

$$\mathbf{x}\_{C}^{\{s+1\}} = \mathbf{x}^{\{s\}} + \beta\_{C1} \cdot \Delta t \cdot F^{\{s\}} + \beta\_{C2} \cdot \Delta t \cdot F\left(\mathbf{x}^{\{s\}} + \beta\_{p} \cdot F^{\{s\}} \cdot \Delta t, \left(\mathbf{s} + \alpha\_{p}\right) \cdot \Delta t\right)$$

where *F* [s] = *F x* [s] , *s* · ∆*t* , <sup>β</sup><sup>p</sup> <sup>=</sup> <sup>α</sup><sup>p</sup> <sup>=</sup> 1 2 , <sup>β</sup>C<sup>1</sup> <sup>=</sup> 0, and <sup>β</sup>C<sup>2</sup> <sup>=</sup> 1.

Expanding *F x* [s] <sup>+</sup> <sup>β</sup><sup>p</sup> · *<sup>F</sup>* [s] · ∆*t*, *<sup>s</sup>* <sup>+</sup> <sup>α</sup><sup>p</sup> · ∆*t* with the multi-variate version of the Taylor series, we get:

$$\begin{aligned} &F\left(\mathbf{x}^{[s]} + \beta\_P \cdot F^{[s]} \cdot \Delta t, \left(\mathbf{s} + \alpha\_P\right) \cdot \Delta t\right) \\ &\approx F^{[s]} + \beta\_P \cdot \frac{\partial F^{[s]} }{\partial \boldsymbol{\omega}} \cdot F^{[s]} \cdot \Delta t + \alpha\_P \cdot \frac{\partial F^{[s]} }{\partial t} \cdot \Delta t \end{aligned}$$

Where the quadratic term was neglected. Plugging it into the previous equation gives:

$$\begin{split} \mathbf{x}\_{C}^{[s+1]} &= \mathbf{x}^{[s]} + \boldsymbol{\beta}\_{C1} \cdot \boldsymbol{F}^{[s]} \cdot \boldsymbol{\Delta t} + \\ & \quad \boldsymbol{\beta}\_{C2} \cdot \left[ \boldsymbol{F}^{[s]} + \boldsymbol{\beta}\_{P} \cdot \frac{\partial \boldsymbol{F}^{[s]}}{\partial \boldsymbol{\alpha}} \cdot \boldsymbol{F}^{[s]} \cdot \boldsymbol{\Delta t} + \boldsymbol{\alpha}\_{P} \cdot \frac{\partial \boldsymbol{F}^{[s]}}{\partial t} \cdot \boldsymbol{\Delta t} \right] \cdot \boldsymbol{\Delta t} \\ &= \mathbf{x}^{[s]} + \left( \boldsymbol{\beta}\_{C1} + \boldsymbol{\beta}\_{C2} \right) \boldsymbol{F}^{[s]} \cdot \boldsymbol{\Delta t} + \\ & \quad \boldsymbol{\beta}\_{C2} \left[ \boldsymbol{\beta}\_{P} \cdot \frac{\partial \boldsymbol{F}^{[s]}}{\partial \boldsymbol{\alpha}} \cdot \boldsymbol{F}^{[s]} + \boldsymbol{\alpha}\_{P} \cdot \frac{\partial \boldsymbol{F}^{[s]}}{\partial t} \right] \cdot \boldsymbol{\Delta t}^{2} \end{split}$$

To find the local truncation error, let us find the Taylor series expansion of the true solution and then compare it to the previous equation. The true solution can be expanded as:

$$\hat{\mathfrak{X}}^{[s+1]} = \hat{\mathfrak{X}}^{[s]} + F^{[s]} \cdot \Delta t + \frac{1}{2} \frac{\partial F^{[s]}}{\partial \boldsymbol{x}} \Delta t^2 + \mathcal{O}(\Delta t^3),$$

Applying the chain rule to the derivative yields:

$$\hat{\mathfrak{X}}^{\{s+1\}} = \hat{\mathfrak{X}}^{\{s\}} + F^{\{s\}} \cdot \Delta t + \frac{1}{2} \cdot \left[ \frac{\partial F^{\{s\}}}{\partial \mathbf{x}} F^{\{s\}} + \frac{\partial F^{\{s\}}}{\partial t} \right] \cdot \Delta t^2 + \mathcal{O}(\Delta t^3),$$

Comparing ˆ*x* [s+1] with *x* [s+1] C , and assuming that these start from a true solution ˆ*x* [s] gives:

$$\begin{split} \boldsymbol{x}\_{C}^{[s+1]} &= \hat{\mathbf{x}}^{[s+1]} \leftrightarrow \\ \hat{\boldsymbol{x}}^{[s]} &+ \left(\beta\_{C1} + \beta\_{C2}\right) \boldsymbol{F}^{[s]} \cdot \boldsymbol{\Delta t} + \beta\_{C2} \left[\beta\_{P} \cdot \frac{\partial \boldsymbol{F}^{[s]}}{\partial \boldsymbol{x}} \cdot \boldsymbol{F}^{[s]} + \alpha\_{P} \cdot \frac{\partial \boldsymbol{F}^{[s]}}{\partial t}\right] \cdot \boldsymbol{\Delta t}^{2} \\ &= \hat{\mathbf{x}}^{[s]} + \boldsymbol{F}^{[s]} \cdot \boldsymbol{\Delta t} + \frac{1}{2} \cdot \left[\frac{\partial \boldsymbol{F}^{[s]}}{\partial \boldsymbol{x}} \boldsymbol{F}^{[s]} + \frac{\partial \boldsymbol{F}^{[s]}}{\partial t}\right] \cdot \boldsymbol{\Delta t}^{2} + \boldsymbol{O}(\boldsymbol{\Delta t}^{3}) \end{split}$$

When solved for the parameters, the above equation gives:

$$\begin{cases} \beta\_{C1} + \beta\_{C2} = 1 \\ 2\beta\_{C2}\beta\_p = 1 \\ 2\beta\_{C2}\alpha\_p = 1 \end{cases}$$

As long as the parameters <sup>β</sup>p, <sup>α</sup>p, <sup>β</sup>C1, <sup>β</sup>C<sup>2</sup> obey the above system of equations, the generic method will have a local truncation error of order O(∆*t* 3 )), without having to compute any derivative of *F*. This also shows that the midpoint method is but an element of a family of methods, all with different sets of parameters, called the two stage Runge Kutta methods [69].

By the same argument as the Forward Euler (in Section 4.6.1), we conclude that the global error of the two stage Runge Kutta method is of order O(∆*t* 2 ).

#### **4.6.3 Adaptive-Step Size**

The numerical integration schemes introduced until now use a step size ∆*t* assumed to be constant throughout the simulation process. These numerical algorithms are computationally expensive in systems where the dynamic behaviour changes slowly except in some limited intervals of time.

Recall that the order of growth of the global error ultimately depends on the Lipschitz constant *K*<sup>f</sup> , in Eq. 4.20. This constant represents the worst case deviation of function *F* as a response to deviations in its parameters2, for all possible values of ˆ*x*(*t*).

A larger *K*<sup>f</sup> indicates that the global error *may* grow faster, which means that the step size ∆*t* should be smaller. To clarify: if a system has a large *K*<sup>f</sup> , it means that there is at least one pair of values *x*(*t*) and ˆ*x*(*t*) for which k*F*(*x*ˆ(*t*)) − *F*(*x*(*t*))k is large. This does not imply the deviations of *F* are large for all possible pairs of values *x*(*t*) and ˆ*x*(*t*). Furthermore, it does not imply that, if the system were to be simulated in a bounded region (e.g, for 0 <sup>&</sup>lt; *<sup>t</sup>* <sup>&</sup>lt; *<sup>t</sup>* <sup>f</sup> ), the Lipschitz constant in that region would be smaller. A smaller Lipschitz constant means that the ∆*t* can be larger.

For a given derivative *F*, it is hard to find the proper *K*<sup>f</sup> in order to pick the right ∆*t*.

An algorithm that can change the ∆*t* throughout the simulation, not only leverages the features of each region in the state space to improve the run-time performance of the simulation but also frees the user from the burden of picking an appropriate ∆*t*. All of this without sacrificing accuracy.

The change of the ∆*t* has to be triggered by some estimate of the error being committed at each simulation step. Assuming the estimate is available, ∆*t* is increased if the error becomes too small and decreased if the error is too large.

The challenge is to come up with a good estimate of the error being committed. Suppose we are given two methods, with local truncation errors O(*c*∆*t* v ) and O(*c* 0∆*t* v 0 ), respectively, with *c*, *c* 0 , v, v 0 positive constants. Formally, let *x*(*t*) be the solution computed by the first method, ˜*x*(*t*) by the second, and ˆ*x*(*t*) be the real solution. Then, after one inaccurate step, solutions *x*(*t* + ∆*t*) and ˜*x*(*t* + ∆*t*) can be written as:

$$\begin{aligned} \dot{\chi}(t + \Delta t) &= \hat{\chi}(t + \Delta t) + \mathcal{O}(c\Delta t^{\circ}) \\ \ddot{\chi}(t + \Delta t) &= \hat{\chi}(t + \Delta t) + \mathcal{O}(c'\Delta t^{\circ^{\prime}}) \end{aligned} \tag{4.26}$$

Comparing *x*(*t* + ∆*t*) with ˜*x*(*t* + ∆*t*) yields

$$\left\| \|\chi(t+\Delta t) - \tilde{\chi}(t+\Delta t)\| \right\| = \left\| \mathcal{O}(c\Delta t^{\nu}) - \mathcal{O}(c'\Delta t^{\nu'}) \right\|.$$

The big O notation tells that there exist constants *K*<sup>1</sup> and *K*<sup>2</sup> such that, in the limit ∆*t* → 0,

$$\left\| \left\| \mathcal{O}(c\Delta t^{\nu}) - \mathcal{O}(c'\Delta t^{\nu'}) \right\| \right\| = \left\| K\_1 c \Delta t^{\nu} - K\_2 c' \Delta t^{\nu'} \right\|.$$

Assuming that *c* 0 > *<sup>c</sup>* and that <sup>v</sup> 0 < <sup>v</sup> (the other cases are similar) we have, as <sup>∆</sup>*<sup>t</sup>* <sup>→</sup> 0,

$$\|\|\mathbf{x}(t+\Delta t) - \tilde{\mathbf{x}}(t+\Delta t)\|\| = \mathcal{O}(c'\Delta t^{\nu^\*}) = \|\|\tilde{\mathbf{x}}(t+\Delta t) - \hat{\mathbf{x}}(t+\Delta t)\|\|,$$

thus proving that comparing the solutions of the two methods gives an estimate of the error in the same order as the local truncation error of the least accurate method.

From the previous sections, there are two approaches to affect the accuracy of a method: (a) use a smaller step-size and (b) use an higher order approximation method (e.g., the midpoint).

The approach (a) is straightforward: simply take any existing numerical method, compute the solution twice (once with two half steps, and once with a single step), and compare the two estimates.

For an example of approach (b), use the midpoint method to compute the solution *x*(*t*), and, at each step, compare it with the result ˜*x*(*t*) of the Forward Euler method. It is easy to see that there is some redundant computation in this approach. Fortunately, higher order Runge-Kutta methods can be combined, reusing most of the redundant computation. These are called the Runge-Kutta Fehlberg methods.

<sup>2</sup> F(x(t)) = F(xˆ(t) + e(t)), with e being the approximation error.

#### **4.6.4 Logic Blocks**

Decision blocks are widely used in CBDs to increase the expressiveness of the language. The most common decision block is the switch block. The switch block, shown in Figure 4.12, outputs the value *u*(*t*) or v(*t*) depending on the value of *c*(*t*). If *c*(*t*) ≥ 0, *u*(*t*) is the output, otherwise v(*t*). The translational semantics are:

Fig. 4.12: Switch block

As will be presented shortly, the operational semantics of this block introduce interesting challenges.

#### **4.6.4.1 Discontinuity Handling – Zero-Crossing Location**

Recall that the simulation of continuous time CBDs can only be performed approximately in a digital computer. See Section 4.5.2. This means that the simulation of a continuous CBDs is actually a discrete set of points

$$(x(0), x(1\Delta t\_1), x(2\Delta t\_2), \dots)$$

computed with an adaptive step size method (see Section 4.6.3).

Suppose the time is *t* and the simulator is going to compute the solution to the output of the switch block y(*t* + ∆*t*). Furthermore, assume that y(*t*) = *u*(*t*), that is, *c*(*t*) ≥ 0. If *c*(*t* + ∆*t*) ≤ 0, then two issues can be identified:


The second issue implies that, by the intermediate value theorem, there exists at least one point *t* <sup>∗</sup> ∈ [*t*, *t* + ∆*t*], at which *c*(*t* + ∆*t*) = 0. Ideally, ∆*t* should be picked in a way such that *t* + ∆*t* ≈ *t* ∗ , thus minimizing δ, for two reasons:


To see why this can be a problem, consider the abstract CBD shown in Figure 4.13. It can be written as a differential equation *x* 0 (*t*) = *F*(*x*(*t*)) (recall Figure 4.10). At the time of the discontinuity *t* ∗ , in the limit <sup>→</sup> 0, *x*(*t* <sup>∗</sup> <sup>−</sup> ) <sup>=</sup> *<sup>x</sup>*(*<sup>t</sup>* <sup>∗</sup> <sup>+</sup> ), but *<sup>F</sup>*(*x*(*<sup>t</sup>* <sup>∗</sup> <sup>−</sup> )) , *<sup>F</sup>*(*x*(*<sup>t</sup>* <sup>∗</sup> <sup>+</sup> )) because of the switch block. This causes a fundamental assumption about the behavior of *F*—the condition in Eq. 4.20—to be violated. Formally,

$$\left\|\left\|F(\mathbf{x}(t^\* + \epsilon)) - F(\mathbf{x}(t^\* - \epsilon))\right\|\right\| \le K\_f \left\|\mathbf{x}(t^\* + \epsilon) - \mathbf{x}(t^\* - \epsilon)\right\| \le 0$$

is a contradiction.

Without the Lipschitz condition assumption, it is hard to guarantee an order for the growth of the global error. There are multiple ways to address this problem, once the exact time of the discontinuity is located (see [211, 310]). We focus here in the location of the time of the discontinuity (also called root-finding, or zero crossing location in the literature).

Fig. 4.13: Abstract CBD which may violate the condition in Eq. 4.20.

Fig. 4.14: The bisection method

Different algorithms have been proposed over the years (see [60, 69]). The essence is always the same: locate *t* ∗ in an interval [*t*, *t* + ∆*t*] such that the condition of the switch satisfies *c*(*t* + ∆*t*) = 0.

A robust yet simple algorithm is the bisection method. As the name hints, the method works by iteratively bisecting the interval. At each iteration it selects the subinterval where the zero-crossing is present to search for the zero location. The algorithm is illustrated in Figure 4.14. The initial steps detects a zero-crossing in the interval between *t*<sup>1</sup> and *t*2. The iterative procedure evaluates first point *a*, then point *b*, then point *c* and finally point *d* that is within the tolerance bounds.

Other algorithms are described in the literature [60].

#### **4.7 Global Error Euler Method**

The global error measures the accumulated deviation of the numerical method from the true solution, across any number of steps. We need to assume that *F*(*x*, *t*) is Lipschitz continuous.

At the initial step, the global error is the same as the local truncation error: *e* (1) = *x* (1) − *x*˜ (1) = *x* (0) + *F*(*x* (0) , *k*∆*t*)∆*t* + O ∆*t* 2 − *x* (k) + *F*(*x* (k) , *k*∆*t*)∆*t* = O ∆*t* 2 .

#### 4 Causal-Block Diagrams 123

At the second step:

$$\begin{aligned} e^{(2)} &= \mathbf{x}^{(2)} - \tilde{\mathbf{x}}^{(2)} = \\ &\mathbf{x}^{(1)} + F(\mathbf{x}^{(1)}, \Delta t)\Delta t + O\left(\Delta t^2\right) - \left(\tilde{\mathbf{x}}^{(1)} + F(\tilde{\mathbf{x}}^{(1)}, \Delta t)\Delta t\right) = \\ e^{(1)} + F(\mathbf{x}^{(1)}, \Delta t)\Delta t - F(\tilde{\mathbf{x}}^{(1)}, \Delta t)\Delta t + O\left(\Delta t^2\right) &= \\ &\left[ F(\mathbf{x}^{(1)}, \Delta t) - F(\tilde{\mathbf{x}}^{(1)}, \Delta t) \right] \Delta t + e^{(1)} + O\left(\Delta t^2\right) \end{aligned}$$

We know that, for some constant *K*, ˜*x* (1) = *x* (1) − *e* (1) , we can write:

$$\left[F(\mathbf{x}^{(1)}, \Delta t) - F(\mathbf{x}^{(1)} - e^{(1)}, \Delta t)\right] \Delta t + e^{(1)} + \mathcal{O}\left(\Delta t^2\right)^{-1}$$

The Lipschitz continuity condition tells us that:

$$\left| F(\boldsymbol{x}^{(1)}, \Delta t) - F(\boldsymbol{x}^{(1)} - \boldsymbol{e}^{(1)}, \Delta t) \right| \leq K e^{(1)},$$

Hence, we can give an upper bound on the above error:

*e*

$$\begin{split} e^{(2)} &= \left[ F(\boldsymbol{\chi}^{(1)}, k\Delta t) - F(\boldsymbol{\tilde{\chi}}^{(1)}, k\Delta t) \right] \Delta t + e^{(1)} + O\left( \Delta t^2 \right) \leq \\ &\quad \boldsymbol{K}e^{(1)}\Delta t + e^{(1)} + O\left( \Delta t^2 \right) \leq \boldsymbol{K}e^{(1)}\Delta t + e^{(1)} + O\left( \Delta t^2 \right) = \\ &\quad \left( \boldsymbol{K}\Delta t + \boldsymbol{1} \right)e^{(1)} + O\left( \Delta t^2 \right). \end{split}$$

In general,

$$\begin{split} \boldsymbol{\hat{x}}^{(k+1)} &= \\ &\boldsymbol{\chi}^{(k+1)} - \boldsymbol{\hat{x}}^{(k+1)} = \\ &\boldsymbol{\chi}^{(k)} + F(\boldsymbol{x}^{(k)}, k\Delta t)\boldsymbol{\Delta t} + \mathcal{O}\left(\Delta t^{2}\right) - \left(\boldsymbol{\hat{x}}^{(k)} + F(\boldsymbol{\hat{x}}^{(k)}, k\Delta t)\Delta t\right) = \\ &e^{(k)} + \left[F(\boldsymbol{x}^{(k)}, k\Delta t) - F(\boldsymbol{\hat{x}}^{(k)}, k\Delta t)\right]\Delta t + \mathcal{O}\left(\Delta t^{2}\right) \leq \\ &K\Delta t e^{(k)} + e^{(k)} + \mathcal{O}\left(\Delta t^{2}\right) \leq \mathcal{O}\left(\Delta t^{2}\right) + (K+1)e^{(k)}. \end{split}$$

Expanding recursively, and assuming that <sup>∆</sup>*<sup>t</sup>* < 1 we get:

$$\begin{split} e^{(1)} &= \mathcal{O}\left(\Delta r^{2}\right) \\ e^{(2)} &\leq \mathcal{O}\left(\Delta r^{2}\right) + \left(K+1\right)\mathcal{O}\left(\Delta r^{2}\right) = \left(K+2\right)\mathcal{O}\left(\Delta r^{2}\right) \\ e^{(3)} &\leq \mathcal{O}\left(\Delta r^{2}\right) + \left(K+2\right)\mathcal{O}\left(\Delta r^{2}\right) = \left(K+3\right)\mathcal{O}\left(\Delta r^{2}\right) \\ &\dots \\ e^{(k)} &\leq \mathcal{O}\left(\Delta r^{2}\right) + \left(K+k-1\right)\mathcal{O}\left(\Delta r^{2}\right) = \left(K+k\right)\mathcal{O}\left(\Delta r^{2}\right). \end{split}$$

To simulate the system from 0 to *t* <sup>f</sup> , we require <sup>t</sup><sup>f</sup> ∆t steps. Thus, the error will be:

$$\begin{aligned} e^{\left(\frac{t\_f}{\Delta t}\right)} &\leq \left(K + \frac{t\_f}{\Delta t}\right) \mathcal{O}\left(\Delta t^2\right) = \\\ K\mathcal{O}\left(\Delta t^2\right) + \frac{t\_f}{\Delta t} \mathcal{O}\left(\Delta t^2\right) &\leq \left(K + t\_f\right) \mathcal{O}\left(\Delta t\right) = \mathcal{O}\left(\Delta t\right) \end{aligned}$$

This leads us to conclude that the order of global error of the forward Euler is O (∆*t*).

#### **4.8 Summary**

Causal Block Diagrams represent a formalisation of the intuitive graphical notation of blocks and arrows. This chapter introduced the different variants of this formalism, in a gradual manner.

The most typical uses for these formalisms are: *(i)* Algebraic CBDs to study the steady state behaviour of systems; *(ii)* Discrete time CBDs to represent computation and software components; and *(iii)* Continuous time CBDs to model physical systems. To connect these three variants, a running example of a cruise control system was used.

Algebraic CBDs represent algebraic systems where there is no notion of passing time. Discrete time CBDs mixes in the passage of time, although at discrete points. These are analogous to difference equations. Finally, continuous time CBDs, were time is a continuum, correspond to differential equations. x

The advantage of CBDs over plain difference/differential equations is the natural support for hierarchical descriptions of complex systems, providing a way to manage complexity.

The disadvantage is in the ability to reuse models of physical components, represented as CBDs. Physical objects do not have a notion of inputs and outputs. They are best modeled with equations where any variable can be an input/output, depending on whether it is known (see Acausal modelling chapter). This way, the same component can be reused in many different settings, with its input/outputs defined upon instantiation. In CBDs, the modeler is forced to think of the possible instantiations of the model, and define the inputs/outputs accordingly.

CBDs are widely used in the development of embedded systems. Understanding their semantics and the numerical techniques employed are a stepping stone into understanding other modelling languages.

#### **4.9 Literature and Further Reading**

Among the references already cited, we highlight: [69] provides an extensive overview of the simulation of continuous systems. [279] gives a good introduction to continuous system modelling and simulation, for someone with a background in Computer Science. [60] provides a mathematically oriented description of multiple numerical techniques. Last but not least, [211] and [310] provide an overview of the the challenges involved in hybrid system simulation, of which CBDs with logic blocks are part of.

#### **4.10 Self Assessment**


#### **Acknowledgements**

This work was partially funded with PhD fellowship from the Agency for Innovation by Science and Technology in Flanders (IWT), and the COST Action MPM4CPS. Partial support by the Flanders Make strategic research center for the manufacturing industry is also gratefully acknowledged.

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

## **Chapter 5 DEVS: Discrete-Event Modelling and Simulation for Performance Analysis of Resource-Constrained Systems**

Yentl Van Tendeloo and Hans Vangheluwe

**Abstract** DEVS is a popular formalism for modelling complex dynamic systems using a discrete-event abstraction. At this abstraction level, a timed sequence of pertinent "events" input to a system (or internal, in the case of timeouts) cause instantaneous changes to the state of the system. Between events, the state does not change, resulting in a piecewise constant state trajectory. Main advantages of DEVS are its rigorous formal definition, and its support for modular composition. This chapter introduces the Classic DEVS formalism in a bottom-up fashion, using a simple traffic light example. The syntax and operational semantics of Atomic (i.e., non-hierarchical) models are introduced first. The semantics of Coupled (hierarchical) models is then given by translation into Atomic DEVS models. As this formal "flattening" is not efficient, a modular abstract simulator which operates directly on the coupled model is also presented. This is the common basis for subsequent efficient implementations. We continue to actual applications of DEVS modelling and simulation, as seen in performance analysis for queueing systems. Finally, we present some of the shortcomings in the Classic DEVS formalism, and show solutions to them in the form of variants of the original formalism.

#### **Learning Objectives**

After reading this chapter, we expect you to be able to:


## **5.1 Introduction**

DEVS [309] is a popular formalism for modelling complex dynamic systems using a discrete-event abstraction. At this abstraction level, a timed sequence of pertinent "events" input to a system cause instantaneous changes to the state of the system. These events can be generated externally (*i.e.*, by another model) or internally (*i.e.*, by the model itself due to timeouts). The next state of the system is defined based on the previous state of the system and the event. Between events, the state does not change, resulting in a piecewise constant state

Hans Vangheluwe University of Antwerp - Flanders Make, Belgium; McGill University, Canada e-mail: hans.vangheluwe@uantwerpen.be

Yentl Van Tendeloo

University of Antwerp, Belgium e-mail: Yentl.VanTendeloo@uantwerpen.be

trajectory. Simulation kernels must only consider states at which events occur, skipping over all intermediate points in time. This is in contrast with discrete time models, where time is incremented with a fixed increment, and only at these times is the state updated. Discrete event models have the advantage that their time granularity can become (theoretically) unbounded, whereas time granularity is fixed in discrete time models. Nonetheless, the added complexity makes it unsuited for systems that naturally have a fixed time step.

Main advantages of DEVS compared to other discrete event formalisms are its rigorous formal definition, and its support for modular composition. Comparable discrete event formalisms are DES and Statecharts, though significant differences exist.

Compared to DES, DEVS offers modularity which makes it possible to nest models inside of components, thus generating a hierarchy of models. This hierarchy necessitates couplings and (optionally) ports, which are used for all communication between two components. In contrast, DES models can directly access other models and send them events in the form of method invocation. Additionally, DEVS offers a cleaner split between the simulation model and the simulation kernel.

Compared to Statecharts, DEVS offers a more rigorous formal definition and a different kind of modularity. Statecharts leaves a lot of room for interpretation, resulting in a wide variety of interpretations [140, 138]. In contrast, DEVS is completely formally defined, and there is a reference algorithm (*i.e.*, an abstract simulator). While both DEVS and Statecharts are modular formalisms, Statecharts creates hierarchies through composite states, whereas DEVS uses composite models for this purpose. Both have their distinct advantages, making both variants useful in practice.

This chapter provides an introductory text to DEVS (often referred to as Classic DEVS nowadays) through the use of a simple example model in the domain of traffic lights. We start from a simple autonomous traffic light, which is incrementally extended up to a traffic light with policeman interaction. Each increment serves to introduce a new component of the DEVS formalism and the corresponding (informal) semantics. We start with atomic (*i.e.*, non-hierarchical) models in Section 5.2, and introduce coupled (*i.e.*, hierarchical) models in Section 5.3. An abstract simulator, defining the reference algorithm, is covered in Section 5.4. Section 5.5 moves away from the traffic light example and presents a model of a simple queueing system. Even though DEVS certainly has its applications, several variants have spawned to tackle some of its shortcomings. These variants, together with a rationale and the differences, are discussed in Section 5.6. Finally, Section 5.7 summarises the chapter.

#### **5.2 Atomic DEVS models**

We commence our explanation of DEVS with the atomic models. As their name suggests, atomic models are the indivisible building blocks of a model.

Throughout this section, we build up the complete formal specification of an atomic model, introducing new concepts as they become required. In each intermediate step, we show and explain the concepts we introduce, how they are present in the running example, and how this influences the semantics. The domain we will use as a running example throughout this chapter is a simple traffic light.

#### **5.2.1 Autonomous Model**

The simplest form of a traffic light is an autonomous traffic light. Looking at it from the outside, we expect to see a trace similar to that of Figure 5.1. Visually, Figure 5.2 presents an intuitive representation of a model that could generate this kind of trace.

Trying to formally describe Figure 5.2, we distinguish these elements:

1. **State Set (***S***)** The most obvious aspect of the traffic light is the state it is in, which is indicated by the three different colours it can have. These states are *sequential*: the traffic light can only be in one of these states at the same time1. The set of states is not limited to enumeration style as presented here, but can contain an arbitrary number of attributes.

<sup>1</sup> In contrast to, say, Statecharts.

Fig. 5.1: Trace of the autonomous traffic light.

$$\mathcal{S} : \times\_{i=1}^n \mathcal{S}\_i$$

2. **Time Advance (***ta***)** For each of the states just defined, we notice the timeout in them. Clearly, some states take longer to process than others. For example, whereas we will stay in green and red a relatively long time, the time in the yellow state is only brief. This function needs to be defined for each and every element of the state set, and needs to deterministically return a duration. The duration can be any positive real number, including zero and infinity. A negative time is disallowed, as this would require simulation to go back in time. DEVS allows a time advance of exactly zero, even though this is impossible in real life. Two use cases for this exist: the delay might be very small and irrelevant to the problem we are modelling, or the state is an artificial state, without any real-world equivalent (*e.g.*, as part of a design pattern). Note that DEVS does not consider time bases, despite the use of seconds in our visualisation. Simulation time is just a real number, and the interpretation given to it is up to the user. Whether these units indicate seconds, years, or even π seconds, is completely up to the users, as long as it is fixed throughout the simulation.

$$
tau: \mathcal{S} \to \mathbb{R}^+\_{0, + \infty}
$$

3. **Internal Transition (**δint**)** With the states and timeouts defined, the final part is the definition of which is the next state from a given state. This is the job of the internal transition function, which gives the next state for each and every state. As it is a function, every state has at most one next state, preventing any possible ambiguity. Note that the function does not necessarily have to be total, nor injective: some states might not have a next state (*i.e.*, if the time advance was specified as +∞), and some states have the same state as next state. Up to now, only the internal transition function is described as changing the state. Therefore, it is not allowed for other functions (*e.g.*, time advance) to modify the state: their state access is read-only.

$$
\delta\_{int}: S \to S
$$

4. **Initial Total State (***q*ini t**)** We also need to define the initial state of the system. While this is not present in the original specification of the DEVS formalism, we include it here as it is a vital element of the model [285]. But note that, instead of being an "initial state (*s*ini t)", it is a total state. This means that we not only select the initial state of the system, but also define how long we are already in this state. Elapsed time is therefore added to the definition of the initial total state, to allow more flexibility when modelling a system. To the simulator, it will seem as if the model has already been in the initial state for some time.

*q*ini t : (*s*, *e*)|*s* ∈ *S*, 0 ≤ *e* ≤ *ta*(*s*)

We describe the model in Figure 5.2 as a 4-tuple of these three elements.

<sup>h</sup>*S*, *<sup>q</sup>*ini t , <sup>δ</sup>int , *ta*<sup>i</sup> *S* = {green, yellow, red} *q*ini t = (green, 0.0) <sup>δ</sup>int <sup>=</sup> {green <sup>→</sup> yellow,

yellow → red, red → green} *ta* = {green → delaygreen, yellow → delayyellow , red → delay red }

For this simple formalism, we define the semantics as in Algorithm 4. The model is initialized with simulation time set to 0, and the state set to the initial state (*e.g.*, green). Simulation updates the time with the return value of the time advance function, and executes the internal transition function on the current state to get the new state.

**Algorithm 4** DEVS simulation pseudo-code for autonomous models.

```
time ← 0
cur r ent_st at e ← ini t ial_st at e
last_t ime ← −ini t ial_ela psed
while not termination_condition() do
   t ime ← last_t ime + ta(cur r ent_st at e)
   cur r ent_st at e ← δin t (cur r ent_st at e)
   last_t ime ← t ime
end while
```
#### **5.2.2 Autonomous Model with Output**

Recall that DEVS is a modular formalism, with only the atomic model having access to its internal state. This naturally raises a problem for our traffic light: others have no way of knowing its current state (*i.e.*, its colour).

We therefore want the traffic light to output its colour, in this case in the form of a string (and not as the element of an enumeration). For now, the output is tightly linked to the set of state, but this does not need to be the case: the possible values to output can be completely distinct from the set of states. Our desired trace is shown in Figure 5.3. We see that we now output events indicating the start of the specified period. Recall, also, that DEVS is a discrete event formalism: the output is only a single event indicating the time and is not a continuous signal. The receiver of the event thus would have to store the event to know the current state of the traffic light at any given point in time. Visually, the model is updated to Figure 5.4, using the exclamation mark on a transition to indicate output generation.

Analysing the updated model, we see that two more concepts are required to allow for output.

Fig. 5.3: Trace of the autonomous traffic light with output.

#### 1. **Output Set (***Y***)**

Similarly to defining the set of allowable states, we should also define the set of allowable outputs. This set serves as an interface to other components, defining the events they expect to receive. Events can have complex attributes as well, though we again limit ourself to simple events for now. If ports are used, each port has its own output set.

$$Y: \times\_{i=1}^{l} Y\_{i}$$

# 2. **Output Function (**λ**)**

With the set of allowable events defined, we still need a function to actually generate the events. Similar to the other functions, the output function is defined on the state, and deterministically returns an event (or no event). As seen in the Figure of the model, the event is generated *before* the new state is reached. This means that instead of the new state, the output function still uses the old state (*i.e.*, the one that is being left). For this reason, the output function needs to be invoked right before the internal transition function. In the case of our traffic light, the output function needs to return the name of the *next* state, instead of the current state. For example, if the output function receives the green state as input, it needs to generate a *show\_yellow* event.

Similar to the time advance function, this function does not output a new state, and therefore state access is read-only. This might require some workarounds: outputting an event often has some repercussions on the model state, such as removing the event from a queue or increasing a counter. Since the state cannot be written to, these changes need to be remembered and executed as soon as the internal transition is executed. Note that it is possible for the output function not to return any output, in which case it returns φ.

$$\lambda: S \to Y \cup \{\phi\}$$

The model can be described as a 6-tuple.

<sup>h</sup>*Y*, *<sup>S</sup>*, *<sup>q</sup>*ini t , <sup>δ</sup>int , <sup>λ</sup>, *ta*<sup>i</sup>

*Y* = {*show\_green*,*show\_yellow*,*show\_red*} *S* = {green, yellow, red} *q*ini t = (green, 0.0) <sup>δ</sup>int <sup>=</sup> {green <sup>→</sup> yellow, yellow → red, red → green} λ <sup>=</sup> {green <sup>→</sup> *show\_yellow*, yellow → *show\_red*, red → *show\_green*} *ta* = {green → delaygreen, yellow → delayyellow , red → delay red }

The pseudo-code is slightly altered to include output generation, as shown in Algorithm 5. Recall that output is generated before the internal transition is executed, so the method invocation happens right before the transition.

**Algorithm 5** DEVS simulation pseudo-code for autonomous models with output.

```
time ← 0
cur r ent_st at e ← ini t ial_st at e
last_t ime ← −ini t ial_ela psed
while not termination_condition() do
   t ime ← last_t ime + ta(cur r ent_st at e)
   ou t pu t(λ(cur r ent_st at e))
   cur r ent_st at e ← δin t (cur r ent_st at e)
   last_t ime ← t ime
end while
```
#### **5.2.3 Interruptable Model**

Our current traffic light specification is still completely autonomous. While this is fine in most circumstances, police might want to temporarily shut down the traffic lights, when they are managing traffic manually. To allow for this, our traffic light must process externally generated incoming events; such as events from a policeman to shutdown or startup again. Figure 5.5 shows the trace we wish to obtain. A model generating this trace is shown in Figure 5.6, using a question mark to indicate event reception.

We once more require two additional elements in the DEVS specification.

1. **Input Set (***X***)**

Similar to the output set, we need to define the events we expect to receive. This is again a definition of the interface, such that others know which events are understood by this model.

$$X = \times\_{i=1}^{m} X\_i$$

# 2. **External Transition (**δe x t**)**

Similar to the internal transition function, the external transition function is allowed to define the new state as well. First and foremost, the external transition function is still dependent on the current state, just like the internal transition function. The external transition function has access to two more values; elapsed time and the input event. The *elapsed time* indicates how long it has been for this atomic model since the last transition (either internal or external). Whereas this number was implicitly known in the internal transition function (*i.e.*, the value of the time advance function), here it needs to be passed explicitly. Elapsed time

Fig. 5.6: Naive model that should generate the trace in Figure 5.5 (but does not).

Fig. 5.5: Trace of the autonomous traffic light.

is a number in the range [0, *ta*(*s*)], with *s* being the current state of the model. Note that it is inclusive of both 0 and *ta*(*s*): it is possible to receive an event exactly after a transition happened, or exactly before an internal transition happens. The combination of the current state and the elapsed time is often called the *total state* (*Q*) of the model. We have previously seen the total state, in the context of the initial total state. The received event is the final parameter to this function. A new state is deterministically defined through the combination of these three parameters. Since the external transition function takes multiple parameters, multiple external transitions might be defined for a single state.

$$\begin{aligned} \delta\_{exl} &: \mathcal{Q} \times X \to S \\ \mathcal{Q} &= \{ (s, e) | s \in S, 0 \le e \le ta(s) \} \end{aligned}$$

While we now have all elements of the DEVS specification for atomic models, we are not done yet. When we include the additional state manual, we also need to send out an output message indicating that the traffic light is off. But recall that an output function was only invoked before an internal transition function, so not before an external transition function. To have an output nonetheless, we need to make sure that an internal transition happens before we actually reach the manual state. This can be done through the introduction of an artificial intermediate state, which times out immediately, and sends out the *turn\_off* event. Instead of going to manual upon reception of the *toManual* event, we go to the artificial state going\_manual. The time advance of this state is set to 0, since it is only an artificial state without any meaning in the domain under study. Its output function will be triggered immediately due to the time advance of zero, and the *turn\_off* output is generated while transferring to manual. Similarly, when we receive the *toAuto* event, we need to go to an artificial going\_auto state to generate the *show\_red* event. A visualization of the corrected trace and corresponding model is shown in Figure 5.7 and Figure 5.8 respectively.

Finally, we give the full specification of the traffic light as an atomic DEVS model, defined by a 8-tuple.

$$\langle X, Y, S, q\_{init}, \delta\_{int}, \delta\_{ext}, \lambda, ta \rangle$$

Fig. 5.8: Model generating trace in Figure 5.7.

Fig. 5.7: Trace of the interrupt traffic light with corrected artificial states.

*X* = {*toAuto*, *toManual*} *Y* = {*show\_green*,*show\_yellow*,*show\_red*, *turn\_off*} *S* = {green, yellow, red, going\_manual, going\_auto,manual} *q*ini t = (green, 0.0) <sup>δ</sup>int <sup>=</sup> {green <sup>→</sup> yellow, yellow → red, red → green, going\_manual → manual, going\_auto → red} <sup>δ</sup>e x t <sup>=</sup> {(green, \_, *toManual*) <sup>→</sup> going\_manual (yellow, \_, *toManual*) → going\_manual (red, \_, *toManual*) → going\_manual (manual, \_, *toAuto*) → going\_auto} λ <sup>=</sup> {green <sup>→</sup> *show\_yellow*, yellow → *show\_red*, red → *show\_green*, going\_manual → *turn\_off*, going\_auto → *show\_red*}

*ta* = {green → delaygreen, yellow → delayyellow , red → delay red , manual → +∞, going\_manual → 0, going\_auto → 0}

Algorithm 6 presents the complete semantics of an atomic model in pseudo-code. Similar to before, we still have the same simulation loop, but now we can be interrupted externally. At each time step, we need to determine whether an external interrupt is scheduled before the internal interrupt. If that is not the case, we simply continue like before, by executing the internal transition. If there is an external event that must go first, we execute the external transition.

**Algorithm 6** DEVS simulation pseudo-code for interruptable models.

```
time ← 0
cur r ent_stat e ← ini t ial_stat e
last_t ime ← −ini t ial_ela psed
while not termination_condition() do
   ne x t_t ime ← last_t ime + ta(cur r ent_stat e)
   if t ime_ne x t_event ≤ ne x t_t ime then
       ela psed ← t ime_ne x t_event − last_t ime
       cur r ent_stat e ← δe x t ((cur r ent_stat e, ela psed), ne x t_event)
       t ime ← t ime_ne x t_event
   else
       t ime ← ne x t_t ime
       ou t pu t(λ(cur r ent_stat e))
       cur r ent_stat e ← δin t (cur r ent_stat e)
   end if
   last_t ime ← t ime
end while
```
*Reflective Question* Why is the output function not called as well before the external transition is invoked?

#### **5.3 Coupled DEVS Models**

While our traffic light example is able to receive and output events, there are no other atomic models to communicate with. To combine different atomic models together and have them communicate, we now introduce coupled models. This will be done in the context of our previous traffic light, which is connected to a policeman. The details of the traffic light are exactly like before; the details of the policeman are irrelevant here, as long as it outputs *toAuto* and *toManual* events.

#### **5.3.1 Basic Coupling**

The first problem we encounter with coupling the traffic light and policeman together is the structure: how do we define a set of models and their interrelations? This is the core definition of a coupled model: it is merely a structural model that couples models together. Contrary to the atomic models, there is *no behaviour whatsoever* associated to a coupled model. Behaviour is the responsibility of atomic models, and structure that of coupled models.

To define the basic structure, we need three elements.

1. **Model instances (***D***)**

The set of model instances defines which models are included within this coupled model.

2. **Model specifications (***M S* = {*M*<sup>i</sup> |*i* ∈ *D*}**)**

Apart from defining the different instances of submodels, we must include the atomic model specification of these models. For each element defined in *D*, we include the 8-tuple specifying the atomic model. By definition, a submodel of the coupled DEVS model always needs to be an atomic model. Later on, we will see how this can be extended to support arbitrarily hierarchies.

$$MS = \{M\_i | i \in D\} = \{ (X\_i, Y\_i, S\_i, q\_{init,i}, \delta\_{int,i}, \delta\_{ext,i}, \lambda\_i, ta\_i) | i \in D \}$$

3. **Model influencees (***I S* = {*I*<sup>i</sup> |*i* ∈ *D* ∪ {self }}**)**

Apart from defining the model instances and their specifications, we need to define the connections between them. Connections are defined through the use of influencee sets: for each atomic model instance, we define the set of models influenced by that model. There are some limitations on couplings, to make sure that inconsistent models cannot be created. The following two constraints are imposed:

• *A model should not influence itself.* This constraint makes sense, as otherwise it would be possible for a model to influence itself directly. While there is no significant problem with this in itself, it would cause the model to trigger both its internal and external transition simultaneously. As it is undefined which one should go first, this situation is not allowed. In other words, a model should not be an element in its own set of influencees.

$$\forall i \in D: i \notin I\_i$$

• *Only links within the coupled model are allowed.* This is another way of saying that connections should respect modularity. Models should not directly influence models outside of the current coupled model, nor models deeper inside of other submodels at this level. In other words, the influenced model should be a subset of the set of models in this coupled model.

$$\forall i \in D: I\_i \subseteq D$$

Note that there is no explicit constraint on algebraic loops (*i.e.*, a loop of models that have a time advance equal to zero, preventing the progression of simulated time). If this situation is not resolved, it is possible for simulation to get stuck at that specific point in time. The situation is only problematic if the circular dependency never gets resolved, causing a livelock of the simulation.

A coupled model can thus be defined as a 3-tuple.

$$\langle D, MS, IS \rangle$$

#### **5.3.2 Input and Output**

Our coupled model now couples two atomic models together. And while it is now possible for the policeman to pass the event to the traffic light, we again lost the ability to send out the state of the traffic light. The events cannot reach outside of the current coupled model. Therefore, we need to augment the coupled model with input and output events, which serve as the interface to the coupled model. This adds the components *X*self and *Y*self to the tuple, respectively the set of input and output events, resulting in a 5-tuple.

$$\langle X\_{self}, Y\_{self}, D, MS, IS \rangle$$

The constraints on the couplings need to be relaxed to accommodate for the new capabilities of the coupled model: a model can be influenced by the input events of the coupled model, and likewise the models can also influence the output events of the coupled model. The previously defined constraints are relaxed to allow for self , the coupled model itself.

$$\forall i \in D \cup \{self\}: i \notin I\_i$$

$$\forall i \in D \cup \{self\}: I\_i \subseteq D \cup \{self\}$$

#### **5.3.3 Tie-breaking**

Recall that DEVS is considered a formal and precise formalism. But while all components are precisely defined, their interplay is not completely defined yet: what happens when the traffic light changes its state at exactly the same time as the policeman performs its transition? Would the traffic light switch on to the next state first and then process the policeman's interrupt, or would it directly respond to the interrupt, ignoring the internal event? While it is a minimal difference in this case, the state reached after the timeout might respond significantly different to the incoming event.

DEVS solves this problem by defining a **tie-breaking function (***select***)**. This function takes all conflicting models and returns the one that gets priority over the others. After the execution of that internal transition, and possibly the external transitions that it caused elsewhere, it might be that the set of imminent models has changed. If multiple models are still imminent, we repeat the above procedure (potentially invoking the *select* function again with the new set of imminent models).

$$s 
text{ : } 2^D \to D$$

This new addition changes the coupled model to a 6-tuple.

$$\langle X\_{self}, Y\_{self}, D, MS, IS, select \rangle$$

#### **5.3.4 Translation Functions**

Finally, in this case we had full control over both atomic models that are combined. We might not always be that lucky, as it is possible to reuse atomic models defined elsewhere. Depending on the application domain of the reused models, they might work with different events. For example, if our policeman and traffic light were both predefined, with the policeman using *go\_to\_work* and *take\_break* and the traffic light listening to *toAuto* and *toManual*, it would be impossible to directly couple them together. While it is possible to define wrapper blocks (*i.e.*, artificial atomic models that take an event as input and, with time advance equal to zero, output the translated version), DEVS provides a more elegant solution to this problem.

Connections are augmented with a **translation function (***Z*i,j**)**, specifying how the event that enters the connection is translated before it is handed over to the endpoint of the connection. The function thus maps output events to input events, potentially modifying their content.

$$\begin{array}{ccc} Z\_{self,j} : X\_{self} \to X\_f \,\,\forall j \in D\\ Z\_{i,self} : Y\_i \to Y\_{self} \quad \forall i \in D\\ Z\_{i,j} \quad : Z\_i \to X\_j \quad \forall i, j \in D \end{array}$$

These translation functions are defined for each connection, including those between the coupled model's input and output events.

$$ZS = \{ Z\_{i,j} | i \in D \cup \{self\}, j \in I\_i \}$$

The translation function is implicitly assumed to be the identity function if it is not defined. In case an event needs to traverse multiple connections, all translation functions are chained in order of traversal.

With the addition of this final element, we define a coupled model as a 7-tuple.

$$\langle X\_{self}, Y\_{self}, D, MS, IS, ZS, selected \rangle$$

#### **5.3.5 Closure Under Coupling**

Similar to atomic models, we need to formally define the semantics of coupled models. But instead of explaining the semantics from scratch, by defining some pseudo-code, we map coupled models to equivalent atomic models. Semantics of a coupled model is thus defined in terms of an atomic model. In addition, this flattening removes the constraint of coupled models that their submodels should be atomic models: if a coupled model is a submodel, it can be flattened to an atomic model.

In essence, for any coupled model specified as

$$$$

we define an equivalent atomic model specified as

$$$$

Therefore, we have to define all the elements of the atomic model in terms of elements of the coupled model. The input and output variables *X* and *Y* are easy, since they stay the same.

$$\begin{aligned} X &= X\_{self} \\ Y &= Y\_{self} \end{aligned}$$

From an external point of view, the interface of the atomic and coupled model is identical: it has the same input and output events and expects the same kind of data on all of them.

The state *S* encompasses the parallel composition of the states of all the submodels, including their elapsed times (*i.e.*, the total state *Q*, as defined previously):

$$\mathcal{S} = \times\_{i \in D} Q\_i$$

with the total states *Q*<sup>i</sup> previously defined as:

$$Q\_i = \{(s\_i, e\_i) \mid s\_i \in S\_i, 0 \le e\_i \le t a\_i(s\_i)\}, \forall i \in D$$

The elapsed time is stored for each model separately, since the elapsed time of the new atomic model updates more frequently than each submodel's elapsed time.

The initial total state is again composed of two components: the initial state (*s*ini t) and the initial elapsed time (*e*ini t). First, we consider the elapsed time (*e*ini t), which is intuitively equal to the time since the last transition of the flattened model, meaning that it is the minimum of all initial elapsed times, found in all atomic submodels. Then, the initial state (*s*ini t) is to be specified, which is the composition of all initial total states of all atomic submodels. Note, however, that for each initial total state of the submodels, the minimum elapsed time (*e*ini t) is to be decremented. Indeed, *q*ini t specifies that we entered state *s*ini t in the past, more specifically *e*ini t time units ago.

$$q\_{init} = (s\_{init}, e\_{init})$$

$$s\_{init} = (\ldots, (s\_{init,i}, e\_{init,i} - e\_{init}), \ldots)$$

$$e\_{init} = \min\_{i \in D} \{ e\_{init,i} \}$$

The time advance function *ta* then returns the minimum of all remaining times.

$$
tau(s) = \min \{ \sigma\_i = ta\_i(s\_i) - e\_i | i \in D \},
$$

The imminent component is chosen from the set of all models with the specified minimum remaining time (*IMM*). This set contains all models whose remaining time (σi) is identical to the time advance of the flattened model (*ta*). The *select* function is then used to reduce this set to a single element *i* ∗ .

$$\begin{aligned}IMM(s) &= \{ i \in D | \sigma\_i = ta(s) \} \\ i^\* &= select(IMM(s)) \end{aligned}$$

The output function λ executes the output function of *<sup>i</sup>* ∗ and applies the translation function, but only if the model influences the flattened model directly (*i.e.*, if the output of *i* ∗ is routed to the coupled model's output). If there is no connection to the coupled model's output (*i.e.*, *i* ∗ is only coupled to other atomic models), no output function is invoked here. We will see later on that these events are still generated, but they are consumed internally elsewhere.

$$\mathcal{A}(s) = \begin{cases} Z\_{i^\*,self}(\lambda\_{i^\*}(s\_{i^\*})) & \text{if } self \in I\_{i^\*} \\ \phi & \text{otherwise} \end{cases}$$

The *internal transition function* is defined for each part of the state separately:

$$\delta\_{\acute{i}nt}(\mathbf{s}) = (\dots, (s\_j', e\_f'), \dots)$$

With three kinds of models: (1) the model *i* ∗ itself, which just performs its internal transition function; (2) the models influenced by *i* ∗ , which perform their external transition based on the output generated by *i* ∗ ; (3) models unrelated to *i* ∗ . In all cases, the elapsed time is updated.

$$(s'\_j, e'\_j) = \begin{cases} (\delta\_{\operatorname{int},j}(s\_j), 0) & \text{for } j = i^\*, \\ (\delta\_{\operatorname{ex},j}((s\_j, e\_j + ta(\mathbf{s})), Z\_{i^\*,j}(\lambda\_{i^\*}(s\_{i^\*}))), 0) & \text{for } j \in I\_{i^\*}, \\ (s\_j, e\_j + ta(\mathbf{s})) & \text{otherwise} \end{cases}$$

Note that the internal transition function includes external transition functions of submodels for those models influenced by *i* ∗ . As *i* ∗ outputs events that are consumed internally, this all happens internally.

The *external transition* function is similar to the internal transition function. Now two types are distinguished: (1) models directly connected to the input of the model, which perform their external transition; (2) models not directly connected to the input of the model, which only update their elapsed time.

$$\delta\_{ext}((s,e),\boldsymbol{x}) = (\dots,(s'\_i,e'\_i),\dots)$$

$$(s'\_i, e'\_i) = \begin{cases} (\delta\_{e \ge t, i}((s\_i, e\_i + e), Z\_{self, i}(\mathbf{x})), 0) & \text{for } i \in I\_{self} \\ (s\_i, e\_i + e) & \text{otherwise} \end{cases}$$

*Reflective Question* Is it possible to replace the translation function *Z* by an atomic DEVS model that takes input and puts the translated value on its output, while preserving semantics?

#### **5.4 The DEVS Abstract Simulator**

Up to now, the semantics of atomic models was defined through natural language and high-level pseudo-code. Coupled models were given semantics through a mapping to these atomic models. Both of these have their own problems. For atomic models, the pseudo-code is not sufficiently specific to create a compliant DEVS simulator: a lot of details of the algorithm are left unspecified (*e.g.*, where does the external event come from). For coupled models, the flattening procedure is elegant and formal, though it is highly inefficient to perform this flattening at run-time.

To counter these problems, we will define a more elaborate, and formal, simulation algorithm for both atomic and coupled models. Atomic models get a more specific definition with a clear interface, and coupled models get their own simulation algorithm without flattening. Coupled models are thus given "operational semantics" instead of "translational semantics".

This simulation algorithm, an *abstract simulator* forms the basis for more efficient simulation algorithms, and serves as a reference algorithm. Its goal is to formally define the semantics of both models in a concise way, without caring about performance or implementation issues. Adaptations are allowed, but the final result should be identical: simulation results are to be completely independent from the implementation. A direct implementation of the abstract simulator is inefficient, and actual implementations therefore vary significantly.

We now elaborate on the abstract simulator algorithm. For each atomic and coupled model, an instance is created of the respective algorithm.

Table 5.1 shows the different variables used, their type, and a brief explanation.

Table 5.1: Variables used in the abstract simulator.


We furthermore distinguish five types of synchronization messages, as exchanged between the different abstract simulators. An overview of messages is shown in Table 5.2.

Table 5.2: Types of synchronization messages.


First is the abstract simulation algorithm for atomic models, presented in Algorithm 7. This algorithm consists of a big conditional, depending on the message that is received. Atomic models only perform an operation upon reception of a message: there is no autonomous behaviour. This algorithm is invoked every time a synchronisation message is received. Messages consist of three components: the type of the message, the source of the message, and the simulation time. The conditional consists of three options: On the reception of an *i* message, we perform *initialization* of the simulation time.

Another option is the reception of a ∗ message, triggering a *transition*. The message consists of both a sender and the time at which the transition should happen. By definition, a transition can only happen at time *t*n, so we assert this. After this check, we have to perform the following steps: (1) generate the output, (2) send it out to the sender of the ∗ message (our parent), (3) perform the internal transition, (4) update our time with the time advance, and (5) indicate to our parent that we finished processing the message, also passing along our time of next transition.

Finally, it is possible to receive an *x* message, indicating *external input*. This can happen anytime between our last transition (*t*l), and our scheduled transition (*t*n), so we again assert the simulation time. Note that these times are inclusive: due to the *select* function it is possible that another model comes right after or before our own scheduled transition. We perform the following steps: (1) compute the elapsed time (*e*) based on the provided simulation time (*t*), (2) perform the external transition, (3) update the simulation time of the next transition, and (4) indicate to our parent that we finished processing the message, also passing along our time of next transition.

#### **Algorithm 7** DEVS atomic model abstract simulator.

```
if receive (i, f r om, t) message then
   tl ← t − e
   tn ← tl + ta(s)
   send (done, sel f , tn ) to par ent
else if receive (∗, f r om, t) message then
   if t = tn then
       y ← λ(s)
       if y , φ then
           send (y, sel f , t) to par ent
       end if
       s ← δin t (s)
       tl ← t
       tn ← tl + ta(S)
       send (done, sel f , tn ) to parent
   end if
else if receive (x, f r om, t) message then
   if tl ≤ t ≤ tn then
       e ← t − tl
       s ← δe x t ((s, e), x)
       tl ← t
       tn ← tl + ta(s)
       send (done, sel f , tn ) to par ent
   else
       error: bad synchronization
   end if
end if
```
Recall that the abstract simulation algorithm did not have any autonomous behaviour. This indicates that there is another entity governing the progression of the simulation This simulation entity is the root coordinator, and it encodes the main simulation loop. Its algorithm is shown in Algorithm 8. As long as simulation needs to continue, it sends out a message to the topmost model in the hierarchy to perform transitions. When a reply is received, simulation time is progressed to the time indicated by the topmost model.


Finally, while not completely necessary due to the existence of the flattening algorithm, we also define a shortcut for the simulation of coupled models. The abstract simulation algorithm for coupled models is shown in Algorithm 9. Coupled models can receive all five different types of synchronisation messages.

First, the *i* message again indicates *initialization*. It merely forwards the message to all of its children and marks each child as active. Every coupled model has a *t*<sup>l</sup> and *t*<sup>n</sup> variable as well, which is defined as the maximum, respectively minimum, of its children. This is logical, as any transition of its children will also require an operation on the coupled model containing it. When a message is sent to a submodel, the submodel is marked as active. The use for this is shown in the processing of the *done* message.

Second, the ∗ message again indicates a *transition*. Contrary to the atomic models, a coupled model is unable to perform a transition itself. Instead, it forwards the message to the imminent submodel, found by executing the *select* function for all models that have that exact same *t*n. Only a single model will be selected, and a ∗ message is sent to that model. Just like before, the model is marked as active to make sure that we wait for its computation to finish.

Third, a y message indicates an *output* message. The output message is output by the output function of a subcomponent, and needs to be routed through the coupled model. This part of the function is responsible for routing the message to the influencees of the model that sent out the message. Note that it is also possible that one of the influencees is *sel f* , indicating that the message needs to be routed externally (*i.e.*, to the output of the coupled model). In any case, the message needs to be translated using the translation function. The actual translation function that is invoked depends on the source and destination of the message.

Fourth, a *x* message can be received, indicating *input*. This is mostly identical to the output messages, only now can we also handle messages that were received from our own parent.

Finally, a *done* message can be received, indicating that a submodel has *finished* its computation. The submodel, which was marked as an active child, will now be unmarked. When *done* messages are received from all submodels (*i.e.*, all children are inactive), we determine our own *t*<sup>l</sup> and *t*<sup>n</sup> variables and send out the minimal *t*<sup>n</sup> of all submodels. This time is then sent to the parent.

The abstract simulator for coupled models can work with any kind of submodel, not necessarily atomic models. In deep hierarchies, the *done* message always propagates the minimal *t*<sup>n</sup> upwards in the hierarchy. In the end, the root coordinator will always receive the minimal *t*n, which is the time of the earliest next internal transition.

*Reflective Question* Is it possible for an atomic DEVS model to do an internal and external transition at the same point in simulated time? Explain your answer.

#### **5.5 Application to Queueing Systems**

The usefulness of DEVS of course goes further than traffic lights. To present a more realistic model and highlight the potential for performance analysis, we present a simple queueing system next. While a lot has been done in queueing theory, we present simulation as an alternative to the mathematical solutions. Even though the

**Algorithm 9** DEVS coupled model abstract simulator.

```
if receive (i, f r om, t) message then
   for all d in D do
       send (i, sel f , t) to d
       ac t ive_chil dr en ← ac t ive_chil dr en ∪ {d}
   end for
else if receive (∗, f r om, t) message then
   if t = tn then
       i∗ = sel ec t({Mi
                          .tn = t |i ∈ D})
       send (∗, sel f , t) to i∗
       ac t ive_chil dr en ← ac t ive_chil dr en ∪ {i
                                                          ∗
                                                           }
   end if
else if receive (y, f r om, t) message then
   for all i ∈ If r om \ {sel f } do
       send (Zf r om,i (y), f r om, to) to i
       ac t ive_chil dr en ← ac t ive_chil dr en ∪ {i}
   end for
   if sel f ∈ If r om then
       send (Zf r om,sel f (y), sel f , t) to par ent
   end if
else if receive (x, f r om, t) message then
   if tl ≤ t ≤ tn then
       for all i ∈ If r om do
           send (Zsel f ,i (x), sel f , t) to i
           ac t ive_chil dr en ← ac t ive_chil dr en ∪ {i}
       end for
   end if
else if receive (done, f r om, t) message then
   ac t ive_chil dr en ← ac t ive_chil dr en \ {f r om}
   if ac t ive_chil dr en = φ then
       tl ← ma x {tl,d |d ∈ D}
       tn ← min{tn,d |d ∈ D}
       send (done, sel f , tn ) to par ent
   end if
end if
```
mathematical solutions have their advantages, simulation offers more flexibility and does not get that complex. It is, however, necessarily limited to "sampling": simulations will only take samples and will therefore generally not find rare and exceptional cases. Not taking them into account is fine in many situations, as it is now in our example model.

In this section, we present a simple queueing problem. Variations on this model — in either its behaviour, structure, or parameters — are easy to do.

#### **5.5.1 Problem Description**

In this example, we model the behaviour of a simple queue that gets served by multiple processors. Implementations of this queueing systems are widespread, such as for example at airport security. Our model is parametrisable in several ways: we can define the random distribution used for event generation times and event size, the number of processors, performance of each individual processor, and the scheduling policy of the queue when selecting a processor. Clearly, it is easier to implement this, and all its variants, in DEVS than it is to model it mathematically. For our performance analysis, we show the influence of the number of processors (*e.g.*, metal detectors) on the average and maximal queueing time of jobs (*e.g.*, travellers).

A model of this system can be shown in Figure 5.9. Events (people) are generated by a generator using some distribution function. They enter the queue, which decides the processor that they will be sent to. If multiple processors are available, it picks the processor that has been idle for the longest; if no processors are available, the event is queued until a processor becomes available. The queue works First-In-First-Out (FIFO) in case multiple events are queueing. For a processor to signal that it is available, it needs to signal the queue. The queue keeps track of available processors. When an event arrives at a processor, it is processed for some time, depending on the size of the event and the performance characteristics of the processor. After processing, the processor signals the queue and sends out the event that was being processed.

Fig. 5.9: Queue system with a single generator, single queue, and *n* processors.

#### **5.5.2 Description in DEVS**

While examples could be given purely in their formal description, they would not be executable and would introduce a significant amount of accidental complexity. We use the tool PythonPDEVS2 [282, 283] to implement the DEVS model and perform simulations. In PythonPDEVS, DEVS models are implemented by defining methods that implement the different aspects of the tuple. All code within these methods is just normal Python code, though a minimal number of API calls is required in the case of a coupled DEVS model. Since most DEVS tools work similarly, these examples could easily be transposed to other DEVS simulation tools. An overview of popular DEVS simulation tools is shown in [284].

To specify this model, we first define the event exchanged between different models: the *Job*. A job is coded as a class Job. It has the attributes *size* (*i.e.*, indicative of processing time) and *creation time* (*i.e.*, for statistic gathering). The Job class definition is shown in Listing 1.

```
class Job :
    def __init__ ( self , size , creation_time ) :
         # Jobs have a size and creation_time parameter
         self.size = size
         self.creation_time = creation_time
                       Listing 1: PythonPDEVS code for the Job event.
```
We now focus on each atomic model separately, starting at the event generator.

The *generator* is defined as an atomic model using the class Generator, shown in Listing 2. Classes that represent an atomic model inherit from the AtomicDEVS class. They should implement methods that implement each of the DEVS components. Default implementations are provided for a passivated model, such that unused functions do not need to be defined. In the constructor, input and output ports are defined, as well as model parameters and the initial state. We see that the definition of the generator is very simple: we compute the time remaining until the next event (remaining), and decrement the number of events to send. The generator also keeps track of the current simulation time, in order to set the creation time of events. The time advance function returns the time remaining until the next internal transition. Finally, the output function returns a new customer

<sup>2</sup> Download: http://msdl.cs.mcgill.ca/projects/DEVS/PythonPDEVS

event with a randomly defined size. The job has an attribute containing the time at which it was generated. Recall, however, that the output function was invoked before the internal transition, so the current time has not yet been updated by the internal transition. Therefore, the output function also has to do this addition, without storing the result in the state (as it cannot write to the state).

```
from pypdevs . DEVS import AtomicDEVS
from job import Job
import random
# Define the state of the generator as a structured object
class GeneratorState :
    def __init__ ( self , gen_num ):
         # Current simulation time ( statistics )
         self . current_time = 0.0
         # Remaining time until generation of new event
         self . remaining = 0.0
         # Counter on how many events to generate still
         self . to_generate = gen_num
class Generator ( AtomicDEVS ) :
    def __init__ ( self , gen_param , size_param , gen_num ) :
         AtomicDEVS . __init__ ( self , " Generator " )
         # Output port for the event
         self . out_event = self . addOutPort ( " out_event " )
         # Define the state
         self . state = GeneratorState ( gen_num )
         # Parameters defining the generator 's behaviour
         self . gen_param = gen_param
         self . size_param = size_param
    def intTransition ( self ) :
         # Update simulation time
         self . state . current_time += self . timeAdvance ()
         # Update number of generated events
         self . state . to_generate -= 1
         if self . state . to_generate == 0:
             # Already generated enough events , so stop
             self . state . remaining = float ('inf ')
         else :
             # Still have to generate events , so sample for new duration
             self . state . remaining = random . expovariate ( self . gen_param )
         return self . state
    def timeAdvance ( self ) :
         # Return remaining time ; infinity when generated enough
         return self . state . remaining
    def outputFnc ( self ) :
         # Determine size of the event to generate
         size = max (1 , int( random . gauss ( self . size_param , 5) ))
         # Calculate current time ( note the addition !)
         creation = self . state . current_time + self . state . remaining
         # Output the new event on the output port
         return { self . out_event : Job ( size , creation ) }
                 Listing 2: PythonPDEVS code for the Generator atomic model.
```
Next up is the queue, which is the most interesting component of the simulation, as it is the part we wish to analyze. The Queue implementation is similar in structure to the Generator. Of course, the DEVS parts get a different specification, as shown in Listing 3. The queue takes a structural parameter, specifying the number of processors. This is needed since the queue has an output port for each processor. When an internal transition happens, the queue knows that it has just output an event to the first idle processor. It thus marks the first idle processor as busy, and removes the event it was currently processing. If there are events remaining in the queue, and a processor is available to process it, we process the first element from the queue and set the remaining\_time counter. In the external transition, we check the port we received the event on. Either it is a signal of the processor to indicate that it has finished, or else it is a new event to queue. In the former case, we mark the processor that sent the event as idle, and potentially process a queued message. For this to work, the processor should include its ID in the event, as otherwise the queue has no idea who sent this message. In the latter case, we either process the event immediately if there are idle processors, or we store it in the queue. The time advance merely has to return the remaining\_time counter that is managed in both transition functions. Finally in the output function, the model outputs the first queued event to the first available processor. Note that we can only read the events and processors, and cannot modify these lists: state modification is reserved for the transition functions. An important consideration in this model is the remaining\_time counter, which indicates how much time remains before the event is processed. We cannot simply put the processing time of events in the time advance, as interrupts could happen during this time. When an interrupt happens (*e.g.*, another event arrives), the time advance is invoked again, and would return the total processing time, instead of the remaining time to process the event. To solve this problem, we maintain a counter that explicitly gets decremented when an external interrupt happens.

```
from pypdevs . DEVS import AtomicDEVS
```

```
# Define the state of the queue as a structured object
class QueueState :
    def __init__ ( self , outputs ) :
         # Keep a list of all idle processors
         self . idle_procs = range ( outputs )
         # Keep a list that is the actual queue data structure
         self . queue = []
         # Keep the process that is currently being processed
         self . processing = None
         # Time remaining for this event
         self . remaining_time = float ( " inf " )
class Queue ( AtomicDEVS ) :
    def __init__ ( self , outputs ) :
         AtomicDEVS . __init__ ( self , " Queue " )
         # Fix the time needed to process a single event
         self . processing_time = 1.0
         self . state = QueueState ( outputs )
         # Create 'outputs ' output ports
         # 'outputs ' is a structural parameter !
         self . out_proc = []
         for i in range ( outputs ) :
             self . out_proc . append ( self . addOutPort ( " proc_ % i " % i ) )
         # Add the other ports : incoming events and finished event
         self . in_event = self . addInPort ( " in_event ")
         self . in_finish = self . addInPort ( " in_finish " )
    def intTransition ( self ) :
         # Is only called when we are outputting an event
         # Pop the first idle processor and clear processing event
```

```
self . state . idle_procs . pop (0)
    if self . state . queue and self . state . idle_procs :
         # There are still queued elements , so continue
         self . state . processing = self . state . queue . pop (0)
         self . state . remaining_time = self . processing_time
    else :
         # No events left to process , so become idle
         self . state . processing = None
         self . state . remaining_time = float ( " inf " )
    return self . state
def extTransition ( self , inputs ) :
    # Update the remaining time of this job
    self . state . remaining_time -= self . elapsed
    # Several possibilities
    if self . in_finish in inputs :
         # Processing a " finished " event , so mark proc as idle
         self . state . idle_procs . append ( inputs [ self . in_finish ])
         if not self . state . processing and self . state . queue :
              # Process first task in queue
              self . state . processing = self . state . queue . pop (0)
              self . state . remaining_time = self . processing_time
    elif self . in_event in inputs :
         # Processing an incoming event
         if self . state . idle_procs and not self . state . processing :
              # Process when idle processors
              self . state . processing = inputs [ self . in_event ]
              self . state . remaining_time = self . processing_time
         else :
              # No idle processors , so queue it
              self . state . queue . append ( inputs [ self . in_event ])
    return self . state
def timeAdvance ( self ) :
    # Just return the remaining time for this event ( or infinity else
        )
    return self . state . remaining_time
def outputFnc ( self ) :
    # Output the event to the processor
    port = self . out_proc [ self . state . idle_procs [0]]
    return { port : self . state . processing }
              Listing 3: PythonPDEVS code for the Queue atomic model.
```
The next atomic model is the Processor class, shown in Listing 4. It merely receives an incoming event and starts processing it. Processing time, computed upon receiving an event in the external transition, is dependent on the size of the task, but takes into account the processing speed and a minimum amount of processing that needs to be done. After the task is processed, we trigger our output function and internal transition function. We need to send out two events: one containing the job that was processed, and one to signal the queue that we have become available. For this, two different ports are used. Note that the definition of the processor would not be this simple in case there was no queue before it. We can now make the assumption that when we get an event, we are already idle and therefore don't need to queue new incoming events first.

from pypdevs . DEVS import AtomicDEVS

# Define the state of the processor as a structured object

```
class ProcessorState ( object ) :
    def __init__ ( self ) :
         # State only contains the current event
         self . evt = None
class Processor ( AtomicDEVS ) :
    def __init__ ( self , nr , proc_param ) :
         AtomicDEVS . __init__ ( self , " Processor_ % i " % nr )
         self . state = ProcessorState ()
         self . in_proc = self . addInPort ( " in_proc " )
         self . out_proc = self . addOutPort ( " out_proc " )
         self . out_finished = self . addOutPort ( " out_finished " )
         # Define the parameters of the model
         self . speed = proc_param
         self . nr = nr
    def intTransition ( self ) :
         # Just clear processing event
         self . state . evt = None
         return self . state
    def extTransition ( self , inputs ) :
         # Received a new event , so start processing it
         self . state . evt = inputs [ self . in_proc ]
         # Calculate how long it will be processed
         time = 20.0 + max (1.0 , self . state . evt . size / self . speed )
         self . state . evt . processing_time = time
         return self . state
    def timeAdvance ( self ) :
         if self . state . evt :
              # Currently processing , so wait for that
              return self . state . evt . processing_time
         else :
              # Idle , so don 't do anything
              return float ('inf ')
    def outputFnc ( self ) :
         # Output the processed event and signal as finished
         return { self . out_proc : self . state . evt ,
                  self . out_finished : self . nr }
                  Listing 4: PythonPDEVS code for the Processor atomic model.
```
The processor finally sends the task to the Collector class, shown in Listing 5. The collector is an artificial component that is not present in the system being modelled; it is only used for statistics gathering. For each job, it stores the time in the queue.

```
from pypdevs . DEVS import AtomicDEVS
# Define the state of the collector as a structured object
class CollectorState ( object ) :
    def __init__ ( self ) :
        # Contains received events and simulation time
        self . events = []
```

```
self . current_time = 0.0
class Collector ( AtomicDEVS ) :
    def __init__ ( self ) :
         AtomicDEVS . __init__ ( self , " Collector " )
         self . state = CollectorState ()
         # Has only one input port
         self . in_event = self . addInPort ( " in_event " )
    def extTransition ( self , inputs ) :
         # Update simulation time
         self . state . current_time += self . elapsed
         # Calculate time in queue
         evt = inputs [ self . in_event ]
         time = self . state . current_time - evt . creation_time - evt .
             processing_time
         inputs [ self . in_event ]. queueing_time = max (0.0 , time )
         # Add incoming event to received events
         self . state . events . append ( inputs [ self . in_event ])
         return self . state
    # Don 't define anything else , as we only store events .
    # Collector has no behaviour of its own .
```
Listing 5: PythonPDEVS code for the Collector atomic model.

With all atomic models defined, we only have to couple them together in a coupled model, as shown in Listing 6. In this system, we instantiate a generator, queue, and collector, as well as a variable number of processors. The number of processors is variable, but is still static during simulation. The couplings also depend on the number of processors, as each processor is connected to the queue and the collector.

```
from pypdevs . DEVS import CoupledDEVS
# Import all models to couple
from generator import Generator
from queue import Queue
from processor import Processor
from collector import Collector
class QueueSystem ( CoupledDEVS ) :
    def __init__ ( self , mu , size , num , procs ) :
         CoupledDEVS . __init__ ( self , " QueueSystem " )
         # Define all atomic submodels of which there are only one
         generator = self . addSubModel ( Generator ( mu , size , num ) )
         queue = self . addSubModel ( Queue (len( procs ) ) )
         collector = self . addSubModel ( Collector () )
         self . connectPorts ( generator . out_event , queue . in_event )
         # Instantiate desired number of processors and connect
         processors = []
         for i , param in enumerate ( procs ) :
             processors . append ( self . addSubModel (
                                  Processor (i , param ) ) )
             self . connectPorts ( queue . out_proc [ i ] ,
                                  processors [ i ]. in_proc )
```

```
self . connectPorts ( processors [ i ]. out_finished ,
                         queue . in_finish )
    self . connectPorts ( processors [ i ]. out_proc ,
                         collector . in_event )
# Make it accessible outside of our own scope
self . collector = collector
```
Listing 6: PythonPDEVS code for the System coupled model.

Now that our DEVS model is completely specified, we can start running simulations on it. Simulation requires an *experiment* file though, which initializes the model with parameters and defines the simulation configuration. An example experiment, again in Python, is shown in Listing 7. The experiment writes out the raw queueing times to a Comma Separated Value (CSV) file. An experiment file often contains some configuration of the simulation tool, which differs for each tool. For PythonPDEVS, the documentation3 provides an overview of supported options.

```
from pypdevs . simulator import Simulator
import random
# Import the model we experiment with
from system import QueueSystem
# Configuration :
# 1) number of customers to simulate
num = 500
# 2) average time between two customers
time = 30.0
# 3) average size of customer
size = 20.0
# 4) efficiency of processors ( products / second )
speed = 0.5
# 5) maximum number of processors used
max_processors = 10
# End of configuration
# Store all results for output to file
values = []
# Loop over different configurations
for i in range (1 , max_processors ) :
    # Make sure each of them simulates exactly the same workload
    random . seed (1)
    # Set up the system
    procs = [ speed ] * i
    m = QueueSystem ( mu =1.0/ time , size = size , num = num , procs = procs )
    # PythonPDEVS specific setup and configuration
    sim = Simulator ( m )
    sim . setClassicDEVS ()
    sim . simulate ()
    # Gather information for output
    evt_list = m . collector . state . events
    values . append ([ e . queueing_time for e in evt_list ])
```
<sup>3</sup> http://msdl.cs.mcgill.ca/projects/DEVS/PythonPDEVS/documentation/html/index.html

```
# Write data to file
with open ('output . csv ', 'w') as f :
     for i in range ( num ) :
          f. write ( " % s " % i )
          for j in range ( len( values ) ) :
               f. write ( " , %5 f " % ( values [ j ][ i ]) )
          f. write ( " \ n " )
```
Listing 7: PythonPDEVS code for the experiment on the system.

#### **5.5.3 Performance Analysis**

After the definition of our DEVS model and experiment, we of course still need to run the simulation. Simply by executing the experiment file, the CSV file is generated, and can be analyzed in a spreadsheet tool or plotting library. Depending on the data stored during simulation, analysis can show the average queueing times, maximal queueing times, number of events, processor utilization, and so on.

Corresponding to our initial goal, we perform the simulation in order to find out the influence of opening multiple processors on the average and maximum queueing time. Figure 5.10 shows the evolution of the waiting time for subsequent clients. Figure 5.11 shows the same results, drawn using boxplots. These results indicate that while two processors are able to handle the load, maximum waiting time is rather high: a median of 200 seconds and a maximum of around 470 seconds. When a single additional processor is added, average waiting time decreases significantly, and the maximum waiting time also becomes tolerable: the mean job is served immediately, with 75% of jobs being handled within 25 seconds. Further adding processors still has a positive effect on queueing times, but the effect might not warrant the increased cost in opening processors: apart from some exceptions, all customers are processed immediately starting from four processors. Ideally, a cost function would be defined to quantize the value (or dissatisfaction) of waiting jobs, and compare this to the cost of adding additional processors. We can then optimize that cost function to find out the ideal balance between paying more for additional processors and losing money due to long job processing times. Of course, this ideal balance depends on several factors, including our model configuration and the cost function used.

*Reflective Question* What would you have to change in order to use a different queueing discipline or arrival process? How does this compare to the changes needed when using a mathematical model of this same process?

#### **5.6 DEVS Variants**

Despite the success of the original DEVS specification, as introduced throughout this chapter, shortcoming were identified when used in some domains. For these reasons, a lot of variants have recently spawned. In this section, we touch upon the three most popular ones, with some remarks on other variants. Note that we make the distinction between variants that further augment the DEVS formalism (*i.e.*, make more constructs available), and those that restrict it (*i.e.*, prevent several cases). Both have their reasons, mostly related to the implementation: augmenting the DEVS formalism makes it easier for modellers to create models in some domains, whereas limiting the DEVS formalism makes some operations, such as analysis, possible or easier to implement.

#### **5.6.1 Parallel DEVS**

One of the main problems identified in DEVS is related to performance: when multiple models are imminent, they are processed sequentially. While DEVS does allow for some parallelism, (*e.g.*, between simultaneous external transitions), multiple internal transitions is a common occurrence.

Fig. 5.10: Evolution of queueing times for subsequent customers. Fig. 5.11: Boxplot of queueing times for varying number of active processors.

Parallel DEVS [72] was introduced as a variant of the DEVS formalism, in which parallel execution of internal transition functions is allowed. This changes the semantics of models though, so it requires changes to the abstract simulator [73]. The proposed changes are therefore not just syntactic sugar: they explicitly modify the semantics of models.

Allowing for parallelism is, however, not a trivial task: several modifications are required, which we briefly mention here. The first logical change is the removal of the *select* function: instead of selecting a model to go first, all imminent models are allowed to transition simultaneously. Whether or not this happens in parallel or not, as it might not necessarily be faster [148], is up to the implementation. This creates some repercussions throughout the remainder of the formalism, as the *select* function was introduced for good reasons.

Since models can now perform their internal transition simultaneously, output functions also happen simultaneously. While this is in itself not a problem, routing might cause the need for events to be merged together, for example when two events get routed to the same model. The abstract simulator was not designed for this, as an external transition was immediately invoked upon the reception of an external event. So in Parallel DEVS, events are always encapsulated in *bags*, which can easily be merged. Bags, or multisets, are a kind of set which can contain items multiple times. This way, multiple bags can be trivially joined, without losing information. Note that order is undefined, as otherwise it would depend on the synchronisation between different output functions: which one is executed before the other. Due to this change in interface, the external transition needs to be altered to operate on a bag of input events, and the output function has to generate a bag of output events.

Problems don't stop there, as internal and external transition might happen simultaneously. Recall that in DEVS, self-loops were not allowed for this exact purpose. In Parallel DEVS, however, two models can perform their internal transition simultaneously, with one outputting an event for the other one. In that case, the model needs to process both its internal transition, and its external transition caused by the other model's transition. Since there is no priority defined between them (that was part of the purpose of the *select* function), they should execute simultaneously. To allow for this, a new kind of transition is defined: the *confluent transition function*. This transition is only performed when both the internal and external transition happen simultaneously. Parallel DEVS leaves open what the semantics of this is, though a sane default is for the internal transition to go first, followed by the external transition.

Thanks to the potential performance gains, many tools favor Parallel DEVS over DEVS in their implementation. Some stick to the elegance of the original DEVS formalism, despite the performance hit.

#### **5.6.2 Dynamic Structure DEVS**

Another shortcoming of the DEVS formalism, also present in Parallel DEVS, is the lack of dynamic structure. Some systems inherently require a dynamic structure to create, modify, or delete models during the simulation. While possible in DEVS formalism by defining the superset of all possible configurations and activating only one of them, this has high accidental complexity, and performance suffers. Furthermore, systems might grow extremely big, making it practically impossible to create all possible configurations statically.

To counter these issues, Dynamic Structure DEVS [23] was devised as an extension of DEVS. In Dynamic Structure DEVS, the model configuration is seen as a part of the state, making it modifiable during simulation. Since the coupled model has no state of its own, a *network executive* is added, which manages the structural state of a specific scope. In a separate phase, models can send events to the network executive to request a structural change.

This proposed extension is, however, only a mathematical model as to how it can be made possible. Similar to previous formalisms, an abstract simulator [25] is provided that is structured that way. Real implementations, however, are free to implement this however they want. The network executive might therefore not even exist in the implementation, with all structure changing messages being intercepted in the implementation.

Even though dynamic structure now becomes possible in DEVS models, this formalism is not well suited to handle a huge amount of changes. The work to be done for a change, both for the user and the implementation, is just too time-consuming to execute frequently. But even while highly dynamic models are not ideally suited, infrequent structural changes become very possible.

#### **5.6.3 Cell-DEVS**

Another variant of DEVS presented here is the Cell-DEVS formalism. Despite the elegance of the DEVS formalism, it is still difficult to use it in a variety of situations, specifically in the context of cellular models. Cellular Automata [305] are a popular choice in the domain of cellular models, but contrary to the discrete-event nature of DEVS, Cellular Automata is discrete-time based. While discrete-time is a good match with most models in the problem domain of cellular automata, some models would profit from a discrete-event basis. While not frequently a problem, cellular models become restricted to the granularity of the time step, resulting in low performance when the time step is not a good match with the model's transition times.

Cell-DEVS was introduced as a combination of DEVS and Cellular Automata, combining the best of both worlds. Model specification is similar to Cellular Automata models, but the underlying formalism used for simulation is actually DEVS. Due to this change, models gain more control over the simulation time. Furthermore, cellular models can now be coupled to other, not necessarily cellular, DEVS models.

#### **5.6.4 Other Variants**

Apart from the formalisms introduced here, many more variants exist that tackle very specific problems in DEVS. We do not have the space here to discuss all of them, though we wish to provide some pointers to some other useful extensions. Examples are other solutions to the dynamic structure problem (DynDEVS [275]), restrictions to make DEVS models analysable (FD-DEVS [152]), and extensions to allow for non-determinism (Fuzzy DEVS [177]). Many of the previously proposed formalisms also have augmented themselves with the changes made to Parallel DEVS, resulting in a parallel version of Dynamic Structure DEVS [24] and Cell-DEVS [273].

*Reflective Question* What does it mean for there to be extensions to DEVS, while we previously stated that DEVS can be seen as a simulation assembly language?

#### **5.7 Summary**

In this chapter, we briefly presented the core ideas behind DEVS, a popular formalism for the modelling of complex dynamic systems using a discrete-event abstraction. DEVS is primarily used for the simulation of queueing networks, of which an example was given, and performance models. It is most applicable for the modelling of discrete event systems with component-based modularity. It can, however, be used much more generally as a simulation assembly language, or as a theoretical foundation for these formalisms.

Future learning directions on DEVS can be found in the Further Reading section, which provides a list of relevant extensions on DEVS, as well as mentions of some of the problems currently being faced in DEVS.

#### **5.8 Literature and Further Reading**

Zeigler's book [309] is the default reference for the DEVS formalism and contains further information on other related formalisms. It mostly focusses on the theoretical aspects of modelling and simulation, though some examples are given. A more practical introduction to the formalism of DEVS and examples and how to actually use the formalism and the tool CD++ are given by Wainer [301]. Finally, another text Nutaro [218] develops the design and development of efficient simulators.

The contributions that lead to the the most common variant of DEVS that is in use today have been presented in some landmark papers. Most DEVS research is currently being made on Parallel DEVS [72]. A complete formalisation of simulation formalisms starting from DEVS in [24]. Another paper by Chen [70] presentes the symbolic flattening (closure under coupling) that is actually implemented in Parallel Devs. The idea of DEVS as a simulation assembly language. Details are given on why such a language is necessary, and what the implications are is found in [287]. Currently a lot of DEVS tools exist, but there is almost no interoperability in any way between them. Even today, DEVS standardisation is ongoing work [252].

#### **5.9 Self-Assessment**


#### **Acknowledgements**

This work was partly funded with a PhD fellowship grant from the Research Foundation - Flanders (FWO). Partial support by the Flanders Make strategic research centre for the manufacturing industry is also gratefully acknowledged.

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

## **Chapter 6 Statecharts: A Formalism to Model, Simulate and Synthesize Reactive and Autonomous Timed Systems**

Simon Van Mierlo and Hans Vangheluwe

**Abstract** Statecharts, introduced by David Harel in 1987, is a formalism used to specify the behaviour of timed, autonomous, and reactive systems using a discrete-event abstraction. It extends Timed Finite State Automata with depth, orthogonality, broadcast communication, and history. Its visual representation is based on higraphs, which combine graphs and Euler diagrams. Many tools offer visual editing, simulation, and code synthesis support for the Statechart formalism. Examples include STATEMATE, Rhapsody, Yakindu, and Stateflow, each implementing different variants of Harel's original semantics. This tutorial introduces modelling, simulation, and testing with Statecharts. As a running example, the behaviour of a digital watch, a simple yet sufficiently complex timed, autonomous, and reactive system is modelled. We start from the basic concepts of states and transitions and explain the more advanced concepts of Statecharts by extending the example incrementally. We discuss several semantic variants, such as STATEMATE and Rhapsody. We use Yakindu to model the example system.

#### **Learning Objectives**

After reading this chapter, we expect you to be able to:


## **6.1 Introduction**

The systems that we analyse, design, and build today are characterised by an ever-increasing complexity. This complexity stems from a variety of sources, such as the complex interplay of physical components (sensors and actuators) with (real-time) software, the large amounts of data these systems have to process, and the interaction with a (non-deterministic) environment. Almost always, however, complex systems exhibit some for of *reactivity* to the environment: the system *reacts* to stimuli coming from the environment (in the form of *input events*) by changing its internal *state* and can influence the environment through *output events*. Such reactive systems are fundamentally different from traditional software systems, which are *transformational* (i.e., they receive a number of input parameters, perform computations, and return the result as output). Reactive

Hans Vangheluwe

Simon Van Mierlo

University of Antwerp - Flanders Make, Belgium e-mail: simon.vanmierlo@uantwerpen.be

University of Antwerp - Flanders Make, Belgium; McGill University, Canada e-mail: hans.vangheluwe@uantwerpen.be

systems run continuously, often have multiple concurrently executing components, are reactive with respect to the environment, and can act proactively by making autonomous decisions. An example is a modern car, whose systems are increasingly controlled by software. Multiple concurrently running software components are interpreting signals coming from the environment (the driver's controls as well as sensors interpreting current driving conditions) and making (autonomous) decisions that generate signals to the car's actuators.

Such timed, reactive, autonomous behaviour needs to be specified in an appropriate language, in order to validate the behaviour with respect to its specification (using verification and validation techniques, such as formal verification, model checking, as well as testing techniques), and to ultimately deploy the software onto the system's hardware components. Traditional programming languages were designed with transformational systems in mind, and are not well-suited for describing timed, autonomous, reactive, and concurrent behaviour. In fact, describing complex systems using threads and semaphores quickly results in unreadable, incomprehensible, and unverifiable program code [181]. This is partly due to the cognitive gap between the abstractions offered by the languages and the complexity of the specification, as well as the sometimes ill-defined semantics of programming languages, which hampers understandability. As an alternative, this book chapter describes the Statechart formalism, introduced by David Harel in 1987 [134]. The syntax and semantics of Statecharts are well-defined and can natively describe a system's timed, autonomous, reactive, and concurrent behaviour. Its basic building blocks are states and transitions between those states. States can be combined hierarchically into composite states, or orthogonally into concurrent regions. Many (visual) modelling tools exist that support the complete life-cycle of modelling a system's behaviour using Statecharts: from design to verification and validation, and ultimately deployment (code generation).

Throughout the sections of this chapter, we introduce the constructs of the Statechart formalism by incrementally building the model of the behaviour of an example system. We explain the syntax as well as the semantics of each construct. The examples are modelled in the Yakindu tool (https://www.itemis.com/en/yakindu/ state-machine/), but the techniques can be transferred to any Statecharts modelling and simulation tool with comparable functionality.

Section 6.2 provides background for the rest of the chapter: it explains how we can view a system's behaviour using a discrete-event abstraction, it explains the behaviour of the example digital watch system we are going to model, and it introduces a process model that can be used to build a system (from requirements, through design, down to deployment) using Statecharts. Section 6.3 explains each Statechart construct, starting from the basic state and transition, and progressively introducing more advanced constructs. Section 6.4 explains the semantics of Statecharts (as implemented by STATEMATE) in detail. Section 6.5 explains how Statechart models can be tested, to check whether they satisfy the requirements of the system. Section 6.6 explains how code can be generated from a Statechart model and deployed onto a target platform. Section 6.7 goes into a number of advanced topics. Section 6.8 summarises this chapter.

#### **6.2 Background**

This chapter provides background for the rest of the chapter. In Section 8.4, we explain the running example that we will model using Statecharts in the next section. In Section 6.2.2, we look at a system's behaviour using a discrete-event abstraction. Finally, in Section 6.2.3, we present a process model that can be used to model a system using Statecharts, verify that it satisfies the requirements (through simulation and testing), and finally deploy it.

#### **6.2.1 Running Example**

The example system we use in this chapter to demonstrate the capabilities of the *Statechart* formalism is a digital watch. A visual representation of the watch is shown in Figure 6.1. A watch is primarily used for keeping time, but has other functions, such as chronometer, an alarm, and a light. A user can interact with the watch by pressing buttons that result in switching between the different modes, editing the current time, turning on the light, . . . It is inherently timed and autonomous, as it changes its internal state without any input from the user.

Fig. 6.1: The running digital watch application.

Some notion of orthogonality is also present, as the system has to ensure time is updated while the chronometer is running, for example.

A full specification of the requirements is given below:


These requirements now need to be translated to a design of the system. Many options exist: since we are talking about control *software*, a possible choice would be a high-level programming language. But as we have argued

Fig. 6.2: Discrete-event abstraction of an example "tank wars" game.

Fig. 6.3: A possible behavioural model of an example "tank wars" game.

earlier in this chapter, a more appropriate choice (to describe this timed, reactive, autonomous behaviour) is the *Statechart* language.

#### **6.2.2 Discrete-Event Abstraction**

Certain system behaviour, in particular the behaviour of control software, can be described using a discrete-event abstraction. In Figure 6.2 a view of the behaviour of an example system is shown – in this case, the system is a "tank wars" game, in which a tank drives around a virtual map by reacting to a player's input through the keyboard. The tank can shoot at the player's command, and it can run out of fuel, at which point it goes into a mode where it can only drive towards a fuelling station (and is no longer able to shoot).

As is clear from this intuitive description, the system reacts to *input* from the environment, and produces *output* to the environment. Such input/output signals can be described by *events*. At the top of Figure 6.2, an input event *segment* is shown. A segment is a finite interval of time, in which a number of events occur. Within such a finite interval, only a finite number of such events can occur (which differentiates discrete-event systems from continuous systems, whose input and output behaviour we can infinitely zoom into, as they are continuous functions). The system *reacts* to the input event segment by producing an output event segment, shown at the bottom of Figure 6.2. The environment (entities interacting with the system) can view the system as a black-box which has an interface (defined by the input events it accepts, as well as the output events it produces). In this case, the player interacts with the system by sending input events corresponding to key strokes: the player controls the tank by pressing the *up*, *down*, and *enter* key. As a result, the system produces output, which describes the reaction of the system to the input it receives. In this case, four output events can be produced: *move\_up*, *move\_down*, and *shoot*, which signify that the tank starts moving up, starts moving down, or shoots, respectively, and *low\_fuel*, which signifies that the tank is low on fuel.

The system has an internal state, which changes over time as a result of input being received, as well as autonomously by the system. A possible system state trajectory for the example system is shown in the middle of Figure 6.2. Three states are defined: *shooting*, *moving*, and *low\_fuel*. The first two input events do not cause the state of the system to change, but it does cause two corresponding output events to be raised by the system. The third input event changes the system state from *moving* to *shooting*. And, at some point after that, the

Fig. 6.4: The workflow for modelling, simulating, testing, and ultimately generating code from Statechart models.

system autonomously changes its state to *low\_fuel*. From the input, output, and state trace, we can deduce that the system is *timed* (its behaviour includes timeouts), *reactive* (to input from the environment), and *autonomous* (as it can change the system state without any input from the environment).

To describe all possible state trajectories of the system, a state diagram can be used – see Figure 6.3 for a possible model describing the system's behaviour. It shows the different states or *modes* the system can be in: at the highest level, three states (*moving*, *shooting*, and *low\_fuel*) are defined (represented by rounded rectangles). The *moving* state has three substates, corresponding to the direction the tank is traveling in. The state of the system can change when a transition (represented by an arrow) *triggers*. A transition triggers due to an (optional) *event* or *timeout*, and an optional *condition* on the total state of the system (including the values of the system's variables). When a transition is triggered, an action is executed, which can change the values of the system's variables, or *raise* an event.

This concludes a high-level description of discrete-event abstractions to describe a system's behaviour, including a possible diagrammatic notation. In the rest of this chapter, the *Statechart* formalism is explained as an example of such a diagrammatic language to describe the timed, reactive, and autonomous behaviour of systems.

#### **6.2.3 Process**

As a running example that demonstrates the use of Statecharts, we will develop a Statechart model describing the timed, autonomous, and reactive behaviour of a digital watch. Whenever a system is developed, however, it is important to consider which steps are taken and which artefacts are created in the system development process, and to describe this process in a model. This process, or workflow, will guide us throughout the chapter to design, simulate, test, and ultimately deploy our example system. Figure 6.4 shows a model of this process, in a *Formalism Transformation Graph and Process modelling* (FTG+PM) language [195].

On the right side, a process model (PM) describes the different phases in developing the system. The process consists of several *activities*, either manual or automatic. Manual activities require user input: for example, creating a model starts with a user opening a model editor and ends when the user saves the model and closes the model editor. Automatic activities are programs that are transformational, in the sense that they can be seen as black boxes that take input and produce output. All activities produce *artefacts*, and can receive artefacts as input. Fork and join nodes can split the workflow into parallel branches, where multiple activities are active at the same time. Decision nodes can decide, depending on a boolean value, how the process proceeds.

On the left side, a formalism transformation graph (FTG) is a map of all the *languages* used during system development. Each artefact produced in the process model conforms to a language in the formalism transformation graph. Moreover, it defines the *transformations* between the languages, which can either be manual or automatic. Again, there is a correspondence between activities in the process model and transformations in the formalism transformation graph: the transformations act as an "interface" defining the input and output artefacts, to which the activities in the workflow need to conform.

In our workflow, we will start by defining the requirements of the example system and developing an initial model of the system. This model is subsequently (and in parallel) simulated and tested. A simulation produces an output trace from a given input trace (according to the discrete-event abstraction discussed earlier). This output trace is manually checked and a decision is made whether or not the requirements are satisfied. In the other parallel branch of the workflow, a test case is defined by a generator (which produces input events) and an acceptor, which checks whether the generated output trace is correct. A test runs fully automatically, and again a decision is made whether the requirements are satisfied by the design of the system. If that is not the case, the model of the system is revised until all requirements are satisfied. Once all requirements are satisfied, the system can be deployed by generating appropriate application code. In our case, the system is deployed by generating Python code and coupling it to a visualization of the (simulated) digital watch as shown in Figure 6.1.

#### **6.3 Modelling with Statecharts**

The previous section introduces the requirements of our example digital watch example, explains how we can view its behaviour with a discrete-event abstraction, and describes a process for developing the system using the Statechart formalism. In this section, we explain the elements of the Statechart formalism that can be used to model the timed, reactive, and autonomous behaviour of systems. We start with the basic concepts of states and transitions, and gradually introduce the more advanced concepts of depth, orthogonality, broadcast communication, and history. Each new concept's syntax and semantics are explained, and is illustrated by progressively developing the running example's model.

#### **6.3.1 States and Transitions**

The basic building blocks of any Statechart model are *states* and *transitions* between those states. They are essential concepts that need to be explained before moving onto more advanced Statechart elements. These basic building blocks have a theoretical underpinning in Finite State Automata [150]. To illustrate the use of states and transitions, two parts of the digital watch behaviour are shown in Figure 6.5 and Figure 6.6, implementing the part of the system that updates the clock value every second, and the part of the system that is responsible for turning on and off the Indiglo light.

Fig. 6.5: Updating the clock value every second.

States model the *mode* a system is in. In the absence of concurrent regions, exactly one state is active at any point in time of the system's execution. A state has a *name*, uniquely identifying it. Exactly one state in the model is the initial state – on system start-up, the state of the system is initialised to that initial state. The visual representation of a state is a rounded rectangle, or roundtangle. To visualize the initial state, a small black circle is drawn, with an arrow pointing to the initial state.

In Figure 6.6, three states are modelled, implementing the behaviour of the Indiglo light: *off* (the default state), *pushed*, and *released*. These names are strategically chosen to reflect the state of the actual ("physical") watch (the display). However, there is no direct link between the name of the state and the state of the display: the names are merely used to quickly convey their meaning to a person looking at the model; the actual behaviour (turning on and off the light) has to be implemented in the link between the Statechart model (or more precisely, its generated code) and the platform code (*i.e.*, the physical digital watch and its embedded software platform, or in our case, a simulated platform in Python). The state *off* represents the light being off; the state *pressed* represents the state where the user is pressing the top right button (turning on the light); the state *released* represents the state where the user has released the top right button.

Besides the state – or mode – the system is in, a system keeps track of a number of *state variables* {v1, <sup>v</sup>2, . . . , <sup>v</sup><sup>n</sup> }. The data type and possible assignments for these variables depend on the data model supported by the specific variant of the Statechart formalism. In case of Yakindu, the implementation-language-independent types *integer*, *real*, *boolean*, *string*, and *void* are defined1. These variables with names {v1, <sup>v</sup>2, . . . , <sup>v</sup><sup>n</sup> } and types {*t*1, *<sup>t</sup>*2, . . . , *<sup>t</sup>*<sup>n</sup> } have values {v*al*1, <sup>v</sup>*al*2, . . . , <sup>v</sup>*al*<sup>n</sup> } where <sup>v</sup>*al*<sup>i</sup> <sup>∈</sup> *dom*(*t*i) <sup>∀</sup>*<sup>i</sup>* <sup>∈</sup> [1, . . . , *<sup>n</sup>*]

While states describe the current configuration the system is in, transitions model the dynamics of the system and describe how this configuration evolves over time. A transition connects exactly two states: the *source* state and the *target* state. When the system is running, a transition can *trigger* when a number of conditions are satisfied. When the transition triggers, the current state of the system is changed from the source state to the target state. At the same time, the transition's *action* is executed. In general, the signature of a transition is written as follows: < *tri*gg*er* <sup>−</sup> *<sup>e</sup>*v*ent* > [< *tri*gg*er* <sup>−</sup> *condition* >] / < *action* >. The triggering condition of a transition consists of the following elements:

• A triggering *event* (optional), identified by a *name* and a list of *parameters*. In general, an event has the following signature: < *<sup>e</sup>*v*ent* <sup>−</sup> *name* > (< *<sup>e</sup>*v*ent* <sup>−</sup> *params* >). The event can be an input event (coming from the environment) or it can be internal to the Statechart model. The triggering event can also be a

<sup>1</sup> https://www.itemis.com/en/yakindu/state-machine/documentation/user-guide/sclang\_statechart\_language\_ reference#sclang\_types

timeout, which is identified by the reserved event name *after* and a parameter denoting the amount of time (using a certain time granularity) that will pass until the timeout triggers.

• A triggering *condition* (optional), which models a boolean condition on the state of the system. The condition can check the values of system variables and check whether a specific state (in another orthogonal component, see Section 6.3.3) is active.

A transition that has no trigger is said to be *spontaneous*. The transition leaving the marker for the initial state is always spontaneous. The transition's action can:


In Figure 6.6, transitions are modelled that describe the dynamic behaviour of the Indiglo light: it turns on when the *topRightPressed* event arrives from the environment. It stays on as long as the button is not released; if it is, the light stays on for 2 seconds and then turns off again. The *interface* of this model consists of the set of accepted input events *X* = {*topRi*g*htPressed*, *topRi*g*htReleased*}, the set of possible output events *Y* = ∅, and a set of callback functions {*set Indi*g*lo*, *unset Indi*g*lo*}. When this model is deployed (by generating code) and placed in an environment, the environment can send input events belonging to the input event set to the running system. It can listen to output events raised by the system and take appropriate actions. Moreover, on system start-up, it has to provide implementations for the call-back functions: these implementations are not known by the Statechart model, as they will change the ("physical") state of the system. In this sense, the same model can be placed in different environments to implement the same behaviour on different "physical" systems; for example, an updated version of the system's hardware might not necessarily entail a change in the behaviour of the system. In this case, we can update the hardware and its associated environment, but leave the Statechart model the same and generate code that is placed in the new environment.

#### **6.3.2 Composite States**

A composite state is a collection of substates, which themselves can be basic states or composite states. This allows for nesting states to arbitrary depths. The main purpose of composite states is to group behaviours that logically belong together. Transitions entering a composite state will enter its default state (transitively, to the lowest level). This means that all composite states need to have exactly one default state, as was the case for the Statechart model as well. It is also possible to enter a child state of the composite state directly by targeting it, of course. Transitions going out of a composite state can be thought of as being defined on all of the inner states as well – through a flattening procedure, it is possible to obtain an equivalent Statechart model that only contains basic states and transitions.

For example, in Figure 6.7, the behaviour of the alarm is modelled. A composite state *blinking* is defined: it is entered when the *checkTime* procedure returns true (signifying that the time of the alarm has been reached). Upon entering the *blinking* state, the default *on* state is entered as well (and, if an action is defined on the transition to the default state, it is executed as well). Two outgoing transitions are defined: when the user presses any button, or after 4 seconds, the alarm is turned off. Regardless of the internal active state of *blinking*, when the outer transition is triggered, that active state is exited before the *blinking* state is exited and the *off* state is entered.

One important issue with composite states is that unwanted non-determinism can occur if a substate has an outgoing transition that is triggered on the same event as its composite state's transition. In the flattened version of the Statechart model, this non-determinism will be obvious, since a state will have two outgoing transitions that are triggered on the same event. We can obtain the flattened version of a Statechart model by removing hierarchy: we only retain "leaf" (basic states), by adding the transitions that leave (or enter) their ancestor states on the leaf state. By doing this recursively (starting at the lowest level), we remove hierarchy by progressively adding these "higher-level" transitions to the basic states.

For example, in Figure 6.7, if there was a transition on the *topRightPressed* event from the state *on* to the state *off*, the model is non-deterministic in case the *on* state is active when a *topRightPressed* event is raised by the environment. To resolve such non-determinism (as Statecharts is a deterministic formalism), either the outer-most transition can be chosen – as is the case in STATEMATE [141] – or the inner-most transition can

Fig. 6.7: The component that controls the alarm behaviour.

be chosen – as in Rhapsody [139]. These different options are presented in Figure 6.8, which also shows the flattened version of the models. In this tutorial, we assume STATEMATE semantics.

#### **6.3.3 Orthogonal Regions**

States can be combined hierarchically in composite states (as explained in the previous subsection), or orthogonally in concurrent regions. While before, exactly one state of the Statechart model was active at the same time, when entering a state which has concurrent regions, all regions execute simultaneously. Each region has a default state, that is entered when the region is entered. Orthogonal regions can react to events concurrently, and communicate with each other. This is done by raising events in one concurrent region that are "sensed" by the other concurrent regions (broadcast communication). A second way in which orthogonal regions can communicate is by querying the state of another orthogonal region: the triggering condition of a particular condition could include a constraint on which state is active in a different orthogonal region.

Figures 6.5, 6.6, and 6.7 all are orthogonal to each other. Indeed: the time needs to be updated, even if the Indiglo light is turned on, or the alarm goes off. Otherwise, the watch would be useless as a timekeeping device. A fourth orthogonal component is shown in Figure 6.9. It controls the display of the digital watch, by switching

Fig. 6.8: Non-determinism in composite state; (a) an example model containing non-determinism, (b) flattened version: non-determinism in state A, (c) Statemate semantics: outermost transition is prioritized, (d) Rhapsody semantics: innermost transition is prioritized.

(in the *displaying* composite state) between the *displaying\_time*, *displaying\_chrono*, and *displaying\_alarm* states when the user presses the top left button. The user can edit both the current time, as well as the time at which the alarm is set. For this, there is a transition from the *displaying\_time* and *displaying\_alarm* state to the *editing\_time* state, where the user can increase the hours/minutes/seconds by pressing the bottom left button, and change the current selection by pressing the bottom right button. The *display* orthogonal component communicates with the *time* orthogonal component by raising the *time\_edit* and *edit\_done* events. This will ensure that the time is not updated while the user is editing it.

#### **6.3.4 History**

A last element of the Statechart formalism is the *history* state. A history state can be placed in a composite state as a direct child. It remembers the current state the composite state is in when the composite state is exited. Two types of history states exist: *shallow* history states remember the current state at its own level, while *deep* history states remember the current state at its own level and all lower levels in the hierarchy. When a transition has the history state as its target, the state that was remembered is restored (instead of entering the default state of the composite state).

In Figure 6.9, a shallow history state remembers the active direct child of the *displaying* composite state when it is exited (*i.e.*, when a transition to the *editing\_time* state is taken). Upon returning from the *editing\_time* state, the history state will restore the last active state, to ensure that we end up back in the *displaying\_time* or the *displaying\_alarm* state, depending on what we were editing. If no history state were present, we would always end up back in the *displaying\_time* (default) state.

Fig. 6.9: The component that controls the display behaviour.

#### **6.3.5 Syntactic Sugar**

The previous subsections discussed the essential elements of the Statechart formalism. There are, however, additional syntactic constructs that make the modeller's life easier, but can be modelled using the "standard" Statechart constructs as well.

One of those "syntactic sugar" additions is the entry/exit action for states, which is a more efficient way of specifying actions that always need to be executed when a state is entered or exited, instead of repeating the action on each incoming/outgoing transition. An entry action is executed when a state is entered, while an exit action is executed when a state is exited. This has an important effect on the semantics of executing a transition combined with composite states. A transition is defined between states *A* and *B*. When executing this transition, the state A is exited, and the state B is entered. However, this is only the case if A and B are direct descendants of the same composite state. More states are exited if A is part of a state hierarchy, and more states are entered in case B is part of a (different) state hierarchy. To execute a transition, the "least common ancestor" (LCA) state is computed from the source state A and target state B. The LCA is a state up the hierarchy of both A and B that has both A and B as a substate (and is the bottom-most state to have that property). To execute a transition, starting from A, the states in the hierarchy up to but not including the LCA are exited (and their exit actions are executed in the same order). Then, the transition's action is executed. Then, the states down the hierarchy towards B are entered, including B but excluding the LCA (and their enter actions are executed in the same order).

Entry and exit actions have been shown throughout the components of the digital watch model in this chapter. For example, for the alarm orthogonal component of Figure 6.7, whenever the *blinking* state is exited (which signifies that the alarm "triggered" and the blinking phase is over), the alarm is disabled by a call to *setAlarm*, and the Indiglo light is turned off by a call to *unsetIndiglo*. Were we not to model this action as an exit action, we would have to repeat it on the two transitions that leave the *blinking* state. Within the *blinking* composite state, the *on* state has an entry action that turns on the Indiglo light. Were we not to model this action as an entry action, we would have to repeat it on the incoming transition that marks this state as the initial state, and the incoming transition from the *off* state.

#### **6.3.6 Full Statechart Model**

The full Statechart model (where the previously discussed orthogonal regions have been placed in subdiagrams) of the digital watch is shown in Figure 6.10. One extra component not discussed in the previous subsections is the *chrono* component, which is responsible for increasing the chronometer when it is activated. Note that the chronometer can only be activated when the chronometer is shown (in the *display* component); the *active* function takes a state reference as a parameter and returns *true* when the state is active at that moment.

#### **6.4 Detailed Semantics**

The detailed semantics of Statecharts are more intricate than first meets the eye. In this section, we explain the semantics of Statecharts according to its implementation in STATEMATE [141]. As was already touched upon, some semantic variations are possible if multiple options can be chosen (for example, taking the inner or outer transition if there is a conflict in a composite state). In Section 6.7, we will explain that more options are possible.

The execution of a Statechart is divided into (micro)steps. An event queue holds the events that are currently raised (either by the environment, or locally by the Statechart). It also keeps track of timeouts that will expire in the future (corresponding to an *after* condition on a transition). In each microstep, the execution algorithm decides which transition(s) (in different orthogonal regions) are enabled. They are executed (in arbitrary order) by changing the state of the system from the source state of each transition to its target state. In detail, the execution algorithm works as follows:

1. A set of candidate transitions is generated that are enabled by events that were raised locally in a previous step, by timeouts, or by events coming from the environment. The candidate transitions are filtered by

Fig. 6.10: The full Statechart model of the behaviour of the digital watch.

evaluating their condition (which is a boolean function on the total state of the system). The state of the system stays constant until all the transitions execute (at the same time); a function which checks whether a particular state is active does not depend on which transition fires first (as the check is done before any transition fires).

	- Two candidate transitions can be in conflict if they have the same source state. In the case of STATE-MATE, the execution algorithm cannot give priority to one or the other; as such, a warning is issued to the user and one of the candidates is chosen arbitrarily. More elaborate schemes could assign priority to these transitions based on other criteria; these will be discussed in Section 6.7.1.
	- Two candidate transitions can be in conflict if they are enabled in the same hierarchical state (on any level of the hierarchy). In case of STATEMATE, the top-most transition in the hierarchy is chosen.
	- a. The *Least Common Ancestor* (LCA) of the transition is calculated. This is the state that is lowest in the hierarchy of states that has both the source and the target state as descendant.
	- b. The exit set of the transition is calculated. This set contains all the states that need to be exited when the transition is executed. This includes the source state of the transition, as well as all the states in the hierarchy up to (but excluding) the LCA.
	- c. For each composite state in the exit set that has a history state as a direct child, the current configuration of the composite state is remembered.
	- d. For each state in the exit set (in order, from lowest to highest in the hierarchy), its exit action is executed and the state is removed from the current configuration of the system.
	- e. The action of the transition is executed. Actions that are modelled using code (such as value assignments) are immediately executed. Events that are raised are placed in the queue, either to be sent to the

environment as output at the end of the step, or to be sensed by the Statechart in the next iteration of the execution algorithm.


This process is continued indefinitely – or until an end condition on the execution is satisfied. For example, a particular state could syntactically be designated as the "final" state, or a condition could be defined on the full state of the system. In any case, the execution algorithm is responsible for respecting the timings specified in *after*-events, by pacing the execution in such a way to approach real-time execution (with or without guarantees, depending on the operating system).

#### **6.5 Testing Statecharts**

To test a Statechart model, we need to define a trace of input events and an expected trace of output events, as was shown in Figure 6.4. Tests need to be fully automated. Therefore, we need a different tactic from simulating the model and manually providing the input events, while checking the model's reaction. We want to autonomously generate a number of events (timed) in a "generator" and check whether the system raises the correct events in an "acceptor". Basically, an environment interacting with the system is simulated in the form of this generator-acceptor pair.

To simulate such an environment, either we regard the system as black box and use a mechanism to generate events correctly outside of the model. Alternatively, we can view the system as a white box and model the generator/acceptor pair using Statecharts as well. This has the advantage of instrumenting the model in the same language as it was developed in. Moreover, the Statechart language is appropriate to express the behaviour of the generator and acceptor, as they are timed, autonomous, reactive systems. This is illustrated in Figure 6.11, where we develop a test case for (a part of) the digital watch model. The generator and acceptor are modelled as orthogonal regions alongside the actual system.

The test case tests the expected behaviour of the digital watch in case the user wants to edit the time. To do this, an input event corresponding to the user pressing the bottom right button is raised after 1 second. The acceptor checks whether this results in the system switching to the *waiting\_to\_edit* state. Next, after an additional 1.6 seconds, the bottom right button is released, which should result in the system state changing to *editing\_time*. Then, 0.4 seconds later, the bottom left button is pressed; this results in the *increasing* state to be activated until the bottom left button is released (after 3 seconds). Then, 5 seconds later, the system should automatically switch to the *displaying\_time* state again. If the test ends up in the *passed* state, the *testPassed* callback is called, signifying that the test has passed. Otherwise, the *testFailed* callback is called.

Due to our white-box approach, we were able to both check the output events produced by the system, as well as its internal state. To be able to check the events raised by the model, we had to change these events to be locally raised, instead of raised to the environment. If we were testing using a black-box approach, the generator and acceptor could be modelled as separate Statechart models, and a communication channel between the generator, the system, and the acceptor could be set up. However, this has the disadvantage of a delay being introduced by the communication channels, which might be difficult to account for in the generator and acceptor. It does allow for testing a system for which we do not have access to the model, but it is outside of the scope of this chapter.

Fig. 6.11: The extra components of the digital watch test.

#### **6.6 Deploying Statecharts**

Once we have specified the timed, reactive, autonomous behaviour of a system, it needs to be deployed onto a target platform. The most common method of doing so is by generating code in a high-level language such as C++, Python, or Java. The generated code is then coupled (through its interface of input/output events and callback operations) to a (hand-coded) platform that implements the non-modal (*i.e.*, non-timed, -reactive, or -autonomous) behaviour. Most often, this platform consists of a number of library functions that perform some action, such as displaying information on a screen, sending a signal to an actuator, or querying the value of a sensor. An execution kernel for the platform also has to exist, which is responsible for implementing the behaviour specified by the Statechart – more information on these platforms can be found in Section 6.7.2.

For code generation, we rely on Yakindu. Yakindu is a Statecharts modelling and simulation tool, with the following features:


Figure 6.3.6 shows the digital watch model, as it was modelled in Yakindu. Central to the figure is the canvas, on which the Statechart model is drawn. The tool is "syntax-directed", which means only syntactically correct models can be constructed. The valid syntactic elements are shown on the right side in a palette. These elements correspond to the ones discussed in the previous sections, along with a few extra syntactic sugar elements, which will not be discussed here. On the left of the figure, an interface for the Statechart model is defined. This interface makes explicit the possible input, output, and locally raised events, as well as any data variables and callbacks. In the previous sections, we have left this definition of the interface implicit, but Yakindu requires to make it explicit for various reasons:


By checking the syntactic validity of the model, as well as the validity of condition triggers and action code, Yakindu prevents many possible errors that a modeller can make. We can, from this model, also generate a running application. In our case, we will generate the behaviour and visualize it in a Python GUI, which shows the current state of the system (depending on the display mode either the current time, the chrono, or the alarm, as well as the Indiglo light), and allows to interact with the system by pressing the four buttons of the watch. To do this, we define a visualization library that can display the state of our system. It has the following interface:


This library can be instantiated to show (and change) the current state of the digital watch, as is shown in Figure 6.1, where the current time is shown (corresponding to the default display). To connect this GUI to the code generated by Yakindu from the Statechart model, we define appropriate listeners for the buttons in the interface: pressing/releasing the bottom left/top left/bottom right/top right button will send an appropriately named event from the set *{bottomLeftPressed, bottomLeftReleased, topLeftPressed, topLeftReleased, bottomRightPressed, bottomRightReleased, topRightPressed, topRightReleased}*.

The callback functions that are called during the execution of the Statechart are implemented by calling the function with the same name in the interface. This coupling is trivial, but more complex couplings are possible, as long as the callback functions themselves do not introduce waiting behaviour, spawn threads, or take too long to execute.

This development method allows for cleanly separating behaviour (encoded in the model, and generated to executable code by an appropriate code generator) and the presentation (encoded in a visualisation library). More complex control systems benefit from this by separating the control logic from the actuators and sensors, through appropriate interfaces that offer the necessary functionality.

#### **6.7 Advanced Topics**

This section explores a number of advanced topics related to Statecharts. We first explore possible semantic variation for Statecharts; we can consider Statecharts not as a single formalism, but a family of formalisms, whose semantics differ slightly. Then, we explain that Statecharts can be executed (deployed) on multiple possible platforms, which has an effect on how the kernel handles the event queue and how time is advanced. Last, we explore ongoing work to introduce dynamic structure to allow for multiple concurrent objects ("agents").

#### **6.7.1 Semantic Variations**

In Section 6.4, we've explained the execution semantics of Statecharts with *small steps*: an (unordered) execution of an enabled transition in each orthogonal region. While this is a correct specification, we can ask ourselves several questions:


In their paper, Esmaeilsabzali et al. explore these semantic options for big-step modelling languages (a set of languages that Statecharts belongs to) [94]. These semantic options lead to a *family* of (related) languages: there is no longer *the* Statechart language, but one can configure the language in such a way to suit the application at hand.

At the essence lies the observation that there are three *layers* of steps: small steps, combo steps, and big steps. A big step is a sequence of combo steps, and a combo step is a sequence of small steps. The special property of a big step is that after it ends, environmental input (events sent to the Statechart) and output (events sent to the environment) are processed. One could state that small steps and combo steps are *internal* steps, while big steps lead to *externally visible* changes. A small step behaves the same as defined before, however, the choice can be made to not allow concurrency in a small step: only one transition is executed in that case. Moreover, when concurrency is allowed, a choice can be made whether transitions can *preempt* each other. A combo step groups a sequence of small steps. In the following paragraphs, we explore a number of semantic choices that can be made; these choices configure the Statechart language, resulting in a language "variant".

#### Big Step Maximality

This semantic choice decides when a big step ends, which always has to be in a "consistent state" (so after at least one small step). One option (*syntactic*) is to designate certain states as "stable" control states; in that case, a big step ends after a series of small steps that end in such a state. A second option is *take one*, which executes exactly one small step. And last, there is the *take many* option, which executes small steps until there are no more enabled transitions.

In the first and last options, a downside is that big-steps might not terminate (either because a designated control state was not entered or because transitions remain enabled). A downside of the second option is the fact that big steps have no clear syntactical scope (while in the other cases the scope of a big step can be deduced from the model).

#### Combo Step Maximality

This semantic choice is identical to the big step maximality, but then applied to combo steps. The main difference between combo steps and big steps is that after a combo step, no environmental input can be processed.

#### Small Step Concurrency

While the big step maximality and combo step maximality govern how many small steps can be executed, this semantic option allows for one small step to consist of a *single* transition execution or *many* (concurrent, enabled) transition executions. The advantage of the *single* approach is its simplicity, but it requires that the transitions are ordered non-deterministically. The *many* approach, on the other hand, has the potential for race conditions.

#### Small Step Preemption

If one transition is an interrupt for another transition (this is the case when both transitions are enabled in orthogonal regions, and one of them has a target state which is not orthogonal to the source states of both transitions, which effectively exits both orthogonal regions), and *many* concurrency is enabled, this semantic option allows to control what happens. Either both transitions are executed (*non-preemptive*, the result being the execution of both the transition's actions, and the target state outside of the orthogonal regions to be active), or only the interrupting transition (*preemptive*) is.

#### Event Lifeline

The *event lifeline* specifies how long an event "lives" (and can trigger a transition). Both input events and internally generated events have a lifeline (which can be different). There are five options:


This semantic option has a potentially major impact on the execution of a Statechart model. It also shows the potential benefits of splitting up the executions in big steps, combo steps, and small steps.

#### Transition Priority

The last semantic option resolves the issue when two or more sets of transitions exist that can be executed in a small step. In that case, a choice has to be made which set is to be executed. A common example is when two transitions in the same state hierarchy are enabled. The *hierarchical* choice lets the priority be determined by the source and destination states of the transitions; for example, in STATEMATE [141], the outermost transition is chosen, while in Rhapsody [139], the innermost transition is chosen. More elaborate schemes are possibly within this choice, however. The *explicit priority* option lets the modeller assign priorities explicitly in the model. Last, the *negation of triggers* requires the modeller to go through all transitions and strengthen the event triggers in such a way that conflicts are avoided. The last two options are tedious to use, but allow for precise control over the priorities.

Fig. 6.12: The three runtime platforms.

#### **6.7.2 Execution Platforms**

We have discussed deployment of Statechart models in Section 6.6. In particular, we discussed how to provide an implementation for the computation functions that are called in the actions of the Statechart model, and how a "glue" layer has to be constructed that correctly sends input events to the Statechart and interprets output events coming from the Statechart. We did not yet consider *who* the control in the deployed application has; we always consider it is the Statechart. But often, Statechart models are embedded in applications that also require to have control, such as UI systems and game engines. This section explores how the Statechart kernel can work on these platforms by relinquishing certain key control functions.

The semantics of Statecharts (configured according to the semantic options presented in the previous section) are executed on a runtime platform, which provides essential functions used by the runtime kernel, such as the scheduling of (timed) events. The kernel attempts to run the Statechart model in real-time, meaning that the delay on timed transitions is interpreted as an amount of seconds. The raising of events and untimed transitions are executed as fast as possible. It is useful to discuss these platforms, as the Statechart simulators/executors depend on them; moreover, we need different types of platforms for different application scenarios. We distinguish three platforms, each applicable in a different situation. Figure 6.12 presents an overview of the three platforms, and how they handle events.

The most basic platform, available in most programming languages, is based on threads. In its simplest form, the platform runs one thread, which manipulates a global event queue, made thread-safe by locks. Input from the environment is handled by obtaining this lock, which the kernel releases after every (big) step of the execution algorithm. This allows external input to be interleaved with internally raised events. Running an application on this platform, however, can interfere with other scheduling mechanisms (*e.g.*, a UI module), or with code that is not thread-safe.

To overcome this interference problem, the event loop platform reuses the event queue managed by an existing UI platform, such as Tkinter. The UI platform provides functions for managing time-outs (for timed events), as well as pushing and popping items from the queue. This results in a seamless integration of both Statechart events and external UI events, such as user clicks: the UI platform is now responsible for the correct interleaving. The interleaving is implemented in the "main loop" of the UI platform, instead of (for the threads platform) an infinite *while*-loop.

The game loop platform facilitates integration with game engines (such as the open-source Unity2 engine), where game objects are updated only at predefined points in time, decided upon by the game engine. In the "update" function, the kernel is responsible for checking the current time (as some time has passed since the last call to the "update" function), and processing all generated events. This means that events generated in between two of these points are not processed immediately, but queued until the next processing time.

#### **6.7.3 Dynamic Structure**

The exclusive use of Statecharts does not scale to the complex (and often dynamic-structure) behaviour of complex software systems, such as (WIMP) graphical user interfaces, games, multi-agent systems, . . . Their complexity goes further than the timed, reactive, autonomous behaviour Statecharts is good at representing. In many applications, there is a need for a set of collaborating, concurrent objects, that can appear and disappear at runtime. Object-oriented modelling methodologies address software complexity and allow for the construction of a set of interacting objects, but are not specifically designed for modelling timed, interactive discrete-event systems [137].

A number of approaches, such as OO Statecharts [137] were proposed. More recently, SCCD [281] was presented, combining the structural object-oriented expressiveness of Class Diagrams with the behavioural discrete-event characteristics of Statecharts.

Figure 6.13 presents an overview of the SCCD language, applied to a "bouncing ball" application: the application allows for a user to create a number of balls on the screen. Their autonomous behaviour is simply to move in a certain direction and bounce off the sides of the screen. The user can select and delete balls. As we can see, a number of objects are present: an instance of the *Window* class, and two instances of the *Ball* class are shown. There are a number of links between objects; these links can be used to send or receive events. The object diagram (consisting of objects and links) *conforms* to the class diagram part of the SCCD model. On the other hand, each object has a runtime state, corresponding to one of the states in its Statechart model. A central entity, the object manager, allows for instances to request a new object or link to be created or deleted.

Objects can communicate using events: SCCD specifies a number of event *scopes*. A *narrow cast* allows for an object to send an event over a connection to another specific (set of) object(s). A *broad cast* will send the event to all other objects in the application. An *output event* works similarly to an output events in Statecharts: it is sent to the environment of the application. A special *cd* scope is defined for sending event to the object manager.

In essence, the objects of a Statechart run concurrently and communicate in a more "loose" way than the orthogonal regions of a Statechart. The Statechart model in each object has to finish a big step before events can be sent to other objects or input from other events can be processed. The communication between objects is asynchronous: they are not able to call each other's methods, or change their variable values directly. In this sense, SCCD can be seen as a semantic basis for multi-agent systems, where agents have a well-defined interface through which they can communicate.

#### **6.8 Summary**

This chapter demonstrates how to use the Statechart formalism to model the timed, reactive, autonomous behaviour of a system. The chapter is built around a development process that starts from requirements gathering, to build an initial design of the system. The concepts of the Statechart formalism (states, transitions, hierarchy, orthogonality, broadcast communication, and history) are explained by a running example of a digital watch. This design is refined by simulating the model and testing it, by providing an input event segment to the simulation/test and checking the output produced by the model (either manual in a simulation, or automated using an oracle in a test). Ultimately, code is generated from the design model and deployed on a platform.

<sup>2</sup> https://unity3d.com/

Fig. 6.13: SCCD: An overview.

Coupling between the platform functions and the Statechart output events/callback functions is required to finally arrive at a running system. Last, a number of advanced topics were discussed.

#### **6.9 Literature and Further Reading**

A thorough discussion of the origins of the Statecharts visual notation can be found in [136]. The origins of the Statecharts formalism are described in [134]; this work was later complemented with a discussion of its semantics in STATEMATE [141] and Rhapsody [139]. More recently, Esmaeilsabzali et al. have deconstructed the semantics of "big-step modelling languages", a family of languages to which the Statecharts language belongs, and have presented a family of their execution semantics [94]. A standard for the precise execution semantics of UML state machines is being worked on by the OMG [221].

Coordinating concurrently executing Statechart objects has its roots in a 1997 paper by Harel and Gery [137]. SCCD [281] attempt to constrain the possible object operations (creation and deletion of objects, as well as communication between objects) by modelling the allowed object configurations in a class diagram, to which each object diagram (a snapshot in the execution of the model) has to conform.

#### **6.10 Self Assessment**


#### **Acknowledgements**

This work was partly funded by Flanders Make vzw, the strategic research centre for the manufacturing industry.

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

## **Chapter 7 Petri Nets: A Formal Language to Specify and Verify Concurrent Non-Deterministic Event Systems**

Didier Buchs, Stefan Klikovits, and Alban Linard

**Abstract** The study of concurrent and parallel systems has been a challenging research domain within cyberphysical systems community. This chapter provides a pragmatic introduction to the creation and analysis of such system models using the popular Petri nets formalism. Petri nets is a formalism that convinces through its simplicity and applicability. We offer an overview of the most important Petri nets concepts, analysis techniques and model checking approaches. Finally, we show the use of so-called High-level Petri nets for the representation of complex data structures and functionality and present a novel research approach that allows the use of Petri nets inside Functional Mock-up Units and cyber-physical system models.

#### **Learning Objectives**

After reading this chapter, we expect you to be able to:


#### **7.1 Introduction**

Since the early days of computing the modelling and verification of programs has been an important subject. Nowadays this subject is even more vital as computers are ubiquitous in our current way of life. Computers thrive in all kinds of environments, and some of their applications are life critical. Indeed, more and more lives depend on the reliability of airborne systems, rail signalling applications and medical device software for examples.

Given the importance of the matter, much effort has been invested to ensure the quality of the software. On the organisational side, project management techniques have been devised for the software development process, e.g. the RUP (Rational Unified Process) [174], the Waterfall Model [244], the Spiral Model [40], B-method [189], etc. Most recently, so-called "agile" methodologies, such as SCRUM [261], are taking over the

Didier Buchs

Faculty of Science, Computer Science Department, University of Geneva, Switzerland e-mail: didier.buchs@unige.ch

Stefan Klikovits Faculty of Science, Computer Science Department, University of Geneva, Switzerland e-mail: stefan.klikovits@unige.ch

Alban Linard

Faculty of Science, Computer Science Department, University of Geneva, Switzerland e-mail: alban.linard@unige.ch

industry [249]. However, software development frameworks can improve software quality only up to a certain point. In fact, they cannot offer complete guarantees for critical systems by themselves as their effectiveness is only based only on empirical evidence [249].

These approaches have the fact in common that all of them require the description of what the system does without prescribing how to do it. That description is called the *specification*. Depending on the development process used, the specification can be informal (e.g. SCRUM), semi-formal (e.g. RUP) or formal (e.g. B-method). Getting the specification right is paramount for the software quality. On the one hand, the specification is used to check if the development team understood the requirements (to answer the question "Are we building the right thing?"). This process is called *validation*. On the other hand, it is used to check if the finished software does what it was meant to do ("Are we building the thing right?"). We call this step *verification*.

A very simple way to do verification is *testing*. In software testing, we use the specification to derive behaviours that we expect from the software. For each expected behaviour we write a *test*. A test is a procedure that exercises the software (or a part of it), and tells if the observed behaviour is as expected or not (according to the specification). Hence, a test can prove that there are errors in the software. However, proving the absence of errors is much more complicated. It implies to write a test for each possible behaviour of the software. The number of behaviours of even simple software is extremely large, meaning that testing is infeasible for proving the absence of errors. Nevertheless, there are some kinds of software that cannot afford to diverge from specification as human life or health depends on it. This need gave birth to a set of verification techniques that can guarantee the absence of errors in a given system: *formal verification*.

Formal verification techniques, a.k.a. *formal methods*, can guarantee the absence of errors in a system up to its modelling. There are several formal methods ranging from *theorem proving* to *model checking*. These techniques aim to build a formal mathematical proof of the program's correctness. This requires of course that the specification is also *formally* described. It further requires that the program itself has a formally specified semantics. In these sections we focus on the modelling phase and the model checking variant of formal methods.

Formally modelling complex systems requires languages that are adapted to the kind of system we are interested in and also must be defined with certain structuring mechanisms. In this chapter, we will mainly describe languages that provide features related to dynamic systems and data types. For structuring mechanisms we propose to consult publications on extensions of algebraic nets such as CO-OPN [32] and LLAMAS [197]. We will not describe them further as they are not absolutely necessary for the understanding of the basic concepts behind formal methods.

#### **7.2 Modelling Concurrency**

The modelling of concurrency requires specially adapted formal techniques. Among the numerous existing ones, we observe that all of them use constructs to either explicitly or implicitly describe events, states and synchronisation mechanisms. Moreover, the technique's semantics must exhibit the various behaviours of the modelled system because parallelism and concurrency inherently introduce activity non-determinism into a system. One of the most well-known formalisms is Petri nets, which we will introduce throughout this chapter. However, it is important to understand that most of the explained principles can be translated to other kinds of models such as process algebra [207], state charts [135] and similar.

In order to explain the essence of modelling with Petri nets, we use an example of a car engine throughout this paper. The system describes a very simple combustion engine consisting of foot pedal, engine, carburettor and fuel tank. The system is built from several elementary components, that are similar to automata used in some modelling tools [277]. We will see how all components are combined in a single Petri net that describes the entire system.

Although we could use a model of communicating automata for such problems, the use of a Petri net makes communication between components explicit, whereas it is often implicit and hence unclear when using automata. For instance, the choice of synchronous versus asynchronous communication is a meta-property in automata, rather than an explicit choice.

So, in summary, we will have the possibility to model systems with Petri nets in a condensed way. These systems will be composed of some non-deterministic entities communicating synchronously or asynchronously.

#### **7.2.1 Petri Nets**

Petri nets [237] are a graphical, formal modelling language dedicated to the representation of concurrent processes, including communication and synchronisation between them. Petri nets consist of four basic concepts: *places*, *transitions*, *arcs* and *tokens*. Places (represented by circles) model processes and resource containers (such as a fuel tank) of the system, while transitions (represented by rectangles) are used to model system evolution (e.g. the starting of an engine). Places and transitions are connected by arcs. Arcs describe how many tokens (represented as large dots) are taken from a place before and how many tokens are put into a place after a transition is executed. We usually refer to these arcs as the *pre-* and *postconditions* of a transition. Tokens are used to model resources (e.g. the petrol in our example) or control (whether an engine is on or off). Note, that in classic Petri nets only one kind of token is used, meaning that the process control and the resources are both represented equally, which might be confusing for beginners. This feature however offers great flexibility and renders Petri nets a very powerful formalism.

Figure 7.1 shows an example of a Petri net, that represents in a simple way the behaviour of a throttle foot pedal, engine and fuel tank within a car. It represents processes and resources as places: e.g. up, off, fuel or filled. The Petri net also contains transitions such as press, stop or empty. It can be easily observed that the amount of fuel is modelled by the number of tokens within the place fuel, but also that control of the engine is being handled by an individual token which is either in place on or off. An execution of a transition (e.g. start) will *consume* tokens from the precondition states (off) and produce tokens in postcondition states (i.e. on in our example).

The groupings (i.e. the big frames) shown for foot pedal, fuel tank, engine and carburettor have no semantic influence on the system, but merely help system description.

Fig. 7.1: A Petri net that represents a simplified functionality of a car's acceleration

Each places contains a (positive) number of *tokens* (0 by default), that describes how many processes or resources are in this state. We refer to the number of tokens in a place as its *marking*. The combination of markings of all Petri net places is also referred to as the Petri net's *marking* and describes the entire system's state.

Due to their well-studied semantics, they can be simulated, or used for static or dynamic analysis. Their simplicity makes it very easy to transfer them to other forms. For instance, Figure 7.2 shows the marking of the Petri net shown in Figure 7.1 encoded in the Lua programming language1. This Petri net can thus be embedded

1 https://lua.org

and used within a software application. We will use the Lua language throughout this article to show how to implement and use Petri nets in practice. The marking of the Petri net is a structure that affects to each place its number of tokens. The initial marking is the one described initially in the Petri net.

```
function Marking . new ( t )
  return {
   up = t . up or 0 ,
   down = t . down or 0 ,
   fuel = t . fuel or 0 ,
   off = t . off or 0 ,
   on = t . on or 0 ,
   filled = t . filled or 0 ,
   maximum = t . maximum or 0 ,
 }
end
                                               initial = Marking . new {
                                                 up = 1 ,
                                                 fuel = 7 ,
                                                 off = 1 ,
                                                 maximum = 2 ,
                                               }
```
Fig. 7.2: Declaration of a Petri net marking as Lua code. The new function (left) of the Marking module is used to create a mapping that represents the Petri net marking. The code on the right shows the usage of this function for the creation of a new marking. Note, that it is only necessary to specify the places that contain tokens, as the other tokens are initialised with 0 by default.

A Petri net state (represented by its marking) is changed by "firing" transitions. In order to more efficiently describe system evolution we will from use markings, and operations thereon to express the behaviour of a Petri net. For convenience, we therefore define the following operators on markings: comparison, addition and subtraction. The comparison operator compares the number of tokens in each place of the two operands for equality or whether one of the operands is smaller/greater. Addition and subtraction operators perform place-wise addition or subtraction of the number of tokens of the operands. These operators allow the concise description of the transition firing semantics. Figure 7.3 provides the operator implementations in Lua.

As stated, the evolution of a Petri net is effected by firing transitions. Such transition firings are dominated by a simple rule: a transition can be fired if it is *enabled*. A transition is called enabled, iff there are enough tokens in all its input places (i.e. the places connected to the transition). When a transition is fired, it removes tokens from its precondition places, and adds new tokens into its postcondition places. It is important to understand that tokens do not "move" from one place to another, but are *consumed* and new (different) tokens are *produced*. The number of tokens consumed and produced are defined using annotations on arcs. By convention arcs annotations stating a weight of 1 token are omitted for legibility reasons.

For an illustration of a transition firing we can look at the empty transition from the car engine example above. The transition consumes one token from place filled, and another token from place on. Therefore it can be fired if the places filled and on contain *at least* one token each. Once fired, the transition produces one token in place maximum, and another one in place on. Figure 7.4 shows the Lua code that describes the firing of the transitions press and empty. It first checks if the input places contain enough tokens. If this condition is met, it performs firing by subtracting the precondition arcs and adding the postcondition arcs to the marking of the Petri net. If the transition is not fireable, the function returns nil, the Lua equivalent for NULL or null value.

#### **7.2.2 Common Petri net patterns**

Petri nets are better at expressing communication and synchronisation than the traditional automata formalism, as they make these concepts explicit. However, similar to automata, Petri nets have the aforementioned drawback to not distinguish processes and resources. It is up to the modeller to clarify the role of each place, for instance with naming or colour conventions. In order to introduce some common modelling practices we present a few standard patterns which are found in the Petri nets in Figure 7.5:

• Figure 7.5a represents the creation of two processes (q, r) from a process (p), or the release of a resource (r) from a process (p, q).

```
function Marking . __add (l , r )
  return {
    up = l . up + r . up ,
    down = l . down + r . down ,
    fuel = l . fuel + r . fuel ,
    off = l . off + r . off ,
    on = l . on + r . on ,
    filled = l . filled + r . filled ,
    maximum = l . maximum + r . maximum ,
  }
end
```
Listing 8: Addition operator

```
function Marking . __sub (l , r )
  return {
    up = l . up - r . up ,
    down = l . down - r . down ,
    fuel = l . fuel - r . fuel ,
    off = l . off - r . off ,
    on = l . on - r . on ,
    filled = l . filled - r . filled ,
    maximum = l . maximum - r . maximum ,
  }
end
```

```
function Marking . __eq (l , r )
  return l . up == r . up
     and l . down == r . down ,
     and l . fuel == r . fuel ,
     and l . off == r . off ,
     and l . on == r . on ,
     and l . filled == r . filled ,
     and l . maximum == r . maximum ,
end
```


Listing 11: Less-than-or-equals op.

Listing 10: Subtraction operator

Fig. 7.3: Addition, subtraction, equality and less-than-or-equals operators used to work on Petri net markings. The evolution of a Petri net can be expressed using these operators.

```
function press ( marking )
  if marking >= { up = 1 } then
    return marking
        - { marking . up = 1 }
        + { marking . down = 1 }
  else
    return nil
  end
end
  Listing 12: Code of the press transition
                                                     function empty ( marking )
                                                       if marking >= { filled = 1 ,
                                                                         on = 1 }
                                                       then
                                                         return marking
                                                             - { marking . filled = 1 ,
                                                                  marking . on = 1 }
                                                             + { marking . maximum = 1 ,
                                                                  marking . on = 1 }
                                                       else
                                                         return nil
                                                       end
                                                     end
```
Listing 13: Code of the empty transition

Fig. 7.4: Lua code as examples showing the implementation of transitions


Fig. 7.5: These four common Petri net patterns can be used to express various concepts related to control flow split, merge, choice or synchronisation, but also for the consumption, production, acquisition and release of resources.

#### **7.2.3 Formal syntax and semantics**

Since we introduced Petri nets as a formal method, we feel obliged to also provide the syntax and semantics in a more formal setting. We encourage the reader to bear with us through this section, as understanding of these concepts will be necessary for the more complex aspects of Petri nets. In return, we promise to keep ourselves short and only introduce the essential parts. It is also worth mentioning that these formal definitions can be used directly for the creation of tools that manage, simulate and analyse models.

Formally, a Petri net is a *labelled bipartite directed graph*, i.e., a graph whose vertices can be divided into two disjoint finite sets *P* and *T* (with *P* ∩ *T* = ∅), such that every edge is directed and connects a vertex of *P* to a vertex of *T* (preconditions), or a vertex of *T* to a vertex of *P* (postconditions). This graph has natural number labels on vertices of *P* (place markings), no labels on vertices of *T* (transitions), and positive number labels on edges (number of consumed or produced tokens).

A Petri net is thus described as a tuple h*P*,*T*, pre, post, *m*0i. The set of all possible markings is denoted *M* = *P* → N. It contains all possible functions that associate tokens to places of the Petri nets. The initial marking *m*<sup>0</sup> is an element of *M* that maps all places to their initial number of tokens. The pre : *T* → *M* and post : *T* → *M* functions represent arc valuations, and are called the pre− and postconditions of the transitions. For every transition, they return a marking that corresponds to the valuations of input (resp. output) arcs of the transition. Note, that their signature is implicitly in curried form, as they can be rewritten as pre : *T* → (*P* → N) and post : *T* → (*P* → N).

The arithmetic and comparison operators (+, −, =, 6) that we introduced in the previous section are formally defined on markings as follows. We require that ∀*m*<sup>l</sup> , *m*<sup>r</sup> ∈ *M*

> *m*<sup>l</sup> + *m*<sup>r</sup> = ∀*p* ∈ *P*, (*m*<sup>l</sup> + *m*<sup>r</sup> )(*p*) 7→ *m*l(*p*) + *m*<sup>r</sup> (*p*) *m*<sup>l</sup> − *m*<sup>r</sup> = ∀*p* ∈ *P*, (*m*<sup>l</sup> − *m*<sup>r</sup> )(*p*) 7→ *m*l(*p*) − *m*<sup>r</sup> (*p*) *m*<sup>l</sup> = *m*<sup>r</sup> ≡ ∀*p* ∈ *P*, *m*l(*p*) = *m*<sup>r</sup> (*p*) *m*<sup>l</sup> 6 *m*<sup>r</sup> ≡ ∀*p* ∈ *P*, *m*l(*p*) 6 *m*<sup>r</sup> (*p*) where *a* 7→ *x* signifies that *x* is the image value of *a*.

In this chapter we will describe the evolution and behaviour of Petri net using Structured Operational Semantics (SOS) rules such as the example in Equation (7.1). We remind the reader that an SOS rule is composed of a conjunction of premises (above the line) and a conclusion (below the line). The rule states that it can be applied i.e. the conclusion transformation be executed, when the premises are satisfied. Both the premise(s) and the conclusion are expressions (usually called "term predicates").

$$rule: \frac{tpred\_1 \land tpred\_2 \dots \land tpred\_n}{tpred}$$

Each Petri net transition describes possible evolutions of the system. Formally it is a relation between Petri net states, i.e. markings. Thus, the behaviour is described as a transformation of the Petri net marking. The conclusion of SOS rules that describe transition firings are written as *m* t −→ *m* 0 , where *m* and *m* 0 are Petri net markings and *t* is a transition. *m* t −→ *m* 0 states that the system's current marking *m* leads to *m* <sup>0</sup> by firing *t*.

Using a model checking mentality we can also say that the SOS rule states that, given two markings *m* and *m* 0 , firing *t* is correct if all the premises are correct. The semantics of firing one transition is given by the general rule in Equation (7.2).

$$transition\_t: \frac{pre(t) \leqslant m}{m \stackrel{t}{\to} m - pre(t) + post(t)}\tag{7.2}$$

*Example* Let us consider the release transition in Figure 7.1. Its semantics is represented by the following rule:

$$\text{release}: \frac{(\text{down} \mapsto 1) \lesssim m}{m \xrightarrow{\text{release}} m - (\text{down} \mapsto 1) + (\text{up} \mapsto 1)}$$

Remember that for a marking *m* to be greater or equal than another one, all individual place markings have to be greater or equal. For this specific premise to be valid, it means that all places in *m* need to have a greater or equal marking than (down 7→ 1) (i.e. all places need to have at least 0 tokens, except for down which needs at least 1 token). If and only if this is the case, then firing the transition will lead to a new marking by removing one token from down and adding one token to up.

Sequences of transitions also have simple semantics: beginning from a starting state, the transitions within the sequence are applied one by one. Formally, sequences of transitions (noted *T* ∗ ) are inductively defined as lists. Note, that every transition *t* ∈ *T* can also be seen as a sequence of transitions of length 1. Hence *T* ⊆ *T* ∗ . Further, we use a concatenation operator (.) such that ∀*t* ∈ *T*,∀*s* ∈ *T* ∗ , *t*.*s* ∈ *T* ∗ , i.e. every concatenation of transitions is a transition, followed by a sequence of a transitions. Note that a the sequence *s* can be a single transition. This semantics is given by Equation (7.2) and Equation (7.3).

$$issequence:\frac{m\xrightarrow{t}m',m'\xrightarrow{s}m\prime\prime}{m\xrightarrow{t.s}m\prime\prime} \tag{7.3}$$

Figure 7.6 shows the Lua code that performs the computation of a sequence of transition. Each transition is itself a function, such as those we have already defined for press and empty.

```
function sequence ( marking , transitions )
  for _ , transition in ipairs ( transitions ) do
    marking = transition ( marking )
    if not marking then
      return nil
    end
  end
  return marking
end
```
Fig. 7.6: The Lua code that handles the execution of a sequence of transitions on an initial marking. Note that transitions is a list of transition functions as defined above. The ipairs function is an ordered iterator over the elements of transitions.

#### **7.2.4 Deduction Based on Rules**

As we have seen above, we can compose new relations from existing rules, as shown for the sequences in Equation (7.3). We refer to this feature as *transitive closure*. However, in order to compute new relations based on existing SOS rules, we need to know exactly how to compute a rule's term predicates, as another rule's premises can be used as a conclusion of another rule.

This process, called deduction, is based on three principles: rule matching, variable instantiation and predicate reduction.These principles require the definition of additional operations on functional terms (the expressions including only application of function) and term predicates (the predicates applied on functional terms).

These principles are related to the use of variables. The operations that manage the values which can be taken by these variables can take must be thoroughly defined.

An assignment (or *substitution*) is defined as a function σ <sup>∈</sup> <sup>Σ</sup>, where <sup>Σ</sup> is the set of partial functions from variables to terms, or <sup>⊥</sup> if no term is associated to the variable. For instance, a substitution σ can be the replacement of the variable *a* with the term down 7→ 1, or by ⊥ if the variable *a* is undefined. Substitution is extended to apply on terms instead of variables only: for all terms *<sup>t</sup>*, σ(*t*) returns the term *<sup>t</sup>* where all variables that are defined in σ have been replaced by their associated term in σ. For instance if we take the term pre (*x*) and apply the substitution σ(*x*) <sup>=</sup> release onto this term we see that σ(pre (*x*)) <sup>=</sup> pre (release).

Matching refers to the fact that we would like to identify two terms*t*1, *<sup>t</sup>*<sup>2</sup> modulo a substitution <sup>σ</sup>. This means that matching checks if there exists a substitution σ such that σ(*t*1) <sup>=</sup> σ(*t*2). For instance, the substitution σ <sup>=</sup> {*<sup>x</sup>* 7→ release, <sup>y</sup> 7→ release} can be used to match pre (*x*) <sup>=</sup> pre (y).

We would like to introduce a simple example defining the comparison predicate over natural numbers. According to the rules given in Equation (7.4): *a*, *b* ∈ N are variables over natural numbers.

$$R1: \frac{a \leqslant b}{a \leqslant b+1} \qquad R2: \frac{a \leqslant b}{a+1 \leqslant b+1} \qquad R3: \frac{}{0 \leqslant 0} \tag{7.4}$$

We assume that the reader is familiar with the operations based on addition of natural numbers. Their very definitions can be given as an exercise to the reader. Deductions are computed using a special *Infer* function. Infer (*R*) is defined as the deduction process for a set of rules *R*. In our specific case Infer will be defined as Infer ({*R*1, *R*2, *R*3}) and we will use Infer to compute the possible deduction on the predicate 6.

In such deductions rules are applied on top of each other, the correspondence being the possible matching of one premises with the conclusion of another rule placed above. Correct deductions have to be finite and also must rely on a base case, i.e. a rule without premises (in our case R3).

*Example* The following examples show possible deductions, based on the rules R1, R2 and R3. By applying a rule whose conclusion that matches the provided term, we can find a premise, which we then use to match against another rule. This means we generally work bottom-up and try to find matching rules which will lead us closer to R3.

On the left, we try to deduce that 1 6 2. We observe that 1 6 2 can be the conclusion of the rule R1, leading us to infer that the premise of this rule must be 1 6 1. Using rule R2 and the 1 6 1 as conclusion, we see that the premise for this rule is 0 6 0. Now we can apply R3, which does not have any premise and we successfully deduced that 1 6 2.

On the other hand we can look at the example to the right. Our goal here is to deduce that 4 6 2 is true. A first application of rule R2 will get us to 3 6 1 and another application of R2 to the premise 2 6 0. At this point, none of the rules can be applied any more This means that, according to the rules we defined, we cannot reach a base case and that 4 6 2 must be incorrect.

Note, that in both cases we could have applied different rules than the ones that we actually used. On the left hand we could have swapped the rules and first applied R2 before using R1. On the right side we could have also used R1 instead of R2. In either case we would have reached the same conclusions. In general, inferences can be performed in any order by using any rule that is applicable. The trick is to use rules that quickly lead to an end (either a clash or a base-case).

7 Petri Nets: A Formal Language to Specify and Verify Concurrent Non-Deterministic Event Systems 185

*R*1 *R*2 *R*3 0 6 0 1 6 1 1 6 2 *R*2 *R*2 *R*? ??? 2 6 0 3 6 1 4 6 2

According to the principles we gave, we can say that Infer (*R*) is the least set that includes the results of all substitutions possible on all conclusions of all rules that do not have premises:

$$\sigma(post(r)) \in Infer(R) \text{ if } pre(r) = \emptyset, \forall r \in R, \forall \sigma \in \Sigma$$

and all rules' substituted conclusions where a substitution exists so that a rule premise is in the set:

$$\sigma(\phi(post(r))) \in Infer(R) \text{ if } \phi(pre(r)) = \phi(d), \forall r \in R, \sigma \in \Sigma \exists \phi \in \Sigma, \forall d \in Infer(R)$$

where *pre*(*r*) are is the premise and *post*(*r*) the conclusion of the rule

This last rule is called modus ponens, Example 7.2.3 shows such a deduction for a sequence of transitions. Infer (*R*) is then obtained by fixpoint application of the modus ponens rule. For rules with positive numerator (no negation, only conjunction) this set always exists according to fixpoint theorem of Knaster-Tarski [264]. Nevertheless, the set can be infinite.

*Example* Let us consider the sequence press.release in Figure 7.1. The semantics of this sequence are represented by the following simple deduction using the SOS rules of press and release. What we see is that the conclusion of the rule (the firing of press.release and creation of a new marking) has two premises: 1. the conclusion of the press rule, and 2. the conclusion of the release rule. Each of these is part of an SOS rule with it's own premises, which has to be satisfied for this rule to be applicable.

$$\begin{array}{c} \begin{array}{c} (\mathsf{up} \mapsto \mathsf{l}) \leqslant m \\ \hline \hline \end{array} \xrightarrow{\text{press}} m' = m + (\mathsf{up} \mapsto \mathsf{l}) - (\mathsf{down} \mapsto \mathsf{l}) \\ \end{array} \qquad \begin{array}{c} (\mathsf{down} \mapsto \mathsf{l}) \leqslant m' \\ \hline \end{array} \xrightarrow{\text{release}} m' = m' + (\mathsf{down} \mapsto \mathsf{l}) - (\mathsf{up} \mapsto \mathsf{l}) \\ \end{array}$$

#### **7.2.5 Reachability Graph**

We saw that applying a transition to a Petri net marking generates a new marking. In order to study system evolutions in a more efficient manner, we can try to represent transitions and the thereby created markings as an automaton. The automaton's states are the markings and the automaton's transitions correspond to the Petri net's transitions. We refer to such an automaton as the *reachability graph* of a Petri net. This is due to the fact that it shows, starting from an initial state, the possible states of the system that can be reached.. To fully understand the definition of the automaton, it is noteworthy that the automaton's input alphabet is the Petri net's set of transitions.

Note, that depending on the initial marking, a Petri net has different reachability graphs, as different transitions might be enabled. To visualise this, we present the reachability graphs of the Petri net of Figure 7.1 in Figure 7.15 (at the end of this chapter). The two graphs correspond to the possible system evolutions with 0, 1, 2 and 3 initial tokens in fuel in Figures 7.15a – 7.15d, respectively. We can clearly see the repeated groups of markings that correspond to matching behaviour.

These groups of reachability graph nodes differ by the number of tokens available in the fuel place. To aid the legibility, we use different shades of gray to distinguish markings with different token numbers in place fuel, where the lightest is 0 and the darkest is 3. The last group at the bottom of the figures (almost white) shows the behaviour when fuel is empty. We can easily observe that the states of 0 tokens in Figure 7.15a is repeated in Figure 7.15b, but this time with 1 token (signalled by the darker shade of grey). In the same way, we can find the group of Figure 7.15b in Figure 7.15c, where however, every state is one shade darker, as there is one more token in state fuel. The reachability graph of the marking shown in Figure 7.1 with seven tokens in fuel has 84 states. We can observe from the graphs in Figure 7.15 that a Petri net with 0 tokens has 4 states

and 12 states with 1 token. The number of states increases by 12 for each additional token added initially to the fuel place.

The advantage of Petri nets is that, due to their better representation of concurrent processes and resources, they can be *orders of magnitude* smaller than their equivalent automata. For instance, [300] managed to simulate the state of several multi-threaded programs to perform intrusion detection. Simulation was performed onthe-fly during the program execution by wrapping system calls, and thus required an efficient representation and computation time. This goal was achieved using Petri nets, and it would not have been possible using the equivalent automata on the available resources.

Formally, the reachability graph of a Petri net is defined by a function *s* : *M* → *T* → *M* ∪ {⊥} that returns the successor for any marking and transition, or ⊥ if none exists. This function is derived from the following basic rules:

$$\forall m \in M, t \in T, \begin{cases} s(m)(t) = \bot \quad \Leftrightarrow \not\exists m' \in M, m \xrightarrow{t} m' \in Infer(\{transition\_{t\_i} | t\_i \in T\})\\ s(m)(t) = m' \quad \Leftrightarrow m \xrightarrow{t} m' \in Infer(\{transition\_{t\_i} | t\_i \in T\}) \end{cases} \tag{7.5}$$

The relation can be restricted to the subset of states that are reachable from the initial state *m*<sup>0</sup> of the Petri net. This subset is easily defined using the sequences of transitions of Equation (7.3).

We define that the state space (*SS*) is the set of reachable markings starting from an initial marking *m*<sup>0</sup> for a given set of transitions *T*

$$\text{LSS}(T, m\_0) = \{ m \in M \mid \exists s \in T^\*, m\_0 \xrightarrow{s} m \in \text{Infer}(\{transition\_{l\_i} | t\_i \in T\} \cup \{sequence\}) \}\tag{7.6}$$

By convention, for a given Petri net it is natural to implicitly define *SS*(*m*0) = *SS*(*T*, *m*0).

The (naive) reachability graph generation algorithm is given in Figure 7.7. This function iterates over the reachable markings, initially only initial, and tries to apply all transitions. The function returns the set of reachable markings, each one annotated with the transitions that can be fired, and the corresponding successor marking. The explored set contains the already explored markings, whereas the encountered set contains markings that have not been explored, or that have been encountered again since their exploration. The code shows a simple implementation that iterates over all previously seen markings to ensure uniqueness. More efficient implementations may use a hash table.

#### **7.2.6 Monotony**

Petri nets exhibit an interesting property: monotony. Monotony means that if a transition can be fired for one marking, then it is also fireable for any marking greater than the evaluated one. Extended to the reachability graph, monotony means that all sequences of transitions that exist in the reachability graph of a Petri net also exist in reachability graphs of the same Petri net with greater initial markings. Trivially expressed we could say that adding tokens to a Petri net can only add new behaviours, but never inhibit existing ones.

Formally, monotony is defined by Equation (7.7), which can be derived from the rules in Equation (7.2) and Equation (7.3). This rule defines monotony on both, a transition and a sequence of transitions.

$$t \, monotony : \frac{m \xrightarrow{t} m'}{m + \delta \xrightarrow{t} m' + \delta} \tag{7.7}$$

In our example monotony means that any sequence of actions in our engine can also be performed if we add tokens to any state of the Petri net (such as adding more fuel). We can observe the inclusion of reachability graphs in Figure 7.15 for initial markings fuel = {0, 1, 2, 3}. The sequence stop.release.start.press is observed several times, but with different initial markings, leading to a varying number of tokens in the fuel place for each one.

```
local markings = {}
function unique ( marking )
  for _ , m in ipairs ( markings ) do
    if marking == m then
      return m
    end
  end
  markings [# markings +1] = marking
  return marking
end
                                        function reachable ()
                                          local explored = {}
                                          local encountered = {
                                            [ unique ( initial ) ] = true
                                          }
                                          while next ( encountered ) do
                                            local marking = next ( encountered )
                                            encountered [ marking ] = nil
                                            if not explored [ marking ] then
                                              explored [ marking ] = true
                                              for _ , transition in ipairs ( transitions ) do
                                                 local successor = transition ( marking )
                                                 if successor then
                                                   successor = unique ( successor )
                                                   marking [ transition ] = successor
                                                   encountered [ successor ] = true
                                                 end
                                              end
                                             end
                                          end
                                          return explored
                                        end
```
Fig. 7.7: Source code function that enumerates reachable markings (right). The code iterates over the already encountered markings and tries to find all possible successors by attempting to fire all individual transitions on that marking and adding the successful attempts into the list of encountered markings.

The unique function ensures that each marking corresponds to only one entry in the Lua memory. It is required by the explored [marking] and encountered [successor] lookups.

To summarise, we can see that the reachability graph of a Petri net is always included in the reachability graph of the same Petri net with a greater initial making. While the markings of the sequences' states may differ for each one, the transition sequences are preserved.

In fact, since monotony is a property of all Petri nets, we can observe the following lemma. It states that the state space (and thus the reachability graph) inferred from just the transitions is equal to the state space inferred by the transitions and the monotony rule that we can define as:

$$\text{LSSM}(T, m\_0) = \{ m \in M \mid \exists s \in T^\*, m\_0 \xrightarrow{s} m \in \text{Infer}(\{ \text{transition}\_{l\_i} | t\_i \in T \} \cup \{ \text{sequence}, m \text{ontony} \})\} \tag{7.8}$$

So that the following statement holds:

$$SS(T, m\_0) = SSM(T, m\_0) \tag{7.9}$$

We also know that behaviours are preserved when extending markings:

$$m \le m' \Rightarrow SS(T, m) \le SS(T, m') \tag{7.10}$$

Where ≤ on markings compare markings one by one.

#### **7.3 Properties of Petri Nets**

In the previous section we introduced Petri nets and the rules for the exploration of the reachable state space of an initial marking. In this section we investigate the properties of Petri nets using representatives of state properties and transition properties.

#### **7.3.1 Marking Properties**

The state properties or in Petri net-lingo *marking properties* of a Petri net can be used to analyse one configuration of a Petri net. One of the most common representatives for these kinds of properties is the *bound*. A place's bound refers to the minimum (lower bound) and the maximum (upper bound) number of tokens that can be reached by any marking. The minimum and maximum number of tokens of all places are commonly referred to as the *bound* of a Petri net. This means that the Petri net bound is composed of


Formally, we can define the lower and upper bound as follows:

$$lower = \max\left( \{ m \in M \mid \forall m' \in \text{SS}(T, m\_0), m' \ge m \} \right) \tag{7.11}$$

$$upper = \min\left( \{ m \in M \mid \forall m' \in \text{SS}(T, m\_0), m' \lesssim m \} \right) \tag{7.12}$$

Figure 7.8 shows the code that computes the bound of a Petri net, using its reachable markings. The code works by iterating over all markings and computing the minimum and maximum number of tokens for each place. There exist algorithms to compute the bound without the use of the set of reachable markings. These algorithms use structural properties of the Petri net instead, such as the one shown in [188].

The importance of bounds is paramount as they are often used to detect dead parts in the model, i.e. places that can never contain any tokens. Bounds computation can further detect places that can have an infinite number of tokens. However, as an infinite number of tokens would (theoretically) require an infinite reachability graph, such a bound cannot be detected using algorithms such as the one presented below. In order to detect an infinite bound, we have to use a *coverability graph*, an adaptation of the reachability graph for which a detection of repetitive sequences is added. This is explained for example in [238].

In the Petri nets community the term *k-boundedness* is often used, where *k* ∈ N is a natural number. This notion of bound refers to the upper bound at the place level and helps describing a Petri net. We say that a place *p* is *k*-bounded iff it contains at most *k* tokens in any reachable marking i.e. ∀*m* ∈ *SS*(*T*, *m*0), *m*(*p*) 6 *k*. We can further refer to Petri net as being *k*-bounded iff all its places are *k*-bounded, i.e. ∀*p* ∈ *P*, *p* is *k*-bounded.

```
function bounds ( marking )
  local markings = reachable ( marking )
  local bound = {
    up = { minimum = math . huge , maximum = 0 } ,
    down = { minimum = math . huge , maximum = 0 } ,
    fuel = { minimum = math . huge , maximum = 0 } ,
    off = { minimum = math . huge , maximum = 0 } ,
    on = { minimum = math . huge , maximum = 0 } ,
    filled = { minimum = math . huge , maximum = 0 } ,
    maximum = { minimum = math . huge , maximum = 0 } ,
  }
  for marking in pairs ( markings ) do
    bound . up . minimum = math . min ( bound . up . minimum , marking . up )
    bound . up . maximum = math . max ( bound . up . maximum , marking . up )
    ...
  end
  return bound
end
```
Fig. 7.8: Source code stub of the function that calculates the Petri net's bounds

#### **7.3.2 Sequence Properties**

While marking properties provide useful information about the state of a system, they do not give any information about *how* the system evolves. In contrast, sequence properties express the possibility to fire transitions in the reachability graph. One such property describes the liveness of a transitions. This property assigns a liveness level (*l*<sup>i</sup> ∈ {*l*0, *l*1, *l*2, *l*3, *l*4}) to each transition of the Petri net, so that it provides information about whether a transition is fireable, can/will be fireable or will never be fireable. The individual levels are defined as follows:


Note that the liveness constraints are ordered and that if a transition is *l*<sup>k</sup> -live, it is also *l*k−<sup>1</sup> live, except for *l*<sup>0</sup> (dead). The liveness level of transitions is a useful information to debug models, as this level should in theory match the intended behaviour of the process using by the transition. In practice, *l*0-live transitions should almost never occur in models: finding a *l*0-live transition is usually a clear indication of a bug within the model as it should not appear at all if the model was correct. Transitions that are *l*1-live can be fired at least once, and have no really interesting meaning. They can appear in any behaviour, such as the representation of scripts or programs that terminate. *l*2-live transitions trigger infinitely often, and are thus found in the behaviour of programs that do not terminate, for instance web servers. They are distinguished from *l*3-live transitions, because the latter can fire infinitely often in all execution paths. Thus, *l*2-live transitions are used usually in looping processes that can terminate, whereas *l*3-live transitions are used usually in looping processes that cannot terminate. *l*4-live transitions are in practice very rare, as they represent an action that can always happen. They can be found in user interfaces, where one process records the inputs and has thus transitions that can always be fired.

In order to find the liveness level of transitions, we can employ the algorithm provided in Figure 7.9. The computation works on the set of reachable markings and further uses the information about a reachability graph's strongly connected components (calculated using *Tarjan's strongly connected components algorithm* [263]). The algorithm works in several stages, treating each transition individually as follows:


#### **7.3.3 Invariants**

The actual aim of modelling is often to reason over certain problems. Invariants pose a convenient way of reasoning over Petri nets independent from their actual marking.

Invariant reasoning is part of the structural analysis of Petri nets. Generally, invariants are distinguished between place (P-)invariants and transition (T-)invariants.While the former is useful for deadlock detection [214], T-invariants serve the modelling of logic programs [215] and Horn clauses [187] as pointed out in [199].

The goal of invariant creation is the establishing of proofs based thereon. In general, proofs based on invariants have an algorithmic part that consists of computing invariants and a more analytic part, which is written by a human and describes the reasoning necessary for building the proofs. There is a large number proofs we can perform with invariants, ranging from state based proofs such as mutual exclusion to liveness properties. Such invariant-based proofs are interesting alternatives to the ones based on temporal logic properties. Although they tend to be less powerful, they can nevertheless provide parametric proofs more easily. This comes however at the cost of human contribution while temporal logic proofs are automateable.

```
function liveness ( marking )
  local markings = reachable ( from )
  local components = tarjan ( markings )
  for _ , transition in ipairs ( transitions ) do
    transition . liveness = {
      l0 = true ,
      l1 = false ,
      l2 = false ,
      l3 = false ,
      l4 = true ,
    }
    for marking in pairs ( markings ) do
      if marking [ transition ] then
         transition . liveness . l0 = false
         transition . liveness . l1 = true
      else
         transition . liveness . l4 = false
      end
    end
    for _ , component in ipairs ( components ) do
      for marking in pairs ( component ) do
         if marking [ transition ]
         and marking [ transition ]. tarjan . component == component then
           transition . liveness . l2 = true
         end
      end
      transition . liveness . l3 = component . is_final and transition . liveness . l2
    end
  end
  return transitions
end
```
Fig. 7.9: Liveness level detection algorithm.

#### **7.3.4 Formal Definition of Invariants**

Each state *m* ∈ *SS*(*T*, *m*0) can be associated with an observation value. The observation is a summary of the state that contains only information relevant to the properties that are verified. Given a set of observations *O*, which observations are obtained through functions ω : *<sup>M</sup>* <sup>→</sup> *<sup>O</sup>* that return an observation for any possible marking in *<sup>M</sup>*, ω is an invariant if and only if it returns the same observation for all the reachable states of the system. For instance, in Figure 7.1, the foot pedal is either up or down. In the marking, this means that there is one token in one of the places and none in the other at all times. Therefore ω : *<sup>m</sup>* 7→ *m*(up) + *m*(down) is a function that always returns the value 1 for all reachable states and is thus an invariant. More formally, ω is an invariant iff <sup>∃</sup>*<sup>o</sup>* <sup>∈</sup> *<sup>O</sup>*,∀*<sup>m</sup>* <sup>∈</sup> *SS*(*R*, *<sup>m</sup>*0),ω(*m*) <sup>=</sup> *<sup>o</sup>*.

The definition above for invariants is very general. It can be used if the users define the invariants themselves, but cannot help in deducing invariants from the structure of the Petri net. It is interesting to consider instead only functions that are linear combinations of elementary observation of places.

Usually, elementary observations are functions that for any place and marking return the marking of the given place. The elementary observations is thus defined as the function *o*<sup>e</sup> : *P* → (*M* → N) such that ∀*m* ∈ *M*,∀*p* ∈ *P*, *o*<sup>e</sup> (*p*)(*m*) = *m*(*p*) These elementary observations can be instantiated using any place of the Petri net, for instance *o*<sup>e</sup> (up) is an observation. The set of all elementary observations is included into the observations. For convenience, we consider that writing the name of a place is equivalent to the elementary observation for this place. Hence we will use up to also refer to the function that returns the marking of this place: *m* 7→ *m*(up).

Observations can be composed as linear combinations of observations. For any observations *<sup>o</sup>*1, . . . *<sup>o</sup>*<sup>n</sup> <sup>∈</sup> *<sup>O</sup>*, and constants *<sup>c</sup>*1, . . . *<sup>c</sup>*<sup>n</sup> <sup>∈</sup> <sup>N</sup>, an observation can be built to compute *<sup>c</sup>*<sup>1</sup> <sup>∗</sup> *<sup>o</sup>*<sup>1</sup> <sup>+</sup> . . . *<sup>c</sup>*<sup>n</sup> <sup>∗</sup> *<sup>o</sup>*n, for instance 1 ∗ *o*<sup>e</sup> (up) + 1 ∗ *o*<sup>e</sup> (down) (the places with coefficient 0 are not shown). The set of observations is thus defined by the linear combinations of elementary observations:

$$O = \{ \Sigma\_{p \in P}(c\_p \* o\_e(p)) \mid \forall p \in P, c\_p \in \mathbb{N} \}$$

Following this definition, if <sup>ω</sup><sup>1</sup> and <sup>ω</sup><sup>2</sup> are invariants, then <sup>ω</sup><sup>1</sup> <sup>+</sup> <sup>ω</sup><sup>2</sup> is also invariant. The addition of two invariants <sup>ω</sup><sup>1</sup> <sup>+</sup> <sup>ω</sup><sup>2</sup> : *<sup>M</sup>* <sup>→</sup> *<sup>O</sup>* is defined as: <sup>∀</sup>*<sup>m</sup>* <sup>∈</sup> *<sup>M</sup>*, (ω<sup>1</sup> <sup>+</sup> <sup>ω</sup>2)(*m*) <sup>=</sup> <sup>ω</sup>1(*m*) <sup>+</sup> <sup>ω</sup>2(*m*). Also, if <sup>ω</sup> is an invariant then <sup>∀</sup>*<sup>k</sup>* <sup>∈</sup> <sup>N</sup>, *<sup>k</sup>* <sup>∗</sup> ω is an invariant. The multiplication of an invariant with a constant is defined as: <sup>∀</sup>*<sup>m</sup>* <sup>∈</sup> *<sup>M</sup>*, (*<sup>k</sup>* <sup>∗</sup>ω)(*m*) <sup>=</sup> *<sup>k</sup>* <sup>∗</sup>ω(*m*). To compute invariants it is necessary to find the appropriate linear combination of elementary observations. The well-known Farkas algorithm can be employed for the finding of invariants, as explained in the next section.

#### **7.3.5 Computing P-invariants**

Discovering the P-invariants can be done using the Farkas algorithm [97]. The Farkas algorithm is an iteration process operating on a structure which corresponds to a Petri net's incidence matrix. For spatial reasons we do not provide the implementation of the algorithm but describe the (basic) functionality in textual form.

Its principle is to represent and manipulate a matrix where columns represent the transitions of the Petri net, and lines represent place markings or linear combinations of place markings. The algorithm works iteratively, performing the following actions:


The process terminates when all columns are nullified. The solutions are linear combination of place markings that have a constant observation, and are thus invariants.

*Example* Below is an example of how to compute invariants following the given algorithm, on a very simple Petri net shown in Figure 7.10.

Fig. 7.10: Example of Petri net used to compute invariants

The successive *F*<sup>i</sup> structures show the advance in Farkas algorithm. Each *F*<sup>i</sup> is the result of one step, computed from the *F*i−<sup>1</sup> structure. The first one (*F*0) is the incidence matrix of the Petri net, that represents for each place and transition the difference between the weight on post arcs that rely the place and the transition, and the weight on pre arcs that rely them also.

$$F\_0 = \begin{bmatrix} a & t\_2 & t\_3 \\ a & \begin{bmatrix} -1 & 1 & 0 \\ 1 & -1 & 0 \\ 1 & -1 & 1 \\ -1 & 1 & -1 \end{bmatrix} \end{bmatrix}$$

The first iteration is to eliminate *t*1. To do it, we have to find linear combinations of rows such that the column for *t*<sup>1</sup> is always zero. Obviously, both *a* + *b*, *c* + *d*, *a* + *c* and *b* + *d* are correct linear combinations. There is no need to represent greater coefficients, such as 2 ∗ *a* + 2 ∗ *b*, thus only the minimal combinations are kept. Because all rows *a*, *b*, *c*, *d* have been used to compute the new rows, the rows *a*, *b*, *c*, *d* are removed from the matrix in *F* 0 1 . All columns that contain only zeros are also removed in *F* 00 1 , as they are useless for the remaining of the iterations.

$$F\_1 = \begin{bmatrix} \iota\_1 & \iota\_2 & \iota\_3 \\ & b & \begin{bmatrix} -1 & 1 & 0 \\ 1 & -1 & 0 \\ 1 & -1 & 1 \\ -1 & 1 & -1 \\ 0 & 0 & 0 \\ 0 & 0 & 0 \\ 0 & 0 & 1 \\ 0 & 0 & 1 \\ \end{bmatrix} & F\_1' = \begin{matrix} \iota + b \\ b & 0 \\ -b + c \\ 0 & 0 \\ 0 & 0 \\ \end{matrix} & \begin{matrix} 0 & 0 & 0 \\ 0 & 0 & 0 \\ 0 & 0 & 1 \\ 0 & 0 & -1 \\ \end{matrix} & F\_1' = \begin{bmatrix} \iota + b \\ 0 \\ a + c \\ b + d \\ \end{bmatrix} & F\_1' = \begin{bmatrix} 0 \\ 0 \\ a + c \\ b + d \\ -1 \\ \end{bmatrix}$$

As there is only one transition *t*<sup>3</sup> remaining, the second iteration is to remove it. Only one linear combination can do it: *a* + *b* + *c* + *d*, obtained by two ways: by adding the lines *a* + *b* and *c* + *d*, and by adding the lines *a* + *c* and *b* + *d*. But the Farkas algorithm requires to use only the rows that are not zero, thus *a* + *b* and *c* + *d* are not taken into account. As previously, the rows that have been used to compute the new ones are removed (*a* + *c* and *b* + *d*) in *F*2", and the nullified column is also removed in *F* 00 2 .

$$F\_2 = \begin{array}{c} a+b \\ c+d \\ d+d \\ b+d \\ a+b+c+d \end{array} \begin{array}{c} \begin{array}{c} t\_3 \\ 0 \\ 0 \\ 1 \\ -1 \\ 0 \end{array} \\ \begin{array}{c} \\ -1 \\ 0 \end{array} \end{array} \begin{array}{c} \begin{array}{c} \\ 0 \\ 1 \\ a+b+c+d \\ 0 \end{array} \begin{array}{c} t\_3 \\ 0 \\ 0 \\ 1 \end{array} \end{array} \begin{array}{c} t\_3 \\ \begin{array}{c} \\ 0 \\ 0 \\ 1 \end{array} \end{array} \begin{array}{c} t\_3 \\ \begin{array}{c} \\ 0 \\ 0 \\ 1 \end{array} \end{array} \begin{array}{c} t\_3 \\ \begin{array}{c} \\ 0 \\ 0 \\ 1 \end{array} \end{array} \begin{array}{c} t\_3 \\ \begin{array}{c} \\ 0 \\ 0 \\ 1 \end{array} \end{array} \begin{array}{c} t\_3 \\ \begin{array}{c} \\ 0 \\ 0 \\ 1 \end{array} \end{array} \begin{array}{c} t\_3 \\ \begin{array}{c} \\ 0 \\ 0 \\ 1 \end{array} \end{array} \begin{array}{c} t\_3 \\ \begin{array}{c} \\ 0 \\ 0 \\ 1 \end{array} \end{array} \begin{array}{c} t\_3 \\ \begin{array}{c} \\ 0 \\ 0 \\ 1 \end{array} \end{array} \begin{array}{c} t\_3 \\ \begin{array}{c} \\ 0 \\ 0 \\ 1 \end{array} \end{array} \begin{array}{c} t\_3 \\ \begin{array}{c} \\ 0 \\ 0 \\ 1 \end{array} \end{array} \begin{array}{c} t\_3 \\ \begin{array}{c} \\ 0 \\ 0 \\ 1 \end{array} \end{array}$$

After this iteration, there are no more columns to remove. The remaining rows represent invariants of the Petri net: *a* + *b* and *c* + *d*, that are named for later use:

$$\begin{aligned} i\_1 &= a + b \\ i\_2 &= c + d \end{aligned}$$

As previously discussed, invariants are formulas that do not change applied on reachable markings. This means that for any sequence *s* and markings *m*, *m* 0 , such that *m* s −→ *m* 0 , the invariant *i* applies at both ends of the sequence, and even at each state within the sequence: *i* ∗ *m* = *i* ∗ *m* 0 . In our example *i* is either *i*<sup>1</sup> or *i*2, stating that the observation of *a* + *b* and *c* + *d* remains constant, independently of which transitions are fired.

#### **7.3.6 Using Invariants for Proving Properties**

Proving properties on models can be done by exploration of the reachability graph. Nevertheless, in most practical applications this method is difficult to use due to the state space explosion problem. The previous section defines invariants on Petri nets, that can be computed without the need to create the full reachability graph. In fact, invariants can be computed without even having to specify an initial marking. This section outlines the power of invariants by showing how to use them to prove properties on models. The usual way of performing these proofs is to establish invariants, and follow a case by case analysis of the possible state of the Petri net. This is done using in the reasoning the fact that invariants are respected in the whole reachability graph and also for the initial marking.

Proofs can usually be expressed as case analysis of the reachability graph of the Petri net. The proof process is then based on the following steps:


Using the invariants from Example 7.3.1, we can prove the principle of mutual exclusion of *a* and *b* in the Petri net above. The reasoning steps for this proof are as follows:


While this trivial proof can easily be computed by hand, the same principle can be used to create more complex, semi-manual, structural proofs. In practice such proofs are supported by powerful proof checkers such as Coq [30] to verify that hand written proofs are correct. The detailed description of this technique surpasses the scope of this book, but we encourage the reader to consult publications dedicated to this topic.

#### **7.4 Techniques for Model Checking**

Invariants can often be computed using less time and memory than a Petri net's the entire reachability graph. In some cases, however, such as during the computation of causality properties (for instance "if an event A occurs, then an event B must occur later"), the need to perform the generation of the state space is still required. Although the computation is straightforward (see the algorithm in Figure 7.7), this technique does not scale well since many models have an exponentially growing number of states with respect to to their size. It is not uncommon for a model's reachability graph to have more nodes than the number of atoms in the universe (1082).

The size of the reachability graph of a Petri net usually depends on two factors: the number of places and transitions within the Petri net and the number of tokens in each place. For instance, the reachability graph of our example in Figure 7.1 increases with the number of tokens in the fuel place. It could also increase if we add more places, for instance to represent several positions of the foot pedal (up, middle, down for instance).

In order to still be able to calculate the state space, research led to the development of various approaches to overcome the increasing size of the state space. Below, we will briefly outline a few examples.


verification, the model and the formula are both encoded as Büchi automata which accept the languages that represent the executions of the model and the valid executions with respect to the property to verify. Model checking then consists of checking that the language of the executions is included in the language of the property.


Some techniques have been developed that combine several approaches [92]. For instance, symmetry and partial order reductions are also often coupled with static reductions techniques that reduce the size of the specification with respect to the property to check, or with state compression as in [96], where some states are represented by the difference with their predecessor. Similarly, parallel model checking is easily used in combination with the other approaches discussed above. One exception is symbolic model checking because Decision Diagrams require a unicity table and computation caches, that need to be locked and are thus bottlenecks.

#### **7.5 Data manipulation in Petri nets**

The previous sections present the use of simple Petri nets models. While this type of Petri nets are sufficient to represent simple systems, they lack several features that are useful when dealing with complex cyber-physical systems, such as modularity, time constraints, and data manipulation. Such simple models encode data as a number of tokens. For instance, the fuel level is represented by a certain amount of tokens within the fuel place.

The basic Petri nets we introduced so far are commonly referred to as *Place/Transition* (P/T) nets. As we have seen, they are well-suited for the modelling of process control, synchronisation and resource flow within a system. However, in more complex situations the information used might not be easily representable as simple, black tokens. We can easily imagine cyber-physical systems where the transmission of more complex information is required. A P/T net modelling a very simple drone controller may have transitions up, down, turn left, turn right, move forward and move backward, which all modify the state. However, if we now add possibilities to perform multiple actions at the same time, we would have to add more transitions such as move up & forwards. The number of transitions within this relatively simple system would grow exponentially.

It would be more efficient to represent such information directly in the tokens. In order to do so, we need a token for vertical movement that could express to either move up, move down or stay, another one for changing directions (left, right, stay) and a third one for the forward/backward movement. We can then send these three tokens into a transition that would perform the action depending on the token values.

This simple scenario shows the necessity for *High-level Petri nets* (HLPN). HLPN were developed with the goal to attach a values to tokens, such as described before. Transitions and arcs are extended with *guards*, which evaluate the token values and assert a certain configuration.

#### **7.5.1 Drone Controller**

Our new High-level Petri net drone controller is presented in Figure 7.11 On the first view we can see three distinct groupings for vertical movement, horizontal movement and orientation. Each one of these three groups contains one place with an initial token with value stay. The behaviour of the groups follows the same scheme. From the initial place we can use transitions to create tokens with different values. The transitions' preconditions are guarded. This means that if the token's value is stay, we can only fire transitions whose guards require a stay-token (there are two in each group). Once we fire the transition, the stay-token is consumed and a new one is produced. For example from the place altitude we can either fire a transition move up, which produces an up-token, or move down, that creates a down-token. This behaviour matches the pushing of a joystick on the drone's physical remote to either direction. There are two more transitions within this group that are guarded by up and down, respectively. Firing these transitions will consume the token respective token and produce a stay token. In other words, we can use them to "reset" the token (i.e. to stop movement into that direction). On an actual drone remote, this behaviour matches the releasing of the drone's altitude joystick to neutral position. The groups that express the horizontal movement and orientation behave correspondingly.

Next to these three groups we can see the central move transition. This transition is responsible for the actual displacement of the drone Move consumes the tokens from vertical, horizontal and orientation. Interestingly, the arcs for these tokens are not guarded by concrete token values, but by variables (a, d and m). These variables are assigned when move fired and take the tokens' values. The transition further uses a token from place drone and a token from place battery. Note, that both drone and battery have different token types (i.e. can hold different valuations): While battery contains multiple, classical black tokens, the drone-place only holds one data-record token whose value stores information about the drone's current *position* (as h*x*, y, *z*i-coordinates) and *angle* (stored as anti-clockwise deviation angle from north2).

Firing move will consume the three movement indicator tokens, one battery-token and the drone-token (assigned to variable s). It then produces equivalent tokens to the consumed ones in each one of the movement places, plus a new token in the drone-place, whose value is updated to match the new state of the drone3. Producing equivalent movement tokens to the one that has been consumed, has the effect that the behaviour of the drone will remain continuous until it is actively altered. In the example, move's consumption of an up token will produce another up in the altitude-place. Hence, when firing move again, the drone will continue rising, unless the token has been modified (using the transitions within the altitude group)

Note, that since there is no way to produce tokens in the battery-place, this is the resource that limits the number of times we can trigger the central transition and hence move the drone.

Our drone controller further has a safety-mechanism integrated. This mechanism is shown as a guard on the central transition and expresses that we cannot fire this transition if the drone's position *z*-position is lower than 50 (centimetres) and the altitude token is specifies a downward movement (i.e. has value down).

#### **7.5.2 Formalising High-level Petri nets**

As we saw in the example, HLPN use various additional concepts such as variables and expressions. In this section we will focus on the adaptation of our existing Petri net formalism to integrate these concepts.

**Variables and expressions** To formally express the concepts that were used in the example above, we need to define matching and filtering of tokens. For this reason we introduce the notions of variables and expressions: We define a set of variables *V* (e.g. s,a,d,m), and a set of expressions over data and variables (noted *E*).

<sup>2</sup> I.e. the value 90 describes West, 180 South, and 270 and −90 stand for East

<sup>3</sup> In the figure the update is simply expressed as s + f (a, d, m), where we assume the existence of a function f which can provide the hx, y, zi-coordinate and orientation angle change produced depending on the group tokens.

Since variables are expressions or parts thereof, *V* is a subset of *E*: *V* ⊆ *E*. We further define a function variables : *E* → P(*V*), which returns the set of variables that are used by an expression.

If an expression does not contain any variables, we call it a *ground expression*. The set of ground expressions *E* <sup>∅</sup> is defined as *E* <sup>∅</sup> = {*e* | *e* ∈ *E* ∧ variables (*e*) = ∅}. In order to express concrete values (such as stay or up) this set has to be non-empty.

**Binding** Equipped with these tools we can now express the binding of variables (such as binding of the altitude token to the variable <sup>a</sup>). A binding σ <sup>∈</sup> <sup>Σ</sup> is a partial function from variables to ground expressions: σ : *<sup>V</sup>* <sup>→</sup> *<sup>E</sup>* <sup>∅</sup>∪{⊥}. We remind ourselves that a substitution, as introduced in Section 7.2.4, is denoted noted σ(*e*). This means that it is the application of a binding σ on an expression *<sup>e</sup>* <sup>∈</sup> *<sup>E</sup>* and replaces variables with their value in the binding. Note, that a substitution does not have to replace all variables within an expression. Variables that do not appear in the binding remain in the expression. Formally:

∀*e* ∈ *E*, ∃*e* <sup>0</sup> ∈ *E* <sup>∅</sup>, *e* <sup>0</sup> <sup>=</sup> σ(*e*) <sup>∧</sup> variables (*<sup>e</sup>* 0 ) <sup>=</sup> variables (*e*) \ {<sup>v</sup> <sup>|</sup> <sup>v</sup> <sup>∈</sup> *<sup>V</sup>* <sup>∧</sup> σ(v) , ⊥}.

**Transition guards** In high-level Petri nets transition guards are used to prevent transitions to fire with unwanted token values and thereby stop unwanted behaviour. In the drone controller we use the guard ¬(a = down∧s.position.<sup>x</sup> < <sup>50</sup>) to prevent the drone from moving down when its altitude is below a certain threshold. Formally, transition guards are functions that evaluate to Boolean values (B = {>, ⊥}). Transitions can only be fired iff the guard evaluates to >.

**Integration of the concepts** Using the above definitions, we modify the definition of a Petri net to incorporate the new concepts. Specifically we change the following:


Formally, HLPN are described as tuples based on the structure of P/T nets (as defined before), but with added and modified fields: h*V*, *E*, variables, *P*,*T*, pre, post, guard, *m*0i, where:


This definition differs resembles the P/T definition from before, except for the introduction of variables and expressions and the new definition of marking, where a marking consists of a multiset of expressions rather than a natural number.

In fact, we can look at a classical P/T net is a special kind of high-level Petri net where the set of variables is empty (*V* = ∅) and only one expression (*E* = {•}) exists. Note that since transition guards are usually defined as Boolean expressions over expression comparisons, a P/T net's guard function always returns true: <sup>∀</sup>*<sup>t</sup>* <sup>∈</sup> *<sup>T</sup>*,∀σ <sup>∈</sup> <sup>Σ</sup>, guard (*t*, σ) <sup>=</sup> <sup>&</sup>gt;.

The semantics of a transition *t* is given in Equation (7.13). It differs from the previous transition semantics given in Equation (7.2) by adding the substitution of a binding within the pre and post functions.

$$\begin{aligned} \textit{transition}\_{t} &: \frac{\exists \sigma, \sigma(pre(t)) \leqslant m, guard(t, \sigma) = \top}{m \overset{t}{\to} m - \sigma(pre(t)) + \sigma(post(t))} \end{aligned} \tag{7.13}$$

The use of expressions in HLPN requires the extension of the substitution to include all expressions in the function image. Formally, <sup>∀</sup>*<sup>m</sup>* <sup>∈</sup> *<sup>M</sup>*,∀*<sup>p</sup>* <sup>∈</sup> *<sup>P</sup>*, σ(*m*)(*p*) <sup>=</sup> σ(*m*(*p*)). This substitution also has to be extended to multisets, since HLPN markings are defined as such. Applying a substitution on a multiset is performed by applying the substitution to each element: <sup>∀</sup>es ∈ M(*E*), σ(es ) <sup>=</sup> [σ(*e*) <sup>|</sup> *<sup>e</sup>* <sup>∈</sup> es], where [ ] denotes a multiset by intention.

Fig. 7.11: Petri net representing the control of a drone, using data as tokens and arc valuations. The control is composed of three modules, that represent the state of the controller joysticks: one to move upwards or downwards, one to rotate left or right, one to move forwards or backwards. The drone moves when the move transition is fired. It captures the state of the controller to move the drone. Places are labelled with multisets of tokens, shown as [token1, . . . tokenn]. Each token is a structured data, that can be a simple token (•), an atom (stay) or a record or subdata with named fields, such as (position = (*x* = 0, y = 0, *z* = 0), angle = 0). The position is a position relative to the initial position of the drone, and the angle is an angle on the horizontal plane and signifies the deviation from north. Arcs are labelled by multisets of tokens, that can use variables, for instance x. Transitions have implicitly a guard that always returns >, except the move transition that has an explicit guard <sup>¬</sup>(<sup>a</sup> <sup>=</sup> down <sup>∧</sup> <sup>s</sup>.position.<sup>x</sup> < <sup>50</sup>).

#### **7.5.3 Other High-level nets**

In the last couple of decades, researchers hae come up with numerous extensions and modifications of the P/T net formalism to ease the modelling of complex systems. This section introduces four representatives of such complex variants of Petri nets.

**Coloured Petri nets (CPN) [158]** CPN are an extension of Petri nets where each token can be of a certain *colour*. Each colour is a set of values, comparable to a type definition. The set of colours has to be clearly specified for a CPN. Arcs are modified to allow the specification of the colour to use in pre- and postconditions.

The drone example in Figure 7.11 is a CPN with the following colours:


Unfortunately, not all data types can be easily represented as colours, for instance, the drone state is a dictionary or tuple. The corresponding colour contains all the possible combinations of positions and angles. Since this set is infinite (*x*, y, *z* and angle are rational), this solution is not usable in practice, and the domains have to be made discrete and bounded.

**Symmetric nets [71]** Symmetric nets, formerly known as "well-formed Petri nets", are a special kind of Colored Petri nets that use only simple data types: tuples of constants in finite and ordered domains. The data structure is thus very limited, and cannot easily represent data of varying size, as well as data in *a priori* unbound domains. Operations on data are also very restricted: it is only possible to obtain the successor or predecessor of a value, and test equality between two values. There are no operations allowed on the tuples themselves.

Despite all these limitations, symmetric nets are successfully used in practical problems because they offer a formalism that is convenient for efficient structural analysis and model checking. The limited expressiveness of these types increases the number of properties that can be verified, in particular for the structural analysis of models, such as computation of bounds or invariants.

**Algebraic Petri nets (APN) [297]** Algebraic Petri nets are a special form of Colored Petri nets, that allow the use of abstract algebraic data types [87] as colours. Such algebraic data types consist of a signature and axiomatisation and hence allow the user to represent custom data types. The advantage of APNs is that every data type used has a precise axiomatisation and consequently proofs can be done by theorem proving without the usual limitation of finiteness of model checking. Using APNs, parametric and under-specified systems can be modelled and also be verified in a more systematic way.

**Timed Petri nets** [231] The concepts of time and of Petri nets are quite opposite: while time determines the occurrences of events in a system, Petri nets consider only their causal relationships. Several variants of Petri nets have been defined with the notion of time. The three most common are: Time Petri nets, Timed Petri nets, and Petri nets with Time Windows. In Time Petri nets, transitions are labelled with time intervals, that define the time at which the transition can be fired, after it has been enabled (has all its preconditions met). In Timed Petri nets, time is also put within tokens, that have thus an age, and transitions are labelled with time intervals that define the age at which tokens can be consumed. In Petri nets with Time Windows, transition are given time intervals, this means that transition can fire (not mandatory) only in this time interval.

In this chapter we do not consider time with Petri nets for simplicity, and only focus on the causal relations associated to Petri nets.

#### **7.6 Combining Model Semantics and Simulation**

The recent rise of computers in everyday life is especially of importance when their purpose is to react to and act upon environment changes. We refer to such systems as cyber-physical systems (CPS). Such systems consist of a software part (e.g. a controller program) and a hardware side that usually consists of sensors and actuators.

While smaller systems, such as heating/light systems that measure presence have been installed and used for a long time, the trend towards Internet-of-Things applications, "smart systems" (such as new-generation cars and trains), and general large-scale systems that include hundreds, sometimes even thousands of components drives the need for means to verify and validate such systems.

The problem of these highly heterogeneous systems lies in finding the right means to model each part of the system. While former approaches to find *the one* modelling language or tool failed, nowadays the trend is reversed. Modern research is looking to model every part of the system with its most appropriate modelling formalism. Subsequently the individual components are combined and simulated together. This approach, called co-simulation [126] has shown promising research results, but comes with one important question: How should we combine models that were developed using different syntaxes and semantics?

One of the approaches that aims to answer this question are *Functional Mock-up Units* (FMUs) [36]. The FMU formalism provides a homogeneous interface, the Functional Mock-up Interface (FMI). Each component is wrapped inside its own FMU and is henceforth executed using the FMI. The individual FMUs' inputs and outputs are connected to one another in order to allow information to be transmitted within a system. The semantics of such a composition are dominated by a so-called *master algorithm* that is responsible for passing control to individual components, relaying signals and choosing appropriate time step sizes which suit all units in the system.

In this section we introduce Petri Net Functional Mock-up Units (PNFMUs) [180]. This new type of FMU wraps a Petri net within the FMU in order to provide access to the efficient evaluation and calculations we introduced in the previous sections. Using Petri nets it is possible to detect deadlocks and possible system evolutions.

The FMI standard strictly defines the qualities of a valid FMU. In order to comply with this standard however, it is necessary that PNFMUs overcome three major challenges:

**1. Time evolution** Similarly to a Mealy or Moore machine, the Petri net formalism doesn't explicitly define a time concept. Often, the firing of a transition is accepted as a time unit. To overcome this limitation, the periodic or aperiodic wrappers presented in [272] can be used for this purpose. In addition, these wrappers has also been discussed in [83] when considering the semantic adaptation, giving the possibility to automatically generate FMUs from a domain specific language that solve this problem.

**2. Inputs/Outputs adaptation** Obviously, the inputs and outputs type and nature of a given formalism can differ from the simple value affectation of a variable defined by the FMI standard. Therefore, an adaptation must be performed as well for inputs and outputs of a FMU. The authors of [83] provided solutions with their domain specific language to overcome this limitation too.

**3. Non determinism** In the standard, FMI API functions are mathematically modelled as total functions [272]. This means that calling an FMU's API with the same parameters should always yield the same result. An initial, yet naive, approach to represent a Petri net state would be to consider it as a single marking. However, in situations where a Petri net has more than one fireable transitions at a given state, the evolution function of the FMI API (*doStep*) cannot yield a deterministic result. This particularity is clearly shown by the Petri net and its reachability graph in Figure 7.12. In this example, either *t*<sup>1</sup> or *t*<sup>2</sup> can be fired from its initial marking, leading to different system evolutions. This issue must be addressed to be able to represent a Petri net within an FMU.

Since the two first subjects of interest have been extensively discussed in the referenced publications, the non determinism of the formalism is considered here. Now that the problems related to the consideration of formalisms as FMUs has been addressed, let's discuss now of the PNFMU formalisation.

Fig. 7.12: A simple Petri net and its reachability graph. The markings are encoded as <sup>h</sup>*p*1, *<sup>p</sup>*2, . . . , *<sup>p</sup>*ni, where *<sup>p</sup>*<sup>i</sup> are the number of tokens within the places, which the ordered by their index. h1, 0, 1, 0, 0i encodes the initial marking on the left, stating that there is one token in the first and third place each (i.e. *p*<sup>1</sup> and *p*3).

#### **7.6.1 PNFMU Formalisation**

The need for Petri nets within an FMI system is closely tied to the need to analyse system evolutions and reachability of possible states. In order to do so, we need to define the formal basis of an PNFMU, which we base on the FMU formalisations presented in [272] and [51].

A standard FMU is defined as the structure *F* = h*S*,*U*,*Y*, *D*, *s*0, set, get, *doStep*i. Given a Petri net PN = h*P*,*T*, pre, post, *m*0i, we define that a PNFMU is a tuple PNFMU = h*S*,*U*,*Y*, *D*, *s*0, setN, getN, doStepNi.

A PNFMU's internal states *S* are all possible markings of the Petri net, not just the reachable ones (i.e. reach(*s*0) ⊆ *S*). *U* and *Y* are the Petri net's places which are writeable and readable, respectively. *D* remains the dependency of outputs on inputs and is used to avoid circular dependencies when composing FMUs. *s*<sup>0</sup> is set to the initial marking *m*0.

The biggest difference between FMU and PNFMU is that the former only operates on one state. On the contrary, PNFMU are designed to explore and operate on a Petri net's reachability graph. This change is reflected in the three functions set, get and doStep, which are adapted to perform operate on sets of states as follows:


$$doStep(s,0) = (s,0) \tag{7.14}$$

$$doStep(s, \, l) = \begin{cases} (succ, l) & \text{s.t.} \quad succ = \left\{ s' | \exists t \in T, \exists s\_i \in \left( s \cap SS(T, s\_0) \right), s\_i \xrightarrow{l} s' \right\} \land succ \neq \emptyset \\\ (s, 0) & \text{otherwise.} \end{cases}$$

$$(7.15)$$

$$\text{For } h \ge 2:\tag{7.16}$$

$$doStep(s, h) = \begin{cases} \quad (s, 0) \text{ s.t. } (s, 0) = doStep(s, 1) \\\ \left(s^{\prime\prime}, h^{\prime\prime} + 1\right) \text{s.t. } (s^{\prime}, 1) = doStep(s, 1) \wedge (s^{\prime\prime}, h^{\prime\prime}) = doStep(s^{\prime}, h - 1) \end{cases} \tag{7.17}$$

The *doStep* function for the example Petri net net above is given by the equations above. To show its execution, here is the first four steps of *doStep* for *pn*<sup>0</sup> :


Table 7.1 compares the definitions of the individual components of both, the FMU and PNFMU.

#### **7.6.2 PNFMU Example**

Figure 7.13 shows some possible evolutions of a PNFMU that wraps the Petri net of the above example. Out of the infinite sequences of actions possible, we choose five traces that are being presented as an evolution tree.

• First, the main branch (center) shows the *doStep* evolution of the system. Note that after the third *doStep* the returned state remains unchanged and the returned *h* 0 is 0. This indicates a deadlock, as no further evolution is possible.


Table 7.1: Comparison of the structures of FMU and PNFMU.


We can easily see that, using PNFMUs, it is possible to study the possible evolutions of a system and analyse whether the execution of certain sequences leads to a reachable marking (i.e. a "good state"). We can also find deadlocks situations, i.e. states where a *doStep*) returns 0.

Fig. 7.13: A tree displaying possible system evolutions. Nodes are the (sets of) states and arcs are annotated with the action performed (where *s* is the variable that stores the previous states). Markings that are not in the reachability graph of *s*<sup>0</sup> are gray .

#### **7.6.3 PNFMU Composition**

The FMI standard defines FMU composition in a very simple manner. An FMU's outputs are directly connected to another FMU's inputs. This is usually performed by the *master algorithm* using the *set* method. Generally, the master algorithm performs such updates in two steps: 1. update all FMUs' input values; 2. perform system evolution by calling *doStep* on each FMU.

The composition of PNFMUs is slightly more complex, as it is necessary to handle sets of states. In general, three main scenarios can be distinguished:

**One-to-One/One-to-Many** Connecting a PNFMU that is currently in one, single state to another PNFMU is most trivial of the possibilities. Upon update, the marking(s) of the second PNFMU's inputs are set to the first PNFMU's output places' values. If the second PNFMU has multiple states, all states are updated.

As represented in Figure 7.14a the place *p*<sup>5</sup> of PNFMU <sup>1</sup> is linked to the place *p*<sup>0</sup> of PNFMU <sup>2</sup>, drawn in bold. The execution scenario is quite trivial. In fact, for every marking of PNFMU <sup>2</sup>, the number of tokens of place *p*<sup>0</sup> is set to the number of tokens of the place *p*<sup>5</sup> from the PNFMU <sup>1</sup>.

**Many-to-One** The case represented Figure 7.14b is slightly more complicated.PNFMU <sup>1</sup>, which has multiple markings, is connected to PNFMU <sup>2</sup> that has one single marking. In other words, there is two distinct numbers of tokens in the place *p*<sup>5</sup> in PNFMU <sup>1</sup>, respectively 0 and 1. In consequence, the variables update step should create one marking for each values of PNFMU <sup>1</sup>'s output variable. In the current case, PNFMU <sup>2</sup> should have two markings after the update, one for *M*(*p*1) = 0 and another for *M*(*p*1) = 1.

**Many-to-Many** After a step evolution, it is possible that both PNFMUs contain more than one marking. In fact, the *Many-to-Many* relationship is a generalisation of the *Many-to-One* case. This case requires to write all output values of one PNFMU to all inputs of the other. Effectively, the Cartesian product of possible states is created, where all combinations of PNFMU <sup>1</sup>'s values are applied to all input places of PNFMU <sup>2</sup>.

Fig. 7.14: FMU relationships before and after the update

#### **7.6.4 Advanced Composition Mechanisms**

Modularity is a mandatory principle to apply Petri nets to real world-sized systems. Modular extensions of Petri nets allow to create complex models by combining smaller entities. They facilitate the modelling and verification of large systems by applying a divide and conquer approach and promoting reuse. Modularity includes a wide range of notions such as encapsulation, hierarchy and instantiation. Over the years, Petri nets have been extended to include these mechanisms in many different ways. The heterogeneity of such extensions and their definitions makes it difficult to reason about their common features at a general level. An approach has been proposed to standardise the semantics of modular Petri nets formalisms, with the objective of gathering even the most complex modular features from the literature. This is achieved with a new Petri nets formalism, called the *LLAMAS* Language for Advanced Modular Algebraic Nets (LLAMAS)[197]. This framework can be envisioned to extend current work on *PNFMU* and for the abstract description of the master algorithm.

#### **7.7 Tooling**

The vast amount of research invested in the Petri nets domain not only led to many important, theoretical findings but also saw the development of tools and software that can be used to model, analyse and simulate Petri nets. In the following section we will describe some tools that can be used to develop models based on Petri nets and to perform model checking thereon. Some of the tools described below are currently unavailable or are not able to perform model checking for Petri nets directly. Nevertheless, we will introduce them since they contribute interesting concepts and serve as potential candidates for extension to the formalism. Note, that since the domain is subject of intensive research, new ideas are often presented in in academic tools which oftentimes remain proof-of-concept implementations and not advanced into mature, reliable software.

#### **7.7.1 Tools for Petri net Modelling and Verification**

Since the Petri net formalism is based on a graphical syntax, matching model editors, composers and visualisers are an important important part of the Petri nets tool chain. Over the years, a lot of tools have been implemented to perform these tasks, but only a few have survived long enough to be well-recognised by the Petri nets community, or to be used in industry.

**CPN Tools** [206] (http://cpntools.org) is a tool for editing, simulating, and analysing high-level Petri nets. It supports basic Petri nets, timed Petri nets and Coloured Petri nets. It features a graphical editor, a simulator and includes a state space analysis component.

**CPN-AMI**[132] (http://move.lip6.fr/software/CPNAMI) is a formal modelling platform based on Petri nets, more specifically targeting Symmetric nets. It provides a graphical user interface to create and edit models, run tools built upon the platform and obtain their results. The CPN-AMI platform uses tools developed by several research teams to perform structural and behavioural analysis of models.

The platform features software to graphically create Petri nets modularly or using a scripting interface. Other tools allow to compute structural properties, such as bounds, invariants, syphons, traps, and liveness. The platform is also able to generate the state space of a Petri net, and perform CTL and LTL verification using various model checkers.

**ITS-Tools** ITS-TOOLS [267] (http://ddd.lip6.fr/) is a successor of CPN-AMI. It allows its users to create models using a textual language or a graphical editor for Petri nets. This tool is able to perform behavioural analysis (safety, CTL and LTL model checking) on models expressed in Place/Transition, Symmetric and Time Petri nets, as well as some other formalisms.

**AlPiNa & StrataGEM: Algebraic Data Types and Term Rewriting tools** In recent years, the University of Geneva's SMV group has produced two tools for model checking and model editing: the Algebraic Petri Nets Analyzer (AlpiNa) [56, 57, 151] and StrataGEM 4 [190, 39]. AlpiNa is a model checker dedicated to Algebraic Petri Nets. StrataGEM marries the concepts of Term Rewriting to the efficiency of Decision Diagrams, in order to perform efficient model checking. While AlPiNA is adapted to high-level specifications using Petri nets, StrataGEM focuses on the low-level ones.

These two tools heavily rely on algebraic data types and term rewriting techniques to represent systems and their semantics. They are able to compute large state spaces, and to evaluate reachability properties, as proven in the Model Checking Contest [171].

**SNAKES** [230] (https://snakes.ibisc.univ-evry.fr) is a Python library that provides a framework to define and execute many sorts of Coloured Petri nets. A key feature of SNAKES is the ability to use arbitrary Python objects as tokens and standard Python expressions in many points, for instance in transitions guards or arcs.

**Renew**: Renew [62] (http://www.renew.de) is a tool that supports the development and execution of object-oriented Petri nets, a specific kind of Coloured Petri nets. Its main feature is its integration with the Java programming language: Petri nets can be labelled by Java code, and thus call Java methods in transition guards or on arcs.

**Petri net kernel (ePNK)**: [164] (http://www.imm.dtu.dk/~ekki/projects/ePNK/) is a platform for developing Petri net tools based on the PNML [147] transfer format. Its main idea is to support the definition of

<sup>4</sup> https://github.com/mundacho/stratagem

Petri net types, which can be easily integrated into the tool, and to provide a simple, generic graphical editor, which can be used for graphically editing nets of any plugged in type.

**Tina** [29] (http://www.laas.fr/tina) The TIme Petri Net Analyser is a toolbox for the editing and analysis of Petri nets, and Time Petri nets. It features a graphical editor, and a set of tools to perform structural analysis (e.g. invariants), behavioural analysis (e.g. reachability and coverability graphs) and LTL model checking.

**TAPAAL** [157] (http://www.tapaal.net/) is a tool for the modelling, simulation and verification of Timed Petri nets. It offers a graphical editor for drawing Petri nets, a simulator for experimenting with the designed nets, and is able to check the bound of the model, and to verify properties expressed in a subset of CTL. TAPAAL can translate its models to the format of the UPPAAL tool. In the same domain, Open-Kronos [298] uses the Büchi automata approach to verify real-time systems.

**The Petri nets repository** [146] (http://pnrepository.lip6.fr) is a recently created repository of Petri net models. It includes models imported from several sources, such as the Model Checking Contest [170, 169], the former PetriWeb repository [127], and the Very Large Petri nets benchmark suite (http://cadp.inria. fr/resources/vlpn/). Its main feature is that this repository provides access to models and corresponding, computed properties through both, a web interface and an API.

Many other tools exist to perform model checking on systems specified with formalisms that are not Petri nets, such as for instance automata or communicating processes. Among them, the following tools are worth mentioning:

**SPIN** [149] (http://spinroot.com) is a software model checker that verifies specifications written in PROMELA (PROcess MEta LAnguage), adapted to the representation of asynchronous distributed systems. The tool uses the Büchi automata approach to verify LTL properties on the models.

**SPOT** [192] (https://spot.lrde.epita.fr) is a Büchi automata library rather than a full model checker. It is intended to be coupled with an engine able to compute the transition relation of the system, in order to build a LTL model-checker. This design allows it to be used with any kind of formalism. This library implements great number of useful algorithms related to LTL model checking: LTL parsers, LTL formulae syntactical simplification, translation to several flavours of Büchi automata, automata simplification, and of course emptiness check algorithms for them. It is considered one of the best candidates for operational model checking [245].

**UPPAAL** [27] (http://www.uppaal.com) UPPAAL is an integrated tool environment for modelling, simulation and, verification of real-time embedded systems. Typical application areas of UPPAAL includes real-time controllers and communication protocols in particular, those where timing aspects are critical.

**SCADE** [265] (http://www.esterel-technologies.com) is an industrial-grade environment for the development of critical embedded systems. It is coupled with a model checker and used in industry in the domain of synchronous systems.

Note that this list is non-exhaustive and the provision of a complete list is out of the scope of this chapter. Its purpose is to provide a short overview over some of the more popular tools to help the decision of an appropriate one. The choice of a tool should however depend on various criteria, such as the Petri net class (P/T net, Coloured Petri nets, Timed Petri net), the type of properties that should be tested by the tool, the required efficiency of the tool and the execution environment. We encourage the reader to consult other resources5 to find additional guidance towards a better informed decision process.

#### **7.7.2 Evaluation of Model Checking Techniques**

The Petri nets community is eagerly hosting and participating in various model checking contests in order to evaluate the various model checking techniques and tools and to discover approaches that might be particularly well-suited for certain model classes and types. Some of the more prominent ones are following, but note that this list is non-exhaustive.

**The Hardware Model Checking Contest** [34] was first held in 2007, and is now associated with the CAV (Computer Aided Verification) and FLOC (Federated Logic Conference) conferences. It focuses on circuit verification by means of model checking based on SAT-solvers. This event ranks the three best tools according to a selected benchmark.

<sup>5</sup> such as https://en.wikipedia.org/wiki/Model\_checking

**The Verified Software Competition** [165] takes place within the Verified Software: Theories, Tools and Experiments (VSTTE) conference. This competition is a forum where researchers can demonstrate the strengths of their tools through the resolution of five problems. The main objective of this event is to evaluate the efficiency of theorem proving tools against SAT-solving. Started in 2010, it has now become a yearly event.

**The Competition on Software Verification** [4] is an event associated with the conference on Tools and Algorithms for the Construction and Analysis of Software (TACAS). Aimed at the verification of safety properties of C programs, it has been held yearly since 2012.

**The Satisfiability Modulo Theories Competition** [54] takes place within the context of the CAV conference. Held yearly since 2005, its objective is to evaluate the decision procedures for checking the satisfiability of logical formulas.

**The SAT Competitions** [159] proposes to evaluate the performance of SAT solvers. Initiated in 2002, it is held every two years since 2007, and identifies new challenging benchmarks at each edition.

**The Model Checking Contest** [169] at the Petri Nets conference puts emphasis on the specification of parallel and distributed systems, and their qualitative analysis.

The main problem of these contests is the difficult choice of comparison metrics. It is seemingly easy to compare tools for a set of models. Drawing conclusions from the achieved tool results in order to compare of model checking *techniques* is a much more complex endeavour, as each tool merges several techniques to be efficient. Moreover, the efficiency of model checking techniques highly depends on each individual model's characteristics. For instance, partial order reductions are showing good results for highly parallel systems with few synchronisations, but are less efficient when the degree of synchronisation increases. However, since verification techniques are often combined with other ones, it is difficult to clearly attribute good performance to an individual technique.

#### **7.8 Summary**

In this chapter we have shown a way to develop cyber-physical systems that include concurrent dimension. Our proposal is to consider to model first our system as many entities cooperating. Each entities can be modelled using the most convenient formalism to the problem that is considered. We propose for concurrent systems the use of Petri nets. We explain the interest and capabilities of Petri nets for modelling complex systems in an abstract way, i.e. by masking details that are not useful. Such modelling techniques hide concerns related to distribution, naming, communication mechanism and representation of data structures. We provide also their semantics through deduction systems in order to explain precisely all notions we are using such as states, marking and state space. It must be noted that the key aspect of the semantics of Petri net is the potential non-deterministic behaviours that we can exhibit from a model. The impact of this dimension is the potentially very large number of states of a system. We then develop some formal ideas to analyse Petri nets such as marking exploration and the use of invariants. While there is a complexity barrier for marking exploration, the use of invariants need human intervention.

In the rest of the chapter we have been interested into the idea of managing complexity by applying the *divide to conquer* principle. It means to consider separately the modelling and verification into small units. We also promote by this model decomposition the possible integration of heterogeneous modelling which is very important for the intrinsically heterogeneous cyber-physical systems.

The need for simulation of heterogeneous systems is also covered by our approach. It is based on the construction of functional units (FMU) and their cooperation into a larger system by specific master algorithms. Petri nets being a formalism often used to represent concurrent executions, defining its state as a set of markings was discussed and formally presented, avoiding the violation of the FMI API determinism. Furthermore, the API standard was extended with functions to add more observability and functionalities on the considered PNFMU. This study showed that deadlocks can be detected when simulating a PNFMU with the standard API, yet without being able to know the actual markings in which the Petri net is in a deadlock. Then, the composition of PNFMUs was introduced, yet partially leaving out of the study time evolution and outputs/inputs adaptation. Moreover, since the state of a PNFMU is now defined as a set of markings, a multi states relationship of the composition between FMUs was presented.

start

press start

release

press

Fig. 7.15: The reachability graphs of the Petri net in Figure 7.1 with different initial markings. Note how the smaller graphs can be found as subgraphs inside the larger ones. This is due to the monotony of Petri nets as discussed above. Moreover, the node colour is representative of the number of tokens in place fuel, ranging from 0 (lightest) to 3 (darkest).

#### **7.9 Literature and Further Reading**

For a deeper understanding of concurrency modelling and Petri nets, we refer the interested reader to the following works. An excellent book by Reisig [239] is explaining fundamental analysis techniques for Petri nets. Through well-chosen examples, it also shows how to model several well-known systems that can be useful for beginners and newcomers to the domain of discrete dynamic system modelling and analysis. M. Diaz [85] also provides a look at basic techniques for modelling with Petri nets. Several extensions of place transition nets are explained and their practical use for concrete applications detailed. This book will probably be of more interest for the curious Petri-netter who wants to dive into various modelling options such as stochastic Petri nets, Timed Petri nets and their corresponding formal techniques.

Finally, [26] is a reference for people who are interested in exciting and practicable directions related to performance modelling and cost estimations of system through quantitative methods. The authors presented useful methods based on Markov chains and develop these techniques for the purpose of stochastic Petri net analysis.

#### **7.10 Self Assessment**


8. In these Petri nets, what are the bounded places. What are the place bounds of this Petri net?

9. Can you identify which of these transitions are live, and which ones are not?

10. For which initial marking of *P*<sup>1</sup> this Petri net has no dead state or has dead state?

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

## **Chapter 8 AADL: A Language to Specify the Architecture of Cyber-Physical Systems**

Dominique Blouin and Etienne Borde

**Abstract** This chapter is devoted to formalisms for describing system architectures, and in particular to the Architecture Analysis and Design Language (AADL). AADL is an Architecture Description Language (ADL) well suited for the modelling of embedded and cyber-physical systems. The architecture is central in Multi-Paradigm modelling for Cyber-Physical Systems as it provides a description of the overall system and the environment into which it will operate. From such description, other models of other languages and formalisms such as those described in this book can be generated and augmented to study other aspects of the system, which is essential for its validation and verification. After a brief introduction to ADLs and their role in MPM4CPS, the AADL will be presented and its use illustrated with the modelling, analysis and code generation for a simple Lego Mindstorm robot for carrying objects in a warehouse. A simple top-down architecture-centric design process will be followed starting from the capture of stakeholder goals and system requirements followed by system design, design analysis and verification and finally automated code generation.

#### **8.1 Learning Objectives**

After reading this chapter, the reader should have sufficient knowledge of the family of AADL languages and modelling approaches for:


#### **8.2 Introduction**

This chapter introduces Architecture Description Languages (ADLs) and in particular the SAE Architecture Analysis & Design Language (AADL). We start by a short introduction on the problems of building nowadays complex cyber-physical systems and explain the overall approach to solve these problems as promoted by the AADL community, which is based on architecture-centric virtual integration.

We then move on to the introduction of AADL by a short overview of the language followed by a detailed introduction of the language constructs and semantics. We have chosen to introduce AADL by presenting a

Dominique Blouin and Etienne Borde

Telecom ParisTech, Paris, France

e-mail: {dominique.blouin,etienne.borde}@telecom-paristech.fr

typical development process so that it better illustrates how the language can be used. Therefore this process is first introduced followed by the Lego Mindstorm line follower robot example that is used to illustrate AADL modeling. We then present the detail modeling of the example for each step of the development process. Note that we have chosen to introduce the language constructs in an incremental way, by only introducing the constructs that are necessary for the modeling corresponding to the current step of the development process. In this manner, the reader can immediately see how the constructs are used in the context of the development process.

We illustrate the modeling process by presenting successive refinement steps of the models down to automatic code generation. Traceability links established between each step are also illustrated as well as basic analysis capabilities of AADL on the models of the deployed system. In the end, C code is automatically generated that can be compiled and deployed on the Lego robot for building a real working system.

#### **8.2.1 Increasing Systems Complexity and Unaffordable Development Costs**

The complexity of CPSs is constantly increasing due to the increasing number of functions that these systems are required to perform, which often must include more and more intelligence and must be more and more interconnected. In addition, these systems must satisfy an increasing number of constraints due to their operating environments, which are often hostile and limited in resources. Therefore, these systems are becoming more and more difficult to develop at affordable costs. This is particularly true for the avionics domain, for which a measure of complexity can be obtained from the number of Software Lines of Code (SLOC) embedded in aircrafts. This increase in complexity is illustrated in figure 8.1 where a plot of the number of onboard SLOCs as a function of years for the most common aircrafts built by Airbus and Boeing since the 70's is shown. For each constructor, the slope of the curve indicates that the number of SLOCs has roughly doubled every four years resulting in a non-linear increase in systems complexity.

The development effort required to develop these systems has been shown to increase exponentially with the number of SLOC. For example, while the F35 military aircraft has approximately 175 times the number of SLOC of the F16, it is estimated that it required 300 times the development effort of the F16 [253]. The result of this, as shown in figure 8.1, is that we are no longer able to develop more complex aircrafts with traditional development methods, since their development costs is not affordable. This is illustrated on the figure by the dark blue line whose slope is pegged after roughly year 2010.

Fig. 8.1: The evolution of the number of SLOCs with time in commercial aircrafts (reproduced from [133])

In order to understand how this limit is reached, let us consider the traditional V-cycle model (figure 8.2), which is the most commonly used engineering process for safety-critical embedded systems. The numbers in blue on the figure indicate the percentage of errors introduced at the various phases of the cycle using the traditional development methods. As can be seen, a large majority of these errors (70%) are introduced at the *early* phases (requirements engineering and design) of the cycle, while the majority of these errors are only discovered much later at system integration and operation time. As a result, the cost of fixing these errors is dramatically high, since they often require the upfront design to be modified and parts of the system to be re-implemented. As a matter of fact, studies have shown for large projects that on one hand, rework due to introduced errors may account for 60% to 80% of the total software development costs [133]. On the other hand, the cost of software development, which could be as high as 70% in 2010 keeps increasing and could reach up to 88% of the total system-development cost by 2024 [133]. These figures show the potential for achieving high cost reductions by the discovery of flaws as early as possible during development.

Fig. 8.2: V-cycle development process model annotated with figures for introduced errors and costs to removed them (reproduced from [101])

#### **8.2.2 Mismatched Assumptions in Collaborative Engineering**

But how are these errors leading to these rework costs are introduced? In order to understand this, let us consider a number of well-known errors that led to important damages and costs.

#### **Ariane 5 Rocket**

In June 1996, the Ariane 5 rocket exploded during its inaugural flight less than 40 seconds after departure. This was due to an integer overflow in the software used to control the side velocity of the rocket. That error propagated to an error in the navigation system, which triggered self-destruction of the rocket to prevent ground damages. This software bug cost 370 million dollars and is known to be the most expensive bug in history [10].

The integer overflow occurred because the software of Ariane 4, which had much smaller velocities, was reused for Ariane 5. It was forgotten that this software was working under the *assumption* of a maximum velocity that could be represented in software. Such assumption was no longer matched by Ariane 5, which had much greater velocities.

#### **iTunes**

When dual core processors were first used in computers, the iTunes software was crashing randomly when ripping music CDs [156]. The software was multi-threaded with one thread determining the sound level of tracks while a second one was converting the audio data. A single core processor would always sequentially execute the first task and then the second one. On a dual core, the two concurrently executing threads were attempting to update the same music data without proper synchronization.

In this case, the software was implicitly assuming sequential execution of tasks, which assumption was no longer matched by dual core processors.

#### **Airbus 380 Cables**

When the first Airbus 380 aircraft was assembled in Toulouse in France, the wires and their harnesses turned out to be a few centimeters too short for the cabin, which led to several billions of extra costs [5].

The problem was traced to the fact that different design teams had used different versions of a Computer Aided Design (CAD) tool to create the drawings. Version 5 of the tool was a rewrite of version 4 and the calculations of bend radii for wires as they follow the air frame were inconsistent across the two versions. It was eventually realized that the issue was pervasive throughout the design. Again, this issue can be traced to different assumptions on the way calculations of wire bending are performed between different teams using different tools.

These few examples show that an important source of errors is due to assumptions a system or component makes for proper operation not being matched by the environment in which it is used. This points out the need for improved system integration performed early for ensuring consistency of the overall system is preserved during the constantly evolving collaborative designs.

#### **8.2.3 System Architecture Virtual Integration: Integrate, Analyze then Build**

A solution to this mismatch assumptions problem is promoted by System Architecture-centric Virtual Integration (SAVI), which makes use of models of the systems that can be virtually integrated and analyzed for early fault discovery before the system is physically built [253]. Such process is illustrated in figure 8.3 where the left side of the well-known V-cycle development process is augmented with parallel left side validation activities making use of models for the domains covered by the system at the appropriate levels of abstraction at each phase.

#### **8.2.4 Architecture-Centric Authoritative Source of Truth**

The aforementioned virtual integration process is supported by an architecture model playing the role of Authoritative Source of Truth (ASoT) [253]. The model provides a global view of the system and its environment and is a central place into which other models detailing the different parts of the system can be integrated. It forms a reference model capturing all properties relevant for determining if the system meets its requirements.

Such ASoT model is depicted in figure 8.4. Other models for the various analyses required by the virtual integration process may be generated from the architecture model. Properties such as safety, security, real-time performances, resources consumption, etc. estimated from the analysis activities supporting virtual integration are then used to determine if the system meets its requirements.

This architecture-centric approach therefore makes architecture models first class citizens in the development of CPSs in order to support virtual integration activities, thus reinforcing the importance of ADLs, which is the topic of this chapter. Such architecture-centric virtual integration process can actually lead to substantial system development costs reduction as shown by a study on the Return of Investment (ROI) for the SAVI Initiative [133]. According to this study, the cost reduction for a 27-MSLOC system can be as high as \$2 billion out of an estimated \$9 billion total cost, which represents a cost saving of about 26% due to early correction of requirements and design faults.

Fig. 8.3: Traditional V-cycle development process model augmented with architecture-centric virtual integration validation activities (reproduced from [205])

Fig. 8.4: Architecture-centric single source of truth modelling approach (reproduced from [98])

#### **8.2.5 Organisation of the Chapter**

The previous sections of this chapter illustrated the central role of ADLs for architecture-centric system architecture virtual integration in order to address the challenges of developing complex CPSs. Therefore, the rest of this chapter introduces ADLs in greater details, and in particular AADL, which is an ADL well suited for the modelling of both the cyber and physical parts of CPSs, and the deployment of the cyber part over the physical execution platform part.

AADL will be introduced in a tutorial-like fashion by presenting the modelling of a simple robot CPS whose purpose is to carry objects in a warehouse. This example is introduced in section 8.4. Even if the AADL language itself does not impose any development process in particular, in order to better illustrate the use of AADL, the aforementioned top down design V-cycle process model augmented with SAVI will be followed (figure 8.3), starting from requirements modelling down to automated code generation from the software architecture model. For each step of this process, the required AADL constructs will be first introduced and their usage will then be illustrated by modelling the corresponding part of the robot example system.

#### **8.3 AADL Overview**

The development of AADL dates back to 1999 when Bruce Lewis working for the US army started a committee to make AADL an SAE standard. Initially standing for Avionics Architecture Description Language, AADL was first developed as an ADL for the avionics domain. It was strongly inspired from another language called MetaH and developed by Honeywell during a DARPA research project. Much of the syntax and the strongly typed property of MetaH (and therefore of AADL) were borrowed from the Ada programming language, which is dedicated to safety-critical embedded systems. As it was soon realized that AADL could be used for any embedded system, it was renamed to Architecture Analysis and Design Language thus preserving the acronym.

As an SAE standard AS-5506, AADL is being developed by the AS2C subcommittee, which includes participants from both academia and industry such as the Software Engineering Institute (SEI) of the Carnegie Mellon university, ISAE, Kansas State University, the U.S Army, NASA, the European Space Agency, INRIA, the Russian Academy of Science, Adventium Labs, Ellidiss Technologies, the Aerospace Corporation, Honeywell, Rockwell-Collins, Airbus industries, Boeing, Dassault Aviation, Toyota and Telecom ParisTech, which is the institution of the authors of this chapter. The committee has also active collaborations with other research initiatives and standardization bodies such as the aforementioned SAVI initiative, the ARINC653 working group and The Open Group Real-time. Despite that the development of AADL was started long time ago, its development is still an ongoing work, for which there has already been 2 major releases while a third one (AADL 3) is in preparation at the time of writing.

A comparison of the capabilities of AADL with other well-known ADLs such as SysML, MARTE and UML is depicted in figure 8.5, according to the intended use and domain covered by the languages. Both SysML, which covers the domain of the physical world and UML, which covers the domain of software were developed mostly for modelling with limited analysis capabilities, due to the weak semantics inherited from their high level of genericity. Conversely, AADL and MARTE were given a stronger semantics due to their more specific covered domain of embedded systems, with AADL performing better on the analysis domain due to its longer history and better maturity1.

A few approaches have made use of UML and SysML for embedded systems modelling such as respectively Papyrus UML-RT [227] and TTool [274]. However, the only way to make these languages useful for embedded systems is to specialize them using the UML profile extension mechanism. We note however that while the advantage of using UML profiles is that existing tools can be reused with the extended language, it has the drawback of less flexibility in tailoring the language for the domain, including the introduction of accidental complexity due to unnecessary features inherited from the generic language also visible from the extended language. Such is also the case of MARTE, which while showing characteristics similar to those of AADL in terms of intended use and domain suffers from its implementation as a UML profile. The fact that AADL was directly implemented as a DSML avoids this accidental complexity and provides constructs better fitted for the intended domain and use.

While the intended domain of AADL was originally avionics (it was initially named Avionics Architecture Description Language) and soon extended to embedded systems, its version 2 is an adequate language to also model CPSs. Version 2 added abstract components that can be used to model at the system level of abstraction, with similar level of abstraction than SysML. It also introduced annexes for behavior and fault tolerance modelling. In addition, the hardware modelling capability initially developed for embedded systems in combination with the system and abstract components can be reused for modelling the physical parts of CPSs (plant model), with a more appropriate coverage of the domain than what could be done with the too generic SysML block concept. Finally, the software modelling and deployment capabilities of AADL make it an ideal language for addressing the challenges due to the rapidly growing cyber part of CPSs [101].

There are 3 main tools for editing and analysing AADL models. The Eclipse-based Open Source AADL Tool Environment (OSATE) [224], which is developed by the SEI at Carnegie Mellon University, is a reference implementation as it is developed by the leading language architecture team. There is also another Eclipse-based

<sup>1</sup> Note that this comparison taken from [3] is only illustrative and not very precise as one could argue that the UML should somehow overlap with MARTE and AADL regarding the covered domains since all three languages cover parts of the software domain.

Fig. 8.5: Comparison of well-known ADLs in terms of intended use and domains (reproduced from [3])

tool named MASIW [200], which is developed by the Russian academy of science and finally, commercial tools such as STOOD and AADL Inspector developed by Ellidiss Technologies are also available [7].

#### **8.4 CPS Running Example**

The running example that will be used throughout the rest of this chapter consists of a robot system whose purpose is to carry objects in a warehouse from one point to another. The robot shall follow a path indicated by a line drawn on the floor of the warehouse. Several robots may be used in the warehouse and their paths may cross each other. Therefore, the robot should be able to stop momentarily when an obstacle is detected on the line and resume its trajectory once the obstacle is gone. The robot system should be able to carry objects in a minimal amount of time, and the cost of manufacturing such robot should be as low as possible so that the product has advantages over its competitors on the market. For illustration purposes, we will also add a few performance requirements to illustrate the need to perform performances analyses such as timing and latency.

Due to its low cost thus making it easily available, the Lego Mindstorm robot [182] in its NXT version will be used in a configuration as shown on figure 8.6, where two wheel assemblies are provided ❶ with a light sensor for line following ❷ and a sonar for obstacle detection ❸.

The robot will be running a simple line follower application described in [220] for following the edge of a thick black line as illustrated in Figure 8.7. Since the light sensor has a given field of view, the observed light intensity is inversely proportional to the part of the field of view of the sensor occupied by the black line. This light intensity will be used to compute the turn angle of the robot.

The turn angle will be computed using a PID (Proportional Integral Derivative) control algorithm. Such algorithm has the advantage of providing a much smoother line following behaviour compared to the two simpler algorithms depicted in Figure 8.8, since the computed turn angle variable has a much finer grained set of states (theoretically continuous) compared to the left (bang bang) and middle approaches where the turn angle variable has respectively 2 (left or right) and 3 (left, straight or right) states.

Fig. 8.6: The Lego NXT Mindstorm robot configured to execute a simple line following application with obstacle avoidance

Fig. 8.7: Robot and light sensor following the edge of a line (reproduced from [208])

Fig. 8.8: Three ways of controlling the robot with the adopted PID method on the RHS of the figure (reproduced from [208])

#### **8.5 The Development Process**

While AADL does not impose any specific development process, it is typical for safety-critical systems to follow a V-cycle development process model augmented with architecture-centric system architecture virtual integration as discussed earlier and illustrated in Figure 8.8. The modelling of the line follower robot CPS will follow such process. Introducing AADL by following a development process allows to better illustrate how AADL can be used and what can be achieved with it.

The architecture-centric virtual integration process is partially supported by the ALISA (Architecture-Led Incremental System Assurance) set of notations and workbench. ALISA is an add-on to the AADL language supported by the OSATE tool that will be used for this tutorial. It originated from the Requirements Definition and Analysis Language [37, 236], which was originally planned to become a requirements annex for AADL.

ALISA augments AADL with a set of languages for the modelling of stakeholders, stakeholder goals, system and software requirements, verification plans and verification methods, and assurance cases for the incremental development of high-assurance systems. Similar to SysML, requirements can be modelled and allocated to architecture elements responsible for verifying them. Requirements can be decomposed and refined incrementally as the architectural design is refined and decisions are made. Complete modelling of assurance cases with arguments and claims linked to requirements is supported making ALISA ideal for the certification of safety-critical systems. Although a thorough description of ALISA is beyond the scope of this chapter, its basic requirements modelling capability will be demonstrated with the running example of this chapter. For instance, a few performance requirements will be captured and linked to the scheduling and latency analyses performed on the running example.

RDAL, and consequently ALISA, were strongly inspired by another work that is worth mentioning in this chapter. It consists of a set of 11 best practices described in the Requirement Engineering Management Handbook (REMH) [184]. The REMH was commanded to Rockwell Collins by the Federal Aviation Administration (FAA) to survey requirements engineering practices in industry [183]. Following this survey, the authors recommended 11 practices for the requirements management of safety-critical systems based on lessons learned from the Requirements Engineering (RE) research and results from the industry survey. The proposed practices can be adopted piecemeal, with minimal disruption of an organizations development process to address the slow or non-existent industry adoption of RE.

For this chapter, the left part of the V-cycle process model decomposed into steps inspired by the best practices of the REMH will be used to illustrate the use of AADL. Such decomposition is depicted in figure 8.9, where the boxes of the central column depicts the steps of the process, with their input and output models shown as boxes respectively located on the left and right sides of the figure. The language used for the models is specified following the ":" symbol. The dashed borders indicate steps that are not covered in this chapter.

The process starts by capturing an overview of the system to be developed creating models of the stakeholders, goals and operational contexts for the system. Such models are then used to derive use cases scenarios for the system, which together with the contexts and goals allow creating a functional architecture for the system. Then, a physical plant model for executing the system functions is specified. Next, the software model is derived from the functional model and deployed on the physical plant. From the deployed system model, analyses such as scheduling and latency can be performed. The models may then be modified to meet performance requirements and optimize non functional properties. Then, an operating system platform is selected to execute the software. The models are then refined for the given operating system using the RAMSES tool [235]. This refined AADL model can then be analysed again providing more accurate results due to specifics of the execution platform taken into account. Depending on the analyses results, the input models at any step of the process may be modified in an iterative manner until the design meets the requirements. Then, code can be automatically generated using RAMSES.

#### **8.6 Modelling the Line Follower Robot with AADL**

This section presents the modelling of the running example introduced in section 8.4 by following the development process introduced in section 8.5. Note that for didactic purposes, we will not present the complete set of models but only the parts relevant for the language concepts being taught. For more information, the reader can view the complete set of models made available from [63].

Fig. 8.9: The process for designing the CPS system (left side of the V-cycle of Figure 8.3) and the employed notations

#### **8.6.1 System Overview**

The first step of the process consists of specifying the overview of the system to be developed. It includes specifying why the system is needed by stating its purpose and goals, as well as how he system will interact with its environment. Specifying the system and its environment provides a sound understanding of the *boundary* of the system. Such boundary is defined by the set of monitored and controlled variables representing the precise interaction of the system with its environment. Identifying a correct system boundary is difficult since one needs to ensure that all interactions of the system with its environment on which proper system operation depends have been considered, for all the operation modes of the system.

**Stakeholders and their Organizations** For the running example, let us assume that company *Tartempion Warehouse Equipment* is developing our robot system introduced in section 8.4. Many stakeholders, each of which having their own concerns about the system are involved in the development of the system. Example stakeholders are the customers who will use the system, the designers of the system, the marketing in charge of selling the system, etc.

Stakeholders and their development organisation can be captured with the *organisation* notation of ALISA. An *organisation* has a name and can declare stakeholders. A *stakeholder* also has a name (that must be unique within the containing organisation) and optional description, role, email, phone and supervisor stakeholder. An organisation is declared in a separate file with the extension *org*.

#### Running Example Specification

The specification of Tartempion Warehouse Equipment Ltd, which develops the line follower objects carrier robot is shown in Listing 14.

```
organization Tartempion_Warehouse_Equipments_Ltd
stakeholder Customer [
    description " The customer of the line follower robot system "
]
stakeholder Marketing [
    description " The people in charge of marketing the line follower
       robot system "
]
```
Listing 14: Stakeholders and their organizations

#### **Stakeholder Goals**

As stated in section 8.4, the purpose of the robot is to carry objects in the warehouse by following a predefined trajectory. In addition, it must also be able to stop momentarily upon obstacles detection since other robots working in the same warehouse may be crossing the followed line. Furthermore, the time taken to carry objects should be as low as possible as well as the cost of producing the robot.

#### Constructs

Goals and requirements modelling is supported by the *ReqSpec* notation of ALISA. A stakeholder goal must have a name and can have several optional attributes such as a title, a description, a category, a rationale, etc. Providing rationale is of particular importance especially for non-trivial goals as it allows to quickly understand why the goal exists. Furthermore, providing rationale avoids questioning the goal over and over again when new people are introduced to the project.

Another important characteristic for goals is traceability to the system that should achieve them. This can be represented in ReqSpec through the *for* construct, which must refer to an AADL classifier representing the system to be built. AADL classifiers will be introduced in section 8.6.1.

#### Running Example Specification

A specification for the goals of our running example is shown in Listing 15. Goal *G\_Behav\_1* is first defined, which consists of carrying objects from one point to another by following a trajectory marked on the floor. *G\_Behav\_1* has *Customer* as stakeholder and has a *Behaviour* category since it relates to the functions of the system we want to build. Note the rationale on *G\_Behav\_2* that allows understanding why it exists. As will be seen in section 8.6.4, these goals will be transformed into requirements verifiable by the system.

```
stakeholder goals Line_Follower_Robot_Behavior for
   Line_Follower_Functions :: Cary_Object [
    goal G_Behav_1 : " Objects_Transportation " [
        description
                " The robot should be able to carry an object between two
                    specified points by following a predefined trajectory
                    in the warehouse . "
        stakeholder Tartempion_Warehouse_Equipments_Ltd . Customer
        rationale " This fulfills the main need of customers . "
        category Quality . Behavior
    ]
```

```
goal G_Behav_2 : " Obstacle_Avoidance " [
        description " The robot should be able to avoid obstacles along
            the path . "
        stakeholder Tartempion_Warehouse_Equipments_Ltd . Customer
        rationale
                 " There may be several robots working on the warehouses
                    and therefore , it is important to avoid damaging the
                    robots and the carried object "
        category Quality . Behavior
    ]
]
```
#### Listing 15: Behavioural stakeholders goals

Listing 16 shows some performance goals for the system. As opposed to behaviour goals, performance goals can be set with a level of achievement that can be useful when performing design optimisation. Such goals can also be transformed into verifiable requirements that will set bounds on the level of achievement of the goals.

```
stakeholder goals Line_Follower_Robot_Perf for Line_Follower_Robot_Cps ::
   Line_Follower_Robot_Cps [
    goal G_Perf_1 : " Minimal Cost " [
        description " The cost of producing the robot should be minimal . "
        stakeholder Tartempion_Warehouse_Equipments_Ltd . Customer
            Tartempion_Warehouse_Equipments_Ltd . Marketing
        rationale " The robot should be cheap so that it is easy to market
            ."
        category Quality . Cost
    ]
    goal G_Perf_2 : " Minimal_Transportation_Time " [
        description " The time taken to carry objects should be minimal . "
        stakeholder Tartempion_Warehouse_Equipments_Ltd . Customer
            Tartempion_Warehouse_Equipments_Ltd . Customer
        rationale " The robot . "
        category Quality . Performance
    ]
]
```
Listing 16: Quality stakeholders goals

The *for* elements of these goals refer the AADL classifier of the system that is being developed to meet the goal. This is introduced in the following section that presents the modelling of the system, its environment and its contexts of use with AADL.

#### **System, Environment and Contexts of Use**

Modelling not only the system but also its environment and their interactions is of primary importance. From these interactions, a set of monitored and controlled variables can be identified. The purpose of the behavioural requirements then consists of specifying the precise relationship between the monitored and controlled variables for all contexts of use of the system and all possible values of the monitored variables.

It is rarely the case that there is only one context of use of a system. For instance, for our running example, the robot carrying an object following a line can be thought of as the normal context of use of the system. But other contexts may exist such as when the robot is under maintenance. Ideally, all contexts of operation of the system should be identified and modelled but for our robot example, we will only present the normal context.

#### Constructs

The system and its environment can be modelled with AADL using component *types* and their *features*, component *implementations* and their*subcomponents*, component *packages* and component *properties*. Together these constructs form the core of the AADL language.

#### *Component Types and Features (Component Interfaces)*

In AADL, a component type declaration is used to provide an interface specifying how a component can interact with other components, without the need to provide details of the component's internal composition. This is achieved by declaring *features*, which are connecting points for connecting the component to other ones. A feature can be typed by a component type declaration. Such typing is used to restrict the connection to other features. A feature must have a direction that can be in, out or in and out. Feature directions also restrict how components can be connected to each other.

Features can be of several kinds, but for modelling at the system level, we only introduce abstract and feature group kinds of features for now. Other kinds of features specific to hardware and software components will be introduced later as they are needed.

An *abstract feature* is a placeholder to be refined to a concrete feature and is to be used for incomplete component type declarations.

A *feature group* is a special kind of feature used to group component features or other feature groups. It is therefore a modelling facility to ease the connection of components with many features, since the connection of a feature group represents the connections of all contained features. Feature group features are declared in a feature group type used for compatibility verification.

#### *Component Implementations (Internal Component Composition)*

The internal composition of a component in terms of its subcomponents and their inter connections is specified in AADL with *component implementation* declarations. A component implementation must have an associated component type specifying the component's interaction features as explained above. The advantage of separating component type and implementation declarations is that several implementations can reuse the same type, similar to interfaces of the Java programming language.

Component types and implementations are grouped under the name of component *classifiers*. Such classifiers are used for typing subcomponents in a component implementation. Connections can be declared inside component implementations to connect subcomponents between each other (or to the containing component), according to the features declared in the subcomponent's type.

#### *Component Categories*

Components classifiers are divided into 13 categories providing semantics for the domain of embedded systems. These categories are divided into 3 root categories; *composite*, *software* and *execution platform* (hardware).

The composite category is subdivided into two sub-categories:


Each component category has its own rule specifying which categories of subcomponents can be contained in a component implementation. This will be detailed along with the *software* and *execution platform* component categories later as we refine the design of the line follower robot example system.

#### *Component Extension and Refinement*

Similar to object oriented programming languages, AADL component types and implementations (classifiers) can be extended thus inheriting the features / subcomponents and connections of the extended component. New features / subcomponents and connections can be added to the extending classifier to provide more details. In addition, the type of the inherited features and subcomponents can be *refined*, according to a compatibility rule chosen by the modeller among a set of predefined compatibility rules.

#### *Packages (Organisation of Component Declarations)*

Component declarations are contained in *packages*, which can have public and private sections. Package can use declarations from other packages provided that they are imported into the using package.

#### *Properties*

Finally, AADL provides a rich sublanguage for modelling *properties*. A specificity of AADL is that property types are defined at the model level and not in the AADL metamodel. This allows users to define their own properties. The AADL standard however defines a set of predefined properties for most common analyses such as timing, scheduling and resource consumption. This avoids everyone defining its own set of properties and contributes to interoperability of the specifications.

A property must have a type (integer, real, range of integer or real values, enumeration, reference, etc.) and optionally a unit type, which can also be defined by users. A property also has an applicability clause restricting the component category or classifier to which property values can be set.

Properties can be set at various places in an AADL specification (e.g.: on a component classifier, a feature, a subcomponent, a connection, etc.). Because component classifiers can be extended, a complex search algorithm must be decided to determine property values. Such algorithm is illustrated in figure 8.10. For example, to determine the value of a property of a subcomponent, the algorithm first search if a value is set on the subcomponent itself (#1). If not, it then searches for a value on its implementation (#2). If no value is found, the extended implementation if it exists is searched (#3). If no value is found, then the component type of the subcomponent is searched for (#4), followed by its extended component if any (#5). If still no value has been found, a value may be searched on the containing component itself (#6), provided that the property type is declared as "inherit", meaning its value can be inherited by the contained subcomponents. Finally, a property type may be set with a default value, which will then be used if no value has been found by the previous searches.

Fig. 8.10: Property value determination (reproduced from [247])

Properties and units are declared in *property sets*, which similar to component packages can be imported to be used by other declarations.

#### Running Example Specification

The previously introduced core AADL concepts will be understood better by using them to model our system overview, which consists of the system, its environment and its contexts of operation. This will complete the modelling of the system overview step as depicted in the process model of figure 8.9.

We propose a modelling approach for which separate AADL packages stored in different files will be created for the warehouse, the robot physical system, the system functions, the software application and finally the integrated line follower robot CPS. In doing so, AADL component libraries are created independently and become reusable over several projects.

#### *Warehouse*

The AADL package declaration for the warehouse is given in Listing 17. The package declares a public section into which two abstract component types are created for the floor and the warehouse. These components of the environment are modelled with the abstract component category, since at this modelling step, it is not meant to know more about these components other than their interaction points. One could also think of using the system category instead of abstract. However, the abstract category is preferred since the AADL system category has the more precise semantics of embedded systems.

An abstract component implementation is declared for the warehouse (line 16), whose name is prefixed (before the dot) by the associated component type (*Warehouse*). It declares a subcomponent for the floor typed by the previously defined *Floor* component type. Note that no component implementation is provided for the floor since its internal composition is of no interest for this modelling. Only the interaction points, which are provided by component types as features are needed in order to model how the system interacts with its environment.

```
package Warehouse
public
    with Physics ;
    abstract Floor extends Physics :: Reflecting_Object
         features
             applied_force : in feature Physics :: Force ;
             reacted_force : out feature Physics :: Force ;
    end Floor ;
    abstract Warehouse
         features
             light_source : feature Physics :: Light ;
    end Warehouse ;
    abstract implementation Warehouse . basic
         subcomponents
             floor : abstract Floor ;
    end Warehouse . basic ;
```
end Warehouse ;

```
Listing 17: Warehouse AADL package
```
The component type for the warehouse declares a *light\_source* abstract feature (line 13 of Listing 17) representing the light emitted by the warehouse lightening system. The feature is typed by a *Light* abstract component type representing the light physical electromagnetic radiation. This component type is declared in a reusable *Physics* package shown in Listing 18. The Physics package is made available to the Warehouse package by adding a *with* clause for the package (line 3 of Listing 17) and by prefixing the imported types by the name of the package that declares them followed by the *::* delimiter symbol (line 7 of Listing 17).

```
package Physics
public
```

```
abstract Reflecting_Object
    features
        light_in : in feature Light ;
        light_reflected : out feature Light ;
```

```
sound_in : in feature Sound ;
             sound_reflected : out feature Sound ;
    end Reflecting_Object ;
    abstract Light
    end Light ;
    abstract Sound
    end Sound ;
    abstract Force
    end Force ;
    abstract Power
    end Power ;
    abstract Power_Consuming_Object
        features
             power_in : requires bus access Power_Bus ;
        properties
             Classifier_Substitution_Rule = > Type_Extension ;
    end Power_Consuming_Object ;
    bus Power_Bus
    end Power_Bus ;
end Physics ;
```
#### Listing 18: Physics AADL package

Both the line and the floor component types extend a *Reflecting\_Object* component type provided by the Physics package of Listing 18. Since the line follower robot is going to observe the reflected light to follow the trace, the component type provides abstract features for modelling this interaction of the robot with both the floor and the line components. Since a sonar device will also be used by the robot to detect obstacles, features for the reflected sound are also added to the *Reflecting\_Object* abstract component type. A *Sound* abstract component type is declared to model the sound physical vibration and used to type these features. Similarly, the floor component type declares features of the *Force* physics type in order to model its interaction with the robot for propulsion.

#### *Robot CPS*

Now that classifiers have been declared for the environment of the system (warehouse and the floor), component types are required for the line to follow and for the robot CPS itself. A new package is created for this as shown in Listing 19. Note that here the *system* category is intentionally used for the CPS (line 8) and not the *abstract* one, which was used for components of the environment previously modelled. This is because we want to use the semantics of the AADL system category, since our robot is made of software and hardware components.

```
package Line_Follower_Robot_Cps
public
    with Line_Follower_Software , Robots_Library , Warehouse , Physics ,
       Physics_Properties ;
    abstract Line extends Physics :: Reflecting_Object
    end Line ;
    system Line_Follower_Robot_Cps
        features
```

```
light_sensor_in : in feature Physics :: Light ;
        sonar_in : in feature Physics :: Sound ;
         sonar_out : out feature Physics :: Sound ;
         force_left_wheel : out feature Physics :: Force ;
         force_right_wheel : out feature Physics :: Force ;
         force_gripper : out feature Physics :: Force ;
end Line_Follower_Robot_Cps ;
```
Listing 19: Libe follower CPS AADL package

The *Line\_Follower\_Robot\_Cps* system type declares features for its interaction with its environment such as the *light\_sensor\_in*, the *sonar\_in* and *sonar\_out*, the *force\_left\_wheel* and the *force\_right\_wheel* and the *force\_gripper*, which represents the force on the object held by the gripper of the robot. Note that a single bi-directional feature could have been used to represent the pair of *sonar\_in* and *sonar\_out* features. However using separate features allows better distinguishing the monitored and controlled variables of the system.

#### *System Context of Operation*

After having provided component classifiers for the system and for its environment, those can be instantiated as subcomponents of an enclosing component implementation for the Warehouse. This is for modelling the system and its environment. This is shown in Listing 20 where a component type is created for the warehouse of the robot extending the generic warehouse (line 1).

```
abstract Warehouse_Robots extends Warehouse :: Warehouse
    properties
        Physics_Properties :: Illuminance = > 150.0 lx applies to
            light_source ;
end Warehouse_Robots ;
abstract implementation Warehouse_Robots . normal extends Warehouse ::
   Warehouse . basic
    subcomponents
        line : abstract Line ;
        line_follower_robot : system Line_Follower_Robot_Cps ;
        obstacle : abstract Physics :: Reflecting_Object ;
    connections
        floor_robot_light_sensor_in : feature floor . light_reflected ->
            line_follower_robot . light_sensor_in ;
        line_robot_light_sensor_in : feature line . light_reflected ->
            line_follower_robot . light_sensor_in ;
        obstacle_robot_sonar_in : feature obstacle . sound_reflected ->
            line_follower_robot . sonar_in ;
        robot_sonar_out_obstacle : feature line_follower_robot . sonar_out
            -> obstacle . sound_in ;
        force_left_wheel_floor : feature line_follower_robot .
            force_left_wheel -> floor . applied_force ;
        force_right_wheel_floor : feature line_follower_robot .
            force_right_wheel -> floor . applied_force ;
        light_source_line : feature light_source -> line . light_in ;
        light_source_floor : feature light_source -> floor . light_in ;
        Warehouse_Robots_normal_new_connection : feature light_source ->
            obstacle . light_in ;
    properties
        Physics_Properties :: Curvature_Radius = > 99.0 mm applies to line ;
end Warehouse_Robots . normal ;
```
Listing 20: Normal context of operation of the robot CPS

A property value is set to characterise the *illuminance* of the light source in *lx* units (line 3). The property is declared to apply to the *light\_source* feature inherited from the extended *Warehouse* classifier. An abstract component implementation (line 6) is created for modelling the normal context of use of the robot CPS, that is when it is carrying an object. It extends the generic warehouse component containing the floor subcomponent by adding other subcomponents for the line to follow, the robot CPS and an obstacle object.

One problem that is faced with the textual representation of Listing 20 is the difficulty of perceiving how subcomponents interact with each other. One advantage of AADL is that it proposes two notations; a textual and a graphical one. Therefore, users can choose the notation that is most appropriate depending on what is being viewed. Only the textual notation has been used so far, which was appropriate to display component types. However for component implementations containing connected subcomponents, the graphical notation is more appropriate. Therefore, a diagram of the AADL graphical notation is shown in figure 8.11 for the normal operation of the robot CPS. This diagram is obviously much easier to read than the code of Listing 20. However, the diagram does not show all information. For instance, the illuminance property of the warehouse is not visible on the diagram. The diagram is just a view while the textual always contain all information of the model.

Fig. 8.11: The normal context of operation of the robot CPS displayed using the AADL graphical notation

In order to better interpret the diagram, figure 8.12 summarises the AADL graphical notation for component categories. Systems are represented as rounded box while abstract components as dashed rectangles. Abstract features are represented by the symbol ">" with a dot inside and connections as lines with arrows indicating the direction of the represented flow.

The diagram of figure 8.11 can be called a context diagram as it describes the context of operation of the system and clearly distinguishes it from its environment. This distinction is achieved by the different graphical representations of system and abstract components, which further justifies the choice of modelling the system to be built with the system category as opposed to abstract for the other entities of the environment.

The diagram also shows how the robot system contained in the warehouse interacts with its environment, represented by abstract features and connections for sensing the obstacle through the sonar, and the floor and line to follow through the light sensor. The interactions of the wheels with the floor for propulsion are also represented. From this context diagram, the system boundary is precisely identified for the given context as being the set of monitored (in) and controlled (out) features of the robot system that are *connected* to entities of the environment. Also note that for this context of operation, the *force\_gripper* feature is not connected as it is assumed that the carried object is contained by the robot system and is therefore not part of the environment. For a different context for which the robot is picking the object, that object would then be part of the environment as it would not yet have been picked by the robot but would be interacting with the robot's gripper actuator. In this context, the *force\_gripper* feature would then be connected to the object to be carried.

Fig. 8.12: The AADL graphical notation for component categories

When developing a system, it is often challenging to be aware of all the interactions the system may have with its environment. One must not forget interactions that must be taken into account for safe operation of the system in the given context and decide which ones can be neglected. A context diagram can help identifying the neglected interactions by searching for features of the system and components of its environment of the same type that are not connected, thus indicating a neglected interaction. For instance, such is the case of the *light\_reflected* and *light\_sensor\_in* features of the obstacle and the robot CPS, which remain unconnected. Although the obstacle actually does reflect the light from the warehouse, its interaction with the light sensor of the robot is neglected, as the light sensor will be close enough to the line and not be influenced by this light. Such neglecting can also be modelled as a verifiable environmental assumption constraining the environment of the system. Environmental assumptions modelling will be presented in section 8.6.3.

Note that only the line following normal context of operation is presented here. Another context could be modeled for when the robot is under maintenance. This context would be modeled as another abstract component implementation for the same warehouse component type, where only the interacting subcomponents and connections for the context would be instantiated.

#### **8.6.2 Operational Concepts**

The next step in the modelling process of figure 8.9 consists of developing scenarios that describe how the system will be used in the contexts provided by the system overview. Use cases are a good way to do this. Several languages exist for use case modelling. The Use Case Maps sublanguage of the User Requirements Notation [155] and its Eclipse-based tool jUCMNav [1] are well suited for this, since the modeled use cases and scenarios can be simulated for their validation. This turned out to be extremely useful in the modelling of the isolette thermostat example provided by the REMH [184] as several errors were discovered in the natural language use cases. However, presenting use case modelling is beyond the scope of this chapter and the reader can refer to [38, 37] for more information.

#### **8.6.3 Environmental Assumptions**

The introduction of this chapter on AADL pointed out how well known design faults leading to catastrophic errors such as the Ariane 5 bug were due to mismatched assumptions between a system and its environment. Therefore, identifying the environmental assumptions on which a system depends for correct operation is essential for reusing the system in different contexts and avoiding misuse of the system.

Assumptions can specify conditions that must be met by one or several entities of the environment of the system for proper operation. They can also constrain the types, ranges, and units of the monitored and controlled variables of the system.

Let us assume that the robot CPS is using a simple passive light sensor, which measures the light reflected by the line and the floor in its field of view. An obvious environmental assumption is that a minimum quantity of light is emitted by the light source of the warehouse. This is essential for proper operation of the line following robot otherwise it cannot see the line to follow.

Another example assumption, would be to impose a limit on the curvature radius of the line to follow, since there is a limit on the steering capability of the robot given its speed and the carried mass. A limit on the mass of the carried object would also be a reasonable assumption.

#### **Constructs**

Environmental assumptions are modelled using the *ReqSpec* notation as *system requirements*, but however assigned to elements of the environment and not to the system itself. Similar to goals, system requirements can have a *description*, a *rationale*, a *category*, etc. Furthermore, a requirement can also be traced to a goal that it transforms into a verifiable requirement using the keyword *see*.

Requirements must be verifiable by the entities they constrain. In order to achieve this, they can be set with a predicate expression or a verification activity that can be registered in the workbench and referred by the requirement. A predicate expression can for instance compare the value of properties on the architecture model with bounds set for those values and captured in the requirements set.

#### **Running Example Specification**

Listing 21 shows the modelling of environmental assumptions for the robot carrier CPS with the ReqSpec notation. A system requirements specification named *Line\_Follower\_Robot\_Env\_Assumptions* is created and assigned via the *for* keyword to the *Warehouse\_Robot.normal* system implementation representing the normal context of operation of the robot (see figure 8.11). Both assumptions are captured as system requirements but constraining the *light\_source* and the *line* subcomponents of the warehouse as defined by the *for* keyword (lines 3 and 11). Such assumptions are set with the *Kind.Assumption* category to further distinguish them from the system's requirements.

```
system requirements Line_Follower_Robot_Env_Assumptions for
   Line_Follower_Robot_Cps :: Warehouse_Robots . normal [
    requirement EA_1 : " Minimum Warehouse Luminosity " for light_source [
        description " The power of the light source shall not be less than
            the Minimum Illuminance value "
        rationale " Otherwise the light sensor of the robot will not be
           able to give proper readings given its sensitivity and its
           calibration that was performed under these conditions of
           minimum lightening . Study my_study has shown that the value of
            100 lux is a lower bound for warehouses illuminance "
        category Kind . Assumption
        val Minimum_Illuminance = 100.0 lx
        value predicate # Physics_Properties :: Illuminance >=
           Minimum_Illuminance
    ]
    requirement EA_2 : " Minimum Curvature Radius " for line [
        description " The curvature radius of the line to be followed by
           the robot shall not be lower than the specified
           Minimum_Curvature_Radius value "
        rationale " Otherwise the robot given its speed , mass and response
            time will not be able to follow the line . "
        category Kind . Assumption
        val Minimum_Curvature_Radius = 100.0 mm
```

```
value predicate # Physics_Properties :: Curvature_Radius >=
            Minimum_Curvature_Radius
    ]
]
```
Listing 21: Environmental assumptions for the robot CPS

*Value predicates* are set to the assumptions for their automated verification. For example, the predicate of *EA\_1* (line 8) compares the value of the *Illuminance* property of the *light\_source* feature of the warehouse to a minimum value of 100.0 lx declared in the requirement (line 7).

Note that if an entity constrained by the assumption were to be developed by another organisation, then the organisation would provide an extension of the abstract component representing the entity and the assumption would then be converted to an equivalent requirement for the entity.

#### **8.6.4 Functional Architecture**

The next step of the followed development process is to develop the functional architecture. This step assumes that the operational concepts have been developed as mentioned in section 8.6.2 through use case modelling. Developing the functional architecture then consists of providing a first set of system functions identified from the use cases scenarios.

Following the architecture-led ALISA approach, high level requirements are first modeled for the system functions. Then, their corresponding architecture model elements are specified. Finally, the requirements are assigned to these architecture elements. This is an iterative process where design decisions are taken on the decomposition of the architecture of the system into subcomponents and the initial high level requirements are decomposed accordingly.

**System Requirements**

#### Constructs

Like for assumptions, requirements are modelled with the ReqSpec notation. Requirements modelling has already been introduced during the modelling of environmental assumptions. Additional properties needed for this modelling are presented below:


#### Running Example Specification

The high level stakeholder goals of Listing 15 transformed into verifiable requirements are shown as requirements *R\_Behav\_1* and *R\_Behav\_2* of Listing 22. The *see goal* clause of line 6 refers to the stakeholder goals of Listing 15.

```
system requirements Line_Follower_Robot_Behavior for
   Line_Follower_Functions :: Cary_Object . basic [
    requirement R_Behav_1 : " Carry_Object_Function " [
        description
                " The robot shall carry an object between two specified
                    points by following a predefined trajectory in the
                    warehouse . "
```

```
see goal Line_Follower_Robot_Behavior . G_Behav_1
    category Quality . Behavior
]
    requirement R_Behav_1_1 : " Pick_Up_Object_Function " for
        pick_up_object [
        description " At the beginning of the path , the robot shall
            pick up an object on the floor . "
        category Quality . Behavior
        decomposes R_Behav_1
    ]
    requirement R_Behav_1_2 : " Follow_Line_Function " for follow_line
       [
        description " The robot shall follow a line on the floor of
            the warehouse . "
        category Quality . Behavior
        decomposes R_Behav_1
    ]
    requirement R_Behav_1_3 : " Drop_Off_Object_Function " for
        drop_off_object [
        description " At the end of the path , the robot shall drop off
             the carried object on the floor . "
        category Quality . Behavior
        decomposes R_Behav_1
    ]
requirement R_Behav_2 : " Avoid_Obstacles_Function " for
   detect_obstacle [
    description
             "The robot shall avoid colliding with obstacles along the
                 path . "
    see goal Line_Follower_Robot_Behavior . G_Behav_2
    category Quality . Behavior
]
```
Listing 22: High level system requirements

Those two high level requirements are further decomposed into sub-requirements that each must be verified for the high level requirement to be verified. For instance, *R\_Behav\_1* is decomposed into *R\_Behav\_1\_1*, *R\_Behav\_1\_2* and *R\_Behav\_1\_3* (Listing 22), which state that carrying an object between two points is achieved by picking up the object, moving it along a path and dropping it at destination. This is specified by the *decomposes* keyword referring to the decomposed requirement.

#### **Architecture**

]

Following the architecture-lead modelling approach, the system functions must be represented in the system architecture. This is performed again using the *abstract* component category, which was also used for modelling the components of the environment. Since the abstract category has already been introduced for modelling the system in its environment, we can proceed directly to the running example specification below.

#### Running Example Specification

System functions are shown in Listing 23. An abstract component type is first declared for the*Carry\_Object* function, and a following implementation defines subcomponents for the *pick\_up\_object*, *follow\_line*, *drop\_off\_object* and *detect\_obstacles* sub-functions. Abstract component types are declared for each of these sub-functions with their features representing function variables. An abstract component is declared for the type of a robot state variable determining if an obstacle has been detected. The *detect\_obstacles* function will output such variable and pass it to the *follow\_line* function that will stop the robot in case an obstacle is detected. This is declared by the connection of line 15 in Listing 23.

```
package Line_Follower_Functions
public
    with Physics ;
    abstract Cary_Object
    end Cary_Object ;
    abstract implementation Cary_Object . basic
        subcomponents
             pick_up_object : abstract Pick_Up_Object . basic ;
             follow_line : abstract Follow_Line . basic ;
             drop_off_object : abstract Drop_Off_Object . basic ;
             detect_obstacle : abstract Detect_Obstacle ;
        connections
             obstacle_detection_state : feature detect_obstacle . state ->
                follow_line . state ;
    end Cary_Object . basic ;
```
Listing 23: High level architecture system functions

Now that a component type has been provided for the global carry object system function, the stakeholder goals of Listing 15 can be assigned to this component with the *for* clause of the goals package. Note that the component type is used for the assignment instead of the component implementation because of the visibility of requirements and goals in ALISA. Similar to property visibility (see section 8.6.1), a goal assigned to a component type is automatically assigned to all implementations and subcomponents of the type and to the extending classifiers and their subcomponents, and so on.

Similarly, the top level requirements created from the goals are assigned to the*Carry\_Object.basic* component implementation (Listing 22) and each decomposing requirement is assigned to the corresponding subcomponent decomposing the main component.

#### *Decomposing the Follow Line Function*

As an example of further requirements and architecture decomposition, the abstract component of the *follow\_line* function of Listing 23 is detailed in Listing 24. The *Follow\_Line* component type declares an input feature for the light intensity and output features for the left and right wheel power. Such features are typed by the abstract component types of the Physics package (Listing 18). A data access to a robot state internal variable is further added. This variable will be set by the obstacle detection subprogram to stop the robot when an obstacle is detected.

```
abstract Follow_Line
    features
        light_intensity : in feature Physics :: Light ;
        left_motor_power : out feature Physics :: Power ;
        right_motor_power : out feature Physics :: Power ;
        state : feature Robot_State ;
end Follow_Line ;
```
Listing 24: Follow Line architecture system functions

The line following sub function is further decomposed into two sub functions as illustrated by the the *Follow\_Line.basic* component implementation shown in Listing 25, and by its corresponding diagram of figure 8.13. The implementation specifies subcomponents for two functions for computing the turn angle of the robot as a function of the measured light intensity and to compute the wheels motor power from the desired angle.

```
abstract implementation Follow_Line . basic
    subcomponents
        compute_turn_angle : abstract Compute_Turn_Angle . pid ;
        compute_wheels_motors_power : abstract Compute_Wheels_Motors_Power
            . basic ;
    connections
        light_intensity_compute_turn_angle : feature light_intensity ->
            compute_turn_angle . light_intensity ;
        turn_angle_compute_wheels_power : feature compute_turn_angle .
            turn_angle -> compute_wheels_motors_power . turn_angle ;
        compute_wheels_motors_power_left_motor_power : feature
            compute_wheels_motors_power . left_motor_power ->
            left_motor_power ;
        compute_wheels_motors_power_right_motor_power : feature
            compute_wheels_motors_power . right_motor_power ->
            right_motor_power ;
        state_compute_wheels_motors_power : feature state ->
            compute_wheels_motors_power . state ;
end Follow_Line . basic ;
```
Listing 25: Line following architecture system function implementation

Fig. 8.13: The decomposition of the line following function into sub functions

Feature connections connect the subcomponent functions to the features of the enclosing component and the features between each contained subcomponent. The graphical representation of figure 8.13 clearly illustrates the dependency between the two sub functions, which is a practice recommended by the REMH.

On the requirements side, a new requirements set is created for the *Follow\_Line.basic* component implementation as shown in Listing 26. It contains requirements decomposing *R\_Behav\_1\_2* into requirements *R\_Behav\_1\_2\_1*, *R\_Behav\_1\_2\_2* and *R\_Behav\_1\_2\_3*. These requirements require setting the values of the turn angle internal variable and the left and right wheel power controlled variables. These requirements are allocated via their *for* clauses to the *compute\_turn\_angle* and the *compute\_wheels\_motors\_power* subcomponents having the aforementioned variables as output features.

```
system requirements Follower_Line_Behavior for Line_Follower_Functions ::
   Follow_Line . basic [
    requirement R_Behav_1_2_1 : " Set_Turn_Angle_Function " for
       compute_turn_angle [
        description " The controller shall set the value of the turn angle
             variable . "
        category Quality . Behavior
        decomposes Line_Follower_Robot_Behavior . R_Behav_1_2
    ]
```

```
requirement R_Behav_1_2_2 : " Set_Left_Wheel_Power_Function " for
       compute_wheels_motors_power [
        description " The left wheel controller shall set the value of the
             left wheel power variable . "
        category Quality . Behavior
        decomposes Line_Follower_Robot_Behavior . R_Behav_1_2
    ]
    requirement R_Behav_1_2_3 : " Set_Right_Wheel_Power_Function " for
       compute_wheels_motors_power [
        description " The right wheel controller shall set value of the
            right wheel power variable . "
        category Quality . Behavior
        decomposes Line_Follower_Robot_Behavior . R_Behav_1_2
    ]
]
```
Listing 26: Sub-requirements for the sub-functions of the line following system function

#### **8.6.5 Physical Plant Model**

A functional architecture model has been provided with associated requirements created from the original stakeholder goals of the system overview. Such model remains quite abstract and needs to be refined by providing a software model and an execution platform model for execution of the software. These models will allow more accurate analyses and verification since many analyses strongly depend on the plant (hardware) model providing execution resources for the system functions. Therefore, the next step is to provide a detailed model of the robot hardware plant that will be considered to execute the system functions in order to meet the system requirements.

In the following, the modelling of a simple Lego NXT Mindstorm robot is first introduced. A Lego robot is a highly configurable system and the first step is to model a specific configuration suitable for achieving the system goals. The modelling of this configuration will allow briefly introducing how component families can be modelled in AADL, for which more information can be found in [99].

#### **Constructs**

The composite component categories, which consists of the *system* and *abstract* sub-categories have been introduced in section 8.6.1 and were used to model the system overview. Abstract components were also used to model a first set of system functions. The execution platform (hardware) component sub-categories are now presented in order to use them to model the plant. They are decomposed into six sub-categories:


#### **Running Example Specification**

The NXT Lego robot includes plastic blocks that can be assembled to create the robot physical structure. It also includes two motors and wheels assemblies, a light sensor, a sonar sensor and a so-called brick. The brick itself contains several components such as a battery, an ARM7 processor containing a RAM memory, a Bluetooth module, input and output circuits, etc. An informal diagram of the NXT brick obtained from the NXT hardware developer kit [2] is shown in figure 8.14.

Fig. 8.14: An informal diagram of the NXT brick (reproduced from [2])

In order to model these elements in AADL, a *Robots\_Library* package (Listing 27) is first created to contain classifiers for being instantiated to specify the configuration of the Lego NXT robot. A system type (line 5) and a system implementation (line 10) are declared for the robot. At this level of abstraction, only a single subcomponent for the brick is contained in the robot's system implementation (line 12). This is because it can be can assumed that any robot will always contain a brick while the presence of other components will depend on the specific hardware configuration selected for the robot according to its mission.

System classifiers are then declared for the brick subcomponent (lines 15 and 20). For the purpose of this chapter, only a simplified version of the brick will be modeled, which is sufficient for the analyses that will be presented in this chapter. Such version is limited to the modelling of the processor, the power supply, the input and output circuit and buses to connect these subcomponents.

The basic implementation of the generic brick is illustrated in line 20 of Listing 27 and in the diagram of figure 8.15. Power consumption is a concern for robots as it determines their autonomy. Therefore, the electrical power supply is modelled and represented as a device component connected to a power bus also connected to the processor. Note that for this hardware model, bus access and bus access connections are used instead of abstract features such as those of the system overview. Having explicit components for buses allows representing concurrency on communication resources. In addition, logical connections modelled in the software application can be mapped to hardware bus components to estimate resources consumption.

```
package Robots_Library
public
    with OSEK , Physics , Physics_Properties , SEI ;
    system Robot
        properties
             Classifier_Substitution_Rule = > Type_Extension ;
    end Robot ;
    system implementation Robot . basic
        subcomponents
             brick : system Brick . basic ;
    end Robot . basic ;
    system Brick
        properties
             Classifier_Substitution_Rule = > Type_Extension ;
    end Brick ;
    system implementation Brick . basic
        subcomponents
             main_processor : processor Generic_Processor ;
             power_supply : device Generic_Battery ;
             power_bus : bus Physics :: Power_Bus ;
        connections
             power_supply_power_bus : bus access power_supply . power ->
                 power_bus ;
             power_bus_main_processor : bus access power_bus ->
                 main_processor . power_in ;
    end Brick . basic ;
    processor Generic_Processor extends Physics :: Power_Consuming_Object
        features
             data_bus : requires bus access Data_Bus ;
    end Generic_Processor ;
    bus Data_Bus
        properties
             Transmission_Time = > [ Fixed = > 10 ns .. 100 ns ; PerByte = > 10
                  ns .. 40 ns ;];
    end Data_Bus ;
    device Generic_Battery
        features
             power : requires bus access Physics :: Power_Bus ;
    end Generic_Battery ;
```
Listing 27: AADL package for a robot components library

This component for the brick is generic in the sense that it has nothing specific to the NXT version. In order to capture these specificities, an extension of the brick system implementation is provided as illustrated by Listing 28 and the corresponding diagram of figure 8.16. The system type *Nxt\_Brick* extends the previously defined *Brick* system type and adds bus access features (lines 3 to 9) for the brick to be connected to the sensors and actuators of the robot. The corresponding implementation *Nxt\_Brick.basic* (line 12) extends the *Brick.basic* implementation and adds subcomponents specific to the NXT brick for the input and output circuits and a data bus to connect them to the processor. The input and output circuits take data from the processor as input and

Fig. 8.15: A basic system implementation for a brick of a Lego Mindstorm robot

read / send data accordingly to the connected sensors and actuators. Device component types are provided for the input and output circuits (lines 40 and 49), which inherit their *power\_in* bus access feature from the extended *Power\_Consuming\_Object* provided by the Physics package.

```
system Nxt_Brick extends Brick
    features
        in_1 : requires bus access Sensor_Bus ;
        in_2 : requires bus access Sensor_Bus ;
        in_3 : requires bus access Sensor_Bus ;
        in_4 : requires bus access Sensor_Bus ;
        out_1 : requires bus access Actuator_Bus ;
        out_2 : requires bus access Actuator_Bus ;
        out_3 : requires bus access Actuator_Bus ;
end Nxt_Brick ;
system implementation Nxt_Brick . basic extends Brick . basic
    subcomponents
        main_processor : refined to processor Arm_Processor . nxt ;
        input_circuit : device Input_Circuit ;
        output_circuit : device Output_Circuit ;
        data_bus : bus Data_Bus ;
    connections
        brick_input_circuit_1 : bus access in_1 -> input_circuit . in_1 ;
        brick_input_circuit_2 : bus access in_2 -> input_circuit . in_2 ;
        brick_input_circuit_3 : bus access in_3 -> input_circuit . in_3 ;
        brick_input_circuit_4 : bus access in_4 -> input_circuit . in_4 ;
        brick_output_circuit_1 : bus access output_circuit . out_1 -> out_1 ;
        brick_output_circuit_2 : bus access output_circuit . out_2 -> out_2 ;
        brick_output_circuit_3 : bus access output_circuit . out_3 -> out_3 ;
        power_bus_input_circuit : bus access power_bus -> input_circuit .
            power_in ;
        power_bus_output_circuit : bus access power_bus -> output_circuit .
            power_in ;
        main_processor_data_bus : bus access main_processor . data_bus ->
            data_bus ;
        data_bus_input_circuit : bus access data_bus -> input_circuit .
            control ;
        data_bus_output_circuit : bus access data_bus -> output_circuit .
            control ;
    properties
```

```
SEI :: PowerCapacity = > 9.0 W applies to power_supply ; -- 6 AA
            batteries in series at 1 A
        Physics_Properties :: Mass = > 200.0 g ;
        Scheduling_Protocol = > ( RMS ) applies to main_processor ;
        OSEK :: SystemCounter_MaxAllowedValue = > 2000 applies to
            main_processor ;
        OSEK :: SystemCounter_TicksPerBase = > 1 applies to main_processor ;
        OSEK :: SystemCounter_MinCycle = > 1 applies to main_processor ;
end Nxt_Brick . basic ;
device Input_Circuit extends Physics :: Power_Consuming_Object
    features
        in_1 : requires bus access Sensor_Bus ;
        in_2 : requires bus access Sensor_Bus ;
        in_3 : requires bus access Sensor_Bus ;
        in_4 : requires bus access Sensor_Bus ;
        control : requires bus access Data_Bus ;
end Input_Circuit ;
device Output_Circuit extends Physics :: Power_Consuming_Object
    features
        out_1 : requires bus access Actuator_Bus ;
        out_2 : requires bus access Actuator_Bus ;
        out_3 : requires bus access Actuator_Bus ;
        control : requires bus access Data_Bus ;
end Output_Circuit ;
```
Listing 28: NXT brick extension

The generic *main\_processor* subcomponent of the extended generic brick system implementation is *refined to* an *ARM\_Processor.nxt* type as shown in Listing 28 (line 14). The type of this refined subcomponent is an extension of the generic processor component type as shown in Listing 29 below (line 1). It contains a property association setting the MIPS capacity of the processor (line 3). The processor implementation provides a RAM memory subcomponent (line 8) with a memory capacity property value of 64 KByte (line 10) as given by the Lego hardware specification of the NXT brick.

```
processor Arm_Processor extends Generic_Processor
    properties
         SEI :: MIPSCapacity = > 43.2 MIPS ;
end Arm_Processor ;
processor implementation Arm_Processor . nxt
    subcomponents
         ram : memory RAM_Memory ;
    properties
         SEI :: RAMCapacity = > 64.0 KByte applies to ram ;
end Arm_Processor . nxt ;
memory RAM_Memory
    features
         data_bus : requires bus access Data_Bus ;
end RAM_Memory ;
                    Listing 29: ARM processor for the NXT brick extension
```
Such combination of classifier extensions and subcomponent and feature refinements is extremely useful in modelling component families as further explained in [99]. In this modelling, two different ways are used to provide the NXT-specific information. One of them is to add property associations within the extending

Fig. 8.16: The internal composition of a NXT Lego Mindstrom brick

component implementation of the brick with values pertaining to this specific model, as shown for the power capacity value set for the power supply subcomponent (line 32 of Listing 28).

The second way is to refine the classifier of a subcomponent as is done for the ARM processor extending the generic processor. Having this new classifier then allows providing more details such as the internal composition of the processor, which includes a RAM memory subcomponent. MIPS and RAM capacity property values can be declared in theses processor extensions (lines 3 and 10 of Listing 29). Deciding on which mechanism should be used depends on the modelling context. For example, the advantage of creating such extension classifiers for the processor is that they allow encapsulating the NXT specific information and makes it easy to reuse in other specifications.

Now that component classifiers are provided for the brick, other classifiers must be declared for the sensors and actuators of the robot. Those are presented in Listing 30 where classifiers of the *device* category are declared for the light sensor, the sonar, the wheel assemblies and the gripper, which is used to lift the carried object. Note that such gripper does not actually exist for the Mindstorm kit but is added for illustration purposes only. The component types for the sensors and actuators declare interaction features whose types for the corresponding physical resources are provided by the *Physics* package of Listing 18. They also declare bus access features typed with classifiers for the sensor and actuator buses. Those will represent the standard RJ12 connectors provided with the NXT kit. Note that no component implementation is provided for sensors and actuators since their internal composition is irrelevant for this modelling.

```
device Light_Sensor extends Physics :: Power_Consuming_Object
    features
        light_in : in feature Physics :: Light ;
        light_data : requires bus access Sensor_Bus ;
    properties
        Physics_Properties :: Mass = > 20.0 g ;
end Light_Sensor ;
device Sonar extends Physics :: Power_Consuming_Object
    features
        sound_in : in feature Physics :: Sound ;
        sound_out : out feature Physics :: Sound ;
        sound_data : requires bus access Sensor_Bus ;
    properties
        Physics_Properties :: Mass = > 20.0 g ;
```

```
end Sonar ;
device Wheel_Assembly extends Physics :: Power_Consuming_Object
    features
        power_in : refined to requires bus access Actuator_Bus ;
        force : out feature Physics :: Force ;
    properties
        Physics_Properties :: Mass = > 100.0 g ;
end Wheel_Assembly ;
device Gripper extends Physics :: Power_Consuming_Object
    features
        power_in : refined to requires bus access Actuator_Bus ;
        force : out feature Physics :: Force ;
    properties
        Physics_Properties :: Mass = > 20.0 g ;
end Gripper ;
```
Listing 30: Classifiers for robot sensors and actuators

Now that classifiers have been declared for all the components of the NXT Mindstorm robot kit, they can be instantiated and assembled into a robot plant system configured for object transportation in the warehouse. This is illustrated by Listing 31 and its corresponding diagram of figure 8.17. New *Line\_Follower\_Robot* classifiers are provided extending the partially-configured basic robot classifiers previously defined, which only contains a brick subcomponent (Listing 27 line 10). The extending *Line\_Follower\_Robot* system type adds features specific to the line following configuration for using the wheel assemblies, the gripper and the light and sonar sensors (line 2).

```
system Line_Follower_Robot extends Robots_Library :: Robot
    features
        light_sensor_in : in feature Physics :: Light ;
        sonar_in : in feature Physics :: Sound ;
        sonar_out : out feature Physics :: Sound ;
        force_left_wheel : out feature Physics :: Force ;
        force_right_wheel : out feature Physics :: Force ;
        force_gripper : out feature Physics :: Force ;
end Line_Follower_Robot ;
system implementation Line_Follower_Robot . nxt extends Robots_Library ::
   Robot . basic
    subcomponents
        left_wheel_assembly : device Robots_Library :: Wheel_Assembly ;
        left_wheel_cable : bus Robots_Library :: Actuator_Bus ;
        righ_wheel_assembly : device Robots_Library :: Wheel_Assembly ;
        rght_wheel_cable : bus Robots_Library :: Actuator_Bus ;
        light_sensor : device Robots_Library :: Light_Sensor ;
        light_sensor_cable : bus Robots_Library :: Sensor_Bus ;
        sonar : device Robots_Library :: Sonar ;
        sonar_cable : bus Robots_Library :: Sensor_Bus ;
        gripper : device Robots_Library :: Gripper ;
        gripper_cable : bus Robots_Library :: Actuator_Bus ;
        brick : refined to system Robots_Library :: NXT_Brick . basic ;
    connections
        brick_left_wheel_cable : bus access brick . out_1 ->
            left_wheel_cable ;
        left_wheel_cable_left_wheel_assembly : bus access left_wheel_cable
             -> left_wheel_assembly . power_in ;
```
The configured robot system implementation (line 11) instantiates sensor and actuator subcomponents including buses for the RJ12 connectors. The generic brick subcomponent (line 23) of the extended generic robot is refined to the NXT brick of Listing 28 (line 12) and figure 8.16.

Fig. 8.17: The plant model for the Lego NXT line follower robot

This constitutes the physical plant model of our robot carrier system. Such hardware plant will be used to deploy a software application (the cyber part of the robot CPS) to control the speed of the wheels according to the data sensed by the light and sonar sensors.

#### **8.6.6 Deployment**

This section considers concrete implementations in software of the system functions introduced in section 8.6.4 and the deployment of the software onto the plant model introduced in section 8.6.5: the NXT Mindstorm Lego robot configured for carrying objects in the warehouse. In order to deploy the system, the system functions first need to be refined into a software application executable by the NXT brick of the plant model.

#### **Software Application**

#### Constructs

Software applications can be modelled in AADL using the six software component sub-categories introduced below:


The AADL standard includes several annexes supporting software modelling:


The refined software model presented in this section will provide subprogram classifiers extending the system function abstract classifiers. Thread classifiers will be provided for specifying scheduling properties for these software subprograms. Software-specific properties for supporting timing and scheduling analyses and code generation will be set to these components.

The execution semantics of a thread is specified using predefined properties, which are found under the standard *Thread\_Properties* property set. Those properties are:

	- *Periodic*: the thread is activated periodically
	- *Aperiodic*: the thread is activated upon receiving messages
	- *Sporadic*: the thread is activated upon receiving messages with a minimum delay between two activations
	- *Timed*: the thread is activated *either* upon receiving a message or a given deadline (the timer is reset upon message reception)
	- *Hybrid*: the thread is activated *both* upon receiving a message and a given deadline

Threads can communicate with each other using three predefined communication mechanisms represented by their port and connection types:


Port connections can have different timing semantics:


The standard *Programming\_Prperties* property set defines properties for code generation:


#### Running Example Specification

A package is created to contain declarations for the software classifiers as shown in Listing 32. Concrete data types are declared for the software variables, which are derived from the system function variables by extending them and adding a *SW* suffix to their names. To these classifiers, properties specifying their concrete representation in code are set using the *Data\_Representation* property of the data model annex (line 7). The *Robot\_State\_SW* software variable is also refined by providing properties for an equivalent data structure *Robot\_state* declared in a C code file *data\_types.h* and to be used for code generation (lines 24 and 25).

```
package Line_Follower_Software
public
    with Line_Follower_Functions , Code_Generation_Properties , Base_Types ,
        Data_Model ;
    data Light_Intensity_SW extends Physics :: Light
        properties
```

```
Data_Model :: Data_Representation = > integer ;
         Data_Size = > 4 bytes ;
end Light_Intensity_SW ;
data Turn_Angle_SW extends Line_Follower_Functions :: Turn_Angle
    properties
         Data_Model :: Data_Representation = > integer ;
end Turn_Angle_SW ;
data Power_SW extends Line_Follower_Functions :: Power
    properties
         Data_Model :: Data_Representation = > integer ;
end Power_SW ;
data Robot_State_SW extends Line_Follower_Functions :: Robot_State
    properties
         Data_Model :: Data_Representation = > Enum ;
         Data_Model :: Enumerators = > ( " FORWARD " , " STOP " ) ;
         Source_Name = > " Robot_state " ;
         Source_Text = > ( " data_types . h " ) ;
end Robot_State_SW ;
```
Listing 32: Data classifiers for the software application

Concrete software subprogram implementations for the *compute turn angle* and the *compute wheels motor power* functions are declared as shown in Listing 33. Like for the data types, those subprograms extend the system function abstract components and refine the abstract features to subprogram parameters typed with appropriate SW data types previously introduced.

```
subprogram Compute_Turn_Angle_SW extends Line_Follower_Functions ::
   Compute_Turn_Angle
    features
        light_intensity : refined to in parameter Light_Intensity_SW ;
        turn_angle : refined to out parameter Turn_Angle_SW ;
    properties
        Classifier_Substitution_Rule = > Type_Extension ;
        Source_Language = > ( C ) ;
end Compute_Turn_Angle_SW ;
subprogram implementation Compute_Turn_Angle_SW . pid extends
   Line_Follower_Functions :: Compute_Turn_Angle . pid
    properties
        Source_Name = > " computePID " ;
        Source_Text = > ( " line_follower . h " , " line_follower . c " ) ;
end Compute_Turn_Angle_SW . pid ;
subprogram Compute_Wheels_Motors_Power_SW extends Line_Follower_Functions
   :: Compute_Wheels_Motors_Power
    features
        turn_angle : refined to in parameter Turn_Angle_SW ;
        left_motor_power : refined to out parameter Power_SW ;
        right_motor_power : refined to out parameter Power_SW ;
        state : refined to requires data access Robot_State_SW ;
    properties
        Classifier_Substitution_Rule = > Type_Extension ;
        Source_Language = > ( C ) ;
end Compute_Wheels_Motors_Power_SW ;
```

```
subprogram implementation Compute_Wheels_Motors_Power_SW . basic extends
   Line_Follower_Functions :: Compute_Wheels_Motors_Power . basic
    properties
         Source_Name = > " computeWheelsPower " ;
         Source_Text = > ( " line_follower . h " , " line_follower . c " ) ;
end Compute_Wheels_Motors_Power_SW . basic ;
```
Listing 33: Subprogram classifiers for the compute turn angle and the compute wheels motor power software functions

The implementation of the *compute\_turn\_angle* subprogram makes use of a PID control mechanism, which computes a turn angle that is proportional to the observed light intensity as illustrated on the RHS of figure 8.8. The C code for such subprogram can actually be derived from control simulations with tools such as Matlab Simulink. This code can then be associated with an AADL subprogram classifier via the *Source\_Language*, *Source\_Text* and *Source\_Name* properties as shown in Listing 33 (lines 7, 12 and 13). Note that the *Source\_Language* property is set on the subprogram types (lines 7 and 24) while the other source code properties are set on the subprogram implementations. This ease design space exploration by capturing the variability of different subprogram code implementations of a given programming language.

In order to read the value from the light sensor and to actuate the wheel motors, subprograms provided by the NXT OSEK ECRobot C library [219] are used. A new subprogram implementation is created to encapsulate calls to the *get\_light\_intensity*, *follow\_line*, *set\_left\_motor\_power* and *set\_right\_motor\_power* subprograms as shown in Listing 34 and in figure 8.18. Implementation details are added consisting of data subcomponents for setting the value of required input parameters for the ECRobot subprograms such as the port number and a braking coefficient and initial values on data subcomponents (lines 8 to 19) for the corresponding data structures in code.

```
subprogram Follow_Line_SW_NXT
    features
        state : requires data access Robot_State_SW ;
end Follow_Line_SW_NXT ;
subprogram implementation Follow_Line_SW_NXT . basic
    subcomponents
        left_wheel_port : data Base_Types :: Integer {
             Data_Model :: Initial_Value = > ( " NXT_PORT_B " ) ;
        };
        left_wheel_brake : data Base_Types :: Integer {
             Data_Model :: Initial_Value = > ( " 0 " ) ;
        };
        right_wheel_port : data Base_Types :: Integer {
             Data_Model :: Initial_Value = > ( " NXT_PORT_A " ) ;
        };
        right_wheel_brake : data Base_Types :: Integer {
             Data_Model :: Initial_Value = > ( " 0 " ) ;
        };
    calls
        main_call : {
             get_light_intensity : subprogram ECRobot_Get_Light_Intensity ;
             follow_line : subprogram Follow_Line_SW . basic ;
             set_left_motor_power : subprogram NXT_Motor_Set_Power ;
             set_right_motor_power : subprogram NXT_Motor_Set_Power ;
        };
    connections
        light_intensity_follow_line : parameter get_light_intensity .
            light_intensity -> follow_line . light_intensity ;
```
Listing 34: Subprogram classifiers for the follow line software function

Fig. 8.18: The NXT line following subprogram

Software subprograms extending the *Pick\_Up\_Object* and *Drop\_Off\_Object* system function components must also be declared. Those are not presented here but can be found in the complete set of models from [63].

The next step is to specify how the subprograms of the software application will be executed. The *Pick\_Up\_Object\_SW.basic* subprogram should be executed once the robot has reached the start of the path. The *Follow\_Line\_SW\_NXT.basic* subprogram should be executed once the object has been picked up and periodically at a frequency high enough to follow the line, given a required tolerance, the minimum line curvature radius and the robot speed. The *Drop\_Off\_Object\_SW.basic* subprogram should be executed once the end of the path is reached. The *Detect\_Obstacles\_SW* subprogram should be executed periodically while the line is being followed at a frequency high enough to detect obstacle on time in order to avoid collisions. Finally, the *Logging\_SW* subprogram should be always executed periodically, with a period given by logging requirements.

The modelling of these threads is shown in Listing 35. The *Pick\_Up\_Object\_Thread* thread is set with an *at\_beginning\_path* input event port for its activation when the robot reaches the beginning of the path and an *object\_picked* output event port for notification when the object has been picked by the gripper. An *aperiodic* dispatch protocol is set meaning that the thread will be dispatched upon events on its input event port.

```
thread Pick_Up_Object_Thread
    features
        at_beginning_path : in event port ;
        object_picked : out event port ;
    properties
        Dispatch_Protocol => aperiodic ;
```

```
Deadline = > 5 ms ;
        Priority = > 2;
        Stack_Size = > 512 Bytes ;
end Pick_Up_Object_Thread ;
thread Follow_Line_Thread
    features
        state : requires data access Robot_State_SW ;
        object_picked : in event port ;
        object_dropped : in event port ;
        at_beginning_path : out event port ;
        at_end_path : out event port ;
        right_wheel : out data port Power_SW ;
        left_wheel : out data port Power_SW ;
    flows
        light_to_left : flow path light_intensity -> left_wheel ;
        light_to_right : flow path light_intensity -> right_wheel ;
    properties
        Dispatch_Protocol = > periodic ;
        Period = > 15 ms ;
        Deadline = > 15 ms ;
        Priority = > 3;
        Stack_Size = > 512 Bytes ;
end Follow_Line_Thread ;
thread implementation Follow_Line_Thread . basic
    calls
        main_call : {
              follow_line : subprogram Follow_Line_SW_NXT . basic ;
        };
    connections
        state_follow_line : data access state -> follow_line . state ;
    properties
        Compute_Entrypoint_Call_Sequence = > reference ( main_call ) ;
        Latency => 3 ms .. 5 ms applies to light_to_left , light_to_right ;
end Follow_Line_Thread . basic ;
thread Detect_Obstacles_Thread
    features
        state : requires data access Robot_State_SW ;
    properties
        Dispatch_Protocol = > periodic ;
        Period = > 10 ms ;
        Deadline = > 5 ms ;
        Priority = > 2;
        Stack_Size = > 512 Bytes ;
end Detect_Obstacles_Thread ;
thread Log_Thread
    properties
        Dispatch_Protocol = > periodic ;
        Period = > 20 ms ;
        Deadline = > 5 ms ;
        Priority = > 5;
        Stack_Size = > 512 Bytes ;
```
#### end Log\_Thread ;

Listing 35: Thread classifiers for the tasks of the software application

The *Follow\_Line\_Thread* thread is set with an *object\_picked* input event port for its activation when the object has been picked by the gripper and an *object\_arrived* output event port for its deactivation and a periodic dispatch protocol. The determination of the period of this thread will be detailed in the analysis section 8.6.7. A thread implementation is provided specifying a call to the follow line subprogram (line 21) and a data access connection for the robot state variable, which will be valued by the obstacle detection subprogram. Finally, the *Compute\_Entrypoint\_Call\_Sequence* property (line 35) specifies which call sequence (there could be many) should be executed upon dispatch of the thread.

A *Drop\_Off\_Object\_Thread* thread classifier (not shown in the listing due to space constraints) is provided for executing the *Drop\_Off\_Object\_SW* subprogram with features and properties similar to the ones of the *Pick\_Up\_Object\_Thread* thread. Another thread classifier is provided for the obstacle detection subprogram with a data access feature for the robot state and a periodic dispatch protocol. Finally, the logging function is encapsulated within a periodic thread. More details on other properties of these threads can be found in the analysis section 8.6.7.

Now that these thread classifiers have been declared, they can be instantiated as subcomponents of a *process* implementation, which represents a memory address space for the global software application. This is shown in Listing 36 and figure 8.19, where a data subcomponent is declared for the robot state data with a *FORWARD* initial value. Proper port connections are declared between the subcomponents.

```
process Carry_Object_Process
    features
        light_intensity : in data port Light_Intensity_SW ;
        left_wheel_power : out data port Power_SW ;
        right_wheel_power : out data port Power_SW ;
    flows
        light_to_left : flow path light_intensity -> left_wheel_power ;
        light_to_right : flow path light_intensity -> right_wheel_power ;
end Carry_Object_Process ;
process implementation Carry_Object_Process . basic
    subcomponents
        state : data Robot_State_SW {
             Data_Model :: Initial_Value = > ( " FORWARD " ) ;
        };
        pick_up_object : thread Pick_Up_Object_Thread ;
        follow_line : thread Follow_Line_Thread . basic ;
        drop_off_object : thread Drop_Off_Object_Thread ;
        detect_obstacle : thread Detect_Obstacles_Thread ;
        logging : thread Log_Thread ;
    connections
        pick_up_object_folow_line : port pick_up_object . object_picked ->
            follow_line . object_picked ;
        follow_line_drop_object : port follow_line . at_end_path ->
            drop_off_object . object_arrived ;
        drop_object_follow_line : port drop_off_object . object_dropped ->
            follow_line . object_dropped ;
        obstacle_detection_state : data access detect_obstacle . state ->
            state ;
        state_follow_line : data access state -> follow_line . state ;
        follow_line_begin_path_pick_up_object : port follow_line .
            at_beginning_path -> pick_up_object . at_beginning_path ;
        light_intensity_follow_line : port light_intensity -> follow_line .
            light_intensity ;
```

```
follow_line_right_wheel : port follow_line . right_wheel ->
            right_wheel_power ;
        follow_line_left_wheel : port follow_line . left_wheel ->
            left_wheel_power ;
    properties
        Timing = > Immediate applies to follow_line_right_wheel ,
            follow_line_left_wheel ;
end Carry_Object_Process . basic ;
```
Listing 36: Process classifiers for the software application

Fig. 8.19: The carry object software process implementation

This constitutes a complete software application that can be deployed on the brick of the NXT robot plant model. However, as will be presented in the analysis section, we are interested in determining the latency of steering the robot upon a change in the value of the observed path light intensity. For this purpose, we extend the software model by modeling the drivers of the input and output circuits of the brick driving the light sensor and the two motor assemblies.

In order to achieve this, we first create a system component for the software application as illustrated in figure 8.20. To this system we add a subcomponent of the software application process previously defined and device subcomponents with data ports typed with the software power and light intensity variable types. Such data ports are connected to the software process containing the threads. As explained in section 8.6.5, devices can be used for both hardware and software parts of systems. For software, they represent the software part of corresponding hardware devices, such as drivers residing in a memory and executed on an external processor. Such is the case for the input and output circuit devices of the robot brick (figure 8.16), which include built-in drivers to control sensors and actuators.

#### **Binding of the Software Application on the Execution Platform**

The last step in modeling the robot CPS is to deploy the software application on the plat model. This is presented in the following.

#### Concepts

In order to specify the binding of the software application on the plant model, first a system implementation must be provided for the *Line\_Follower\_Robot\_CPS*, for the system type of the system overview of Listing 19. This implementation should have as subcomponent the software application previously defined and the robot plant model.

Fig. 8.20: A system component for the software application including devices for modeling drivers of sensors and actuators

The binding of the thread and data subcomponents of the process on the execution platform components can then be specified. Properties from the standard *Deployment\_Properties* property set are used for that:


#### Running Example Specification

The system implementation for the line follower CPS component type is shown in Listing 37 and figure 8.21. A system subcomponent for the NXT software application and a system subcomponent for the configured NXT line following robot plant model are instantiated. The features of the robot plant model are connected to the features of the CPS system type of the system overview (Listing 19).

```
system implementation Line_Follower_Robot_Cps . nxt
    subcomponents
        app : system Line_Follower_Software :: Carry_Object_App . basic ;
        robot : system Line_Follower_Robot . nxt ;
    connections
        force_left_wheel_conn : feature robot . force_left_wheel ->
            force_left_wheel ;
        force_right_wheel_conn : feature robot . force_right_wheel ->
            force_right_wheel ;
        light_sensor_conn : feature light_sensor_in -> robot .
            light_sensor_in ;
        force_gripper_conn : feature robot . force_gripper -> force_gripper ;
        sonar_in_conn : feature sonar_in -> robot . sonar_in ;
        sonar_out_conn : feature robot . sonar_out -> sonar_out ;
    properties
        Actual_Processor_Binding = > ( reference ( robot . brick .
            main_processor ) ) applies to app . carry_object_process ;
        Actual_Memory_Binding = > ( reference ( robot . brick . main_processor .
            ram ) ) applies to app . carry_object_process ;
        Actual_Processor_Binding = > ( reference ( robot . brick . input_circuit
            )) applies to app . light_sensor_driver ;
        Actual_Connection_Binding => ( reference ( robot . brick . data_bus ) )
            applies to app . light_sensor_process_conn ;
        Actual_Processor_Binding = > ( reference ( robot . brick .
            output_circuit ) ) applies to app . left_wheel_driver ;
```

```
Actual_Connection_Binding => ( reference ( robot . brick . data_bus ) )
            applies to app . process_left_wheel_conn ;
         Actual_Processor_Binding = > ( reference ( robot . brick .
            output_circuit ) ) applies to app . right_wheel_driver ;
         Actual_Connection_Binding => ( reference ( robot . brick . data_bus ) )
            applies to app . process_right_wheel_conn ;
end Line_Follower_Robot_Cps . nxt ;
```
Listing 37: System implementation for the Robot CPS

Fig. 8.21: The deployed line follower robot CPS

The binding properties *Actual\_Processor\_Binding* and *Actual\_Memory\_Binding* are set to respectively the ARM7 processor and its contained memory as shown in Listing 37 under the properties section (lines 13 and 14). This is also illustrated in figure 8.21 with the dashed arrows pointing from the process subcomponent to the NXT brick ARM processor and its included RAM memory. Since there is only one processor and one memory, it was chosen to apply the binding properties to the enclosing process, which means that all contained threads and data subcomponents are bound to the same processor and memory. If several processors were available, a binding property could have been be set for each individual thread for specifying their execution by different processors.

The device drivers for the light sensor and the wheel motors are also bound to the input and output circuits on the NXT brick. The port connections between the devices and the process are bound to the data bus connecting the input and output circuits to the ARM processor.

#### **8.6.7 Analyses**

The modelling of the object carrier robot CPS has been completed. The next step is to verify some of its properties to ensure that the system will operate properly and will meet its requirements. Furthermore, it would be interesting to estimate its performances. A first question to ask is if the ARM 7 processor can schedule all the threads given their timing properties. This strongly depends on the computation time of the subprograms themselves. Several methods exist to answer this question. For the case of the NXT brick, assume that the times are given by executing the programs alone on the brick and by logging the times to the display of the robot so that they can be memorized.

#### **Scheduling**

Scheduling analysis can be performed from the software application of section 8.6.6 and using tools such as Cheddar or its commercial implementation in AADL Inspector. This analysis will rely on the following properties attached to software components:

In Listing 35, property values are given to AADL threads in order to define their dispatch protocol, period, priority, and their sequence of subprogram calls. From the call sequence of a thread, we can compute an upper bound on the thread execution time by summing the upper bound of the called subprograms execution time. The latter is given for subprogram *Follow\_Line\_SW\_NXT* in listing 34 using the *Compute\_Execution\_Time* property. Last but not least, the scheduling protocol is attached to the AADL processor component on which threads are going to run. This is done in Listing 28 using the *Scheduling\_Protocol* property (line 34). Here, the scheduling protocol is a well known protocol named Rate Monotonic Scheduling (RMS). RMS is a fixed priority scheduling technique (tasks are executed according to a predefined priority) and tasks priorities are ordered as follows: the most frequent tasks are given a higher priority.

#### Semantics

The AADL modeling elements listed above define a periodic task set model (where an AADL thread is a periodic task) which can be summarized on figure 8.22.

Fig. 8.22: Periodic task set

On this figure, a task <sup>τ</sup><sup>i</sup> is characterized by its period *T*<sup>i</sup> , its deadline *D*<sup>i</sup> , its capacity *C*<sup>i</sup> . The capacity of a task corresponds to the upper bound on its execution time, and we explained above how this can be extracted from the execution time of AADL subprograms called in sequence by an AADL thread. In practice, we measure the execution time of subrpograms running on the NXT brick to estimate tasks capacity.

From this task model, the CPU utilization of *<sup>U</sup>*<sup>i</sup> of a task <sup>τ</sup><sup>i</sup> can be computed as follows: *<sup>U</sup>*<sup>i</sup> <sup>=</sup> C<sup>i</sup> Ti and the CPU utilization of the task is simply the sum of every task utilization.

Given a periodic task set model, schedulability analysis can be performed to ensure all the tasks of the object carrier robot can finish their execution within their deadlines. A first option to perform this analysis is to compare the worst-case processor utilization with a safe upper bound: it has been proven by Liu and Layland in 1973 that a necessary condition for the schedulability of a task set scheduled with RMS, on a mono-core processor, is that the CPU utilisation of the task set remains under 69.3147%. Another option, for task sets scheduled with a fixed priority scheduling, is to compute tasks Worst Case Response Time (WCRT) and check that they remain inferior to the tasks deadline. The WCRT of a task <sup>τ</sup><sup>i</sup> , on a mono-core processor, can be computed using the following recursive formula:

$$WCRT\_i = \sum\_{\tau\_j \in HP\_i} \lceil \frac{WCRT\_i}{T\_j} \rceil \cdot C\_f$$

where *HP*<sup>i</sup> is the set of tasks having a higher priority than <sup>τ</sup><sup>i</sup> .

#### Analysis results

Figures 8.23 and 8.24 show the different results provided by AADL Inspector after performing the scheduling analysis of an AADL model.

Fig. 8.23: Tasks execution gantt chart


Fig. 8.24: Response time analysis result

This analysis can help us configure the task set either by modifying the period of AADL threads, reducing the number of tasks executed on the platform, or changing the execution platform itself. In the case of the object carrier robot, given the number of tasks, their execution time, and the physics of the system, the scheduling analysis helped to define tasks period.

#### **Latency**

Another question to ask about our object carrying robot is whether it will be able to follow the line given a minimum speed requirement. For this, the latency of the system in steering the robot must be known. In particular, we are interested in the latency of the data flows involved in the control loop, i.e. the amount of time separating the production of a data from the light sensor, to the production of commands on the engine. AADL is well suited for such analysis using its *flow* constructs.

#### Constructs

AADL flows are used to annotate AADL elements in order to specify paths of information flow across components. As such, flows do not represent any concrete system architecture elements but facilitate analyses and allow characterizing information flows with additional properties. By defining connections among directed ports, possible data flows are already defined by the structure of an AADL model. However, they are **possible** data flows and potentially some of them are not present in the software application. Besides, only a subset of data flows require latency analysis.

In AADL, a flow consists of:


Component types can only contain flow specifications (sources, sinks and paths) annotating the declared features.

Component implementations can only contain flow implementations (sources, sinks and paths) annotating features, connections and subcomponent flows. They can also contain end to end flows beginning by a flow source and ending by a flow sink.

Latency upper bounds can either be attached to end-to-end flows or set in ReqSpec requirements assigned to end-to-end flows. Latency contributions are attached to model elements implementing these flows. In practice, the latency of an end-to-end flow is the sum of latencies contributed by components and connections traversed by the flow.

Figure 8.25 represents the architecture of the robot carrier application along with devices representing the light sensor and the right and left motors. They are represented with an AADL device, representing the logical execution of the device driver. In addition, the end-to-end flow from the light sensor output (flow source) to the left motor input (flow sink) passing by the software application (flow path in *carry\_object\_process*) is coloured in yellow.

Fig. 8.25: Light sensor to left motor end-to-end flow

There exists three types of contributions to a flow latency in AADL:


We explain further how to use these modeling capabilities in the remainder of the following paragraph, illustrating these types.

#### Running Example Specification

**Contribution type 1:** Latency property value attached to a flow path. In the early phase of the development process, or in order to decompose the end-to-end latency requirement into latency requirements attached to subcomponents, AADL users can attach flow latency values to flow path as illustrated in Listing 35 (property *Latency* defined in *Follow\_Line\_Thread.basic*). Note that without this property, the deadline of the thread would be used as an upper bound (and 0 as a lower bound).

**Contribution type 2:** Physical communications contribution. When a flow passes by a logical connection (i.e. connection between software components) bound to a bus component, the communication itself takes time. AADL offers the possibility to model this contribution as a linear function of the number of transmitted bytes. Property *Transmission\_Time* is meant for this usage, which is illustrated in Listing 38. In this listing we can see that the *Transmission\_Time* property consists of two fields: *Fixed* and *PerByte* which respectively represent a communication offset and a communication time per byte. Each of these fields is a time range, representing the lower and upper bound of the communication offset and time per byte. Note that when this property is used, it is necessary to define the size of the transmitted data. This is feasible with the *Data\_Size* property, as illustrated in Listing 32 for the *Light\_Intensity\_SW* data type.

```
bus Data_Bus
    properties
        Transmission_Time => [ Fixed => 10 ns .. 100 ns ; PerByte = > 10 ns
            .. 40 ns ;];
end Data_Bus ;
```
Listing 38: Data bus component transmission time

Note that the example we took is rather simple: AADL architectures may be much more complex, for instance by binding logical connections to virtual busses (representing communication routes) themselves bound to busses and devices representing a network.

**Contribution type 3:** Local communications contribution. This type of contribution is probably the less intuitive and though the main contribution to flow latency from a software architecture viewpoint. To explain how local communications contribute to flow latency, it is necessary to understand further the model of computation and communications entailed by AADL software components, in particular communications among threads and/or devices.

We decompose this explanation in two parts, answering the following questions:


By default, the answers to these questions are:


Listing 36 represents the configuration of connections between process *carry\_object\_process* and device *light\_sensor\_driver* on the one hand, and between process *carry\_object\_process* and *left\_wheel\_driver* and *right\_wheel\_driver*.

For the latter, the value *Immediate* is assigned for the *Timing* property, which means the recipient can only start its execution when new outputs are produced by the process. As a consequence, the activation of the device always receive the latest data produced by the process.

Overall, the end-to-end latency time can be computed in OSATE: with the configuration described in this book, the result obtained is in a range of 3 to 30 milliseconds.

**Other Analyses** The two analyses presented in the previous sections are very common and essential for embedded systems design. However several other analyses can be conducted from an AADL model such as memory usage, power consumption [17], mass, costs, etc. On the behavior side, verification and validation can also be performed via tools such as the BLESS proof checker [179] and model checking [42, 223]. More information on analysis tools for AADL can be found at [6].

#### **8.6.8 Code Generation**

The ultimate activity to be performed from an AADL specification is automatic code generation. Once the analyses have shown a correct design, a large part of the code can be generated automatically, thus reducing the risk of errors introduced by humans. There are currently two main code generators for AADL: the Ocarina tool [222] and RAMSES (Refinement of AADL Models for the Synthesis of Embedded Systems) [235]. In this chapter, RAMSES is presented due to its refinement-based approach providing more accurate analyses and supporting automated design optimizations.

**Concepts** The process flow of the RAMSES approach is presented in figure 8.26. RAMSES takes as input an AADL model and transforms it into another AADL model into which details specific to an operating system specification selected by the user has been added. The POSIX, ARINC 653 and NXT OSEK are currently supported. This step is called model refinement since the generated AADL model includes details specific to the operating system and therefore is of a lower level of abstraction than the original model. The advantage of this approach as opposed to code generated directly from the initial model is a reduced semantic gap between the refined model and the code. In addition, the refined model can be further analyzed giving more accurate analysis results due to this reduced semantic gap.

Fig. 8.26: The RAMSES process flow

The result of such analyses can be used to select of appropriate model transformations for applying design patterns to the initial AADL model for optimizing non-functional properties. The model can be refined iteratively until the desired quality attributes are achieved. Then, a code generator for the selected operating system generates platform-specific code including the required configuration files for the operating system such as thread scheduling and memory partitions.

There are many ways code can be generated from an AADL model. A first approach consists of generating skeletons from AADL components by assembling the source code set by the programming properties to subprograms and / or threads as presented in section 8.6.6. An alternative is to translate into code the behavior specification of components as specified using the AADL behavior annex. This later approach is not presented in this chapter, since the behavior annex has not been introduced. In any case, RAMSES supports these two approaches.

#### **Running Example Specification**

#### Refinement

RAMSES applies several refinement rules to produce the refined model for code generation. The set of applied rules varies depending on the selected operating system platform. We illustrate here one of the simplest RAMSES refinement rule for transforming event data port communications between threads into communication via shared data access. This is illustrated by the diagram of figure 8.27 where the port connection between two periodic threads is transformed into a shared data (queue) and two shared data access connections between the threads and the shared data. For this, the event data ports of the threads have also been converted into data access features. In addition, a call to a subprogram to manage the access of the queued data has been added to each thread.

Fig. 8.27: The RAMSES local communication refinement rule (reproduced from [234])

#### Code Generation step

During the modelling of the software application of the line follower robot, various properties have been set to subprograms and data components for their mapping to existing C code artifacts. We briefly describe the essence of these properties using our software application example.

As shown in Listing 32, we created new data types for our software variables that map to the system variable abstract types that they extend. To these types we added the *Data\_Representation* property from the data modelling annex to specify that our variables will be represented as integers in code. For the robot state internal variable, we have set the *Data\_Representation* as an enumeration with values *FORWARD* and *STOP*. The *Source\_Name* property specifies the name of a corresponding data structure in C code located in a C file specified by the *Source\_Text* property. An initial value of *FORWARD* is set on the data subcomponent of the *Carry\_Object\_Process* process of Listing 36.

For subprograms such as *Compute\_Turn\_Angle\_SW* (Listing 33), the *Source \_Language* property has been set to "C" and similar to the Robot\_State data component type, properties *Source\_Name* and *Source\_Text* are used to identify corresponding subprograms in C code.

From the AADL threads of our software application and their properties such as their priorities, as well as other properties set on the NXT ARM processor of the NXT brick (Listing 28) onto which the NXT OSEK firmware has been installed, the code generator also generates the configuration file for the NXT OSEK operating system specifying which threads should be scheduled and how they should be scheduled.

#### **8.7 Summary**

This chapter introduced the AADL language with a focus on its use for the development of CPSs. The modelling and analysis of a simple object carryer robot was used to introduce AADL by following a typical V-cycle development process (figure 8.3) augmented with some of the requirements engineering management practices promoted by the REMH (figure 8.9) and supported by the ALISA set of notations and workbench. The required AADL notions have been introduced gradually as they were required by the modelling steps of the followed development process.

This allowed presenting how AADL can be used to design a CPS with a top down approach starting from modelling the overview of the system to be built, followed by the capture of stakeholder and goals, verifiable requirements, system functions, physical plant model, software application model and deployment model. From such complete model including the software (cyber) part deployed on the hardware part, scheduling and latency analysis have been illustrated followed by model refinement, refined analyses and finally automatic C code generation with the RAMSES approach and tool.

We hope that introducing AADL this way allowed a better understanding of how AADL can be used and what it can achieve in termes of analyses, design space exploration and system synthesis via automatic code generation.

#### **8.8 Literature and Further Reading**

The AADL language and its annexes are quite rich and it was not possible to present the concepts thoroughly in this chapter due to space constraints. However, many documents are readily available for more in depth learning.


#### **8.9 Self Assessment**


<sup>2</sup> The EV3 Hardware Developer Kit document can be found at https://www.mikrocontroller.net/attachment/338591/ hardware\_developer\_kit.pdf

#### **Acknowledgements**

The authors are grateful to the ISC chair (Ingénierie des Systèmes Complexes) on cyber-physical systems and distributed control systems for supporting this work. ISC is sponsored by renowned industries such as Thalès, Dassault Aviation, DCNS and DGA and operated by the École polytechnique, ENSTA ParisTech and Télécom ParisTech engineering schools.

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

## **Chapter 9 FTG+PM: Describing Engineering Processes in Multi-Paradigm Modelling**

Moharram Challenger, Ken Vanherpen, Joachim Denil, and Hans Vangheluwe

**Abstract** Model-based System Engineering (MBSE) is a methodology that uses models throughout the engineering to replace the paper-based approach of communication among stakeholders. Multi-Paradigm Modelling (MPM) is at the core of this engineering approach as for each phase in the engineering process the most appropriate models at the most appropriate levels of abstraction is used. A design process includes a set of activities in which the design decisions or evaluations of the (sub-) system properties are done. Furthermore, the design artifacts are transformed by the design activities. We can define transformations as the manipulation of a model with a specific purpose. MPM approaches do not have a standard way of representing processes. A process model for MPM should focus on the languages, model instances and transformations between these models at different levels of abstraction. In this chapter, we propose the Formalism Transformation Graph and Process Model (FTG+PM) as a standard representation of MPM processes. The described process can be simulated for analysis and orchestration, as a set of (automatic) transformations.

#### **Learning Objectives**

After reading this chapter, we expect you to be able to:


## **9.1 Introduction**

To tackle the increasing complexity of today's systems, engineers already practice a Model-Based Systems Engineering (MBSE) methodology [95]. In MBSE, models are used to support requirements engineering,

Moharram Challenger University of Antwerp, Belgium e-mail: moharram.challenger@uantwerpen.be

Ken Vanherpen University of Antwerp, Belgium e-mail: ken.vanherpen@uantwerpen.be

Joachim Denil Flanders Make, Belgium e-mail: joachim.denil@uantwerp.be

Hans Vangheluwe McGill University, Canada e-mail: hans.vangheluwe@uantwerp.be design, verification, and validation activities of a system beginning in the conceptual design phase and continuing throughout development and later life cycle phases [153]. While these models often operate at different abstraction levels, model transformations are applied to manipulate models between different appropriate representations. They are typically used for code synthesis, integration, analysis, simulation, and optimization purposes. Multi-Paradigm Modelling (MPM) as a method consolidates these modelling methods and techniques, encouraging engineers to model each aspect of the system explicitly at the most appropriate level(s) of abstraction using the most appropriate formalism(s) [212].

While engineering a system, a design process is followed, in which a set of design activities are executed in a well-defined order. In each design activity a set of design artifacts are consumed and/or produced. These design artifacts explicitly model the informed design decisions taken by the engineers or the evaluations done by the engineer. As such, they can also be regarded as model transformations where information in a set of input models is consumed to produce a set of output models.

Although this series of design activities should result in an operational system that meets the predefined set of requirements, MPM approaches do not have a standard way of representing the process. This is in spite of the many advantages that the explicit modelling of the development process can offer, such as optimization, consistency analysis, time and risk analysis, etc. Generally, having well defined processes reduces the risk of failing a design project, as we can explicitly reason on problems that have to be overcome in the design of a system [143].

In this chapter, we propose the Formalism Transformation Graph and Process Model (FTG+PM) as a standard representation of MPM processes. As its name implies, it consists of two (related) parts: (a) the FTG where the focus is on the languages and transformations used throughout the process and (b) the flow of design activities and design artifacts. As tool-support is crucial in the MBSE (and MPM) life-cycle, we demonstrate how the orchestration of a modelled design process can support designers by scheduling transformations.

#### **9.2 Model-based Systems Engineering**

Document-centric approaches used to be at the core of communicating design choices between different engineers. However, as systems steadily enlarge in size, number of components, and features offered to the user, this is no longer appropriate. The added systems' complexity leads to an increase in the development time, number of errors, and development cost. As such, model-based systems engineering (MBSE) approaches have gained momentum to mend these shortcomings [95]. In MBSE, models are used as an integral part of the technical baseline of the system under design. This includes models in different development phases of a capability, system, and/or product [76].

MBSE is an engineering methodology in which the domain models and modeling techniques are used as the primary means of information exchange between engineers, rather than on document-based information exchange. The MBSE approach was outlined and popularized by INCOSE when it kicked off its MBSE initiative in January 2007 [154]. It focuses on distributed but integrated model management and the main goal is to increase the productivity and reducing the risk, by minimizing unnecessary manual transcription of concepts when coordinating the work of large teams. MBSE methodology provides several advantages:


The MBSE methodology supports system requirement engineering, analysis, design, implementation, verification, and validation activities of a system beginning in the conceptual design phase and continuing throughout development and later life cycle phases [154]. There are a multitude of modelling techniques and approaches that fall within MBSE. Some of them include:


#### 9 FTG+PM: Describing Engineering Processes in Multi-Paradigm Modelling 261

#### • Process Modelling

Recently, the focus of MBSE is also the model execution in computer simulation experiment, to overcome the gap between the system model and the respective simulation software. As a result, the term Modeling and Simulation-based Systems Engineering (M&SBSE) has also been used along with MBSE [123].

The models used in an MBSE approach pave the way to tackle system complexity by providing proper levels of abstraction where engineers make design choices or analyze the systems' capabilities or performance. Models operate at a similar or different levels of abstraction called horizontal and vertical abstractions, respectively [124][254]. The level of abstraction can be regarded as which properties of the system under design are taken into account in the models. Certain design approaches, such as the Model Driven Architecture (MDA) approach, explicitly introduce such levels of abstractions: Platform-specific Modeling (PSM) level or Platform Independent Modeling (PIM) level [166]. In this sense, the horizontal abstraction can be either among PIM models or PSM models. While the vertical abstraction can be considered among PIM and PSM models.

Model transformations can be applied to manipulate models from one abstraction to another. They are typically used for code synthesis, integration, analysis, simulation, and optimization purposes. By using model transformations, models in one formalism are automatically transformed to another formalism. This allows the possibility to benefit from the power of the target formalism, e.g. to simulate the system under design. Two types of transformations exist, Model-to-Model (M2M) and Model-to-Text (M2T) transformations.

Multi-paradigm Modelling (MPM) consolidates the modeling methods and techniques, such as MBSE, enabling engineers to model each aspect of the system explicitly at the most appropriate level(s) of abstraction using the most appropriate formalism(s), while modeling the development process(es) explicitly [213].

Cyber-physical Systems (CPS) are one of the inter-disciplinary systems which require different formalisms, levels of abstraction, tools, and viewpoints in their design and development. Therefore, they need for MPM and MBSE techniques to deal with the complexity and available risks. Also, the evolution in the requirements of different views during the CPS design and development needs for a MPM process management. The next sections deals with the life-cycle and design process in MPM for complex systems such as CPSs and IoT systems [307].

#### **9.3 Development Lifecycle Models**

As designing complex systems involves engineers from various disciplines, engineers follow a set of guidelines to ensure that the product implements the given system requirements. The order in which the guidelines are followed is called the design process. Inspired by the software engineering community, that has defined Software Development Life Cycle (SDLC) models over the past decades [246]. We can distinguish four models that are commonly used when designing complex systems: the waterfall model, the V model, the spiral model, and the agile model. They are conceptually shown in Figure 9.1.

#### **9.3.1 Waterfall Model**

The waterfall model is typed by a sequence of design steps/activities in which a step/activity can only be started if one deliverable from the previous step/activity is arrived, as such it is a gated process. The gate is a decision point to define if a next phase of the project can start. The process starts by defining a set of requirements, which are then refined to a set of technical requirements called specifications. Given these specification, engineers reason about a high-level architecture in which the structure of the system is defined. In the detailed design and implementation phase, the behaviour of the architectural elements is defined after which the system under design is tested. Finally, the designed system is deployed in its intended environment. There is often feed-back between steps/activities.

Note that the waterfall suits projects that are not subject to changes in one of the previous phases during the process e.g. the requirement should not change during architecture design. Otherwise, the design process must start over which may be costly in large engineering projects.

Fig. 9.1: Conceptual overview of commonly used MBSE design processes

#### **9.3.2 V Model**

Similar to the waterfall model, the V model is typed by a sequential design process. However, the V model distinguishes between *design* and *verification & validation* steps, respectively on the left-hand side and righthand side of the V model, while keeping them tightly coupled as illustrated by the horizontal dashed lines, see Figure 9.1. While going from high-level requirements to a low-level implementation, the specifications of the design are verified by executing acceptance tests, ranging from low-level unit tests to high-level system tests. Ultimately, at the top of the V model, it is validated whether the system satisfies the requirements. Model-based techniques allow engineers to front-load a large set of the V&V activities.

Although the verification steps are executed while designing the system so that late detection of implementation errors can be avoided, a changing product requirement still requires one to redesign (parts of) the system which, again, may be costly. Nevertheless, in the context of designing (large) complex systems using a MBSE approach, the V model is widely accepted as the industry standard for designing and testing complex systems [95].

#### **9.3.3 Spiral Model**

Using an iterative design process, spiral model avoid these (costly) redesign by repeatedly going through four design phases: Requirements and specification election, risk analysis, design, and testing and deployment. In the first iteration, preliminary requirements and specifications are elected so that the first prototype of the system can be designed, tested and deployed.

In subsequent iterations, requirements and specifications are added and/or become more detailed so that the initial prototype further evolves towards the final product. During each iteration, the process is monitored such that possible project risks (e.g. technical feasibility and project cost) can be better assessed. Although this design model better mitigates changing requirements and design errors, one should note that an increasing number of iterations can lead to an increasing (cumulative) project cost.

#### **9.3.4 Agile Model**

Agile design process models are typed by so called sprints (i.e. design iterations) in which a small part of the overall system is designed, tested, and deployed. At the end of each sprint, a finalized, working, system is delivered to the stakeholders. This differs from a spiral design approach in which a prototype might be delivered. Moreover, the design iterations of the agile design approach are typically shorter than the ones of the spiral design approach. Agile design processes are therefore suitable when requirements are subject to change during the design and implementation phases, and when multidisciplinary teams need to cooperate. On the downside, the lack of a thorough system analysis may result in a more complex and more expensive design process.

#### **9.4 Modelling the Design Process**

A process for a complex system (such as CPS) should cover different aspects of the system and should make the different levels of abstraction clear. These levels of abstraction could be at the domain-specific design of the computational or physical components, the verification of the system at a specific abstraction level, and/or during deployment where different approximations can be used to obtain a better understanding of the parameters involved. At the defined level of abstraction, it has to be clear which languages and transformations are involved and how they are used together in the design and development process. Though, from a tool building perspective, this definition could be too restrictive, as some activities can require manual intervention before the activity are completed. Since tool-support is crucial in the MDE (and MPM) life-cycle, it is important that the described process can be executed automatically. One approach to do this is by means of a set of transformations scheduled after each other.

The process model has to act as a guide for the design, verification and deployment of the system. This means that the design of a large set of applications has to be described using the modelling language. The language should focus on the constructs of MPM, mainly formalisms and transformations and how these interact with each other. There should also be an explicit representation of control- and data-flow since the output of a single phase in the process does not necessarily means that the produced models are the input of the next phase. This also includes the use of control structures that allow parallel design, iterations, etc.

#### **9.4.1 Rationale**

Over the years, the process engineering community has proposed various process modelling means for software development. Process modelling has a large research community, resulted in many modelling languages. Rolland [241] gives a definition of process modelling: *Process models are processes of the same nature that are classified together into a model. Thus, a process model is a description of a process at the type level. Since the process model is at the type level, a process is an instantiation of it. The same process model is used repeatedly for the development of many applications and thus, has many instantiations.* [241]

Generally, a process model is used for three different goals:


#### **9.4.2 What to model?**

The process models can describe different aspects of the system development. These aspects can be divided in four groups (see Figure 9.2), namely: Functional view, Dynamic view, Informational view and Organization view [78].


#### **9.4.3 Reasoning about maturity**

When processes are repeated multiple times, it is important to extend, evolve and mature the process models as well. Adding more information to process models can ultimately lead to better (e.g. faster, more robust, etc.) processes. The term *maturity* relates to the degree of formality and optimization of processes, from ad-hoc practices, to formally defined steps, to managed result metrics, to active optimization of the processes.

The Capability Maturity Model (CMM1) is a methodology used to develop and refine a development process. The model's aim is to improve existing development processes. CMM was developed and is promoted by the Software Engineering Institute (SEI), a research and development center sponsored by the U.S. Department of Defense (DoD). CMM was originally developed as a tool for objectively assessing the ability of government contractors' processes to implement a contracted software project [303].

<sup>1</sup> CMM is a registered service mark of Carnegie Mellon University (CMU).

The CMM is similar to ISO 9001, one of the ISO 9000 series of standards specified by the International Organization for Standardization (ISO). The ISO 9000 standards specify an effective quality system for manufacturing and service industries; ISO 9001 deals specifically with software development and maintenance. The main difference between the two systems lies in their respective purposes: ISO 9001 specifies a minimal acceptable quality level for software processes, while the CMM establishes a framework for continuous process improvement and is more explicit than the ISO standard in defining the means to be employed to that end [198].

CMM describes a five-level evolutionary path, see Figure 9.3, of increasingly organized and systematically more mature processes. These maturity levels of processes are:


Fig. 9.3: Capability Maturity Model (adopted from: http://performancexpress.org/)

#### **9.5 Activities 2.0 for modelling processes**

When engineering complex system using a MBSE approach, design artifacts will be created at different levels of abstraction within the same or between different engineering domains. A model of the design process should make the relation between different design artifacts, and their respective abstraction level, clear. This process model has to act as a guide for the design, verification & validation, and implementation of the system. There should also be an explicit representation of control- and data-flow since the output of a single phase in the process does not necessarily means that the produced models are the input of the next phase. This also includes the use of control structures that allow parallel design, iterations, etc.

In [194, 196, 216] a Process Model (PM) language is proposed to describe the control and data flow between design activities. To this end, a subset of the Unified Modelling Language (UML) 2.0 activity diagrams are used. It enables to define the process as a descriptive and prescriptive model.

An example of a PM, describing the (partial) process of generating code from a control model, is shown in Figure 9.4.

Fig. 9.4: Example of a Process Model (PM) for generating code from a control model

The labelled square edged rectangles represent the data objects (design artifacts) that flow throughout the design process. In a MBSE approach, these objects corresponds to models that are consumed or produced by design activities, represented by the labelled rectangles with rounded corners. For example, to verify the closed loop behaviour of a control model, a model of the physical system (i.e., a plant model) is required such that a Model-in-the-Loop (MiL) simulation can be executed. Note there the process is typed by a control flow and a data flow represented by solid and dashed edges, respectively. Furthermore, a distinction is made between manual and (semi-)automated activities. Finally, the join and fork Activity Diagram flow constructs, represented in Figure 9.4 as horizontal bars, allow one to represent concurrent design activities.

#### **9.6 The tool perspective: Formalism Transformation Graph**

In each phase of the Process Model, it has to be clear what formalisms and transformations are involved. Corresponding to mega-model principles [19, 31, 142], the Formalism Transformation Graph (FTG) [194, 196, 216] is a language that allows one to declare those formalisms and transformations. It models the relations between the different languages using transformations.

As can be seen in Figure 9.5, domain-specific formalisms are represented as labelled rectangles in an FTG model.

Fig. 9.5: Example of a Formalism Transformation Graph (FTG) for generating code from a control model

Transformations between those formalisms are depicted as labelled circles. Similar to the Process Model, these transformations can be either manual or (semi-) automated. The arrows from formalisms into transformations describe the inputs to the transformations and the arrows from the transformations into formalisms describe the outputs of the transformation. The FTG model is thus a graph describing the modelling languages and the transformations statically available to the engineers of a given domain. In the example of generating code from a control model, one can observe that a MiL Simulation is a (semi-)automated transformation from models expressed in a control, plant, and architectural formalism to a trace model represented in its appropriate formalism.

#### **9.7 FTG+PM: Formalism Transformation Graph and Process Model**

In the previous sections we have introduced models that enable engineers to describe their design activities, the formalisms that are used, and the transformations that exist between formalisms. One may have noticed that there exists a relation between the Formalism Transformation Graph and the Process Model. Indeed, data objects (i.e., models) and design activities in the PM are instances of the formalisms and transformations defined in the FTG, respectively. These typing relations are made clear by the colon defined in the rectangles of the PM.

As such, we define the unified metamodel of the Formalism Transformation Graph and Process Model as depicted in Figure 9.6.

Fig. 9.6: Formalism Transformation Graph and Process Model (FTG+PM) metamodel

On the left-hand side the FTG metamodel can be observed in which the concepts *Language* and *Transformation* are depicted. Both concepts have a *definition* attribute that refers to the definition of the language or transformation. Additionally, an *auto* attribute defines whether the transformation is automatic or not. On the right-hand side the metamodel of the PM language can be seen with its *Activity*, *Object*, and *Control* nodes. Note the typing relation between an *Activity* and an *Object* in the PM, and an FTG *Transformation* and *Language*, respectively.

#### **9.7.1 Reasoning about appropriateness of formalisms and heterogeneous modelling**

The formalism transformation graph can be used for much more than typing alone. The mega-model describes the relations between different formalisms. As such, we can attach properties to formalisms and transformations. We can query the extended FTG to look for appropriate formalisms that satisfy a set of these properties.

The same applies for giving semantics to languages. The relations between the different formalisms can be used to define a path towards a certain analysis goal. For example, if we are interested in getting behavioral traces, we might use a simulator that creates behavioural traces from the model. However, you could also leverage the properties (and capabilities) of other formalisms and define another path in the FTG to create the state trajectories. For example, if a certain formalism can apply symbolic transformations to create a more run-time performant model, you can leverage these transformation and define a path in the FTG that goes over this formalism. As such the different translational semantics of the formalisms can be reused. This also has drawbacks as it is necessary to keep enough traceability information available to allow the engineer to e.g. debug the models. Figure 9.7 shows the FTG from [292]. Here two different properties are attached to the relations: (a) translational semantics (full line) versus simulation (dashed line) and (b) no approximation (blue) versus allowing approximation e.g. sampling (green). The vertical dashed line in the middle shows the split between the continuous-time domain (left) and the discrete-time domain (right).

The FTG also allows us to reason on combining different formalisms together. Multi-paradigm modelling advocates to use the most appropriate levels of abstraction using the most appropriate formalisms. When applying this principle to the design of complex cyber-physical systems, we have to combine both discrete and continuous-time formalisms. The cyber-part is much more naturally described in the discrete-time domain, while models-of-the-physics are much more naturally described in the continuous-time domain. However, to

Fig. 9.7: Formalism Transformation Graph from [292]

evaluate the full system behaviour, we have to combine these models. Therefore, we need to reason on what it means to combine formalisms together, and how we can achieve this.

There are three techniques available to simulate the behaviour of hybrid systems.


#### **9.7.2 Orchestrating Processes**

Orchestration of a process means that the engineers are supported in their design process. This support can take various forms, from showing the engineers a dashboard with various metrics about the process and the steps to follow (e.g. in [193]) to automatically setting up modelling environments, opening the correct models and automatically saving and transforming models when possible. We assume the latter and reason about the orchestration of a process model, more specifically an FTG+PM, in a multi-paradigm modelling environment.

The orchestration of the FTG+PM language requires that the action nodes, denoting a transformation, are properly executed. The order of execution of these nodes is based on the mapping of the activity diagram to coloured Petri nets. The mapping of the activity diagram to the Petri net is described in [168]. When an action node is encountered the action has to be executed. Depending on the state of the auto attribute in the transformation, the framework has to:


For this end, the tool should be able to capture commands from the engineers, e.g. to indicate when the designer is done with her/his task and the process can continue. Furthermore, the FTG part is very important as it gives the information to the MPM environment to open a certain which modelling environment should be opened to aid the designer. Automating the model transformations that are already defined, results in the consecutive execution of different transformations. A multi-paradigm modelling environment, such as AToMPM [259], has dedicated languages to execute model transformations. We can use these languages to enact the FTG+PM by transforming the process model to such a language. Other modelling environments have similar tools available that can be used to setup such an orchestration, e.g. [240, 145, 131].

#### **9.8 Summary**

This section discusses the use of Model-based System Engineering (MBSE) in the development life-cycle of Cyber-Physical Systems (CPS). It focuses specifically on the design processes and transformation of paradigm in the Multi-Paradigm Modelling (MPM) of CPSs.

Generally, MPM approaches do not have a standard way of representing processes. A process model for MPM should focus on the languages, model instances and transformations between these models at different levels of abstraction. These levels of abstraction could be at the domain-specific design of the computational or physical components, the verification of the system at a high abstraction level, but also during deployment where different approximations can be used to obtain a better understanding of the parameters involved.

In this regard, a standard representation for MPM processes of CPS is introduced called Formalism Transformation Graph and Process Model (FTG+PM). The automation and tooling is crucial in MPM lifecycle and it is key that the described process can be simulated for analysis and orchestrated to support the designers. To support the designers, the reasoning on the orchestration of a modelled design process is elaborated.

#### **9.9 Literature and Further Reading**

The interested readers can study the following papers and books for more details. To elaborate on the development/design processes, you can read [246] for software development life cycle models, [95] for the V model which is widely used for MBSE, and the book in [276] for agile development process.

To investigate more on FTG+PM, you can study [194] and [196] for the use of FTG in MDE, as well as the paper in [216] for a case study which uses FTM-PM in automotive. The background studies for FTG+PM can be also found in multiple references [81][41][292][295][291][293][290][178][288][289].

Finally, to read more on the reasoning and orchestration using FTG+PM, you can study tthe work of István et. al [79].

#### **9.10 Self-Assessment**


#### **Acknowledgements**

The authors would like to thank the followings: (1) The COST Action networking mechanisms and support of IC1404 Multi-Paradigm Modeling for Cyber-Physical Systems (MPM4CPS). COST is supported by the EU Framework Programme Horizon 2020. (2) Flanders Make, Belgium. Flanders Make is the strategic research centre for the manufacturing industry in the Flanders area, Belgium.

**Open Access** This chapter is licensed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license and indicate if changes were made.

The images or other third party material in this chapter are included in the chapter's Creative Commons license, unless indicated otherwise in a credit line to the material. If material is not included in the chapter's Creative Commons license and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder.

## **Bibliography**


P. Carreira et al. (eds.), *Foundations of Multi-Paradigm Modelling for Cyber-Physical Systems*, https://doi.org/10.1007/978-3-030-43946-0 © The Author(s) 2020


editors, *Integration of Software Specification Techniques for Applications in Engineering*, pages 325–354. Springer, Berlin Heidelberg, 2004.


*UK, June 20-24, 2011. Proceedings*, volume 6709 of *Lecture Notes in Computer Science*, pages 318–327. Springer, 2011.

