Model interfaces

In order to ensure interoperability, modularity and re-use between different models/simulators, well-defined interfaces are needed. Such simulator interfaces are a set of conventions that, if adhered to, allow a model/simulator to be coupled with other models/simulators using some simulation tool. Here, we will distinguish between low-level interfaces, by which we mean the interfaces between different software modules, and high-level interfaces, which relate to the physical phenomena and systems being modelled. This article describes different types of interfaces and gives some general recommendations.

A low-level interface concerns itself with the details exchange of information between different software modules. This typically includes communications protocols, application programming interfaces (APIs) and application binary interfaces. At this level, we are not concerned about the physical interpretation of the data that is being exchanged; it is all bits and bytes that need to get from one place to another.

There is much to say about this topic, but we'll keep it short. Most simulation interfaces are proprietary and tool-specific. One, however, stands out as being open and freely usable, as well as vendor and software neutral: FMI. Therefore, we strongly recommend its use.

Energy transfer

For connections that represent some kind of energy transfer from one system to another, such as the mechanical energy transferred by a rotating driveshaft or the electrical energy transferred by a power cable, we recommend the use of power bonds.

A power bond between two subsystems A and B consists of two variable couplings, where one represents an effort, and the other represents a flow. For an electrical connection, for example, the effort is the electromotive force (i.e., voltage) while the flow is the current. The two couplings are oppositely directed, meaning that if A has effort as an output variable, then it has flow as an input variable, while they must be the other way around for B. This is illustrated in the figure on the right.

Normally, the product of an effort and a flow has units of power (watt) and is a direct measure of the power that is transferred between the two subsystems. This makes it very easy to keep track of the energy flow through the system, to see where energy is produced and dissipated, and to locate violations of energy conservation. (If nothing else, this can be useful for debugging model code.) This feature is employed to good effect in the ECCO method.

The following table shows the standard definitions and units for different energy domains:

Energy domain Effort Effort units Flow Flow units
Mechanical (translation) Force N Linear velocity m/s
Mechanical (rotation) Torque Nm Angular velocity rad/s
Electrical Electromotive force V Current A
Hydraulic Pressure Pa Volumetric flow rate m3/s
Thermal Temperature K Entropy flow rate W/K

The figure below shows a simplified diesel-electric propulsion system, and illustrates how different energy domains can be seamlessly connected through power bonds in a simulation:

Some physical connections may be represented by multiple power bonds. The most straightforward example is probably a force acting on a body in three dimensions, which can be represented with one mechanical power bond for each spatial dimension.

Force-position coupling

Today, the most common way to model a force acting on some body is through a force-position coupling; that is, one model outputs a force while the other model outputs its position. This site champions a different convention, and here's why:

A force-position coupling between subsystems A and B works well enough if A only needs to know B's position. However, if A needs B's velocity, it has to differentiate the position, and numerical differentiation is notoriously inaccurate and hard to get right [1]. Numerical integration, on the other hand, is less susceptible to errors, so it makes sense to output the highest-order derivative that is likely to be needed in other subsystems, which is normally the velocity. Of course, the best course of action for the author of model B is to supply both position and velocity as outputs, so it can be coupled in either way.

Bond graph theory

The idea of power bonds comes from bond graph theory, [4][5] which is a method for representing dynamic systems graphically, and for systematic derivation of system equations from the graphs. A proper introduction to formal bond graph theory is beyond the scope of this article, and one can make efficient use of power bonds in simulations without a full understanding of the theory. However, for those who are interested in learning more, we recommend the book by Karnopp et al. [6]. There are also some online resources which may be informative:

1. William H. Press; Saul A. Teukolsky; William T. Vetterling; Brian P. Flannery, 2002. Numerical recipes in C++: The art of scientific computing. 2nd edition. Cambridge University Press, ISBN 0-521-75033-4.
3. R. H. Park. Two Reaction Theory of Synchronous Machines. AIEE Transactions, 48, pp.716-727.
4. H. M. Paynter, 1961. Analysis and design of engineering systems: Class notes for M.I.T. course 2.751. M.I.T. Press, Boston.
5. P. C. Breedveld, 1984. Physical systems theory in terms of bond graphs. Twente University.
6. Dean C. Karnopp; Donald L. Margolis; Ronald C. Rosenberg, 2012. System dynamics: Modeling, simulation and control of mechatronic systems. 5th edition. John Wiley & Sons, Inc., Hoboken, New Jersey, ISBN 978-0-470-88908-4.