Modular modelling of complex systems

A ship with examples of sub-components When dealing with any complex problem, it is generally a good idea to divide it into more manageable chunks that can be understood on their own terms. Naturally, this is the case with modelling and simulation too. Splitting a model into sub-models makes it easier to understand and work with, as one can focus on one subsystem at a time. In a virtual prototyping setting this is especially important, as it allows one to build up a library of sub-models that can be combined in new ways and reused for new purposes. This is a lot less time-consuming and error-prone than recreating the same models over and over again in new contexts.

Therefore, most modelling and simulation software is designed so that it is possible to construct a compound model from parts. Most modern commercial tools offer a graphical user interface where the model structure is shown in the form of a block diagram, where the blocks represent sub-models and the lines between them represent model variable couplings, and where the user can modify the model through a point-and-click interface. Many simulation tools allow subsystems to be hierarchically nested, so that sub-models can have their own sub-models, and so on. More often than not, each sub-model will correspond to a distinct entity in the real world. For example, a ship model can consist of a hull model, a propulsor model and a power plant model, each possibly with their own substructure.

We can distinguish between three methods for combining submodels:

  1. Modelling and simulating the entire system using a single software tool.
  2. Exporting models from different modelling tools and importing them into another (model exchange).
  3. Connecting different simulation tools (co-simulation).

The first one is by far the most common approach, simply because that's how most simulation tools have always been designed. The advantage is that you only have to deal with one software package, which typically makes for a smooth, integrated workflow. The downside is that you then rely on that one tool to have good enough support for all your use cases. For highly cross-disciplinary work, such as modelling an entire ship, this is rarely the case. Most general-purpose simulation software can in theory be used to model any system, but the amount of work required on the part of the user to do so, and the resulting performance and/or accuracy, may render it completely unrealistic.

The other two approaches are less common, and we will discuss them each in their own sections below.

As mentioned, it is often not practical to use a single software tool to model all subsystems. Often, you get better results, faster, by using a tool which is specialised for a particular domain. To combine models in one simulation then requires some level of interoperability on the part of the software tools in question. One way of doing this is if one of the simulation tools can use models created with the others. We refer to this as model exchange.

Model exchange requires that one simulation tool can understand the file formats and use the model code generated by the others, or that the others can export the model to a form that the importing tool can understand, or a combination of the above. Best of all is if all the tools can export their models to a standardised format, so that any modelling tool that chooses to support that standard can import them. While we're quite far from the situation that all modelling software can import models from any other software, at least one such standard does exist: FMI.

The figure above shows a typical model exchange setup, where several models are combined and solved under one solver, and where the tool's native models are combined with imported models through FMI for Model Exchange.

Finally, the third approach to modular modelling is to connect the simulation tools, not just the models, as shown in the illustration below. This approach is covered in detail in a dedicated page on co-simulation. Here we will limit ourselves to summarising some of the benefits of this method:

  • It allows the use of specialised solvers for models that benefit from it, and to adapt the micro step size to the dynamics of each subsystem, which can improve both performance, stability and accuracy.
  • The interface to each subsimulator can be minimal and opaque, simply consisting of transfer of input and output values. This allows the models to be “black boxes” where the implementation details can be well hidden, which is often desirable in an industrial setting.
  • It typically represents a very loose coupling between the subsystems, both in the physical sense and in the software-architectural sense. This allows for a great degree of encapsulation, which makes it easier to reuse models in other contexts later, as they will have minimal dependencies on other subsystems.
  • The loose coupling and comparatively large macro step length makes it very well suited for distributed simulations, where the workload can be spread over multiple CPU cores, or even multiple machines in a network. The latter case opens up possibilities to run cross-platform simulations, which may be required in order to combine certain simulation tools.

The FMI standard also caters to the co-simulation case, with an interface called FMI for Co-simulation.

We have now described three different methods for combining different subsysems in a cross-disciplinary simulation. So, which one should you prefer for any given situation?

Most of the time, the answer will give itself based on what choices you have in simulation software and the abilities of that software. However, the list of software tools that support FMI is large, and it keeps growing. So you may have some options.

In the software development world, it is considered good, general advice that one should aim to make separate entities as encapsulated as possible, and the couplings between them as loose as possible. This very much holds for model development as well, which points towards co-simulation as the preferred method in most cases.

Of course, there are exceptions to any rule, and in this particular case, the biggest exception is if the actual physical couplings that are being modelled are tight themselves. If this is the case, consider solving them together inside a subsimulator, possibly using model exchange. We discuss this problem in greater detail in our article on tightly coupled systems.

  • Regardless of which software you use to create your models, and which method you use to combine them, it is wise to define and stick to some conventions to help ensure that the models play well together. Read our article about model interfaces for tips and guidelines about this.
  • Confused about some of the terms used in this article? Hopefully, the glossary'll have you covered.