19.09.15-20.MoDELS.Munich_tutorials_PhysicalSystemsForSoftwareModellers/proposal.tex

\documentclass[conference]{IEEEtran}
\IEEEoverridecommandlockouts
% The preceding line is only needed to identify funding in the first footnote. If that is unneeded, please comment it out.
\usepackage{cite}
\usepackage{amsmath,amssymb,amsfonts}
\usepackage{algorithmic}
\usepackage{graphicx}
\usepackage{textcomp}
\usepackage{xcolor}
\usepackage{url}
\usepackage{pdfpages}
\usepackage{afterpage}
\usepackage{balance}
\def\BibTeX{{\rm B\kern-.05em{\sc i\kern-.025em b}\kern-.08em
    T\kern-.1667em\lower.7ex\hbox{E}\kern-.125emX}}

% comments
\newcommand{\boxedtext}[2]{\colorbox{#1}{\scriptsize\bfseries\textsf{#2}}}
\newcommand{\nota}[3]{
   \boxedtext{#2}{#1}
       {$\blacktriangleright${#3}$\blacktriangleleft$}
}
\newcommand\source[1]{\nota{Source}{green}{#1}}
\newcommand\todo[1]{\nota{TODO}{magenta}{#1}}
\newcommand\note[1]{\nota{Note}{yellow}{#1}}
\newcommand\placeholder[1]{\textless\textless#1\textgreater\textgreater}

\begin{document}

\title{Tutorial Proposal: \\ Physical Systems for Software Modellers}

\author{\IEEEauthorblockN{Hans Vangheluwe}
\IEEEauthorblockA{\textit{University of Antwerp - Flanders Make} \\
Belgium \\
Hans.Vangheluwe@uantwerpen.be}
\and
\IEEEauthorblockN{Cl\'audio Gomes}
\IEEEauthorblockA{\textit{University of Antwerp - Flanders Make} \\
Belgium \\
Claudio.Gomes@uantwerpen.be}
}

\maketitle

\section*{Basic Information}
\subsection*{Title: Physical Systems for Software Modellers}
\subsection*{Presenters}
\textbf{\uppercase{Hans Vangheluwe}} is a Professor at the University of Antwerp (Belgium).
He heads the Modeling, Simulation and Design Lab (MSDL).
In a variety of projects, often with industrial partners, he develops and applies the model-based theory and techniques of Multi-Paradigm Modeling (MPM).
He is the chair of COST Action IC1404 ``Multi-Paradigm Modelling for Cyber-Physical Systems'' (MPM4CPS).
He was a founding member of the Modelica® design team and in the 1990s helped develop this standard language for equation-based object-oriented modelling.
His e-mail address is \url{Hans.Vangheluwe@uantwerpen.be}.
\\

\textbf{\uppercase{Cl\'audio Gomes}} is a PhD student in the Modelling, Simulation and Design
Lab (MSDL) at the University of Antwerp (Belgium).
He was awarded a scholarship from the Research Foundation - Flanders, 
to work on the foundations of co-simulation. Since 2016, he has 
connected the fields of numerical analysis, optimization, and computer science to investigate
the effect of different co-simulation algorithms on the quality of full-system overall simulation results, even in the presence
of ``black-box'' Functional Mockup Units.
His e-mail address is \url{Claudio.Gomes@uantwerpen.be}.
\\

\subsection*{Abstract}
The complex engineered systems we build today get their value from the networking of multi-physical (mechanical, electrical, hydraulic, biochemical, \ldots) and computational (control, signal processing, planning, \ldots) processes, often interacting with a highly uncertain environment. Software plays a pivotal role, both as a component of such systems, often realizing control laws, deployed on a resource-constrained physical platform, and in the construction of enabling modelling and simulation tools. 

This two-part tutorial will introduce software modellers to the two main facets of dealing with physical systems through modelling, simulation and (controller) code synthesis. 

In the first part, the different levels at which physical systems may be modelled are introduced. This starts with the technological level. At this level, components are considered that can be physically realized with current materials and production methods. Such components are often available off the shelf. They are characterized by the very specific context (also known as Experimental Frame) in which their models are valid. The next level uses the full knowledge of physics and engineering to describe the behaviour of physical components to study a wide variety of properties. To study the possibly turbulent flow of a viscous liquid through a pipe for example, a Navier-Stokes Partial Differential Equations model will be used. Such models are hard to calibrate and simulate accurately and efficiently. The next level considers the often occurring situation where, for the properties of interest, the spatial distribution of the problem can be abstracted and a lumped-parameter (as opposed to distributed-parameter) model can be used. In a translational mechanical context for example, an object with a complex geometry may still be considered as a point mass characterized by a single parameter ``mass''. Such models still obey physical conservation laws such as energy conservation. At this level, formalisms such as Bond Graphs that focus on power flow through a system are used. At the next level, the link with physics is weakened and computational components (functions) are added. This leads to the popular Equation-based Object-Oriented modelling languages such as Modelica® and Simscape®. The semantics of such computationally a-causal languages will be explained with particular focus on the process of causality assignment. This leads to the next level at which input-output computational blocks are used. The main disadvantage of this level is that it focuses on ``how'' to compute the evolution of state variables over time as opposed the focus on ``what'' the governing equations are in equation-based languages, leaving the ``how'' to a model compiler.

Even the discretized level is still an idealization as the numerical values as not Real numbers, but are implemented as floating point approximations.

The second part of the tutorial starts from the computationally causal level. The formalisms used are known as Causal Block Diagrams (CBDs) or Synchronous Data Flow (SDF), with Simulink® as the most notable example. Three different semantics of CBDs will be explained, bridging the gap between the equations resulting from causality assignment described in the first part of the tutorial and their realization in software. This software can either be a simulator (or a Functional Mockup Unit in case of co-simulation) on a digital computer or a controller deployed on a micro-controller or ECU.

A first semantics of such input-output Causal Block Diagrams focuses on algebraic CBDs only. Here, time has been abstracted away, which may lead to ``algebraic loops'' which need to be detected and revoled. The second semantics focuses on discrete-time CBDs. Time is abstracted as a discrete counter. The introduction of memory in the form of a delay block allows, in combination with feedback loops in the CBD, for the expression of complex dynamics. The third semantics treats time as continuous. To allow for simulation on a digital computer, discretization is required. As such, continuous-time CBDs are approximated and mapped onto discrete-time CBDs. Such approximation introduces numerical errors which must be dealt with. 
Even the discretized level is still an idealization as the numerical values as not Real numbers, but are implemented as floating point approximations.

Once CBDs are well understood, the tutorial gives a very basic introduction to automatic control. In engineering practice, the behaviour of virtually every physical systems (also known as ``plant'') is regulated by some form of controller. The principles of automatic control will be explained by means of the most simple Proportional, Integral and Derivative (PID) controller. The effect of the different parts of such a controller will be explained. A PID controller will be modelled in the form of a continuous-time CBD. This is then the basis for discritezation to a discrete-time CBD and subsequent synthesis of control software. To demonstrate the concepts, a PID controller will be developed and its optimal parameters will be estimated for the simple cruise control of a vehicle.

\subsection*{Proposed Length}
We propose a full-day (6 hours) tutorial.

The topic of dealing with Physical Systems is a complex one, and quite outside the comfort zone of the intended audience. 
To fully explain it requires a sufficient amount of time.

The presenters have experience with giving similar tutorials in the past. Notice that, especially for the MODELS community, 
it is important to cover the ``why'', the ``what'' and the ``how'' of the topic, as the audience is interested in deep understanding.

Past experience, with a tutorial on a-causal modelling (and Modelica in particular) at MODELS 2015 in Ottawa, showed (1) that 
a proper explanation takes time and (2) that the topic of (PID) control is the ``missing link'': it demonstrates where code gets generated
and deployed (or conversely, where the code running in modern software-intensive systems comes from).

The proposal has two main parts. The first three hour part covers modelling of physical systems down to computational causality assignment
resulting in Causal Block Diagrams (CBDs). The second three hour part starts by explaining the semantics of CBDs. This makes the link between
the models of physical systems and their ultimate realization in simulation software (as used in the Functional Mockup Interface standard).
The second link between physical systems and software comes from the introduction of controllers which steer a physical system (known as ``plant'') to a desired behaviour. It is these controllers that are first modelled as CBDs and subsequently discretized and realized as software.

The two parts can be followed independently, but for full understanding of the CBD/PID part, it is best taken after the part focusing on the
physics.

\subsection*{Level of the Tutorial}
Introductory: 
Only basic knowledge of object-oriented software design/programming,
graph algorithms, and calculus are required.
Remembering some undergraduate physics helps.


\subsection*{Target Audience}
Modellers with an interest in the link between physical systems and software modelling.
Those who wish to understand the broad range of languages available for physical system modeling, and their rationale.
In particular, (domain-specific) modelling language engineers may find this a refreshing view on a class of languages
not rooted in software.

\section*{Description and Intended Outline}

This tutorial aims to introduce the families of languages used to model physical systems, to an audience of software modellers.
It goes to the essence of the following language families, sorted from the lowest modeling effort to the highest:
\begin{enumerate}
  \item problem/technology-specific (e.g., a nuclear power plant modeling language);
  \item domain-specific (e.g., SimMechanics); power-flow (e.g., Bond Graphs);
  \item computationally a-causal (e.g., Modelica and Simscape);
  \item computationally causal continuous (e.g., Simulink block diagrams);
  \item computationally causal discretized (e.g., discrete-time block diagrams);
    and
  \item black-box causal discretized (e.g., Functional Mockup Units);
  \item untimed ``algebraic'' block diagrams (and their link with synchronous data flow).

\end{enumerate}

Note that the first three topics are covered in the first three hour part of the tutorial.
The remaining four topics are covered in the second three hour part of the tutorial.

This second part also introduces, at a very introductory level, control theory in general, and 
Proportional -- Integral -- Derivative (PID) control in particular.
The introduction is done by means of a simple example of cruise control of an autonomous vehicle.
Most importantly, the PID controller is modelled as a continuous-time Causal Block Diagram which allows, 
after discretization, for the synthesis of controller software.

Having followed this tutorial, the audience will understand how to write or generate software code that interacts with physical systems (e.g., due to inertia, turning off a physical systems does not stop it), including the crucial aspect of control.

To achieve these goals, the tutorial will cover:
\begin{itemize}
  \item general laws of physics used to derive physical system equations,
  \item algorithms to transform models across the language families introduced above (e.g., causality assignment to translate a-causal models to causal ones, or numerical discretization to transform continuous models to discrete ones),
  and
  \item techniques to integrate and simulate multiple models, even if the contents of these models are protected (e.g., in binary form), or represents physical subsystems (e.g., test rigs).
  These scenarios are common in industry as externally supplied models contain Intellectual Property.
  \item PID controllers and how to realize them in software.
\end{itemize}


\section*{Additional Information}

\subsection*{Similar Tutorials and Novelty}
We presented tutorials on a-causal modelling in 2014 and 2015 at MODELS in Valencia and Ottawa respectively.
These tutorials correspond to the first half of the current proposal. 
The proposed tutorial is also based on a part of the MPM4CPS COST Action Training School held 18 - 21 November 2018 in Pisa, Italy
(\url{http://mpm4cps.eu/trainingSchools/pisa2018}). 
The audience at the Training School consisted, like at MODELS, mostly of researchers with a software engineering background.
The addition of the PID controller part proved to fill the gap identied earlier during the MODELS tutorials.

\subsection*{Required Infrastructure}
Besides a data projector, a white-board or black-board (or flipchart) is required.

\subsection*{Sample Slides}
A number of sample slides of the previous versions of the tutorial are attached in the appendix.

%\bibliographystyle{IEEEtran}
%\bibliography{bibliography}

\balance

\newpage

\includepdf[pages={1-},angle=90]{slides.pdf}

\end{document}

The tutorial is divided in five parts, discussing different topics related to Statecharts:
\begin{enumerate}
	\item An introduction that explains the origins of the Statecharts formalism (both the syntax, coming from state diagrams, and the semantics, coming from state automata), and what classes of system it is good at representing (30 minutes).
	\item The main part that deals with the different Statecharts constructs (syntax and semantics), how to \textbf{model} with them, and how to \textbf{simulate} them (using \textsc{Yakindu}) (3 hours).
	\item A part on how to test models: first conceptually (building a generator and an oracle model), then using the testing framework implementation of \textsc{Yakindu} (30 minutes).
	\item A part on how to deploy Statecharts models on different platforms: code generated for a virtual application or onto hardware (controller software for controlling a physical plant) (30 minutes).
	\item The final part, explaining advanced concepts such as semantic options for configuring Statecharts, real-time execution of Statecharts, and how code generated from Statecharts can interact with different platforms, such as (graphical) user interfaces and games (1,5 hour).
\end{enumerate}

Throughout the different parts of the tutorial, the ``conceptual'' or ``theoretical'' explanation of Statecharts is followed by a practical application in \textsc{Yakindu}.
This ensures diversity for the participants: they will learn about a particular Statechart construct and be able to immediately use it in a modeling and simulation environment.
We have three presenters: Simon Van Mierlo and Hans Vangheluwe from the Univerity of Antwerp will be the presenters of the conceptual parts, and Axel Terfloth, from itemis, will lead the practical parts.
As such, we can bring expertise both from the academic side and the tool builder side to offer a tutorial where participants can optimally be introduced to all aspects of Statecharts.

In the following subsections, we give detailed information on the content of the five parts of the tutorial.

\subsection{Introduction}
In the introduction, we start by explaining the causes of complexity in reactive systems; such systems
\begin{itemize}
	\item interact with the environment (by processing \textit{events} coming from the environment continuously);
	\item exhibit autonomous behavior;
	\item exhibit concurrent behavior.
\end{itemize}
We explain that this type of behavior is fundamentally different from ``transformational'' programs typically encoded using a high-level programming language, and explain why Statecharts is an appropriate formalism to model their behavior by abstracting the system's behavior using the discrete-event paradigm.
To effectively develop reactive systems, traditional approaches based on threads and timeouts add accidental complexity, as they focus on ``how'' the system's behavior is implemented, instead of ``what'' the system is supposed to do.
Instead, a language which has notions of \emph{events}, \emph{timeouts} and \emph{concurrent units} is needed.

Statechart models are usually specified in a visual syntax (an extension of state diagrams), allowing developers to efficiently create and maintain large-scale models.
The notation is based on higraphs: a combination of hypergraphs with Euler diagrams for adding depth and orthogonality.
We explain the notation's origins of and look at it from a set theoretical perspective; this is important to fully understand the notion of hierarchical states and orthogonal regions in Statecharts.

We also explain the running example: a traffic light, which autonomously switches between its lights using timeouts.
Its autonomous behavior can be interrupted and restored by a policeman that pushes a button.
In autonomous mode, a timer shows the time left until the light switches.
This example has the necessary complexity: reactivity, orthogonality, and timing behavior.
Moreover, we can deploy this example on multiple platforms and will bring a hardware prototype based on the Arduino platform to demonstrate this.

A workflow for specifying, simulating, testing, and deploying Statecharts models is presented that guides developers through the different phases of system development.
In the next part(s) of the tutorial, we use the following workflow:
\begin{enumerate}
  \item First, a set of requirements are gathered: these are properties the system's behavior needs to satisfy, and are typically described in text.
  \item Then, an initial design (a Statechart model) is created.
  The model implements (a part of) the system's requirements.
  \item The model needs to be verified (i.e., we need to check whether its behavioral properties are satisfied).
  To do this, the model can be \emph{simulated} (in which the user defines a simulation scenario and checks the outcome of the simulation manually) or it can be \emph{tested} (in which the user defines a number of test cases, which consist of a set of timed inputs that are supplied to the model, and an automatic checker or ``oracle'' that verifies whether the test succeeds).
  If a simulation or test results in a \emph{failure} (i.e., one of the system's properties is not satisfied), the system's model needs to be revised.
  \item When the system's design has gone through several simulation and testing iterations, and its behavior is properly verified, code can be generated to deploy it.
\end{enumerate}

\subsection{Modeling and Simulating with Statecharts}
In this second part, we explain the language elements that the Statecharts language offers.
We start by explaining the basic concepts of \emph{states} and \emph{transitions}.
This allows us to model a simple system, such as an autonomous traffic light that switches between its lights autonomously.
It requires us, however, to touch on a number of fundamental concepts of Statecharts:
\begin{itemize}
	\item The \emph{configuration} of a Statechart, represented by its \emph{current state} and the values of variables that are stored in its \emph{data store}.
	\item The \emph{initialization} of a Statechart (by \emph{entering} the \emph{initial state}).
	\item The \emph{triggering} of a transition by evaluating its \emph{triggering condition}, consisting of a \emph{triggering event} and a \emph{constraint} over the variable values.
	\item The \emph{selection} of a transition if multiple transitions are triggered at the same time (leading to non-determinism!), by for example assigning priorities.
	\item The \emph{execution} of a transition by \emph{leaving} the source state and \emph{entering} the target state of the transition, as well as execution the \emph{transition action} (which can generate an event, and/or assign values to variables).
\end{itemize}
We will explain these fundamental concepts in-depth, as they are necessary to understand the rest of the tutorial.
With these concepts, the participants can already get familiar with many of the features of \textsc{Yakindu} as well.

Next, we look at \emph{hierarchy}: states can be \emph{nested}.
For correct initialization, we need to specify a default state at each level of the hierarchy.
We need to revisit transition execution as well: when a transition is executed, we need to leave not a single state, but a hierarchy of states, and enter not a single state, but a hierarchy of states.
For both these points, we can describe the semantics of Statecharts by a \emph{flattening} procedure: we can transform to a ``basic'' Statechart model with no hierarchy.
This can lead to issues, however, since now transitions on higher levels of the hierarchy are also defined on any state that is lower in the hierarchy.
This can lead to (unwanted) non-determinism, if multiple transitions are triggered in the hierarchy at the same time: different options for managing this non-determinism are discussed.

Next, we discuss history states, which allow for the current configuration (excluding the values of variables in the store) to be remembered and restored.
We approach this from an implementation view: when a transition is executed and it leaves a state that contains a history state, the current configuration has to be remembered.
When a history state is the target of a transition, that configuration is restored by entering the remembered states.
We explain the difference between deep history and shallow history.

Last, we explain orthogonality: states can not only be combined by nesting them hierarchically, but also by combining them in orthogonal regions.
This requires us to completely revisit the execution algorithm for finding triggering transitions, selecting one, and executing it: now this process has to be done for each orthogonal region.
This gives rise to ``steps'': in each step, each orthogonal region gets the chance to execute a transition.
Regions can communicate by raising events (that are stored in an internal event queue, ready to be consumed in the next step) or by constraining the execution of a transition based on the current state of another orthogonal region.
This leads to many potential interactions that have to be managed by the modeler.
We will spend a significant amount of time on the conceptual explanation, as well as the practical hands-on in \textsc{Yakindu}, to explain orthogonality in Statecharts properly.

At the end of this part of the tutorial, the participants will have modeled an interruptible traffic light in \textsc{Yakindu} and have used the simulation capabilities of \textsc{Yakindu} to verify that the correct behavior has been implemented.

\subsection{Testing Statecharts}
Once the Statechart model of the traffic light system has been constructed, it can be tested to check whether it satisfies the requirements.
A test consists of an input event trace, and an ``oracle'' that checks whether the output event trace satisfies the behavioral property.
This means that a test can be seen as a timed, reactive system as well.
The tests in this tutorial, therefore, are first modeled with Statecharts as well.
They can either be modeled as three communicating Statecharts (the input Statechart, the model under test, and the oracle -- corresponding to a black-box approach), or in a single Statechart model in orthogonal components (corresponding to a white-box approach).
Both approaches will be covered, and their advantages and disadvantages will be discussed.

For the practical part, \textsc{Yakindu}'s \emph{SCTUnit} will be used to model the test cases for our example system.
The testing framework allows a modeler to define an input trace (generating events), to advance the \emph{virtual time} of the test execution, and to check (through \emph{assertions}) whether the Statechart reacts correctly.
The participants will construct a number of test cases, corresponding to a number of requirements (use cases).

\subsection{Deploying Statecharts}
The last step in system development is the deploying of the software on a \emph{platform}.
This is an interesting step as its complexity is often overlooked: code is generated in a particular high-level programming language (such as C++, Java, or Python) and executed on a (possibly real-time) operating system; we need to ensure that the semantics of the running system corresponds to the behavior observed in the simulations and in the tests.
While we will not go into all the details of deploying real-time systems, we will cover two platforms to demonstrate that the Statechart model can be used to implement the same behavior on very different platforms:
\begin{enumerate}
	\item A Java GUI application allows for a ``gentle'' transition from the simulations in \textsc{Yakindu} to a deployed (virtual) application: the generated code of the Statechart is coupled to a GUI (displaying the state of the system and allowing for the user to interact through button presses).
	\item A hardware prototype based on the Arduino platform allows the participants to see a ``real'' deployment onto embedded hardware, used to control a physical ``plant'' (the traffic light, in this case represented by three led-lights and a push button).
\end{enumerate}
These deployments illustrate the platform-independent nature of Statecharts; it is only when the code is generated and \emph{bound} to platform-specific functions that a choice for the implementation is made.

\subsection{Advanced Concepts}
The last part of the tutorial is used to cover a number of advanced concepts: \emph{semantic choices} related to Statecharts execution semantics, the \emph{real-time} execution of Statechart models, the binding to execution \emph{platforms} such as a UI or a game engine, and the \emph{coordination} of multiple Statecharts.

For the semantic options, we will base the discussion on the work of Esmaeilsabzali et al.~\cite{Esmaeilsabzali_BigStepModellingLanguages}.
This will require us to break the ``stepping'' semantics of Statecharts down to a series of big steps, combo steps, and small steps.
We explain the semantic choices arising from this: \emph{big step maximality}, \emph{combo step maximality}, \emph{internal event lifeline}, \emph{input event lifeline}, \emph{transition priority} and \emph{small step concurrency}.
This illustrates the fact that Statecharts is not a single language: it is a \emph{family} of languages; a tool can allow for users to configure the simulator/code generator to suit the needs of the application.

Real-time execution of Statecharts is important from a conceptual point of view, and for participants that are interested in how a Statechart simulator/executor is implemented.
Naively, the delays encoded in the Statechart transition can be taken as the values for a \emph{sleep} call in the operating system to implement the waiting periods in the execution of a Statechart model.
This does not take into account, however, the time it takes for the action code to complete.
In certain cases, this can make the clock \emph{drift} significantly.
The tutorial will cover methods to ensure this does not happen, with a practical implementation.
This method also allows to scale up or slow down the execution (\emph{scaled} real-time execution).

Different platforms, such as game loops and user interfaces, can be ``in control'' of the application (they implement a ``main loop'' that the generated code of the Statechart model has to interact with).
This is different from stand-alone applications generated from a Statechart model, that implement their own ``main loop'': an (infinite) while-loop that listens for input events and produces output events to the environment.
We discuss such platforms, and in particular show how generated Statechart code can integrate with the event loop of a UI platform (where Statecharts events are interleaved with UI events) and the game loop of a game engine (where the Statechart execution algorithm is only called at a certain \emph{polling interval)}.

Last, we discuss the coordination of multiple Statechart instances.
We will look at SCCD~\cite{VanMierlo_SCCD}, a hybrid formalism that combines Statecharts with class diagrams to implement dynamic-structure systems consisting of a set of objects (that conform to classes), whose behaviour is specified in Statecharts.
The objects can communicate (using events) by creating \emph{links} to other objects (that conform to associations).
For the practical part, we will demonstrate how multiple traffic light models can be coordinated using \textsc{Yakindu}.