20145255 433-20145255 New trends and methods for the co-simulation of strongly coupled systems using the Functional Mock-up Interface 2.0 Yosuke Ogata 1) Bruno Loyer 2) Antoine Viel 3) 1) LMS Japan, Arena Tower 14F, 3-1-9, Shin-Yokohama, Kohoku-ku, Kanagawa 222-0033, Japan (E-mail: yosuke.ogata@lmsintl.com) 2) LMS Imagine SA, 84, quai Charles de Gaulle 69006 Lyon, France (E-mail: bruno.loyer@lmsintl.com) 3) LMS Imagine SA, 7, Place des Minimes 42300 Roanne, France (E-mail: antoine.viel@lmsintl.com) Presented at the JSAE Annual Congress on 5, 23, 2014 ABSTRACT: Among the methods used for coupling system simulation software, co-simulation is probably the most widely used for its ease of implementation and robustness. An important consequence of co-simulation is that each involved simulator is modeled as a discrete dynamical system. This property leads to a tradeoff between computational efficiency and numerical stability. We present here new methods to deal with this tradeoff by providing analysis tools and numerical extrapolation methods that extend the stability margins. These methods, based on linear discrete system theory, are now enabled thanks to standardization efforts being done in the Functional Mock-up Interface (FMI) initiative. KEY WORDS: Functional Mock-up Interface, Co-Simulation, Model Exchange, Stabilized Co-Simulation 1. INTRODUCTION Complex industrial systems usually involve several types of subsystems from various physical domains (e.g. mechanical, hydraulic or electric subsystems) that interact with each other and that often need to be controlled. In this context, a standard way of coupling together subsystems modeled in various simulation tools was highly needed by the industry. This was finally offered by the Functional Mock-up Interface (FMI) (1) initiative, started within the framework of the ITEA2 Modelisar Project. According to the FMI specification, an instance of a compiled model is called Functional Mock-up Unit (FMU). It can be coupled with a simulation environment either through the FMI for Model Exchange or the FMI for Co-Simulation standard. When simulating an FMU for Model Exchange, only the solver of the importing tool is used, which implies that it is well adapted to the model contained in the FMU. When simulating an FMU for Co-Simulation, the native solver of the FMU model s originating tool is also embedded and used as slave solver in a co-simulation where the solver of the importing tool is used as master solver, see Fig. 1. Fig. 1 FMI for Co-Simulation and for Model Exchange. Generally speaking, Model Exchange suits well for lowdetail physical models that have little impact on the simulation performance while Co-Simulation enables using high-detail physical models while still benefiting of the know-how of each originating tool. Co-Simulation also allows for modular approaches combining various specifically adapted solver types and/or settings. Even co-simulation step sizes can be fine-tuned for each model. This prevents a unique solver from having to resolve all the different kinds of often domain-specific dynamic equations. However as always when dealing with cosimulation, users need to cope with the well-known compromise between stability and CPU efficiency. In this paper the authors illustrate the combined use of FMI for Model Exchange and FMI for Co-Simulation within the LMS Imagine.Lab Amesim TM 13 environment that covers the full range of the FMI specification: FMI Import and Export for either Model Exchange or Co-Simulation. An example inspired from the Energy Sector is presented to demonstrate each aspect of FMU utilization, to provide guidelines on how and when to use Co-Simulation or Model Exchange. In practice indeed and despite the standardization provided by FMI, coupling numerous FMUs coming from various sources raises questions about the performance and the reliability of such a heterogeneous simulation. How to optimize the partitioning of the system? Why is Co-Simulation often preferable to Model Exchange in the frame of a customer-supplier relationship? This is especially crucial in the Automotive industry when dealing for instance with innovative hybrid technologies involving subsystems from various expertise domains and where well-established specialized codes come into play.
The example considered in the first part consists in exporting a Modelica-based heat actuator and controller model as an FMU for Model Exchange, while a steam plant model using LMS Amesim's C-based libraries is exported as an FMU for Co-Simulation. A closed-loop simulation is then created in LMS Amesim by importing these two FMUs and coupling them with a model of the system load, see Fig. 2. hand are very different. This is often the case when dealing with distinct physical domains. Here indeed the steam power plant components that mainly come from LMS Amesim Thermal- Hydraulics, Two-Phase Flow and Hydraulic libraries will be connected to the mechanical part, see Fig. 3. Fig. 2 Considered heterogeneous simulation example. It is then possible to run the simulation, modify interactively the mechanical load and observe the system response via an animated dashboard. At each step, justifications for the modeling choices are provided. Based on this example, a generalization is made to a broader context and the reasons why only FMI for Co-Simulation is needed most of the time are given. Lastly, as co-simulation always requires to manage the tradeoff between computational efficiency and numerical stability, a promising technique that can significantly improve the co-simulation even in the most unfavorable cases is described. Potential gains are discussed based on a prototype implementation of this technique in LMS Amesim, made possible by the Functional Mock-up Interface 2.0 (5). 2. COMBINED USE OF FMI FOR CO-SIMULATION AND FMI FOR MODEL EXCHANGE 2.1. FMU for Co-Simulation: steam plant model For this first FMU, the considered plant model is a simple model of steam power plant built and exported with LMS Amesim. It can be noticed that to protect the Intellectual Property (IP), the parameters and the variables that are exposed by the FMU can be limited. The LMS Amesim model itself is restricted to the feed water and the steam loop. The heater (furnace) and the mechanical load are modeled outside of this first model and a co-simulation will be set up to simulate the whole coupled system. The motivation for this model partitioning is that the dynamics of the feed water and the steam loop on the one hand, and of the mechanical load on the other Fig. 3 Steam power plant model. Following the above choice of model partitioning, the model has two input variables and one output variable: - The heat flow rate produced by the heater is an input of the model; - The rotary speed of the turbine shaft is an input of the model. - The torque applied by the turbine on its shaft is an output of the model. In LMS Amesim, these variables are connected to a Functional Mock-up Interface Co-Simulation block that represents the outside (here: the control loop and the mechanical load models) with which the steam power plant model will be coupled. At this stage, a co-simulation FMU is generated, which illustrates the FMI for Co-Simulation Slave capability of LMS Amesim 13. The resulting FMU can be simulated in any FMI 1.0 compliant master tool. For the demonstration purposes, it will be reimported into LMS Amesim for building the complete coupled model including the speed control loop and the mechanical load. 2.2. FMU for Model Exchange: speed control loop The considered model is a Modelica model of a speed control loop with saturation. It has been built using the Modelica Editor available in LMS Amesim and exported as an FMU for Model Exchange using the FMI for Model Exchange Export capability of LMS Amesim. Fig. 4 Speed control loop model.
This model consists in a block diagram PID-controller with a saturated heater actuator. Although it has been built in LMS Amesim for the demonstration purposes, this FMU could have been generated by another Modelica and FMI compliant tool. The motivation for choosing an FMU for Model Exchange rather than an FMU for Co-Simulation here is that the controller model is a simple low detail continuous model for which no stiff integration algorithm is required. In addition, it is not likely to penalize the solver of the master importing tool. 2.3. Full coupled model in LMS Amesim: steam power plant with control and mechanical load With the aim at performing the transient simulation of the complete system, the two previously generated FMUs are imported into LMS Amesim 13, which illustrates both the FMI for Co-Simulation Master and the FMI for Model Exchange Import capabilities of LMS Amesim. The model of mechanical load to which the two FMUs are coupled is a simple model of a varying load dynamically changed by the user during the simulation and moved by the steam power plant (first FMU containing the model of the steam production loop). The rotary speed of the rotor is regulated by the controller (second FMU containing the servomechanism and the heater actuator) which governs the heat flow entering the boiler. The remaining part of the model represented in the LMS Amesim sketch restricts to the mechanical part of the model, see Fig. 5. slave FMU for Co-Simulation and the FMU for Model Exchange. 3. RESULTS OBTAINED, DISCUSSION AND GENERALIZATION 3.1. Results obtained In this section, the results obtained by running the complete coupled model are presented. Both the master solver and the slave solver of the co-simulation FMU use variable time step sizes for integration. The co-simulation step size was chosen such that the frequencies of the coupling are correctly sampled (at a frequency of 10 times the Nyquist frequency), which is sufficient here as the dynamics are weakly coupled. An LMS Amesim interactive dashboard equipped with gauges and sensors allows monitoring quantities such as the rotor speed, the water level, the boiler temperature, the boiler pressure and the mechanical power. Clutch engagement and pump status are also displayed whereas the mechanical load can be modified interactively by the user by means of the slider located on the left side of Fig. 6. Fig. 6 Interactive dashboard of the full coupled model. Fig. 5 Steam power plant with control and mechanical load. Under these conditions: - The torque applied by the steam turbine on the rotor is an output of the slave FMU for Co-Simulation and thus is an input of the LMS Amesim model. - The heat flow rate produced by the heater and entering the boiler is an output of the FMU for Model Exchange. It is connected to the input of the slave FMU for Co-Simulation through a signal link in the LMS Amesim model. - The rotary speed of the turbine shaft is an output of the LMS Amesim model that is fed to the input of both the Fig. 7 Dynamic input variation of the mechanical load. In the Automotive industry, such an interactive dashboard could of course be used to create a complete driving simulator to which driver inputs are applied (gear shift, steering wheel, accelerator or braking pedals can be selected). During the numerical experiment presented here, the user dynamic input applied led to the curve shown in Fig. 7. The available
mechanical power corresponding to these conditions is shown in Fig. 8 whereas the boiler time response is represented in Fig. 9. Fig. 8 Mechanical power available. equations, discontinuity management mechanisms and potential other model specificities need to be thoroughly described at least in theory in order to be managed by an unknown thirdparty solver. This is by the way not always possible. Exposing all this know-how could even go against the neutrality of the Functional Mock-up Interface in terms of tool, language or technology. A reasonable use of Model Exchange can thus only be restricted to simple low detail models for which commonly used integration methods are efficient. For all these reasons, cosimulation appears to be the most robust and pragmatic response to the need for combining several FMUs sometimes containing highly detailed models together with a sufficient level of reliability and confidentiality. Fig. 9 Boiler time response. 3.2. Discussion 3.2.1. Why FMI for Co-Simulation is the most useful standard in practice? The previous example is a favorable one where users have certain kind of freedom for partitioning their model efficiently as well as insights or expertise on model contents and required solver characteristics. This allows choosing between FMI for Model Exchange and FMI for Co-Simulation knowingly. However in real-world situations, especially in the frame of customer-supplier relationships that are common in the Automotive Industry, end-users have little or no influence on model partitioning and usually no expertise on all the coupled FMUs. This is mainly due to organizational reasons: separated departments for plant and control engineering within the same company, pre-defined perimeters in the frame of a vehicle development project, presence of de-facto domain-specific codes for subsystems, and so on. On top of that, software vendors and project partners usually do not want to share their IP or know-how ( black-box FMUs can for example be used for this purpose, which is a strong requirement of the FMI specification). In this respect, Model Exchange can be very intrusive, as all the internal 3.2.2. Practical usage of Co-Simulation Co-Simulation reduces the coupling between subsystems to a minimal set of variables that are exchanged at scheduled time instants. A local decoupling in time is thus achieved by isolating the simulators in such a way that each of them remains responsible for its part. Each subsystem is seen as discrete by the outside. This numerical sampling process is conditionally stable, especially when a lot of energy lies in the coupling itself. This is the well-known stability-efficiency tradeoff that needs to be managed with any kind of Co-Simulation interface (4). This tradeoff is illustrated in Fig. 10. Fig. 10 Co-Simulation paradigm. Divergence and poor accuracy are usually avoided by taking small enough co-simulation steps but this might lead to a drastic increase of the CPU time in unfavorable situations. A solution could consist in parallelizing the co-simulation (using one CPU core for each subsystem). For this purpose, the best possible conditions for a parallelized co-simulation are satisfied when: - The dynamics involved are weakly coupled; - The co-simulation time step is greater than the largest time constant in the system; - The low-frequency part of the model performs a lot of CPU time-consuming operations.
Under these conditions, speedups can even be expected compared to using only FMUs for Model Exchange integrated by a unique variable-step solver, which cannot be parallelized in practice. However, these conditions are not satisfied very often. Even with an optimized model partitioning, subsystem dynamics can be strongly coupled energetically. A simple yet representative example for these worst-case conditions is given hereafter. 4.1. Simple typical example to understand co-simulation stability aspects The below example consists of a double hydraulic chamber single rod jack (piloted by a spool-valve) and its mechanical load (see Fig. 11). It is assumed that the model is split into a hydraulic part and a mechanical part coupled through cosimulation (in Fig. 11, the mechanical components are only the green ones). In terms of exchanged variables: the hydraulic part computes the force applied to the piston whereas the mechanical part computes the velocity. oversampling factor of more than 300 is observed with respect to the highest dynamics of the system. This illustrates that, as opposed to the previous favorable example where 10 times the Nyquist rate was convenient for the co-simulation time step, stability requirements of strongly coupled co-simulated subsystems can have a negative influence on the CPU time. Indeed, the micro-steps taken by the local numerical solvers that integrate each subsystem cannot exceed the value of the cosimulation time step (also called macro-step ) used for exchanging variables. See Fig. 12. Fig. 12 Considered Co-Simulation stepping scheme. Fig. 11 Hydraulic jack and its mechanical load. This is a typical case of strong energetic coupling between subsystems. Automotive applications in which this generic example is encountered could be a hydraulic active suspension system or a hydraulic power steering system. Here, using the LMS Amesim default parameter values, the highest eigenfrequency f 0 computed by LMS Amesim for this system is around 45 Hz with a damping ratio ξ of about 0.1% completely governed by the fluid dissipation around the spool and the piston. As explained in (4), standard co-simulation introduces sampleand-hold at the boundary between the two subsystems at a rate corresponding to the co-simulation time step T. Stability can be analyzed using the linear discrete system theory by considering the equivalent loop sampled system and looking at the Z transform of the open loop transfer function (4). This analysis yields to an upper bound on the co-simulation interval, namely T < ξ / (π.f 0 ). Numerically, it imposes a co-simulation sampling frequency above 3 khz while the Nyquist frequency is only equal to 2.f 0 = 90 Hz. So, in this extreme situation an 4. CO-SIMULATION STABILIZATION METHOD For an efficient model-based collaborative engineering, end-users should be able to cope with complex co-simulations easily. For this purpose, the linearly implicit stabilization method can be used (2,6). The rationale behind this method is to mitigate the stability-performance trade-off exemplified in the last section, by extending the phase margin. Based on subsystem Jacobian matrices, linear approximations are built in state-space form and integrated locally in time using an unconditionally stable method. This allows taking relatively large macro-steps that do not restrict anymore the size of the micro-steps taken by the embedded solvers (see Fig. 12). Assuming that there are no algebraic loops on coupling variables and following two other reasonable assumptions regarding linearization and discretization methods (4), the dynamics of the system on the duration of a macro-step can be completely defined using the directional derivatives provided by the slave simulators to the master. Under these conditions, Co-Simulation macro-steps can safely be maximized up to the size of the micro-steps taken by the embedded solver without compromising the stability. The only price being a moderate loss of accuracy, as shown in (4). As of FMI 2.0 (current version is Release Candidate 1), slave FMUs may provide the directional derivatives of their state variables and connected inputs. This interface for the directional derivatives is one of the major enhancements of FMI 2.0. Provided that some minor extensions to the Co-Simulation specification are applied, the above-mentioned co-simulation
stabilization method can be implemented in such a way that if any part of the coupled system does not support it, then the classical co-simulation is used. This implementation is described in detail in (4). Although additional operations needed by the stabilization method lead to some implementation-dependent overhead, significant speedups can be regained on strongly coupled models. A summary of the results obtained on a model very similar to the one represented in Fig. 11 is given in Table 1 to give an idea of simulation times. Table 1 Summary of test results. Tested implementation Macro-step [μs] CPU time [s] Continuously coupled reference (no co-sim) 1.0 FMI 2.0 Explicit Co-simulation 1 12 FMI 2.0 Implicit Stabilized Co-simulation 50 1.5 A direct C prototype and the trapezoidal rule as discretization method were used. These results are very close to traditional cosimulation in terms of accuracy and the speedup factor is 8, which is remarkable. All the details of this study can be found in (4). 4. CONCLUSION The example presented in this paper illustrates a practical use of both the Model Exchange and the Co-Simulation FMI standards at the same time and in a unique integration platform, namely LMS Amesim 13. Nevertheless, in realistic industrial contexts where multiple FMUs need to be exchanged between external partners and/or departments of the same company, Co- Simulation really seems to be the most pragmatic and reasonable approach compared to Model Exchange. Especially in the Automotive Industry where model-based collaborative engineering is the common situation, end-users do not have insights or expertise on all of the involved models. These OEMsupplier collaborations are for instance described in (7) as well as the need for improving the FMI Cross Check procedure to ensure a good level of compatibility between FMI implementations (and thus to stabilize the FMI standard). The same goes for FMU suppliers who might ignore the target environment into which their FMUs are imported or at least the precise solver algorithms necessary (or at disposal). This is why in practice, in order to guarantee the reliability of FMU results, the best adapted solver i.e. the one from the originating tool needs to be present and thus embedded in the FMU (hence an FMU for Co-Simulation). This also avoids unexpected model-solver incompatibilities coming from version changes of the importing tools, on which FMU suppliers have no practical influence. Symmetrically, importers usually ignore the characteristics of FMU internal equations and associated solver requirements. Even with this information, adapted solving algorithms might not be present or not be usable for Model Exchange (due to another part of the model having conflicting requirements for the solver). Lastly, when very different dynamics come into play, using a unique solver might cause a dramatic reduction of integration time steps, leading to poor performance. All these reasons tend to prove that FMI for Co-Simulation is the path of least resistance in the Automotive Industry. Nevertheless, as end-users need guidance for setting up complex co-simulations efficiently, ways for analyzing and/or increasing the stability margins are highly needed. Such techniques exist already (2,6) and FMI 2.0 (5) opens the path to using them in a completely standardized manner. REFERENCES (1) Functional Mock-up Interface: http://www.functionalmockup-interface.org/ (2) Arnold M.: Numerical stabilization of co-simulation techniques, the ODE case, Working document MODELISAR, swp 200-203, September 5, 2011. (3) Etele Erdelyi H., Viel A., Ogata Y.: Investigating the applicability of the FMI standard for co-simulation in automotive application scenarios, JSAE Annual Congress, Yokohama, April 24, 2013. (4) Viel A.: Implementing stabilized co-simulation of strongly coupled systems using the Functional Mock-up Interface 2.0, 10 th International Modelica Conference, Lund, March 2014. (5) Modelica Association Project: FMI, Functional Mock-Up Interface for Model Exchange and Co-Simulation 2.0 Release Candidate 1, October 18, 2013, available at https://svn.modelica.org/fmi/branches/public/specifications/fmi _for_modelexchange_and_cosimulation_v2.0_rc1.pdf (6) Arnold M., Clauß C., Schierz T.: Error Analysis and Error Estimates for Co-Simulation in FMI for Model Exchange and Co-Simulation V2.0, The Archive of Mechanical Engineering, Vol.LX, No 1, 2013. (7) Bertsch C., Ahle E., Schulmeister U.: The Functional Mockup Interface seen from an industrial perspective, 10 th International Modelica Conference, Lund, March 2014.