See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/230688277

Hopsan NG, A C++ Implementation using the TLM Simulation Technique

Conference Paper · October 2010

CITATIONS READS

24 724

3 authors:

Björn Eriksson Peter Nordin

19 PUBLICATIONS   250 CITATIONS   
Linköping University
24 PUBLICATIONS   79 CITATIONS   
SEE PROFILE
SEE PROFILE

Petter Krus
Linköping University
286 PUBLICATIONS   1,258 CITATIONS   

SEE PROFILE

Some of the authors of this publication are also working on these related projects:

Conceptual Aircraft Design Laboratory, CADLAB View project

Open Cyber-Physical System Model-Driven Certified Development (OPENCPS) View project

All content following this page was uploaded by Peter Nordin on 12 May 2016.

The user has requested enhancement of the downloaded file.

 Hopsan NG, A C++ Implementation
using the TLM Simulation Technique
Björn Eriksson Peter Nordin Petter Krus

Dept. of Management and Engineering, Linköping University, Sweden,

(e-mail: bjorn.eriksson@liu.se, peter.nordin@liu.se, petter.krus@liu.se)

Abstract: The Hopsan simulation package, used primarily for hydro-mechanical simulation,
was first released in 1977. Modeling in Hopsan is based on a method using transmission line
modeling, TLM. In TLM, component models are decoupled from each other through time delays.
As components are decoupled and use distributed solvers, the simulation environment is suitable
for distributed simulations. No numerical errors are introduced at simulation time when using
TLM; all errors are related to modeling errors. This yields robust and fast simulations where
the size of the time step does not have to be adjusted to achieve a numerically stable simulation.
The distributive nature of TLM makes it convenient for use in multi-core approaches and high
speed simulations. The latest version of Hopsan was released in August 2002, but now the next
generation of this simulation package is being developed. This paper presents the development
version of Hopsan NG and discusses some of its features and possible uses.

Keywords: Hopsan, TLM, transmission lines, distributed modeling, distributed solvers

1. INTRODUCTION simulations. Hopsan has always been free of charge and

available to anyone.
Hopsan is a simulation package primarily intended for
Hopsan’s source code is rather complex and old-fashioned.
modeling and simulation of hydro-mechanical systems.
The non-GUI code, the core, is written in Fortran and
The development of the simulation package began at the
C while the GUI code is written in Visual Basic and
Division of Fluid and Mechanical Engineering Systems,
has been characterized by organic growth over several
Flumes, at Linköping University. Recently, the division
decades. The ageing code makes it difficult to maintain
changed its name to the Division of Fluid and Mechatronic
compatibility with other modern simulation tools. It is
Systems.
also an obstacle to further development. Because of the
The first version of Hopsan was released in 1977. From need for improvements and continued interest from users
the beginning, Hopsan used a central solver as most other wanting to simulate hydro-mechanical applications, work
simulation tools did, and still does. The Hopsan versions has begun on a new Hopsan version. The new version,
with a central solver were inspired by the CSMP/360 Hopsan NG, is still based on TLM, and retains all of the
software from IBM. In the early ’90s, transmission line benefits that come with this method.
modeling, TLM, was adopted. This method meant that
In an attempt to avoid the complexity and limitations
solvers could be distributed and also came with some
of the old Hopsan code-base, development of the new
other benefits, for example improved scalability and higher
version will primarily use open-source tools and only
numerical robustness. The initial TLM implementation
cross-platform supported languages. The new Hopsan
was influenced by Hytran, (McDonnell Douglas Corpo-
package is still divided into a core and a GUI. The core
ration, 1977). Hopsan had actually already been using
is written in standard C++ and the use of external third
distributed solvers in the late ’80s. In 1986, a type of
party dependencies is avoided. The GUI is also written in
predictor-corrector solver implementation was used. This
C++, but uses the Qt cross-platform application and UI
implementation allowed the modeled components to con-
framework, (Nokia Corporation, 2010). The Qt framework,
tain their own solvers. Information of adjacent system
released under the lgpl license, is easy to use, well
dynamics was passed to each solver to enhance numerical
documented, and offers plenty of features useful for GUI
properties. The TLM-method is, however, preferable to
creation.
the predictor-corrector method as it has a natural inter-
pretation of the time delays which break the dependence
between the components at each time step. 2. TRANSMISSION LINE MODELING

Hopsan has been successful ever since it was first released
in 1977. It has mainly served as a research tool at the
division of Fluid and Mechatronic Systems, but has also
been used by a number of companies for high performance
? This work is partly funded by the Swedish Foundation for Strategic
Research, ProViking program.
TLM, or bilateral delay line modeling as it was originally
referred to, can be traced back to the sixties, where it was
used for simulation of distributed systems, (Auslander,
1968). One advantage of the method is that individual
component models are isolated from each other so that
their equations can be solved independently. Depending
on the types of the components, some are suitable to
be modeled as bilateral transmission line elements. These
elements are used to connect the other components and
introduce a time delay that decouples them. The time
delay is a multiple of the time step and is used to simu-
late wave propagation. One example of such a component
is a long hydraulic pipe in which pressure waves travel
between the ends. Applications of TLM are modeling of
any kind of systems where time delays are present or
used to describe dynamics. TLM may not be suitable for
simulating systems of connected static components, for
instance electrical resistors. In these cases TLM introduce
unwanted dynamics through the time delays. Those sys-
tems are favourably modeled as lumped components that
are solved algebraically.
q1 Zc , T q2
p1 p2
Fig. 1. A hydraulic pipe with different pressures and flows
at each end describing a bilateral transmission line.
The properties of the pipe are parametrized by the
characteristic impedance, Zc , and the time delay, T .
A bilateral transmission line element from the hydraulic
field is illustrated in figure 1. Such a line can be described
by a four pole equation, (Viersma, 1980). If friction is ig-
nored and the equations are described in the time domain,
the relation between flow, q, pressure, p, characteristic
impedance, Zc , and the time delay, T , can be described
by equations 1 and 2, (Krus, 2005).
p1 (t) = p2 (t − T ) + Zc q1 (t) + Zc q2 (t − T ) (1)
p2 (t) = p1 (t − T ) + Zc q2 (t) + Zc q1 (t − T ) (2)
To collect the information that propagates from one end
to the other during each time step, the variables c1 and c2
are introduced. These are called wave variables. With these
variables, the pressure, flow, and characteristic impedance
at each end can be described by equations 3 to 6.
c1 = p2 (t − T ) + Zc q2 (t − T ) (3)
c2 = p1 (t − T ) + Zc q1 (t − T ) (4)
p1 (t) = c1 + Zc q1 (t) (5)
p2 (t) = c2 + Zc q2 (t) (6)
In models of systems where no real physical time delay
exists, the time delay required by this method introduces
a modeling error. This error is usually negligible if short
time steps are used. Detailed explanations of TLM and
attached modeling errors can be found in, among other
works, (Johns and O’Brien, 1980; Allen et al., 1987; Krus
et al., 1994, 1990).
3. MODELING IN HOPSAN
In the Hopsan package, TLM with isolated component
models is handled in a intuitive way. Individual models
usually represent a specific real physical component, for
example a hydraulic orifice or a mechanical spring. Com-
ponents in Hopsan are connected to each other in a way
similar to how they are used in reality. As an example,
consider a hydraulic pressure relief valve with an attached
pressure transducer as illustrated in figure 2. The physical
valve would have a high pressure input port and a low
pressure port (to the oil tank). It would also be possible to
attach a signal wire to the sensor to measure the pressure
in the valve. All of those connections are available in the
Hopsan model and can be connected. For the simulation
to work, the hydraulic connections must have been made,
but the use of the pressure sensor signal output is optional.
Fig. 2. A pressure relief valve with an attached pressure
transducer connected to a volume and pressure source
at one end and a hydraulic tank at the other. For the
simulation to work the hydraulic connections must
exist, but the signal from the sensor is optional.
To handle the decoupling feature inherent in TLM, com-
ponents transferring power are separated into two types:
the transmission line element components (capacitive or
inductive components) or lumped parameter components
(describing flow and effort variables as functions of wave-
and impedance variables). These types are called C-
and Q-components, respectively. TLM requires each Q-
component to be separated by a transmission line. That is,
a Q-component must be connected to C-components and
may not be directly connected to another Q-component.
There is a . . . C-Q-C-Q. . . pattern. To handle signals, (like
the value from a sensor) a third component type, S-
components, is introduced. These components can be con-
nected to each other or to other C- or Q-components and
do not need to be separated by transmission line elements.
Typical S-components are signal generators, controllers,
sensors, signal constants or arithmetic operators like plus,
minus or multiplication. The order in which the C- and
Q-components are simulated is important. In every time
step, the C-components read the flow and effort variables
from the previous time step and calculate the TLM spe-
cific wave variables and characteristic impedance. The Q-
components then calculate the new values for flow and ef-
fort variables based on the output from the C-components.
Continuous transfer functions are converted to discrete
filters at modeling time, before simulation starts, e.g. using
bilinear transform. Such transfer functions can be incorpo-
rated into component models. In this way, transformation
rather than a numerical solver is used to map dynamics
from continuous time to discrete time.
4. HOPSAN NG
The development of the next Hopsan generation, Hop-
san NG, is initially focused on re-implementation of basic
Hopsan features, as well as some new additions. The
Hopsan NG package comprises a core library and a GUI
application. The Hopsan GUI links in the core library at
runtime and allows the user to graphically create models
in a way similar to most other modern modeling and
simulation tools. The core contains all of the model code,
handles the simulations, and stores the results. The GUI
application makes it easy to create and simulate large
models and to analyze simulation results. As the core is a
library, it can be used in any “main program”. This means
that it is possible to run simulation models created in the
GUI using only the core and a small dedicated application.
This may be useful for simulation in embedded systems
where a graphical environment may not be present. It also
means that the core can be included in other applications
to simulate Hopsan models.

4.1 Hopsan Core

The Hopsan core is an object-oriented C++ library

containing the basic Hopsan classes and functions and
a set of basic component libraries. It also includes utility
function libraries that can be of use when users are writing
their own components. A main program, for instance
Hopsan GUI or some other application, loads the library
and instantiates an API class through which all core
communication is handled. The object-oriented approach
gives a natural containment of equations and variables
into independent objects for each implemented component
model.
When a simulation model is built, the core is accessed
through the API class to create components. Automatic
runtime creation (instantiation) of components is handled
by a class factory. It takes a string containing a unique
identifier type name for the desired component as its only
argument and returns a pointer to the new component.
Multiple components can be created and stored in any
way suitable, but to be able to connect them to each other,
they must first be added into a special component called
a system component.
The system component can be seen as the model root.
A system component can contain other ordinary compo-
nents, but also other system components. This makes it
possible to build models containing other models in a
hierarchic manner. A system component itself does not
contain any mathematical equations, but instead acts as a
container for the actual simulation code that is contained
within each ordinary component.
The system component has functions for adding, removing
and renaming its child components while maintaining
unique names among them. It also contains functions
for querying, connecting and disconnecting them. The
connection function ensures that erroneous connections
that would prevent a successful simulation can not be
made. Some examples of such errors are an attempt to
connect a signal into a hydraulic connection, to connect
two C-components directly to each other, or to connect
multiple “output signals” to each other. Figure 3 shows
the most important classes in Hopsan Core and their
inheritance.
Nodes and Ports When a connection between two com-
ponents is made a new node is created. A node is an object
Fig. 3. The main classes in Hopsan Core and their
inheritance.
in which the actual simulation variables reside. Compo-
nents read their data from nodes, process it and then re-
turn the results in every simulation step. Nodes can be seen
as an abstraction of the type of information exchanged
between components and they contain different variables
depending on what type of data they are intended to
represent. As the individual models mostly represent real
world physical components, the nodes represent the actual
physical interaction between these components. This could
for example be the medium, oil in hydraulics, flowing
through the system, or the contact between components
in the case of a mechanical system. Some examples of vari-
ables present in the currently existing nodes are shown in
table 1. Aside from variables describing physical properties
all nodes also contain the TLM-specific variables c, and
Zc . Additional node types can be added to describe the
interaction between other kinds of components.
Table 1. Examples of different types of data
nodes in the Hopsan Core and some of their
contained variables.
Node type Contents
HydraulicNode Pressure, Flow, Temperature
MechanicalNode Force, Velocity, Position
ElectricNode Voltage, Current
SignalNode Signal value
Components are connected to each other through so-called
ports. Each port has access to the actual data node that
has been created in a connection. If multiple ports are
connected to each other there will still only be one shared
data node. This means that multiple duplicate copies
of the same data are avoided. Figure 4 illustrates the
component, node and port relationship. When the model
developer specifies a port in a component, the required
node type for that port must also be decided. A hydraulic
port must be connected to another hydraulic port so
that the data exchange between them will be correct.
The required node type in each port is used to prevent
System Component (Main System)
System Component (Subsystem)
Component Port
System Port
Data Node
Fig. 4. This figure illustrates the relationship between
system components, components, ports, and nodes
within the Hopsan Core. The different components
and ports correspond to a real physical system while
the nodes only exist in the implementation and de-
scribe the interaction between components.
the model user from making erroneous connections. Such
connections are rejected by the connect function.
The ports can be given different types in order to restrict
how data can pass through them. There are currently four
types of ports; these are listed in table 2.
Table 2. Descriptions of the four different port
types used to control the node data access.
Port type Description
PowerPort The primary port type used for connections where
power is transferred. Data can be transferred in
two directions.
ReadPort This port can only read values from nodes. It
is typically used in sensor components, and as
inputs to signal components.
WritePort This port can only write values to nodes. It is
used as output from signal components.
SystemPort This port is initially “blank”. It can be used inside
subsystems as system inputs and outputs. It takes
the appearance of any internally connected port.
Equation Parameters Each model can have component-
specific parameters, used by the equations describing its
behavior. The component programmer can register inter-
nal variables as parameters. These parameters can later be
accessed through get and set functions at runtime.
Simulation Steps Hopsan uses fixed time steps for
simulation as this comes naturally from the TLM method.
It should be noted, though, that the use of variable time
steps is not ruled out by TLM as such. The use of variable
time steps with TLM in fluid power system simulation
was examined in (Jansson et al., 1992). As fixed time
steps are used, the code that handles the simulation
becomes very simple. All that the simulation loop has
to do is to call the simulateOneTimestep() method in
every subcomponent. However, care must be taken to
ensure that components of different types are simulated in
the correct order. C-components are simulated before Q-
components as described in section 3. Signal-components,
however, are simulated first so that signals from the
previous time step can be processed and acted upon at
the new time step. An example of the order of execution is
illustrated in figure 5. If a subcomponent happens to be a
subsystem, then all of its subcomponents will be simulated
Fig. 5. This figure illustrates a hydraulic system where a
proportional controller is used to maintain a certain
flow through a pipe by adjusting the supply pressure.
In one simulation step the signal components are run
first, in this case calculating the necessary control
signal to the pressure source. In the second step,
all C-components are simulated to decide the wave
variables and characteristic impedance. Finally, the
Q-components are simulated to determine the actual
hydraulic flow and pressure in each node at this time
step. The arrows show the direction in which data is
written to nodes (through ports) between components
in each step.
in the correct order within the current parent time step.
Subsystems can be given shorter time steps than their
parent system, for instance to resolve faster dynamics in
particular subsystems.
Logging As fixed time step simulation is used, data is
logged at the simulation steps. The amount of data points
to be saved can be selected in three ways:
(1) A skip factor against the simulation time step
(2) The total number of desired log samples
(3) The desired log sample time
Log sample times, however, will be rounded towards the
closest coming simulation time step. Logging for individual
nodes can also be disabled to conserve memory if neces-
sary.
User defined components The Hopsan Core comes
with a basic component library useful for building mod-
els of hydro-mechanical systems. It also includes signal
components that can be used to build in sensor feedback
and control capabilities in the model. For special appli-
cations and simulation of non-standard components, the
user must be able to create additional components. In
Hopsan NG, external components in shared libraries can
be dynamically linked in at runtime. Components must
be written in C++ and be compiled separately. In the
current development version, new components are created
by following a rather simplistic template. The user only
needs to specify a few things:
(1) The type of the component, whether to inherit the C, Real p2 "Right pressure";
Q or S component class equation
(2) A unique component type name, for instance MySpe- q2 = (p1-p2)/Rv "Orifice equation";
cialHydraulicOrifice q1 = -q2 "In flow eq. out flow";
(3) Local variables and which of them should be regis- end LamOrifice;
tered as component parameters and the volume
(4) The kind of ports that should be available and what
type of nodes they require model Volume
(5) What the component must do at the initial time-step parameter Real V=1e-3 "Volume";
to properly initialize the connected nodes parameter Real Be=1e-9 "Bulk modulus";
(6) The equations for simulating one time step Real q1 "Left flow";
(7) A line of code that registers the component with the Real q2 "Right flow";
global component class factory in the core Real p "Volume pressure";
Real p1 "Left pressure";
As the component creation follows a simple template, it Real p2 "Right pressure";
is possible to write an automatic component generator equation
to assist the user in the modeling process. A component q1-q2 = V/Be*der(p) "Continuity eq.";
generator for transforming a sub-set of Modelica code via p1 = p2 = p "Equal pressure";
Mathematica into Hopsan components exist, (Johansson end Volume;
and Krus, 2000). Based on this a Mathematica to Hop-
san NG component generator is already under develop- In Hopsan both flow and pressure have to be calculated
ment. (assigned). This is done by using equations (5) and (6).
The pseudo C++ code for the orifice is
4.2 Model example class LamOrifice
{
The modeling technique when using TLM differs from double Rv=1e9; //Flow resistance
the modeling techniques applied when using central solver
simulators. simulateOneTimestep()
When using a central solver, the modeled system is de- {
scribed by a set of coupled differential equations. The cen- readFromPortLeft(c1, Zc1);
tral solver uses the equation system to derive the different readFromPortRight(c2, Zc2);
states of the system with a numerical integration method.
q2 = (c1-c2)/(Rv+Zc1+Zc2); //Orifice eq.
TLM automatically makes the simulation models dis- q1 = -q2; //Inflow=outflow
tributed. The C-components break the dependence be- p2 = c2+q2*Zc2;
tween the different components in each time step. For p1 = c1+q1*Zc1;
example, the states in the right port of, for instance, a
pipe, are unaware of what is happening in the left port, writeToPortLeft(p1, q1);
and vice versa. This is due to the time delay caused by the writeToPortRight(p2, q2);
wave propagation. }
Here a laminar orifice model and a volume model will be }
shown as a modeling example using both Hopsan as well In the volume, the wave variables, c1 and c2 , and charac-
as Modelica for comparison. The equations describing the teristic impedances, Zc1 and Zc2 , are calculated (assigned).
orifice are The pseudo code for the volume is
p1 − p2
q2 = (7) class Volume
Rv
{
q1 = −q2 (8)
double V=1e-3; //Volume
and the volume double Be=1e-9; //Bulk modulus
V double Zc=Be/(V*Ts); //Char. impedance
q1 − q2 = ṗ (9)
βe
p1 = p2 = p (10) simulateOneTimestep()
where sub-index 1 means the left side of the components {
and sub-index 2 the right side. readFromPortLeft(p1, q1);
readFromPortRight(p2, q2);
Modelica is a acausal language which can interpret equa-
tions as they are. Hence, the Modelica model for the orifice //Wave equations
can be implemented as c1 = Delay(p2 + Zc*q2, Ts);
c2 = Delay(p1 + Zc*q1, Ts);
model LamOrifice
Zc1 = Zc;
parameter Real Rv=1e9 "Flow resistance";
Zc2 = Zc;
Real q1 "Left flow";
Real q2 "Right flow";
writeToPortLeft(c1, Zc1);
Real p1 "Left pressure";
 writeToPortRight(c2, Zc2); 4.4 Hopsan Core API
}
} The communication between Hopsan GUI and Hop-
(Ts in the code above is the simulation time step) san Core takes place trough a string based API class.
Each component within a system is identified by a unique
It can be seen in the pseudo code for Hopsan that the name and any interaction between the core and GUI ob-
causality is fixed. This feature comes from the nature of jects requires that this name is known. Setting and getting
TLM. Q-components (LamOrifice in this example) al- parameters or reading log-data is handled by transferring
ways calculate flow and effort variables and C-components scalars or C++ STL vectors. A schematic illustration
(Volume in this example) always calculate the wave vari- showing the relationship between the core, GUI and API
ables and characteristic impedance (which is often a con- is shown in figure 8.
stant parameter).
The C-components also decouple any dependencies be- 4.5 What is New in Hopsan NG
tween components in each time step due to their intro-
duction of time delays. The largest difference compared to the current Hopsan
version is that all component models are now written in
A major distinction between the two ways of modeling C++ and are pre-compiled before being added to a simula-
is how errors are introduced. The Modelica model is an tion system model. In earlier versions, models were written
exact model of an ideal world. Then, at runtime, the solver in Fortran and converted to C before compilation at
approximates the model by making it discrete. every simulation run. A modeling improvement is the pos-
However, with TLM the model itself contains the approx- sibility to easily create and reuse subsystems. Sub-models
imations. For example, the volume is approximated by can be created in the GUI, saved and later imported into
a transmission line with a physical length. This makes other systems. The GUI application itself is more coherent
TLM a robust method because each component has it own and contains all Hopsan tools within one application.
solver which solves the model without numerical errors at Screen-shots showing the same hydro-mechanical model in
runtime. The simulation is therefore predictable in perfor- the current and new version of Hopsan GUI are shown
mance. in figures 6 and 7.
In the Modelica example, the accuracy is given by the
numerical integration method. Generally, the smaller the
time step the higher the accuracy and the smaller the
calculation errors. In Hopsan, the time step is set by the
“length” of the volume. So, by decreasing the time step the
“length” of the volume model will approach the “length”
of the ideal volume, zero. However, in reality all volumes
actually have a length. Therefore, TLM is a feasible choice
as a modeling method for physical systems. Also, since
it runs at fixed time steps with predictable performance
and computational cost, it is well suited for real-time
and high-demand simulations, for example hardware-in-
the-loop (hwil) simulations and system optimization.
Fig. 6. A screen-shot of the latest Hopsan version while
simulating a typical fluid power system.
4.3 Hopsan GUI

The Hopsan GUI is based on the Qt cross-platform

application and UI framework. The cross-platform support
in Qt means that the drawback with the current Hopsan
version, which is only available for Windows, is avoided.
The GUI itself will not be covered in detail in this paper.
It basically consists of graphical representations of the
most important core objects, components, and system
components. These can be moved in a drag-and-drop
manner and connected to each other with lines. A screen-
shot of an example model and the Hopsan GUI interface
is shown in figure 7. The user interface and the possible
actions are similar to those in the current Hopsan version.
The look and feel of the GUI application are also similar
to those of many other modern graphical simulation tools.
Fig. 7. A screen-shot from Hopsan NG simulating a
The graphical appearance of the modeled components
typical fluid power system. Component libraries are
are loaded from external plain text files and scalable
visible to the left and the main workspace and mes-
vector graphics (SVG). The actual model code, however,
sage window to the right.
is handled by the Hopsan Core library.
Fig. 8. A schematic diagram of the class structure for the model components in Hopsan GUI and Hopsan Core. The
GUI has representations of the most important core objects and communicates through a string-based API class.
5. RELATED SIMULATION SOFTWARE
There are a number of different software programs avail-
able in the hydro-mechanical field. Most of them rely
on central solver techniques. Power ports are often used
for connections between different components within a
system. This is convenient because the modeled systems
represent physical systems which communicate through
power transmission.
An exception from the acausal approach is Matlab/-
SimulinkTM which is a general simulation program where
causal equation assignments are implemented graphically,
(Unknown, 2004). Matlab dates back to the mid-1970s.
There is also a fluid-power library using powerports avail-
able for Matlab/Simulink called SimHydraulics.
Easy5 is another fluid power simulation program. Easy5
supports causal powerports. The components are grouped
into p or q components. Components have to be con-
nected in a . . . p-q-p. . . manner. Then the p-components
calculate pressure and q-components calculate flow. This
simulation package has been developed by the Boeing air-
craft company and is contemporary with Hopsan and has
been around since 1976, (Unknown, 2001). Other similar
simulation programs specifically for fluid power systems
are DSHplus, (Unknown, 2003), and AMESim, (Unknown,
2000). Both use the technique of causal powerports similar
to Easy5.
A program that uses acausal powerports is Dymola, (Un-
known, 2006). This is achieved by using the Modelica
language. It is an interesting approach where the user
inserts equations and the compiler sorts the equations
and transforms them into executable assignments. One
weakness of this approach is that it is a challenge to trace
errors in models. The reason is that the compiler flattens
out the equation system and makes it difficult to recognise
the original equations.
In Hopsan, causal powerports are natural. TLM itself
works with powerports where the information direction
is given, C-components assign wave variables, c, and
impedance, Zc , while Q-components assign pressure, p,
and flow, q.
6. DISCUSSION AND FURTHER WORK
Pre-compiled models are beneficial in large systems since
time-consuming recompilation whenever changes are made
is avoided. This will be convenient if component selection
optimization of a system is performed. That is, optimiza-
tion where not only component parameters but the actual
selection of components is part of the optimization. In such
cases a very large number of different components with
different parameter sets may be available for evaluation in
different combinations. By writing a script this optimiza-
tion can be automated. The complete simulation model
will not need to recompile every time a new combination
is tested. Already tested components are simply discon-
nected and the new ones connected in their place. In the
current Hopsan version, parameter optimization scripting
features are available. The intention is to eventually make
these kinds of scripting features available in Hopsan NG
also.
Hopsan NG is not just meant as a stand-alone desktop
simulation program. The fact that the core and GUI are
separate means that models can be run not only within
the GUI application but in other applications too. When
studying the code in the Hopsan core it soon becomes
evident that the majority of code is concentrated within
the component classes. This means that any external com-
ponent models that inherit from these classes actually in a
way contains almost the entire core. This is very suitable
when the distributive model nature of TLM is to be used.
In fact the intention is to make it possible to compile indi-
vidual components or individual systems of components as
stand-alone objects including a miniature Hopsan Core.
By providing these objects with the appropriate interfaces
they may be used together with other simulation software
for co-simulation and in embedded applications. The dis-
tributed nature of the models also makes them suitable for
multi-core parallel simulations. This has previously been
looked at in (Krus et al., 1990), where different compo-
nents were simulated in different processes and in (Burton
et al., 1994). Utilizing the parallel processing capabilities
on modern multi-core hardware will be examined further.
Finally, maintaining the object-oriented component-based
structure in the executable models is an important benefit
when it comes to debugging models.
7. CONCLUSIONS
This paper shows how TLM can be implemented in a
modern way using the widely known C++ language and
the Qt GUI framework.
Large and/or fixed time steps can be taken without jeop-
ardizing the numerical stability due to TLM. Hopsan NG
is therefore suitable for high-speed simulations which are
needed in real-time applications and simulation in opti-
mization loops.
The object-oriented implementation of Hopsan NG maps
the physical world. This makes it intuitive for the user to
implement their own custom components.
In Hopsan NG, TLM makes it possible to use pre-
compiled models. This makes the simulation faster as no
compilation is needed before it begins. It also enables
models to be shared in a binary format. This is an
advantage for industry, which often deals with propriety
simulation models.
The distributed way of modeling in Hopsan NG enables
verification and testing of sub-models independently of
each other. Verified sub-models will probably also work
together in a system because of the distributed solvers.
Errors are easier to trace in TLM models compared to,
for instance, Modelica models. In Hopsan NG there is
no equation flattening that obstructs the possibility to
recognize the original equations.
Unknown (2000). Amesim, a simulation program for
engineering applications. International Journal of Fluid
Power, 1, 63–67. (Ed.) M. Ivantysynova.
Unknown (2001). easy5 - software for virtual system pro-
totyping, simulation and control. International Journal
of Fluid Power, 2, 53–59. (Ed.) M. Ivantysynova.
Unknown (2003). Dshplus - competence in the simulation
of fluid power systems. International Journal of Fluid
Power, 4. (Ed.) M. Ivantysynova.
Unknown (2004). Modelling and simulation of fluid power
systems with matlab/simulinkTM . International Journal
of Fluid Power, 5. (Ed.) M. Ivantysynova.
Unknown (2006). Dymola and the component libraries
hylib and pneulib. International Journal of Fluid Power,
7, 67–77. (Ed.) M. Ivantysynova.
Viersma, T.J. (1980). Analysis, Synthesis and Design
of Hydraulic Servosystems and Pipelines. Elsevier Sci-
entific Publishing Company, Amsterdam, The Nether-
lands.

REFERENCES
Allen, R., Mallik, A., and Johns, P. (1987). Numerical
results for the symmetrical condensed tlm node. Mi-
crowave Theory and Techniques, IEEE Transactions on,
35(4), 378 – 382.
Auslander, D.M. (1968). Distributed system simulation
with bilateral delay-line models. Journal of Basic
Engineering, 90, 195–200.
Burton, J.D., Edge, K.A., and Burrows, C.R. (1994).
Modeling requirements for the parallel simulation of
hydraulic systems. Journal of Dynamic Systems, Mea-
surement, and Control, 116, 137–145.
Jansson, A., Krus, P., and Palmberg, J.O. (1992). Variable
time step size applied to simulation of fluid power
systems using transmission line elements. In The Fifth
Bath International Fluid Power Workshop.
Johansson, B. and Krus, P. (2000). Modelica in a dis-
tributed environment using transmission line modelling.
In Modelica Workshop 2000 Proceedings, pp. 193–198.
Johns, P.B. and O’Brien, M. (1980). Use of the
transmission-line modelling (t.l.m.) method to solve
non- linear lumped networks. The Radio and Electronic
Engineer, 50, 59–70.
Krus, P. (2005). Robust system modelling using bi-lateral
deley lines. In Simsafe. Linköping, Sweden.
Krus, P., Jansson, A., Palmberg, J.O., and Weddfelt,
K. (1990). Distributed simulation of hydromechanical
systems. In Proceedings of the Third Bath International
Fluid Power Workshop.
Krus, P., Weddfelt, K., and Palmberg, J.O. (1994). Fast
pipeline models for simulation of hydraulic systems.
Journal of Dynamic Systems, Measurement and Con-
trol, 116, 132–136.
McDonnell Douglas Corporation (1977). Aircraft hy-
draulic system dynamic analysis. Technical report, Air
Force Aero Propulsion Laboratory, Ohio, USA.
Nokia Corporation (2010). Qt - Cross-platform application
and UI framework. URL http://qt.nokia.com/.

View publication stats