Hardware-in-the-Loop Simulation of Aircraft Actuator: Robert Braun
Hardware-in-the-Loop Simulation of Aircraft Actuator: Robert Braun
Hardware-in-the-Loop Simulation of Aircraft Actuator: Robert Braun
Robert Braun
Fluid and Mechanical Engineering Systems
Degree Project
Department of Management and Engineering
LIU-IEI-TEK-A–08/00674–SE
Master Thesis
I would like to express my gratitude to LiU for making this project possible
and for giving me the opportunity to complete my studies in an interesting
and rewarding way. During this project I have acquired much experience
and greatly increased my knowledge in my field of specialization.
I would like to thank the staff at IEI who have helped me out through the
project, especially my supervisor Professor Petter Krus.
August 2009
Linköping, Sweden
Robert Braun
Contents
1 Introduction 9
1.1 Purpose . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3 Delimitations . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2 System Description 13
2.1 Hydraulic Supply System . . . . . . . . . . . . . . . . . . . . 15
2.2 Aircraft Control Hydraulic System . . . . . . . . . . . . . . . 15
2.3 Load Hydraulic System . . . . . . . . . . . . . . . . . . . . . 16
2.4 Measurement Equipment . . . . . . . . . . . . . . . . . . . . . 17
2.5 Control System . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.6 Electronic Hardware . . . . . . . . . . . . . . . . . . . . . . . 19
2.7 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7.1 HOPSAN . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.7.2 Mathematica . . . . . . . . . . . . . . . . . . . . . . . 19
2.7.3 LabVIEW . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.7.4 Matlab and Simulink . . . . . . . . . . . . . . . . . . . 20
2.7.5 Microsoft Visual C++ 2008 Express Edition . . . . . 20
3 Work Progress 21
3.1 Gathering Knowledge About the System . . . . . . . . . . . . 21
3.2 Creating a Simulation Model in HOPSAN . . . . . . . . . . . 21
3.3 Building a Rudder Block for HOPSAN . . . . . . . . . . . . . 21
3.4 Exporting Matlab Models to LabVIEW . . . . . . . . . . . . 23
3.5 Exporting HOPSAN Models to LabVIEW . . . . . . . . . . . 23
3.5.1 Requirements on the Code Syntax . . . . . . . . . . . 23
3.5.2 Translation of Hopsan Libraries to C . . . . . . . . . . 24
3.5.3 Importing Models to LabVIEW with Code Interface
Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5.4 Importing Models to LabVIEW from Shared Libraries 25
3.5.5 Optimizing the Shared Libraries . . . . . . . . . . . . 26
3.5.6 Setting up the LabVIEW Block Diagram . . . . . . . 26
4 Results 29
4.1 Rudder Block for Hopsan and LabVIEW . . . . . . . . . . . . 29
4.2 Translated Code Structure . . . . . . . . . . . . . . . . . . . . 31
4.3 Code Structure in Shared Libraries . . . . . . . . . . . . . . . 33
5
5 Analysis 35
5.1 Analysis of the Rudder Block . . . . . . . . . . . . . . . . . . 35
5.2 Comparison Between Hopsan and LabVIEW . . . . . . . . . 38
5.3 Examination of Simulation Performance . . . . . . . . . . . . 41
6 Discussion 43
6.1 Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.2 Sources of Error . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.3 Differences Between Hopsan and LabVIEW . . . . . . . . . . 45
6.4 Recommendation for Next Version of Hopsan . . . . . . . . . 46
6.5 Recommendations for Continued Work . . . . . . . . . . . . . 47
6.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
6
Nomenclature
Abbreviations
HWiL Hardware-in-the-Loop
AC Aircraft Control
LS Load Simulation
DV Directional Valve
Denotations
Ap,e AC Elevator Cylinders Piston Area [m2 ]
Ap,e,L LS Elevator Cylinders Piston Area [m2 ]
Ap,r AC Rudder Cylinders Piston Area [m2 ]
Ap,r,L LS Rudder Cylinder Piston Area [m2 ]
Bp,e AC Elevator Cylinders Viscous Damping [Ns/m]
Bp,e,L LS Elevator Cylinders Viscous Damping [Ns/m]
Bp,r AC Rudder Cylinders Viscous Damping [Ns/m]
Cip,e AC Elevator Cylinders Internal Leakage Coeff. [m3 /sPa]
Cip,r AC Rudder Cylinders Internal Leakage Coeff. [m3 /sPa]
Cip,r,L LS Rudder Cylinder Internal Leakage Coeff. [m3 /sPa]
Cq AC DV Flow Gain [m3 /Vs]
Cq,L LS DV Flow Gain [m3 /Vs]
Dv AC DV Slide Diameter [m]
Dv,L LS DV Slide Diameter [m]
Je Elevator Moment of Inertia of Elevator [kgm2 ]
Jr Moment of Inertia of Rudder [kgm2 ]
K AC DV Orifice to Circumference Ratio [%]
Kce,L LS DV Effective Pressure-to-Flow Coefficient [m3 /sPa]
Ki,L LS Integrating Gain [Vs/m]
Kp AC Proportional Gain [V/m]
Kp,L LS Proportional Gain [V/m]
LA,e LA from Elevator Axis to Airplane Cylinders [m]
LA,r LA from Rudder Axis to Airplane Cylinders [m]
LL,e LA from Elevator Axis to Load Cylinders [m]
LL,r LA from Rudder Axis to Load Cylinder [m]
LM,e LA from Elevator Axis to Center of Mass [m]
Me Mass of Elevator [kg]
Mr Mass of Rudder [kg]
pl0 AC Work Point System Pressure [bar]
pl0,L LS Work Point System Pressure [bar]
ps AC Maximum System Pressure [bar]
ps,L LS Maximum System Pressure [bar]
7
Sp,e AC Elevator Cylinders Maximum Stroke [m]
Sp,r AC Rudder Cylinders Maximum Stroke [m]
Sp,r,L LS Rudder Cylinder Maximum Stroke [m]
Sv AC DV Saturation [?]
Vt,L LS Elevator Cylinders Oil Volume [m3 ]
w AC DV Area Gradient [m]
wL LS DV Area Gradient [m]
xv,0,e AC DV Working Point Spool Stroke (elevators) [m]
xv,0,r AC DV Working Point Spool Stroke (rudder) [m]
xv,max,e AC DV Maximum Spool Stroke (elevators) [m]
xv,max,r AC DV Maximum Spool Stroke (rudder) [m]
βe AC System Oil Bulk Modulus [Pa]
βe,L LS System Oil Bulk Modulus [Pa]
ρ AC System Oil Density [kg/m2 ]
ρL LS System Oil Density [kg/m2 ]
ω1 AC Filter Cutoff Frequency [Hz]
ω2 AC System Cutoff Frequency [Hz]
ω3 AC Valve Cutoff Frequency [Hz]
ωv,L LS DV Bandwidth [Hz]
8
1 Introduction
The future aircraft market will put higher demands on more advanced and
complex systems, but also on faster and more cost efficient development.
In order to achieve this, advanced simulation tools will play a significant, if
not to say crucial, role. This thesis work deals with the possibility of using
an already existing hydraulic test rig in future aeronautic development and
research.
1.1 Purpose
The purpose of this thesis work is to investigate the possibilities of using a
hydraulic aircraft test rig for hardware-in-the-loop simulations in aeronau-
tics research. The primary focus is on how to make use of modern computer
systems for this purpose in the most satisfactory way. Software and hard-
ware must be chosen and investigated. One of the most important demands
is the possibility of importing already existing models and controllers. The
results are supposed to be examined by comparing the hardware-in-the-loop
simulation results with a conventional computer simulation.
1.2 Background
The demand for this project emerged from a large international research ini-
tiative from 59 European aeronautics organizations called Crescendo, mean-
ing ”Collaborative & Robust Engineering using Simulation Capability En-
abling Next Design Optimization”. The purpose of this project is to fa-
cilitate for European aircraft manufacturers to develop complex systems
in more cost effective ways and with shorter lead times, by using more ad-
vanced and thoroughgoing simulation systems. The test rig in the university
laboratory has the potential to become a powerful tool in this context.
Saab Aerospace ceased production of the Saab 2000 in 1999. Parts of
the hardware-in-the-loop test rig (called Ironbird ), namely the tail control
surfaces and their actuators, were then donated to LiTH from Saab in 2000.
In a student project in 2001 the aircraft hydraulics and the load hydraulics
were mathematically decoupled by a computer based control system, to
avoid undesirable interference between the rudder control and the simulated
external load forces. This feature has not been confirmed by practical test-
ings in a satisfactory way, due to defects in the hydraulic supply system.
(Avellan-Hultman et al., 2001)
9
Figure 1: The Ironbird testrig was donated to LiTH from Saab in 2000.
10
Figure 2: A hardware-in-the-loop simulation contains both software and
hardware components.
1.3 Delimitations
Due to lack of time and reconstruction issues, no physical experiments have
been conducted. The resulting documentation and programming solutions
from this project should however make this a both practicable and interest-
ing continuation in the future.
The test rig does only contain the tail parts of the aircraft. This means
that it lacks the ability of simulating for example the ailerons (control sur-
faces on the wings) and the landing gear. Much of the information in this
report can however be of great use even for other, more complex, test rigs.
This applies especially for the descriptions and solutions of software and
11
programming issues.
In a real flight situation the pitch and roll of the aircraft will affect the
influence of gravity on the elevators and the rudder. Gravitational forces are
included in the models of this project, but are assumed to have a constant
angle relative to the aircraft. The lever arms vary with the angle of the
respective control surface, but not with the pitch or roll of the aircraft. The
rudder is thereby assumed not to be affected by gravity at all. The reason
for this is that the test rig is fixed to the floor and unable to simulate pitch
and roll. Because the computer simulation is to be compared with the HWiL
simulation, it is desirable to include these limitations there as well.
Although many good software environments exist on the markets, it
would be too time consuming to investigate them all. The primary focus of
the programming part of this project has been to translate Hopsan models
so that they can be imported in LabVIEW, and to some extent to investigate
the possibility of importing Simulink models in LabVIEW.
12
2 System Description
The Ironbird in the university laboratory simulates the tail parts of the Saab
2000 turboprop airplane. The tail consists of two horizontal stabilizers and
one vertical. Each of these has the ability to control the airflow, and thereby
the movement of the airplane. This is achieved by adjusting the angle of a
control surface at the end of the stabilizer. These are called elevators for
the horizontal stabilizers and rudder for the vertical one, see figure 3.
13
Figure 4: The orientation of an aircraft can be described by pitch, roll and
yaw. Image: http://quest.arc.nasa.gov
Figure 5: The elevator is controlled by two aircraft cylinders while the air
forces are simulated by one external cylinder. The springs represent the
stiffness of the structure.
14
2.1 Hydraulic Supply System
One of the most crucial aspects in airborne systems is redundancy. Dur-
ing flight, even minor complications can have devastating consequences and
must be avoided at all costs. For this reason, the Saab 2000 aircraft contains
three separate hydraulic systems. If two of these should fail, the pilot can
still maneuver the airplane with the third. Each of these systems are also
supplied by two pumps, one motor-driven and one electric-driven. Each of
these pumps can supply the system regardless of the second one. Only two
of these systems affect the tail part, i.e. the rudder and the elevators, of
the airplane. These are included in the Ironbird test rig. Redundancy is
obviously less important in a laboratory environment. To reduce cost and
space requirements, each system is only supplied by one single pump. These
are driven by hydraulic motors from the same pump system as the load hy-
draulics. The aircraft pumps are of in-line type with nine pistons and have
variable displacement with constant pressure feedback. Each of these sys-
tems also contains an accumulator. The main purpose of these is to reduce
pressure peaks and pulsations, but they shall also provide reserve power for
a short period of time if the pump should stop working. (Andersson and
Herres, 1997)
The load simulation system is supplied by its own hydraulic supply sys-
tem, similar to the ones used for the airplane actuators. In order to achieve
satisfactory results and avoid interference during the hardware-in-the-loop
simulation, the bandwidth of the load simulation system must be at least
ten times higher than that of the airplane system (Avellan-Hultman et al.,
2001).
15
the elevator or rudder to its neutral position. This will prevent the rudder
or elevator from flickering after the cylinders have been feathered, facili-
tating for the pilot to maneuver the airplane with the remaining rudders.
(Avellan-Hultman et al., 2001)
The cylinders are supplied by a constant pressure system. Undesirable
dynamic variations in pressure are reduced by an accumulator and the sys-
tem is protected from pressure peaks by a relief valve, see figure 6. The
piston movement is controlled by a directional valve and a position feed-
back loop. The damping of the system is increased by a dynamic pressure
feedback loop.
16
Figure 7: The load simulation hydraulic actuators are supplied by a constant
pressure system. The valve is controlled by a PI-controller.
17
simulation servo system.
Angle sensors are installed at all control surfaces. They are capable of
measuring ± 30°and have a scale factor of 125 mV/°. They are used as
feedback signal in the aircraft servo system position feedback loop. See
appendix B for a detailed list of measurement equipment.
Figure 8: The control system includes a decoupling link, to make the simu-
lated load forces independent of the airplane hydraulics.
18
also includes a block for prediction of the rudder angle using the reference
signal.
2.7 Software
This project includes simulation of fluid mechanics, creation of specific math-
ematical algorithms, translation from different programming languages as
well as control and measurement of physical systems in a laboratory envi-
ronment. This requires several different computer tools. The most crucial
ones are described in this section.
2.7.1 HOPSAN
HOPSAN is a tool for simulation of hydro mechanical systems. It was first
developed in 1977 at the Department of Mechanical Engineering (IKP) at
Linköping University. It supports co-simulation with Matlab and Simulink,
as well as creation of additional components either manually using Fortran
or through an automated process using Mathematica. Version 1.4, which
has been used in this project, uses the LCC-Win32 compiler.
2.7.2 Mathematica
Mathematica is a C-based computational software tool developed in 1988 by
mathematician Stephen Wolfram, founder of Wolfram Research. Features
include a programming language, libraries of mathematical functions, equa-
tion solver algorithms and visualization tools. In this project version 6.0,
developed in 2006, is used.
19
2.7.3 LabVIEW
LabVIEW is an abbreviation for Laboratory Virtual Instrumentation Engi-
neering Workbench. It is a visual programming development environment
primarily designed for connecting signals from physical components with
computer software. It is capable of various tasks such as data acquisition,
instrument control, signal processing, embedded design and industrial au-
tomation. It is created and marketed by National Instruments, and the
latest version is 8.6.1, released in 2009. Although originally designed for
Macintosh computers, it is now available for most operating systems such
as Windows, Unix and Linux.
20
3 Work Progress
The work of this project mainly consists of two parts; describing the test rig
and connecting different software environments. All relevant data possible
to find about the rig has been gathered. This has in turn been used to create
a simulation model. A folder of data sheets has also been put together, to
facilitate future use of the rig. Most Hopsan components have then been
rewritten in C code and imported to LabVIEW. The possibility of import-
ing Simulink models has also been investigated, although not practically
implemented.
21
Figure 9: A special rudder block had to be created in order to simulate the
system in HOPSAN.
Figure 10: A free body diagram of the rudder will give its equation of motion.
Now Euler’s second law with viscous damping finally yields equation 3.1.
X
Ig θ̈ + δ θ̇ = (Fi Li (θ)) + M gLM (θ) (3.1)
i = AC1, AC2, LS
22
3.4 Exporting Matlab Models to LabVIEW
Simulink models can be imported directly to LabVIEW from a small .dll
file by using the Simulation Interface Toolkit (Nat, 2003b). This is a simple
and reliable, albeit limited and costly, procedure. For instance, the Simulink
model must not contain blocks from certain toolkits, such as SimMechanics.
The required LabVIEW toolkit also has to be purchased separately, and is
rather expensive.
An alternative solution is to export everything from Simulink to one .dll-
file, containing the entire model in C-code. This can be quite tricky, but
provides a reliable and much more compatible result. Because the .dll-file
contains everything of interest, it makes the model independent of Matlab
and Simulink and it can be used in practically any advanced simulation
environment. The independence from external software also allows real-time
simulations in a target computer. (Ek, 2006)
A third option, similar to the .dll-method, is to export the model as C
code, and then compile and import this directly into LabVIEW. This allows
manual adjustments of the code after it has been exported. This method and
its requirements are somewhat similar to the ones for HOPSAN mentioned
in section 3.5.
23
Many functions in Hopsan require multiple return values. This is not sup-
ported by C/C++, but can be achieved by using references to the variables
instead of the actual variables as parameters. This is achieved by putting
an & symbol at the beginning of the parameter. This means a function call
can look like this:
...
int func1 (* a , *b , * c )
{
*c = *a + *b;
return 0;
}
This means that all the parameters will be updated according to how they
are affected in the function. In this case the value of *c will be returned
even though the function itself does not return anything useful.
Importing C code to LabVIEW can be achieved in two ways. One can
either use a Code Interface Node (CIN) block, which will include the exter-
nal code entirely into the model file, or a Call Library Function (CLF) block
which calls an external shared library file (.dll). The first method is more
complicated and outdated, even though it provides some interesting features
such as initialization routines. The .dll method is simpler in general, and
makes it possible to place each component in a different LabVIEW block.
This will make the block diagram more understandable, and can possibly en-
able multi-core features. When working with CIN blocks LabVIEW always
passes pointers instead of values, meaning all variables must be preceded by
an asterisk (*). This can be chosen arbitrarily for each variable when using
a CLF. (Nat, 2003a)
Both of these methods have been examined in this project.
24
much manual clean-up work. First of all, the exported files are poorly struc-
tured. They include calls to several external functions that LabVIEW does
not know of, and most types and classes are renamed to match the Fortran
standard. Furthermore they include poor programming solutions such as
global variables, goto-functions and complete enumerations. These prob-
lems were solved by rewriting much of the translated code by hand.
25
/* Call Library source file */
26
block. The simulation time can then be obtained by multiplying the time
step with the number of iterations, which is provided by the Loop Iteration
block. The time and time step signals must then be fed into each Hopsan
block as well (except the simple ones, such as line terminations). This gives
the numerical algorithms the necessary information in order to carry out
continuous mathematical operations such as integrations and filtering. An
alternative approach could be to only provide the blocks with the time step
and then let each component calculate the time iteratively. This would
allow a cleaner block diagram, at the cost of an additional potential source
of error. Something else to notice in the figure is the stop button, which
is used to reset simulation time to zero. This does not really do anything
useful in this case, but LabVIEW demands it to be there.
An alternative approach to the while loop could be a timed loop. This
would provide a similar result, but offers more advanced options such as
priority settings and manual selection of processors (Ek, 2006).
While Loop
Figure 11: The Hopsan functions exported to LabVIEW must receive the
simulation time and the time step.
27
variables and impedances. These components are called Q type and C type,
respectively. In a block diagram, components must always be connected
so that a Q type component is connected to a C type component in each
node. In LabVIEW this will require a feedback loop between the blocks.
The feedback signal will automatically be given a Feedback Node block with
an Initializer Terminal. The function of a Feedback Node is that it will
store the signal value from the last simulation step, so that it can be used
as an input signal at the next step. The Initializer Terminal can be used to
provide a value for the first simulation step, when no value from the previous
step exists. This is however not necessary in most cases. See figure 12.
When working with shared libraries, it is crucial that the function call in
LabVIEW has exactly the same name, number of parameters and data types
as the one in the .dll file. One single wrong symbol may result in a program
crash. The names of the parameters do not matter, but it is obviously most
convenient to choose the correct ones. Using too many parameters will not
crash the simulation either. This is important to have in mind, since an
extra parameter can cause extensive problems without producing any error
messages. It is also important to use different .dll-files for each component,
even if they represent the same type of component. If two components use
the same .dll-file, they will also use the same local variables. This can cause
serious problems, such as division by zero or variables increasing to infinity.
28
When restarting a simulation it is necessary to first close and then reload
the model in LabVIEW. Although there is a Reinitialize Values to Default
function, it will not reset the local variables declared in the memory by each
.dll-file. These will keep their final values from the last simulation, possibly
causing errors in the new simulation.
4 Results
The results of this thesis work consist of a folder of data sheets and pa-
rameters for the test rig, a computer model of the rudder for Hopsan and
LabVIEW, a Hopsan model of the test rig hydraulic system and translations
of most Hopsan components so that they can be imported by LabVIEW.
Figure 13: The attachment of a rudder with its actuators. The geometry
can be described by four measurable lengths.
29
Constants
The necessary constants consists of the distances a, b, c and d for each
cylinder (see figure). Mass, moment of inertia, torsional spring constant,
viscous damping and lever arm between the attachment and the center of
gravity in the neutral position must also be provided. Finally the minimum
and maximum angle for the rudder as well as minimum and maximum stroke
for each cylinder are also required.
Input Parameters
The required input parameters consist of the wave variables and the char-
acteristic impedances for each cylinder.
Output Parameters
The rudder block returns the angle and angular velocity, as well as the lever
arms of each cylinder. The resulting force from each cylinder and their
respective positions are also returned.
30
4.2 Translated Code Structure
The code was at first translated with the idea of importing complete models
using Code Interface Nodes in mind. For this purpose the entire simulation
system was translated, although somewhat simplified.
The resulting translation of the Hopsan source code has a similar struc-
ture as the original code to a certain degree, but has also been modified at
certain points to be more flexible and to make the functions more indepen-
dent of each other. The Fortran code uses global variables and functions to
a great extent. This has now been changed so that each function is aware
only of its input signals, output signals and local variables. Another change
is that the nodes are now represented by a node class which is common
for all node types. The node class is a structure containing a type variable
which determines its type (hydraulic, mechanical, rotational etcetera) and a
node number variable. The variables of the node are then arranged in sep-
arated substructures. Which one of these to use is decided by the contents
of the type variable. Another introduced variable is Sim stat. This is a
structure where all information about the status of the simulation is stored,
for example initialization state, time step and error control. See figure 14.
Figure 14: The nodes are stored in node type structures, and the simulation
status in a sim stat type structure.
31
The nodes are stored in an array and new nodes are added to the array by a
function called addNode. The program is then executed by a main function,
which calls subroutines from two libraries: Components and Arithmetics.
These contain all the components used in the simulation. Each component
is assigned a unique component number to differ them from each other.
The component subroutines take the nodes and the Sim stat variable as
both input and output parameters, and its constant parameters as input
values. The arithmetic functions works in a similar way, but do not affect the
nodes or the simulation status. These libraries do require some subroutines
themselves, for example numerical algorithms and filters. For this reason a
third Auxiliary Functions library is also included. See figure 15.
Figure 15: The code includes a main function, a component library, a library
of arithmetic functions and a library of auxiliary functions.
The components have been redesign so that all constants are now passed as
parameters from the main routine. This eliminates the use of external data
files, in order to facilitate real time applications. The downside is that the
main routine must keep track of all constants for each component, making
32
the file less readable. Each component has been structured in the following
way:
Input Parameters
_
Declaration of Local Variables
_
Declaration of Functions
_
Initialization
_
Equations
_
Output Parameters
The purpose of this is to make the files easy to read and to increase the
coherency of the code.
33
Figure 16: The shared libraries only contains the necessary parts of the
translated code.
A list of all components translated to .dll and the required function calls
and parameters to use in LabVIEW is enclosed in appendix G. At this
point all translated components except two, ”Long Line with Distributed
Parameters” (line.dll ) and ”Long Line with Lumped Parameters” (lline.dll )
work. This means that their basic functionality have been examined and
confirmed in LabVIEW. The line connector functions gcon and tcon have
been translated but not examined, since they are only useful together with
the line components.
34
5 Analysis
The resulting codes and models must be analyzed and verified to confirm
their functionality. The rudder block is examined so that it works properly,
although there was no time to confirm these results with a hardware exper-
iment. The code translation from Hopsan to LabVIEW has been analyzed
by comparing the results between equivalent systems in both simulation en-
vironments. Finally, the performance of the LabVIEW simulations has been
examined.
Figure 17: The rudder block is controlled and analyzed by three force gen-
erators.
The system is simulated for 5 seconds. After 2 seconds a step input signal
tells the rudder to move from -0.5 rad to 0.2 rad. Then after 4 seconds a step
disturbance force is applied. The resulting graphs are shown in figure 18.
As can be seen, the rudder responds in a realistic way. It can also be noted
that no significant differences in the result exists between the simulation
environments.
35
(a) Rudder results from Hopsan. (b) Rudder results from LabVIEW.
Figure 18: The effect on the rudder from a step input and a disturbance
force is simulated in Hopsan and LabVIEW.
The second test aim to examine the behavior of the rudder block when put
into a more complicated hydraulic system. This system is based upon two
pistons controlling the rudder, controlled by one servo valve each. The servo
valves are supplied by two constant pressure pumps. An angular position
feedback with proportional control is used to control the valves, so that
the two systems will always work together and perform the same tasks. A
force generator block is also used to simulate external load forces. See figure
19. In LabVIEW the double pump-valve-piston systems are represented
by one single system, where the force exerted by the piston is duplicated
before it is fed into the rudder block. This dramatically decreases the size
and complexity of the block diagram. Hopsan does however not offer this
convenience.
36
Figure 19: The rudder block is analysed in a system with more advanced
dynamics.
A step input signal and a step disturbance force is simulated. The input
signal will tell the rudder to move from -0.5 rad to 0.2 rad after 1 second.
Then after 2 seconds a disturbance force is introduced. The results are
shown in figure 20. As can be seen, the rudder responds as expected; fast
but with a small overshot and some oscillations. The feedback gain can be
adjusted to remove these, at the cost of a slower response. There are slightly
more oscillations in LabVIEW. The reason for this is most likely numerical
differences, such as time steps or number of samples.
37
(a) Rudder results from Hopsan. (b) Rudder results from LabVIEW.
Figure 20: The rudder block responds in a realistic way in both simulation
environments.
The results show that there are no distinguishable differences between the
results. The spring begins to oscillate, is damped by the viscous friction and
approaches a stationary value. No difference can be seen in either amplitude
38
or frequency. See figure 22.
39
The result shows that both simulation environments give similar results.
See figure 24. It was however found that using too small time steps in
LabVIEW will decrease the quality of the results significantly. The time
step must be reduced to approximately 0.001 s before its effect on the graph
can be considered negligible.
Figure 24: The step response on a piston-mass system gives the same result
in both simulation environments.
As a final test a pressure relief valve was compared between the environ-
ments. This is of great interest because the behavior of the valve depends
on time steps and numerical parameters to a great extent. The system is
supplied by a fixed displacement pump, and a two port volume connects the
pump to the valve. See figure 25. The opening pressure of the valve is set
to 100 bars.
Figure 25: A pressure controlled valve is used to limit the system pressure.
The system begins to oscillate slightly about the reference value, and then
evens out at the desired pressure. The oscillations are a result of the valve
dynamics; it can not open nor close infinitely fast. As can be seen, the results
show no apparent differences between the simulations. This was expected,
because the time step and thereby also the number of samples is the same
in both cases.
40
(a) System pressure in Hopsan. (b) System pressure in LabVIEW.
Inactive input means that the system is running with no change in the input
signal, so that nothing is happening. Active input means that the input sig-
nal is constantly changing. Time step are set to 0.01 s for the single piston
system and 0.001 s for the rudder system. Results are as follows:
41
Rudder system with position feedback and disturbance force
As can be seen, none of the simulations can achieve actual real-time simula-
tions on this system. The rudder simulation takes more than twice as long
time as is simulated.
42
6 Discussion
Making different software environment communicate with each other is a
complicated process. The main reason for this is probably that the software
producers do not want the consumers to use other software than their own.
This procedure does however show very satisfactory results, because you can
take advantage of the strengths in both programs or get around possible
weaknesses. Although commercial toolkits for these purposes often already
exist, they are usually limited. They may for example only support a few
selected products or demand both programs to be running simultaneously,
making real time simulations difficult. Furthermore they are often more
expensive than the programs themselves. For this reason there is a lot of
money to save in solving these problems single-handed.
One important phenomenon I noticed when optimizing the shared li-
braries was the contradiction between readability and efficiency in program-
ming code. A 100% effective code will for example result in long and com-
plicated variable names, making it nearly impossible to find an error in the
code by simply looking at it. A solution to this could be to keep an unopti-
mized version for error detection purposes. On the other hand, the strength
of modern computers may render total optimization unnecessary. In long
and complicated simulations the capabilities of the computers may on the
contrary still play an important role, especially for real time simulations.
During this project I have learned that many problems are easier to
solve than one may first think. I have come across many difficulties that at
first seemed impossible to solve or even understand, but then the solution
appeared out of nowhere before the afternoon coffee break. The conclusion
of this is to always give the problems the time they need, and to not give
up just because you at first do not know how to do.
6.1 Problems
The performance experiment showed that the LabVIEW models were not
able to produce real-time results on the computer used for this thesis work.
The simpler model was however close and should be able to achieve this on
a more advanced system, especially with a digital signal processor (DSP). It
should also be pointed out that several operating system applications were
running simultaneously. The rudder system was on the other hand far from
its goals, and would likely require a very fast machine to run smoothly.
Further optimization of the code is also possible. One shall also have in
mind that multi-core support was not used in neither of these examinations.
43
Three components are still not working properly with the translated code;
the volume with arbitrarily connections, the long line with lumped parameters
and the long line with distributed parameters.
The problem with the volume components is that the current code re-
quires the nodes to be stored in a global array, so that the subroutine can be
told to call arbitrarily many of them. This can be solved by either passing all
nodes to the component routine as input parameters, which would be very
memory inefficient, or by making one volume component for each number of
nodes. The latter of these solutions have been used in this project, although
neither of these solutions could be considered good programming manner.
It is advised to investigate the possibility of passing arbitrarily sized arrays
to a subroutine in C code.
For the line components, the problem is that they are generated exter-
nally from Mathematica models. The code is for this reason very difficult to
follow, and error detection is simply not possible. A solution to this could
be to explore the possibility of exporting models from Mathematica to C
code instead of Fortran code. Issues like these are worth to have in mind
when developing a model generator for the next generation of Hopsan.
44
An important phenomenon in simulations, especially when simulating long-
time scenarios, is the reproduction of errors. An error that may seem in-
significantly small at the beginning can still have a great impact in a larger
system or over a long time.
The exact functionality in LabVIEW can be difficult to analyze because
it is integrated in the environment. This is a great advantage with open
source software, where one can have complete control of the simulation meth-
ods. One very important observation is however that the simulation time
must be calculated by multiplying the number of performed iterations with
the time step. If done in any other way, it proved to cause numerical er-
rors such that making the time scale wrong or reducing the amplitude in
oscillations even when they are not damped and should maintain constant
amplitude. Needless to say it is also important not to change the time step
in the midst of a simulation.
Another risk to have in mind when examining a simulation model is
that one often choose very nice values to obtain good looking and easy-
to-understand results. There is then a risk that the model is only correct
for these values, while it would not work very well with less slanted values.
Verification with the help of physical hardware would therefore be a good
way of confirming the results from the examination of the systems.
45
6.4 Recommendation for Next Version of Hopsan
To maintain compatibility it is strongly recommended to either keep the
component libraries in C code, or to include a simple way of exporting the
component code to C. This would maximize the possibilities of exporting
components and models to other environment (although some modifications
may still be necessary).
When it comes to code structure, it is not advisable to keep the current
system with global variables. A better and more efficient solution would be
to store the nodes in an array in the main routine, and then pass the nodes
only to the components that will need them. A similar system with the
global simulation parameters, for example time step and error codes, would
also be to prefer. Another poor solution used in the Fortran code is goto
commands. These can easily be exchanged with for example switch-case
expressions.
The simulation model must keep track of the components and nodes by
providing them with a number. It is advisable to keep a similar numbering
system as in the previous version. This means that each component routine
will assign the numbers themselves and return the number to the main
routine, to make sure the numbers start at 0, 1, 2... and nothing else.
One problem with the previous version is that the data is stored in fixed
arrays, limiting the maximum number of each component type a model can
have. A solution to this could be to investigate the possibility of using
variable sized arrays, which will be increased automatically if they should
become too short. This would reduce the amount of required memory, and
allow arbitrarily sized systems to be simulated.
A significant improvement would be to improve the graphical user in-
terface, to make the program more user friendly. It is also recommended to
introduce an undo-function, because mistakes easily happen in the current
interface. Another interesting improvement would be an autosave-function,
as the program is not always very stable. The instability issues can also be
countered by introducing some sort of exception handling in the code, to
prevent sudden unexpected program crashes.
The compatibility between Hopsan and LabVIEW should be investigated
further. This can probably more or less be included in the program itself,
for example with an automatic export function for .dll-files. It would also
be interesting to consult representatives from National Instruments for an
exchange of ideas and opinions.
46
6.5 Recommendations for Continued Work
The possibility of using the shared libraries (.dll-files) in computer environ-
ments suitable for real-time simulations with host-target computers should
be investigated further. Then it is recommended to conduct a test run of a
HWiL simulation with the .dll-files in a simpler physical hydraulic system.
If all of the above works well, a full scale test run of a simulation with the
Ironbird is necessary to finally verify the results.
The rudder block needs to be tested and verified by comparing it with
the behavior of the real physical component.
The multi-core support in LabVIEW would provide interesting opportu-
nities and needs to be investigated further. The possibility of implementing
this in the next version of Hopsan would also be of great interest and should
be examined. The ability of importing and exporting .dll-files to and from
other simulation environments would also be an interesting feature, which
would further increase the compatibility.
6.6 Conclusions
It is possible, although somewhat complicated, to use Hopsan components
in the LabVIEW environment. This enables powerful features such as real-
time simulations and advanced plotting tools. It does on the other hand
require powerful computer systems. The possibility of taking advantage of
multi-core support and conducting hardware-in-the-loop simulations should
be investigated further.
47
References
J. Andersson and T. Herres. Modellering och simulering av det hydrauliska
försörjningssystemet till saab 2000. Master’s thesis, Linköping University, 1997.
48
A List of Parameters
Elevator Control Hydraulic System
System Parameters
Maximum System Pressure ps 200 bar
Work Point Pressure pl0 20 bar
Oil Bulk Modulus βe 1.2 GPa
Oil Density ρ 850 kg/m2
Filter Cutoff Frequency ω1 10 kHz
Cutoff Frequency (noise reduction) ω2 10 Hz
Valve Cutoff Frequency ω3 500 Hz
Directional Valve
Flow Gain Cq 0.67
Slide Diameter Dv 5 mm
Maximum Spool Stroke (elevators) xv,max,e 1 mm
Maximum Spool Stroke (rudder) xv,max,r 0.5 mm
Working Point Spool Stroke (elevators) xv,0,e 0 mm
Working Point Spool Stroke (rudder) xv,0,r xv,max,r
Orifice to Circumference Ratio K 30 %
Saturation Sv 0.001
Area Gradient w K· π· Dv
Control System
Proportional Gain Kp 0.004
Elevator Cylinders
Internal Leakage Coefficient Cip,e 1· 10−12
Piston Area Ap,e 1.2339· 10−3 m2
Stroke Sp,e 5 cm
Viscous Damping (estimated) Bp,e 3500 N s/m
Rudder Cylinders
Internal Leakage Coefficient Cip,r 1· 10−12
Piston Area Ap,r 1· 10−3 m2
Stroke Sp,r 9.8 cm
Viscous Damping (estimated) Bp,r 3500 N s/m
A-1
Load Simulation Hydraulic System
System Parameters
Maximum System Pressure ps,L 200 bar
Work Point Pressure pl0,L 20 bar
Oil Bulk Modulus (estimated) βe,L 1 GPa
Oil Density (estimated) ρL 860 kg/m2
Directional Valve
Flow Gain Cq,L 0.67
Flow-Pressure Coefficient Kce,L 4· 10−11
Slide Diameter Dv,L 1 cm
Area Gradient wL π· Dv,L
Bandwidth ωv,L 700 Hz
Control System
Proportional Gain Kp,L 1· 10−6
Integrating Gain Ki,L 1· 10−6
Elevator Cylinders
Piston Area Ap,e,L 1.347· 10−3 m2
Viscous Damping (estimated) Bp,e,L 5500 N s/m
Oil Volume Between Piston and Valve Vt,L 0.001 m3
Rudder Cylinders
Internal Leakage Coefficient Cip,r,L 1· 10−12
Piston Area Ap,r,L 2.1· 10−3 m2
Stroke Sp,r,L 0.5 m
Mechanical Model
Elevators
Mass Me 40 kg
Moment of Inertia Je 3.79kgm2
Level Arm to Center of Mass LM,e 100 mm
Airplane Cylinders Distance a ae,AC -10 mm
Airplane Cylinders Distance b be,AC 85 mm
Airplane Cylinders Distance c ce,AC 0
Airplane Cylinders Distance d de,AC 450 mm
Load Cylinders Distance a ae,LS -10 mm
A-2
Load Cylinders Distance b be,LS 170 mm
Load Cylinders Distance c ce,LS 170 mm
Load Cylinders Distance d de,LS 650 mm
Rudder
Mass Mr 55 kg
Moment of Inertia Jr 9kgm2
Airplane Cylinders Distance a ar,AC 40 mm
Airplane Cylinders Distance b br,AC 80 mm
Airplane Cylinders Distance c cr,AC 270 mm
Airplane Cylinders Distance d dr,AC 390 mm
Load Cylinders Distance a ar,LS 240 mm
Load Cylinders Distance b br,LS 200 mm
Load Cylinders Distance c cr,LS 950 mm
Load Cylinders Distance d dr,LS 360 mm
A-3
B List of Components
Hydraulic Equipment, Aircraft System
Servo Actuators, Elevators
Manufacturer: Dowty Aerospace
Model Number: 7U7852
Serial Number: 0004, 0005, 0006, 0009
Position: In front of each elevator
Accumulator
Manufacturer: York Industries
Model Number: 08-8423-001-1
Serial Number: 8423-8586, 8423-7870
Position: Below the rig, at the aircraft system supply pipes
Servo Valve
Manufacturer: MOOG
Model Number: 7852-419
Serial Number: 0001, 0002, 0003, 0005, 0012, 0052
Position: Directly connected to each servo actuator
Bypass Valve
Manufacturer: Unknown
Model Number: -
Serial Number: -
Position: Directly connected to each servo actuator
A-4
Hydraulic Equipment, Load Simulation System
Servo Actuators
Manufacturer: Rexroth Mecman
Model Number: 207 MT4
Serial Number: -
Position: In front of and bellow the elevators,
and at the right side of the rudder
Bypass Valve
Manufacturer: MOOG
Model Number: E504-024
Serial Number: E121, E125, E126
Position: Directly connected to each servo valve
A-5
Force Gauges
Rudder & Elevators
Manufacturer: Revere Transducers Inc.
Model Number: 363-5K-D3-20P1
Serial Number: AZ0958, CT0626, DT0641
Output: 3 mV/V at 5 K
Range: 0-5000 lbs
Position: At the piston rod of the load simulation cylinders
Angle Sensors
Left Elevator
Manufacturer: BI Mexico
Model Number: -
Serial Number: -
Position: Directly attached to the elevator, next to the servo actuators
Rudder
Manufacturer: Schaevitz
Model Number: R30D
Serial Number: 9631 AJUAY
Range: ± 20°
Output: ± 2.5 V (125 mV/°)
Position: Directly attached to the rudder, next to the servo actuators
A-6
Pressure Gauges
Rudder
Manufacturer: Paine
Model Number: 210-30-110-09
Serial Number: 158075
Range: 0-5000 PSIS
Position: At the high pressure side of the servo valve
for the right aircraft actuator
Manufacturer: Paine
Model Number: 210-30-110-09
Serial Number: 165677
Range: 0-5000 PSIS
Position: At the high pressure side of the servo valve
for the left aircraft actuator
Manufacturer: Paine
Model Number: 210-30-110-04
Serial Number: 146452
Range: 0-2000 PSIS
Position: At the low pressure side of the servo valve
for the right aircraft actuator
Manufacturer: Paine
Model Number: 210-30-110-04
Serial Number: 146450
Range: 0-2000 PSIS
Position: At the low pressure side of the servo valve
for the left aircraft actuator
Right Elevator
Manufacturer: Paine
Model Number: 210-30-110-09
Serial Number: 146439
Range: 0-5000 PSIS
Position: At the high pressure side of the servo valve
for the left aircraft actuator
Manufacturer: Paine
A-7
Model Number: 210-30-110-09
Serial Number: 165075
Range: 0-5000 PSIS
Position: At the low pressure side of the servo valve
for the left aircraft actuator
A-8
Flow Meters
Pump System 1, Pump Leakage
Manufacturer: Flow Technology
Model Number: FT4-8AENS-LEA-1
Serial Number: 84 010 000
Range: 0.95-9.5 l/min
Position: Directly connected to the leakage line
A-9
C Derivations for Hopsan model
For the hydraulic cylinders, the level arm expressions can be derived by
introducing four lengths in the geometry, see figure 27.
Figure 27: The attachment of a rudder with its actuators. The geometry
can be described by four measurable lengths.
From these four lengths, a triangle between the cylinder attachments and
the rotational axis of the rudder can be defined, see figure 28. From this,
an equation for the level arm as a function of c, d and β can be defined.
p
L = c2 + d2 sin β (C.2)
A-10
Figure 28: The triangle between the attachment points of the actuator and
the rotation axis of the rudder.
p p p
( a2 + b2 )2 − ( c2 + d2 )2 − (x0 + x)2 = −2 c2 + d2 (x0 + x)cosβ (C.3)
a2 + b2 − c2 − d2 − (x0 + x)2
β = arccos ( √ ) (C.4)
−2 c2 + d2 (x0 + x)
Equation (C.2) and (C.4) then yields the final equation for the level arm as
a function of x.
p a2 + b2 − c2 − d2 − (x0 + x)2
L= c2 + d2 sin (arccos ( √ )) (C.5)
−2 c2 + d2 (x0 + x)
A-11
Figure 29: The right-angled d-e-x-triangle will give equations for x as a
function of θ.
The lengths of e and f can be described as the initial value and the change
in position from this value. That gives equation (C.6) and (C.7), see figure
30.
e = e0 + ∆e (C.6)
f = f0 + ∆f (C.7)
Figure 30: The actual position can be described as initial value plus the
change in position from the initial value.
A-12
Because x describes the change in length of the hypotenuse, it can be ex-
pressed as the difference between the actual length and the initial length.
p q
x = (x0 + x) − x0 = (e0 + ∆e)2 + (f0 + ∆f )2 − e20 + f02 (C.8)
∆e and ∆f can be obtained from studying figure 27 and noticing the fol-
lowing relationships:
e0 = c − b (C.11)
f0 = a + d (C.12)
Equations (C.8)-(C.12) put together gives the total expression for x as a
function of a, b, c and d. After some simplifications the final expression for
the cylinder positions is derived:
p
x= (c + a sin θ + b cos θ)2 + (d + a cos θ + b sin θ)2 −
p (C.13)
(c − b)2 + (a + d)2
The expression for the level arm to the center of gravity on the elevators
will be as shown in equation (C.14). LG,0 is the level arm at the neutral
position (θ = 0).
A-13
D Complete Hopsan Model
Figure 31: The system was modeled in the Hopsan simulation software.
A-14
E Importing External C-Code to LabVIEW
This guide will explain step-by-step how to import external C Code to Lab-
VIEW. Most of the information is gathered from Nat, 2003a. It has been
modified to work with the following software:
This example function will receive two input signals and return
their sum and product, respectively.
A-15
Go to Project → Add Existing Item
Browse to <your LabVIEW directory> \cintools
Add the following files:
– cin.obj
– labview.lib
– lvsb.lib
– lvsbmain.def
Go to Project → Properties
Choose All Configurations in the Configurations box
Select C/C++
Specify the path to your cintools directory under Additional
Include Directories
Go to C/C++ → Code Generation
Set Struct Member Alignment to 1 byte
Set Runtime Library to Multi-threaded DLL (/MD)
Select the Custom Build Step tab
Write the following on a single line in the Command Line box:
– <your cintools directory> \lvsbutil -c ”$(TargetName)” -d
”$(OutDir)”
Write the following in the Output box:
– $(OutDir)$(TargetName).lsb
Go to Linker → Input
Write the following in the Module Definition File box
– <your cintools directory> \lvsbmain.def
Click on OK to close the Properties screen
Select Build → Build <project name>
A-16
Connect the signals. Each row can only have one input signal or
one output signal.
Figure 32: A Code Interface Node block is used to execute external code in
LabVIEW.
A-17
F Importing Shared Libraries to LabVIEW
This guide will explain step-by-step how to create a shared library file (.dll)
and import it from LabVIEW. Most of the information is gathered from
Nat, 2003a. It has been modified to work with the following software:
This example function will receive two input signals and return
their sum and product, respectively.
A-18
Browse to the correct directory and add your C file
Go to Project → Properties
Choose All Configurations in the Configurations box
Select C/C++
Specify the path to your cintools directory under Additional
Include Directories
Go to C/C++ → Code Generation
Set Struct Member Alignment to 1 byte
Set Runtime Library to Multi-threaded DLL (/MD)
Click on OK to close the Properties screen
Select Build → Build <project name>
4. You should now be able to connect and execute your code in Lab-
VIEW.
A-19
G List of DLL Function Calls
If used correctly, the function calls in the Call Library Function block in
LabVIEW shall look like this.
abso.dll
int32_t abso_func(double *in, double *out);
ackum.dll
int32_t ackum_func(double *p1, double *q1, double *c1, double *zc1,
double *voil, double *betae, double *pmin, double *vtot,
double *vgas, double *kappa, double *kce, double *e0,
double *time_step, double *time);
div.dll
int32_t div2_func(double *in1, double *in2, double *out);
fcsrc.dll
int32_t fcsrc_func(double *fi, double *c, double *zc, double *time_step,
double *time);
fpump.dll
int32_t fpump_func(double *p1, double *q1, double *c1, double *zc1,
double *p2, double *q2, double *c2, double *zc2,
double *speed, double *dp, double *kcp,
double *time_step, double *time);
gain.dll
int32_t gain_func(double *in, double *out, double *k);
machine.dll
int32_t machine_func(double *p1, double *q1, double *c1, double *zc1,
double *p2, double *q2, double *c2, double *zc2,
double *f3, double *x3, double *sx3, double *s2x3, double *c3,
double *zc3, double *eps, double *betae, double *je, double *v1,
double *v2, double *dp, double *cim, double *bm,
double *time_step, double *time);
mkload.dll
int32_t mkload_func(double *f1, double *x1, double *sx1, double *s2x1, double *c1, double *zc1,
double *f2, double *x2, double *sx2, double *s2x2, double *c2, double *zc2,
double *ml, double *bl, double *kl, double *xmin, double *xmax,
double *time_step, double *time);
A-20
mload.dll
int32_t mload_func(double *f1, double *x1, double *sx1, double *s2x1, double *c1, double *zc1,
double *f2, double *x2, double *sx2, double *s2x2, double *c2, double *zc2,
double *ml, double *bl, double *xmin, double *xmax,
double *time_step, double *time);
mload4.dll
int32_t mload4_func(double *f1, double *x1, double *sx1, double *s2x1, double *c1, double *zc1,
double *f2, double *x2, double *sx2, double *s2x2, double *c2, double *zc2,
double *f3, double *x3, double *sx3, double *s2x3, double *c3, double *zc3,
double *f4, double *x4, double *sx4, double *s2x4, double *c4, double *zc4,
double *ml, double *bl, double *xmin, double *xmax,
double *time_step, double *time);
mloadc.dll
int32_t mloadc_func(double *f1, double *x1, double *sx1, double *s2x1, double *c1, double *zc1,
double *f2, double *x2, double *sx2, double *s2x2, double *c2, double *zc2,
double *ml, double *bl, double *fc, double *xmin, double *xmax,
double *time_step, double *time);
motorj.dll
int32_t motorj_func(double *p1, double *q1, double *c1, double *zc1,
double *p2, double *q2, double *c2, double *zc2,
double *f3, double *x3, double *sx3, double *s2x3, double *c3, double *zc3,
double *jl, double *bl, double *eps, double *dp, double *cim, double *bm,
double *time_step, double *time);
mrudder.dll
int32_t mrudder_func(double *f1, double *c1, double *zc1,
double *f2, double *c2, double *zc2,
double *f3, double *c3, double *zc3,
double *the, double *sthe, double *l1, double *l2, double *l3,
double *ml, double *igl, double *bl, double *kl, double *lg,
double *a1, double *b1, double *se1, double *d1,
double *a2, double *b2, double *se2, double *d2,
double *a3, double *b3, double *se3, double *d3,
double *themin, double *themax, double *x1min, double *x1max,
double *x2min, double *x2max, double *x3min, double *x3max,
double *time_step, double *time);
mult2.dll
int32_t mult2_func(double *in1, double *in2, double *out);
ocv.dll
int32_t ocv_func(double *p1, double *q1, double *c1, double *zc1,
double *p2, double *q2, double *c2, double *zc2,
double *p3, double *q3, double *c3, double *zc3,
double *x0, double *pref, double *tao, double *kcs, double *kcf, double *qnom,
double *ph, double *kappa, double *time_step, double *time);
A-21
pcsrc.dll
int32_t pcsrc_func(double *pi, double *c, double *zc, double *time_step, double *time);
pids.dll
int32_t pid_func(double *out, double *yref, double *y, double *k, double *wi, double *td,
double *ymin, double *ymax, double *time_step, double *time)
pistm1.dll
int32_t pistm1_func(double *p1, double *q1, double *c1, double *zc1,
double *p2, double *q2, double *c2, double *zc2,
double *f3, double *x3, double *sx3, double *s2x3, double *c3, double *zc3,
double *ml, double *bl, double *kl, double *a1, double *a2, double *sl,
double *cip, double *bp, double *time_step, double *time);
piston.dll
int32_t piston_func(double *p1, double *q1, double *c1, double *zc1,
double *p2, double *q2, double *c2, double *zc2,
double *f3, double *x3, double *sx3, double *s2x3, double *c3, double *zc3,
double *betae, double *me, double *v01, double *v02, double *a1,
double *a2, double *sl, double *cip, double *bp,
double *time_step, double *time);
ppump.dll
int32_t ppump_func(double *p1, double *q1, double *c1, double *zc1,
double *p2, double *q2, double *c2, double *zc2,
double *p3, double *q3, double *c3, double *zc3,
double *z, double *vz, double *pdif, double *speed, double *qmin,
double *qmax, double *taov, double *lp, double *rp, double *tp,
double *tm, double *wp1, double *kcp, double *time_step, double *time);
preg.dll
int32_t preg_func(double *p1, double *q1, double *c1, double *zc1,
double *p2, double *q2, double *c2, double *zc2,
double *p3, double *q3, double *c3, double *zc3,
double *x0, double *pref, double *tao, double *kcs, double *kcf,
double *qnom, double *ph, double *time_step, double *time)
prv.dll
int32_t prv_func(double *p1, double *q1, double *c1, double *zc1,
double *p2, double *q2, double *c2, double *zc2,
double *x0, double *pref, double *tao, double *kcs, double *kcf, double *qnom,
double *ph, double *time_step, double *time);
psrc.dll
int32_t psrc_func(double *pi, double *p, double *q, double *c, double *zc,
double *time_step, double *time);
A-22
pvalv.dll
int32_t pvalv_func(double *p1, double *q1, double *c1, double *zc1,
double *p2, double *q2, double *c2, double *zc2,
double *p_open, double *q_open, double *c_open, double *zc_open,
double *p_close, double *q_close, double *c_close, double *zc_close,
double *x0, double *pref, double *tao, double *kcs,
double *kcf, double *qnom, double *ph, double *time_step, double *time)
serval.dll
int32_t serval_func(double *p_p, double *q_p, double *c_p, double *zc_p,
double *p_t, double *q_t, double *c_t, double *zc_t,
double *p_a, double *q_a, double *c_a, double *zc_a,
double *p_b, double *q_b, double *c_b, double *zc_b,
double *xv, double *xvr, double *rho, double *cq, double *sd,
double *frac, double *xul, double *xvmax, double *wv, double *dvint,
double *time_step, double *time);
spring.dll
int32_t spring_func(double *x1, double *sx1, double *c1, double *zc1,
double *x2, double *sx2, double *c2, double *zc2,
double *k, double *x0, double *time_step, double *time);
sub2.dll
int32_t sub2_func(double *in1, double *in2, double *out);
sum2.dll
int32_t sum2_func(double *in1, double *in2, double *out);
sxsrc.dll
int32_t sxsrc_func(double *sxi, double *f, double *x, double *sx, double *c, double *zc,
double *time_step, double *time);
valv33.dll
int32_t valv33_func(double *p_p, double *q_p, double *c_p, double *zc_p,
double *p_t, double *q_t, double *c_t, double *zc_t,
double *p_a, double *q_a, double *c_a, double *zc_a,
double *xv, double *rho, double *cq, double *sd, double *frap,
double *frat, double *xap0, double *xat0, double *xvmax,
double *time_step, double *time);
valv43.dll
int32_t valv43_func(double *p_p, double *q_p, double *c_p, double *zc_p,
double *p_t, double *q_t, double *c_t, double *zc_t,
double *p_a, double *q_a, double *c_a, double *zc_a,
double *p_b, double *q_b, double *c_b, double *zc_b,
double *xv, double *rho, double *cq, double *sd,
double *frap, double *frat, double *xap0, double *xat0,
double *frbp, double *frbt, double *xbp0, double *xbt0,
double *xvmax, double *time_step, double *time);
A-23
volume2.dll
int32_t volume2_func(double *p1, double *q1, double *c1, double *zc1,
double *p2, double *q2, double *c2, double *zc2,
double *v, double *betae, double *time_step, double *time);
volume3.dll
int32_t volume2_func(double *p1, double *q1, double *c1, double *zc1,
double *p2, double *q2, double *c2, double *zc2,
double *p3, double *q3, double *c3, double *zc3,
double *v, double *betae, double *time_step, double *time);
volume4.dll
int32_t volume2_func(double *p1, double *q1, double *c1, double *zc1,
double *p2, double *q2, double *c2, double *zc2,
double *p3, double *q3, double *c3, double *zc3,
double *p4, double *q4, double *c4, double *zc4,
double *v, double *betae, double *time_step, double *time);
vpump.dll
int32_t vpump_func(double *p1, double *q1, double *c1, double *zc1,
double *p2, double *q2, double *c2, double *zc2,
double *eps, double *speed, double *dp, double *kcp,
double *time_step, double *time);
A-24