When it comes to physical modeling and simulation of technical systems, the question often comes up: Modelica or Simulink? We want to answer this question by looking at the basic differences and by using a simple example.

**Simulink** is a **signal flow-based** modeling and simulation environment developed by the MathWorks as part of the** Matlab **software package released in the early 1990s. Through continuous development, Simulink is now the de facto industry standard for modeling and simulation of controllers and signal-based systems of all kinds.

**Modelica** is an** equation-based** modeling language for physical systems that was developed in the mid-1990s. It has been further developed as open-source by the Modelica Association since 2000 and is used in various simulation programs. The best-known commercial programs that use Modelica are **Dymola**, SimulationX, Wolfram SystemModeler, Modelon Impact and MapleSim. With OpenModelica there is also a quite mature open source alternative.

Both Simulink and Modelica can be used to model and simulate dynamic systems as differential-algebraic systems of equations (DAE). Simulink is executed in Matlab, Modelica in a suitable development environment, such as Dymola. A graphical user interface is available for both variants, in which complex systems can be modeled as a network of individual, interconnected components. The individual components can be reused and structured in subsystems or submodels. This **component-based **modeling increases clarity and user-friendliness when modeling complex systems.

The difference between Simulink and Modelica lies in the definition of the individual components and especially in the communication between them. Simulink uses a **signal flow-based** or causal approach, while Modelica uses an** equation-based** or acausal approach.

In **signal flow-based modeling**, as the name implies, individual components are connected by signals. These signals are exchanged between the components, each of which has fixed input signals (inputs) and output signals (outputs). Within a component, the computation of the outputs takes place from the known inputs by explicit assignments and operations. This type of calculation is comparable to general programming languages such as Python or C++. The direction of the signal flow is thus always clearly defined within a component and cannot be changed.

The signal connections between the components define unique assignments between the inputs and outputs of different components (*Input _{2} ∶= Output_{1}*). For this reason, when connecting more than one input/output pair, some special features must be taken into account. For example, it is possible to connect an output with several inputs in parallel, because in this case all inputs receive the same signal. On the other hand, it is not possible to connect several outputs to one input, since in this case it must be defined how the signals interact with each other. This must necessarily be done by an additional component.

Due to the explicit assignments, there is a fixed, causal relationship within and between the components, which is why this approach is also referred to as **causal modeling**. By linking the inputs and outputs of various components, the desired overall model is created as a system of equations from the individual explicit operations. The solver can numerically evaluate the system of equations by successively applying the individual operations and thus calculate solutions of the modeled differential equation system.

In **equation-based modeling**, equations are defined instead of explicit operations. This is the crucial difference to signal flow-based modeling (Simulink), since there the calculation order is defined by the signal flow. In detail: explicit operations assign a value to a variable based on a defined expression. This expression, in turn, can only use variables that are known (assigned) before the assignment. As with classical algorithms, the calculation order is thus fixed. A change of the computation order, due to a change of the looked for variables, necessarily requires an adjustment of the assignments.

Equations, however, define only the equality of two expressions. The order of the equations does not play a role here, since the equation system is considered first as a whole. The determination of the calculation order is only done by defining some variables as a fixed (known) boundary condition. This approach offers the advantage that an equation has to be defined only once to define a relation of several variables. It can be reused without adjustment or manual rearrangement, even if the variable searched for changes.

Since there is no explicit assignment between the variables of a component in equation-based modeling, we speak here not of inputs and outputs, but of connectors. They define variables as interfaces between different components. When connectors are connected, instead of explicit assignments (*Input _{2} ∶= Output_{1}*), equations are generated (Kirchhoff's node rule) that are part of the system of equations. It is possible to connect any number of connectors to any number of components.

The system of equations can then be brought into a causal relationship by symbolic transformation and solved by a solver. This process is automated in the background in Modelica and the user is not aware of it. Since at the highest level of modeling there is no clear causal relationship between the variables, this approach is also called **acausal (non-causal)** modeling.

Signal flow-based modeling in the Matlab extension Simulink is particularly suitable for modeling systems where the causal relationships are unambiguous and do not change, e.g. controllers or systems based on signals. These can be adopted directly, giving the user a high degree of control. This is not possible with equation-based models, since the transfer to the causal relationship is automated and can lead to undesirable interpretations.

In contrast to signal flow-based modeling, equation-based modeling with Modelica is particularly suitable for physical systems. These are often better described as general mathematical relationships between different quantities (e.g. energy balance). Their solution order depends on the particular interconnection without changing the basic equations themselves. For signal flow-based modeling, such systems would first have to be transformed by the user into a connection with explicit assignment between inputs and outputs. This transfer can be costly for the user and involves some sources of error.

A simple example will illustrate to the user the differences between Modelica and Simulink when modeling physical systems. The goal is to simulate the time-varying temperature of a hot steel ball at constant ambient temperature.

Simplified, the example can be represented as a **thermal capacitance** with the time-dependent temperature (T_{C}), releasing a **heat flux **(Q_{flow}) to the ambient air (T_{L}). The two physical phenomena, the temperature change of a thermal capacity and the convective heat transfer, can be described by the following equations:

Temperature change of a capacity: $${Q_{flow}}(t) = C \cdot \frac{dT_C}{dt}$$

Heat transfer by convection: $${Q_{flow}}(t) = \alpha \cdot A \cdot (T_L(t) - T_C(t))$$

In Modelica, the two equations can each be implemented in their own components (resistance and capacity). The overall system then consists of the interconnected components and another for the temperature boundary condition (ambient air).

In the graphical representation, the individual components and thus the physical components (capacity and convection) of the model and their interrelationships can be seen at a glance. This is particularly advantageous for complex systems, as individual model components can be easily identified and modified. The graphical representation of a system model corresponds to physics and not to the signal flow.

To create the same model in Simulink, the two individual equations must first be combined into one model equation. This results in a 1st order linear differential equation with time constant T and gain K. Especially for physical systems, such as fluid flows, this process can be very time-consuming. The model equation is as follows:

$$y(t) + T \cdot \frac{dy}{dt} =K \cdot u(t) → T_C(t)+\frac{C}{\alpha \cdot A} \cdot \frac{dT_C}{dt}=T_L(t)$$

Modeling in Simulink is done by recreating the equation as a linkage of simple mathematical relationships (multiplication, addition, integration, ...).

The graphical representation is also much more abstract here, because unlike in Modelica, the components are not created on the basis of the individual physical components, but on the basis of the overall model equation. In addition, the individual quantities of the basic equations are summarized in the time constant T and the gain K, which makes later identification more difficult.

The resulting model equation and also the simulation result are the same, but the effort for the creation and especially for later adjustments and changes of the model is very different. Since in Modelica the basic equations are within the individual components and only the connectors are connected, the example shown can be changed with very little effort. In Simulink, when a model is changed, the model equation must be recreated, which can sometimes be very time-consuming for physical models. Therefore, for modeling physical systems, the equation-based approach in Modelica is preferable to the signal flow-based approach in Simulink in many cases.

Now we know the advantages and disadvantages of Modelica and Simulink and what they are suitable for, but can the two approaches also be combined with each other? Yes, with the Functional Mock-Up Interface (FMI) an open standard is available as an interface between dynamic simulation models, which both Simulink and all common Modelica tools support. FMI can be used to combine the advantages of different modeling approaches. For example, in a closed-loop system, the advantages of signal-flow-based modeling for the controller and equation-based modeling for the controlled system can be combined. The FMI interface can then be used to combine both submodels into an overall model and simulate them together.

Simulink has offered an alternative to Modelica to model physical systems for some time through: its* *Simscape toolbox. Like Modelica, Simscape uses an equation-based modeling approach, but unlike Modelica, Simscape is not an open-source modeling language, but a proprietary extension of Simulink and can only be used here.

Since Simscape is an extension of Simulink, Simscape can interact directly with Simulink without an additional interface like FMI, which brings some advantages. Simulink and Matlab, for example, are equipped/extendable with extensive and well-documented toolboxes in the area of optimization and data processing, and offer a much better user experience than Modelica in this area.

In contrast, due to its longer history, Modelica has a large user base with many specialized libraries for modeling physical systems. This gives Modelica the advantage over Simscape in that users can draw on existing models. An example of this is our TIL Suite, which provides comprehensive models for modeling cooling cycles, among other things.