proposal.tex 13 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177
  1. \documentclass[conference]{IEEEtran}
  2. \IEEEoverridecommandlockouts
  3. % The preceding line is only needed to identify funding in the first footnote. If that is unneeded, please comment it out.
  4. \usepackage{cite}
  5. \usepackage{amsmath,amssymb,amsfonts}
  6. \usepackage{algorithmic}
  7. \usepackage{graphicx}
  8. \usepackage{textcomp}
  9. \usepackage{xcolor}
  10. \usepackage{url}
  11. \usepackage{pdfpages}
  12. \usepackage{afterpage}
  13. \usepackage{balance}
  14. \def\BibTeX{{\rm B\kern-.05em{\sc i\kern-.025em b}\kern-.08em
  15. T\kern-.1667em\lower.7ex\hbox{E}\kern-.125emX}}
  16. % comments
  17. \newcommand{\boxedtext}[2]{\colorbox{#1}{\scriptsize\bfseries\textsf{#2}}}
  18. \newcommand{\nota}[3]{
  19. \boxedtext{#2}{#1}
  20. {$\blacktriangleright${#3}$\blacktriangleleft$}
  21. }
  22. \newcommand\source[1]{\nota{Source}{green}{#1}}
  23. \newcommand\todo[1]{\nota{TODO}{magenta}{#1}}
  24. \newcommand\note[1]{\nota{Note}{yellow}{#1}}
  25. \newcommand\placeholder[1]{\textless\textless#1\textgreater\textgreater}
  26. \begin{document}
  27. \title{Tutorial Proposal: \\ Physical Systems for Software Modellers}
  28. \author{\IEEEauthorblockN{Hans Vangheluwe}
  29. \IEEEauthorblockA{\textit{University of Antwerp - Flanders Make} \\
  30. Belgium \\
  31. Hans.Vangheluwe@uantwerpen.be}
  32. \and
  33. \IEEEauthorblockN{Cl\'audio Gomes}
  34. \IEEEauthorblockA{\textit{University of Antwerp - Flanders Make} \\
  35. Belgium \\
  36. Claudio.Gomes@uantwerpen.be}
  37. }
  38. \maketitle
  39. \section*{Basic Information}
  40. \subsection*{Title: Physical Systems for Software Modellers}
  41. \subsection*{Presenters}
  42. \textbf{\uppercase{Hans Vangheluwe}} is a Professor at the University of Antwerp (Belgium).
  43. He heads the Modeling, Simulation and Design Lab (MSDL).
  44. In a variety of projects, often with industrial partners, he develops and applies the model-based theory and techniques of Multi-Paradigm Modeling (MPM).
  45. He is the chair of COST Action IC1404 ``Multi-Paradigm Modelling for Cyber-Physical Systems'' (MPM4CPS).
  46. 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.
  47. His e-mail address is \url{Hans.Vangheluwe@uantwerpen.be}.
  48. \\
  49. \textbf{\uppercase{Cl\'audio Gomes}} is a PhD student in the Modelling, Simulation and Design
  50. Lab (MSDL) at the University of Antwerp (Belgium).
  51. He was awarded a scholarship from the Research Foundation - Flanders,
  52. to work on the foundations of co-simulation. Since 2016, he has
  53. connected the fields of numerical analysis, optimization, and computer science to investigate
  54. the effect of different co-simulation algorithms on the quality of full-system overall simulation results, even in the presence
  55. of ``black-box'' Functional Mockup Units.
  56. His e-mail address is \url{Claudio.Gomes@uantwerpen.be}.
  57. \\
  58. \subsection*{Abstract}
  59. 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.
  60. 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.
  61. 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.
  62. Even the discretized level is still an idealization as the numerical values as not Real numbers, but are implemented as floating point approximations.
  63. 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.
  64. 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.
  65. Even the discretized level is still an idealization as the numerical values as not Real numbers, but are implemented as floating point approximations.
  66. 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.
  67. \subsection*{Proposed Length}
  68. We propose a full-day (6 hours) tutorial.
  69. The topic of dealing with Physical Systems is a complex one, and quite outside the comfort zone of the intended audience.
  70. To fully explain it requires a sufficient amount of time.
  71. The presenters have experience with giving similar tutorials in the past. Notice that, especially for the MODELS community,
  72. it is important to cover the ``why'', the ``what'' and the ``how'' of the topic, as the audience is interested in deep understanding.
  73. Past experience, with a tutorial on a-causal modelling (and Modelica in particular) at MODELS 2015 in Ottawa, showed (1) that
  74. a proper explanation takes time and (2) that the topic of (PID) control is the ``missing link'': it demonstrates where code gets generated
  75. and deployed (or conversely, where the code running in modern software-intensive systems comes from).
  76. The proposal has two main parts.
  77. The first three hour part covers modelling of physical systems down to computational causality assignment resulting in Causal Block Diagrams (CBDs).
  78. 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).
  79. 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.
  80. 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.
  81. \subsection*{Level of the Tutorial}
  82. Introductory:
  83. Only basic knowledge of object-oriented software design/programming,
  84. graph algorithms, and calculus are required.
  85. Remembering some undergraduate physics helps.
  86. \subsection*{Target Audience}
  87. Modellers with an interest in the link between physical systems and software modelling.
  88. Those who wish to understand the broad range of languages available for physical system modeling, and their rationale.
  89. In particular, (domain-specific) modelling language engineers may find this a refreshing view on a class of languages
  90. not rooted in software.
  91. \section*{Description and Intended Outline}
  92. This tutorial aims to introduce the families of languages used to model physical systems, to an audience of software modellers.
  93. It goes to the essence of the following language families, sorted from the lowest modeling effort to the highest:
  94. \begin{enumerate}
  95. \item problem/technology-specific (e.g., a nuclear power plant modeling language);
  96. \item domain-specific (e.g., SimMechanics); power-flow (e.g., Bond Graphs);
  97. \item computationally a-causal (e.g., Modelica and Simscape);
  98. \item computationally causal continuous (e.g., Simulink block diagrams);
  99. \item computationally causal discretized (e.g., discrete-time block diagrams);
  100. and
  101. \item black-box causal discretized (e.g., Functional Mockup Units);
  102. \item untimed ``algebraic'' block diagrams (and their link with synchronous data flow).
  103. \end{enumerate}
  104. Note that the first three topics are covered in the first three hour part of the tutorial.
  105. The remaining four topics are covered in the second three hour part of the tutorial.
  106. This second part also introduces, at a very introductory level, control theory in general, and
  107. Proportional -- Integral -- Derivative (PID) control in particular.
  108. The introduction is done by means of a simple example of cruise control of an autonomous vehicle.
  109. Most importantly, the PID controller is modelled as a continuous-time Causal Block Diagram which allows,
  110. after discretization, for the synthesis of controller software.
  111. 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.
  112. To achieve these goals, the tutorial will cover:
  113. \begin{itemize}
  114. \item general laws of physics used to derive physical system equations,
  115. \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),
  116. and
  117. \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).
  118. These scenarios are common in industry as externally supplied models contain Intellectual Property.
  119. \item PID controllers and how to realize them in software.
  120. \end{itemize}
  121. \section*{Additional Information}
  122. \subsection*{Similar Tutorials and Novelty}
  123. We presented tutorials on a-causal modelling in 2014 and 2015 at MODELS in Valencia and Ottawa respectively.
  124. These tutorials correspond to the first half of the current proposal.
  125. The proposed tutorial is also based on a part of the MPM4CPS COST Action Training School held 18 - 21 November 2018 in Pisa, Italy
  126. (\url{http://mpm4cps.eu/trainingSchools/pisa2018}).
  127. The audience at the Training School consisted, like at MODELS, mostly of researchers with a software engineering background.
  128. The addition of the PID controller part proved to fill the gap identied earlier during the MODELS tutorials.
  129. \subsection*{Required Infrastructure}
  130. Besides a data projector, a white-board or black-board (or flipchart) is required.
  131. \subsection*{Sample Slides}
  132. A number of sample slides of the previous versions of the tutorial are attached in the appendix.
  133. %\bibliographystyle{IEEEtran}
  134. %\bibliography{bibliography}
  135. \balance
  136. \newpage
  137. \includepdf[pages={1-},angle=90]{sample_slides}
  138. \end{document}