Introducing the Virtual Systems Interface for Dynamic Coupling of Continuous Time Systems with Discontinuities
Total Page：16
File Type：pdf, Size：1020Kb
Introducing the Virtual Systems Interface for Dynamic Coupling of Continuous Time Systems with Discontinuities Jeffrey Morgan1 Bruno Loyer2 1General Motors, United States of America, [email protected] 2Siemens Digital Industries Software, France, [email protected] Abstract coupling so that the destabilizing effect of the discrete communication can be made negligible by selecting a This paper introduces the Virtual Systems Interface small enough communication interval. (VSI) as a potential enhancement of the FMI interface or as a separate open source interface. The VSI interface This paper focuses on the model exchange interface is intended to simplify model exchange and dynamic and how it can be used effectively for the dynamic model coupling of continuous time systems with coupling of continuous time systems with discontinuities while ensuring fast, accurate and low- discontinuities. First, two example usages of the FMI cost simulations. The VSI interface uses a single 1.0 model exchange interface are presented, and the interface for the coupling of both continuous time and issues encountered are explained. Next, some discrete time systems. It is designed for variable time background for effective usage of a model exchange step integration with proper discontinuity handling and type interface is presented. Finally, a new interface is convergence checking. It requires no run-time licenses introduced which is intended to ensure fast, accurate and for any model packaged using the interface. low cost means for dynamic coupling of continuous time systems with discontinuities. Keywords: virtual systems interface, dynamic coupling, controls integration, functional mock-up interface 2 FMI 1.0 Model Exchange Interface 1 Introduction Examples and Issues Automotive and other industries are relying on the use Two examples are presented using the FMI 1.0 model of simulation models to reduce product development exchange interface. The first example is an automotive time and cost. This has generated a need for the dynamic driveline as an example of a continuous time plant coupling of both physical system models (called plant model with discontinuities. The second example is an models in this paper) and electronic controller models. engine dynamic model as an example of a continuous Furthermore, many systems are composed of time behavioral controls model with discontinuities. The subsystems and components produced by different results and the issues encountered are explained. companies so the exchange of models and their 2.1 Example 1: Automotive Driveline integration into simulation packages is required. This has led to the development of the Functional Mock-up The first example is an automotive driveline torsional Interface (FMI). The Function Mock-up Interface is an model. This model is incorporated into several vehicle open specification which allows import and export of systems models for the evaluation of both the vehicle both plant and controller models into and out of any hardware and control system designs. The automotive simulation packages that support the specification. driveline model contains simple torsional elements There are two types FMI interfaces: model exchange (springs, dampers, inertias, clutches, planetary gear sets, and co-simulation. The model exchange interface is etc.). The model is run in fixed gear with the torque intended for use with models that are described by convertor open, so there are no active controls. The differential, algebraic and discrete equations with or automotive driveline model is a continuous time system without discontinuities, and the system equations are with discontinuities. The discontinuities occur due to the solved simultaneously. The co-simulation interface is inclusion of backlash elements in the model. The intended for use with models where each subsystem is automotive driveline model is shown in Figure 1. solved independently, and data is exchanged between The automotive driveline model is implemented in subsystems only at discrete communication points. In Simcenter Amesim version 15.1 using Microsoft Visual general, the co-simulation interface gives accurate Studio 2010 64 bit as the compiler. The Simcenter results only for systems that physically exchange Amesim FMU generation tool was used to export the information at discrete communication points (i.e. model to FMI 1.0 model exchange format and then it digital controllers) or have low degrees of dynamic was imported back into Simcenter Amesim as an FMU to verify that it runs correctly. DOI Proceedings of the Asian Modelica Conference 13 10.3384/ecp2017413 Oct 08-09, 2020, Tokyo, Japan Introducing the Virtual Systems Interface for Dynamic Coupling of Continuous Time Systems with Discontinuities Figure 1. Automotive Driveline Torsional Model (Simcenter Amesim model) Figure 2. Automotive Driveline FMU integrated into a Vehicle System Model (Simcenter Amesim model) Figure 3. Results for Native Simcenter Amesim Model vs. Simcenter Amesim Model with FMU The automotive driveline FMU is integrated into a vehicle systems models for the evaluation of both the vehicle system model as shown in Figure 2. The vehicle hardware and control system designs. The simulation was run using the Simcenter Amesim engine dynamic model was built in Simulink and a 3rd standard integrator and a 1 ms print interval. The results party commercial FMI generation tool was used to for the system simulation with the automotive driveline export it to FMI format so that it could be used in other included as native elements and as an FMU is shown in simulation packages. The engine dynamic model is a Figure 3 (results are the same and show up as one trace). continuous time system with discontinuities. The The FMU produced accurate results but was 10.3 discontinuities occur due to the inclusion of continuous times slower than the native Simcenter Amsim model time rate limiter elements in the model. The engine (24.7 seconds vs. 2.4 seconds). The slow simulation was dynamic model is shown in Figure 4. determined to be caused by the generation of an implicit The model is implemented in Simulink version 2014a variable when connecting the FMU. This artificial (64 bit). FMUs were generated using Modelon software algebraic loop can be avoided by a better handling of the version 2.6.1 and then imported into Simcenter Amesim model’s input-output dependencies when exporting the version 14.2 using Microsoft Visual Studio 2010 64 bit FMU. It should be noted that improving the as the compiler for system simulation. Even though the management of these artificial algebraic loops was one Model Exchange interface was used, it was found that of the motivations behind FMI 2.0. the exported model was different depending on which Simulink solver was specified at the time of export. 2.2 Example 2: Engine Dynamic Model When a fixed time step solver (ODE4 with 1 ms time step) was specified the exported FMU was generated The second example is an automotive gasoline engine with each time step being a discontinuity (call this the dynamic model. This model is incorporated into several 14 Proceedings of the Asian Modelica Conference DOI Oct 08-09, 2020, Tokyo, Japan 10.3384/ecp2017413 Session 1: Mechanical Systems Figure 4. Engine Dynamic Model (Simulink Model) FMU with time-based discontinuities). When a variable based discontinuities was due to incorrect handing of the time step solver (ODE45 using a relative tolerance of model’s real discontinuity points. 1e-3) was specified the exported FMU was generated without each time step being a discontinuity but 2.3 FMI Model Exchange 1.0 Interface including event-based discontinuities (call this the FMU Issues with event-based discontinuities). For comparison, a The learnings from the two examples was that the FMI Simcenter Amesim equivalent model was created so the 1.0 Model Exchange interface does not contain enough results could be compared. The results are shown in information on how the internal equations, discontinuity Figure 5. handling, and solution algorithms should be The simulation was run using the Simcenter Amesim implemented in order to ensure that fast and accurate standard integrator and a 1 ms print interval. The FMU FMUs are generated. with time-based discontinuities produced accurate This paper proposes a new (extended) interface results while the FMU with event-based discontinuities intended to address these issues. The new interface did not. The FMU with time-based discontinuities was combines Virtual Systems in-the-Loop (VSiL) 65 times slower than the native Simcenter Amesim technology developed jointly by General Motors with model (1733 seconds vs. 26 seconds). The FMU with the support of LMS (now Siemens Digital Industries event-based discontinuities was 1.3 times slower than Software) and Autonomie technology developed by the native Simcenter Amesim model (33 seconds vs. 26 Argonne National Labs. These two technologies are seconds). The slow simulation speed of the FMU with described next. time-based discontinuities was due to the creation of discontinuities at each time point corresponding to the Simulink model’s originally specified integration time 3 Virtual Systems in-the-Loop (VSiL) step (1 ms). The inaccuracy of the FMU with event- Virtual Systems in-the-Loop (VSiL) has been used at General Motors since 2005 (Glaue, 2006). This DOI Proceedings of the Asian Modelica Conference 15 10.3384/ecp2017413 Oct 08-09, 2020, Tokyo, Japan Introducing the Virtual Systems Interface for Dynamic Coupling of Continuous Time Systems with Discontinuities Figure 5. Results for the Engine Dynamic Model Represented Using FMI 1.0 Model Exchange methodology allows electronic control units (ECUs) to be integrated with Simcenter Amesim plant models and run as a single executable. The Simcenter Amesim plant model is modeled using standard and custom sub models based on Bond Graph (powerflow) methodology (Rosenberg and Karnopp, 1983). This approach defines causality between the powerflow variables which determines how the equations are assembled and solved. The controller model is built using the actual software source code corresponding to the application layer.