EEE6207 – Operating Systems Assignment – 2022
The objective of this assignment is to explore some capabilities of the Functional Mockup Interface (FMI) that can be used, among other things, to interface dynamical1 simulators.
1 Introduction
Systems are becoming increasingly complex and consequently expensive to engineer. Therefore, the ability to simulate a system during its design phase is becoming ever more important as a means of improving the design process, and reducing costs. However, writing a new simulator for every new, proposed system is an almost impossible undertaking. The obvious solution is to reuse existing simulators of electrical, thermal, etc. (sub-)systems, but interconnect them such that they can exchange data. Each simulator is, in effect, simulating a part of a proposed, complex system; this is a sensible reuse of existing software, the development of which has, in most cases, been a huge effort on its own. The question remains: how to interface a diverse range of existing simulators such that they can all cooperate to simulate a large, complex system?
One solution is the open-source Functional Mockup Interface (FMI) developed by the Modelsar consortium of European companies, many of them aerospace companies that have a big interest in complex systems. FMI defines a very general standard to exchange information between stand-alone computer programs that requires only an acceptable amount of modification of the program. In essence, it is only necessary to include an FMI into the program to allow it to inter-operate with other FMI- enabled programs; if the program is not collaborating with other programs, the FMI part is inactive.
The Wikipedia page https://en.wikipedia.org/wiki/Functional_Mock-up_Interface gives a reasonable overview while very comprehensive documentation of the FMI is available at https:// fmi-standard.org/ although beware—much of this is ‘standards’ documents. While being very pre- cise, standards documents are not easy reading! But they are the definitive source of information about the FMI. The “Why FMI’?” link from this website leads to a short video that explains some more about FMI (although you can ignore the stuff about “ProStep IVIP SE”).
In practice, adding an FMI to an existing simulator also requires some means of specifying the internal simulator variables that need to be exposed (i.e. made available) to the external FMI. In a full FMI implementation, this is done using an eXtensible Markup Language (XML) file, but we shall omit this refinement in the present assignment. Ignore anything to do with XML files.
This assignment will explore a number of the operating system related concepts that the FMI relies upon.
2 Step 1: The Gentle Introduction
As a first step, write a C program to print out the values of y(t) for piecewise constant inputs u(t). That is, between t = ti and t = ti + ∆t, the input u is constant. Between ti and ti + ∆t, the output y varies as:
iττ
y(t) = y(t )e−∆t + u(t)[1 − e−∆t ] (1)
which is sketched in Figure 1. This, of course, is a simple first-order system.
If u = 0 then y will decay exponentially from the value of y at time ti; if u = 1 then it will rise over
the interval ∆t. Take ∆t = 1 second, a value of τ = 10 seconds and an (initial) u = 1. This will act as our (very simple) dynamical system with which we will interface—the same principles apply here as interfacing to a complex, fluid mechanics simulation of an aircraft wing.
1A ‘dynamical’ system is one that changes as a function of time.
1
Figure 1: Sketch of time response
In the next step we will change the values of u as a function of time in order to control y between two limits. Add a simple bang-bang controller where u is set depending on the value of y according to the rule:
and y then decreases until y < 0.4 at which point u is set to +1 again. And so the cycle repeats. 3 Step 2: Adding a Functional Mockup Interface
An FMI can allow the exchange of (mathematical) models, co-simulation, and many other things. Here we are only interested in co-simulation—the exchange of data with the program you wrote in Section 2. A key concept in co-simulation is the notion of a master and a slave. The program you wrote under Section 2 will be the master: what this means in practice is that the master dictates the advance of
time in a simulation.
As a first step to adding the capabilities of an FMI, download and include the three C header files:
• fmi2Functions.h
• fmi2FunctionTypes.h • fmi2TypesPlatform.h
from the FMI website (https://github.com/modelica/fmi-standard/releases/download/v2.0.3/ FMI-Standard-2.0.3.zip). These header files contain a large number of C declarations that support all of the FMI facilities, most of which we will not use. Note, however, these C files are just declarations. There are no definitions, i.e. code to implement any of the declared functions—you need to add those— or at least the definitions for the small number of functions we will actually use.
Of the large number of functions declared in fmi2Functions.h, three are of particular interest to us here:
1. fmi2SetReal 2. fmi2DoStep 3. fmi2GetReal
ify<0.4 u→+1 ify>0.6 u→0
(2) In other words, when u = +1, y increases until it is greater than 0.6 at which point u is set to zero,
2
We should note a few key points about the FMI declarations:
• Everything is done from the perspective of the master in the co-simulation. So fmi2SetReal allows the master to set the values of a series of real numbers in the FMU. Similarly, fmi2GetReal allows the master to get values of real variables from the FMU
• Although the FMI contains a lot of functionality to setup and manage simulations, we will ignore almost all of these facilities. Equation (1) is sufficiently simple that we do not need to consider more complicated features.
• In so-called Step Mode, i.e. when the master is running the simulation, the three functions above are repeatedly called in the sequence . . . , fmi2SetReal, fmi2DoStep, fmi2GetReal, . . . and so on until the simulation completes. These correspond to the simulator i) passing its current state to the FMU, ii) the FMU performing some action, and iii) the simulator retrieving the results from the FMU.
Notice that the terms ‘FMI’ and ‘FMU’ are usually used fairly loosely: an FMU is a single instance that implements the FMI.
4 Step 3: Creating the External FMU
As explained above, the key point in the FMI is for the definitions (i.e. the function implementa- tions) to be outside the simulator. So the next stage is to create implementations of the functions in fmi2Functions.h although all of these other than fmi2SetReal, fmi2DoStep and fmi2GetReal can do nothing other than return “fmiOK” simply to satisfy the compilation requirements.
Create and build a shared object library (on Linux or Mac) (or its equivalent dynamic link library or DLL on Windows) to supply the definitions of the fmi2SetReal, fmi2DoStep and fmi2GetReal functions2 .
A couple of implementation points:
• The FMI defines a number aliased types, such as fmi2Real, which actually resolves to a C double
via a typedef statement.
• The fmi2Component arguments are a so-called opaque pointer to the instance of the FMI. In practice, it can point to anything—here we can just use a NULL value although often it is a pointer to a structure that contains things like the value of the simulation time.
• The variables are exchanged between the simulator and fmi2SetReal/fmi2GetReal in the value array which is of dimension nvr. The value reference array vr is a rather elaborate way of indexing the variables—we do not need to consider it. Pass values to/from the FMI using the value array (of double types).
• The currentCommunicationPoint argument of the fmi2DoStep function represents the current (master) simulation time.
4.1 Initial Test of Your FMU Implementation
As an initial test of your FMI implementation, build a shared object library/DLL and link it to a modified version of the simulator program in Section 2. The simulator program will now need to call fmi2SetReal, fmi2DoStep and fmi2GetReal (in this sequence) in the simulation loop. You should print out the variables communicated between the program in Section 2 and the FMI implementation to verify correct operation.
2As mentioned above, a full FMI-complaint FMU would require an XML file specifying the exported variables. But we will dispense with this complete implementation.
3
4.2 Making the FMU Independent of the Simulator
The code under Section 4.1 is a good test, but, in practice, you will be interfacing the FMI you have written with a simulator that somebody else has written. In many cases, the simulator will be complex, commercial software where you have no access to the source code so you would not be able to link different FMI implementations as you did above. Modify the program developed under Section 4.1 to dynamically load the shared object library/DLL at run time thereby making the compilation/building of the simulator and FMI independent of each other.
5 Moving the Bang-Bang Control to the FMU
At the current stage, the bang-bang control of the dynamical system still resides in the simulator. One of the possible uses of an FMI is to develop controllers for a (simulated) dynamical system. Hence you might want to put a (possibly maybe) experimental controller in an FMI and see how it performed (in simulation!). Therefore, the next step is to move the code the bang-bang control you developed in Section 2 into the FMU.
6 Socket Communication with the FMU
A further refinement is to virtualise the simulator entirely by creating, say, a Berkeley sockets interface between the FMU and another program. The remote controller program needs to create a server socket to which the FMU can then connect; at this point, there can be an exchange of data to/from the simulator and the remote controller program via the FMU. One consequence is that the remote controller program needs to be started before the simulator/FMU otherwise the socket client in the FMU will fail because there would not be any server socket for it to connect to.
Implement a remote controller program with socket communication between the FMU, and move the bang-bang control functionality to this remote controller.
7 Marking Scheme
The following marks will be awarded for demonstrating successful operation of each of the above sections:
Section 2 25% Section 4.1 25% Section 4.2 15% Section 5 20% Section 6 15%
• The report should comprise up to 4 pages of A4 submitted via the EEE6207 course page on Black- board by the beginning of Week 9 (Monday, 21st November). Submit via the Blackboard course page under “OS Assignment - I".
• The report should not include your code. You will be advised later how to separately submit your code listings, possibly via a separate submission.
• On the subject of code, wud U. rite th:E Boddiy OF /ˆthe ripport lYke thiSS? No? So why would you submit a program written like this? See the interesting article on Technical Debt (https://www.parkersoftware.com/blog/what-is-technical-debt-and-what -should-you-do-about-it/). That students frequently submit difficult-to-follow code that is totally devoid of comments is probably understandable—‘success’ in a programming assignment is usually seen as getting the program to work, end of story. But a properly presented program makes it clear to me what you have done, how you have done it, and therefore makes it easy for
4
me to award you marks! If you force me to work through contorted logic with variables named ‘d’ , ‘dd’, ‘ddd’, etc.3, I may fail to grasp your ingenious, working solution to the problem, and award a low mark because I cannot understand what you have done. Core principle: always help the examiner to award you marks.
3I once had a colleague—now no longer in the department—who would write Fortran programs in which the first variable was named ‘d’ (for data). If he needed a second variable, he would call it ‘dd’. A third variable would be called ‘ddd’. A fourth ‘dddd’. And so on. I really wish I was making this story up. . .