Professional Documents
Culture Documents
s
e
c
o
n
d
With Linux process
Without Linux process
Figure 3.11: Deterministic feature of RTLinux
37
0 200 400 600 800 1000 1200 1400 1600 1800
0.013
0.014
0.015
0.016
0.017
0.018
0.019
0.02
index
m
i
l
l
i
s
e
c
o
n
d
task execution time of process
t
hrea and output
t
hread
With Linux process
Without Linux process
Figure 3.12: Task Execution Time of process thread and output thread
0 200 400 600 800 1000 1200 1400 1600
0.48
0.485
0.49
0.495
0.5
0.505
0.51
0.515
index
m
i
l
l
i
s
e
c
o
n
d
task execution time of sampling
t
hread, process
t
hrea, and output
t
hread
With Linux process
Without Linux process
Figure 3.13: Task Execution Time of sampling thread, process thread and out-
put thread
38
3.6 Response of the HAL
The main goal of the VAL system is making users understand the role of a PID controller
in hardware not in simulation. To verify this, several experiments can be performed using
dierent PID gains. Figure 3.14 and 3.15 show the characteristic of a PID controller as
an example of the data the user can obtain. The desired position is 10 inches for both
directions. So, using the VAL system, users can gain the fundamental knowledge of a
feedback control system in real hardware not in simulation.
39
0 5000 10000 15000
2000
0
2000
4000
6000
8000
10000
12000
14000
time[millisecond]
p
o
s
i
t
i
o
n
[
m
i
l
l
i
i
n
c
h
]
Step response of the HAL
P=100, I=0, D=0
P=100, I=50, D=0
P=100, I=100, D=0
P=100, I=0, D=50
P=100, I=0, D=100
P=100, I=50, D=50
P=100, I=100, D=50
(a) When P=100
0 5000 10000 15000
2000
0
2000
4000
6000
8000
10000
12000
14000
time[millisecond]
p
o
s
i
t
i
o
n
[
m
i
l
l
i
i
n
c
h
]
Step response of the HAL
P=200, I=0, D=0
P=200, I=50, D=0
P=200, I=100, D=0
P=200, I=50, D=50
P=200, I=100, D=50
(b) When P=200
Figure 3.14: Step response of the HAL in a horizontal direction
40
0 5000 10000 15000
0
5000
10000
15000
time[millisecond]
p
o
s
i
t
i
o
n
[
m
i
l
l
i
i
n
c
h
]
Step response of the HAL
P=100, I=0, D=0
P=100, I=50, D=0
P=100, I=0, D=50
P=100, I=0, D=100
P=100, I=50, D=50
P=100, I=50, D=100
P=100, I=100, D=100
(a) When P=100
0 5000 10000 15000
0
2000
4000
6000
8000
10000
12000
14000
time[millisecond]
p
o
s
i
t
i
o
n
[
m
i
l
l
i
i
n
c
h
]
Step response of the HAL
P=200, I=0, D=0
P=200, I=50, D=0
P=200, I=0, D=50
P=200, I=0, D=100
P=200, I=50, D=50
P=200, I=50, D=100
P=200, I=100, D=100
(b) When P=200
Figure 3.15: Step response of the HAL in a vertical direction
41
CHAPTER IV
REAL-TIME SIMULATION
Computer simulation provides an important tool for the study of complex systems. Dra-
matic improvements in computer equipment have provided an ability to model large systems
with relatively short simulation run-times, with some classes of simulation running in less
time than the time period they are simulating. In general, a simulation means o-line
simulation which simulates non-actual time. In o-line simulation, the simulation can take
10 hours to simulate 30 seconds of system behavior. In Real-Time(RT) simulation, time
must be synchronized with actual time. This means that calculations for each simulation
timestep have to be completed within the same corresponding interval of real-world time.
RT simulation of complex systems is always dicult in that complex and dicult mod-
elling must be followed by validation of its result. One approach to the problem is to make
parts of the system actual hardware while the others are simulated by the RT simulation
software. This approach is called Hardware-In-the-Loop(HIL) simulation. In this chapter,
RT simulation of the HAL is implemented by PC-based simulation tools, i.e. MATLAB,
Simulink, Dymola(Modelica), xPC Target, and RT-Lab.
4.1 Development of RT Simulation
In the rst phase of RT Simulation, customized hardware and software are created for a RT
simulation, which are high-cost and time-consuming jobs. Rapidly increasing calculation
power of PCs helps to solve this problem. PC-based RT simulation tools provide general
methods so that the developers use their skills on other aspects of the RT simulation. Flex-
ible, modular, and reusable components of a RT simulation are provided by the commercial
tools. RT simulation tools consist of a RTOS(RT kernel), modelling software, an auto code
generation tool, and a user interface. This section explains necessary PC-based tools for a
RT simulation.
42
4.1.1 Real-Time System and RTOS
Real-time systems are computer systems that monitor, respond to, or control an external
environment. This environment is connected to the computer system through sensors,
actuators, and other input-output interfaces. Computer hardware for real-time applications
typically consists of a number of fairly standard components such as processors, memory
units, buses, and peripherals, connected to some real-time input and output devices such
as sensors and actuators. The operating system which runs on Real-time systems is called
Real-Time Operating System(RTOS). RTOS diers signicantly from conventional software
in a number of ways[54]
Timing Constraints.
The program must not only produce the correct answer or output but also compute
the answer on time. More generally, real time software must also satisfy timing
assertions that involve relations over relative and absolute times. The most common
and simplest such assertion is a deadline - a limit on the absolute or relative time when
a computation must be completed. In a robot control system, for example, there may
be a deadline or limit between the time that a moving robot senses an obstruction
in its path and the time that an actuator, such as a wheel controller, is activated to
move the robot in a safer direction.
A qualitative distinction can be made between hard and soft real-time systems. Hard
real-time systems are those that, without exception, must meet their timing constants
- if a constant is violated, the system fails. Soft real-time systems perform their mission
despite missing some constraints, but those are still considered successful.
Concurrency.
Computer systems use concurrency to improve performance, for example, by em-
ploying several processors running in parallel. Real-time systems must deal with the
inherent physical concurrency that is part of the external world to which they are
connected.
43
Reliability and Fault Tolerance.
Reliability is a measure of how often a system will fail. Fault tolerance is concerned
with the recognition and handling of failures. Errors and failures can be very costly,
causing, for example, money losses, property damage, mission failures, or loss of
human life. Consequently, it is very important to avoid failures if possible, through
techniques for reliability, and to respond appropriately, gracefully, and with as little
cost as possible to failures that do occur(fault tolerance).
Two approaches are mainly used to implement PC-based RTOSs. One uses general
OSs (i.e., Windows OSs and Linux) and adds a subsystem to them in order to get RT
functionalities. The other is a stand alone RTOS. Both of them have their advantages and
disadvantages. These are discussed here.
RTX and HyperKernel
Windows NT/2000/XP are designed as general purpose OSs. The extensive pro-
gramming tools and applications are available for Windows OSs. Depending on the
hardware, interrupt latencies under Windows OSs can be very good, averaging less
than 25 micro-seconds. However, worst-case interrupt latencies are unbounded and
can exceed 5 milliseconds. These worst-case latencies are a result of the context under
which Windows User-mode applications are running. Because of this delay, Windows
OSs cannot be used in mission critical applications. To alleviate this disadvantage, a
new strategy has been developed. RTX/Hyperkernel allow Windows OSs to be used as
RTOS. These two are real-time extensions for Windows OSs that provide high-speed
and deterministic real-time capabilities for Windows [63, 12].
Stand alone RTOSs have their own environment and require additional learning time
for software developers. RTX/Hyperkernel are seamlessly integrated with Visual
C/C++ programming environment. Software developers dont need to learn new
development tools, and only one computer is used in development and implementa-
tion.
44
The cost of most development tools are very expensive. The costs of Windows OSs,
RTX/Hyperkernel, and Visual C/C++ compiler should be paid. And the source codes
have poor portability to other OSs.
RTLinux and Realtime Linux Application Interface for Linux(RTAI)
Like RTX/Hyperkernel, RTLinux and RTAI provide real-time functionalities over
Linux. When they were rst developed, both of them were free and open-source
projects based on University projects. Now commercial packages of RTLinux are
available by FSMLabs, Inc [17, 58].
The advantage of RTLinux and RTAI is that they are free of cost, and they follow well
the POSIX standard. All of the development tools are results of open-source projects.
These tools are also free. This free software development has also a disadvantage in
that no responsible company exists to solve problems on open-source projects.
QNX
QNX Neutrino features a true microkernel architecture, in which the kernel provides
only a few essential services. Isolated from all other modules in the system, the kernel
communicates via message passing, forming a virtual software bus. Components can
be plugged in (or out) to deliver necessary services. QNX Neutrino was designed
from the ground up to comply with POSIX realtime standards. With native POSIX
support, users can avoid the added overhead and performance degradation often found
in layered implementations. The Photon microGUI lets users bring rich graphical
capability to the programs.
QNX supports most major 32-bit processor architectures such as x86/Pentium, MIPS,
PowerPC, ARM family, and Hitachi SH-4, and it has been used for more than 20 years
in industry. QNX shows stable and satisfactory performance to the user, and most
open-source programs can be compiled in it [30].
xPC Target Real-Time Kernel
xPC Target is a solution for prototyping, testing, and deploying real-time systems
45
using standard PC hardware. It is an environment that uses a target PC, separate
from a host PC, for running real-time applications. xPC Target does not require any
other operating system on the target PC. A boot disk is used to boot the target PC.
The host PC congures and creates the boot disk for the target PC. xPC Target kernel
runs only on a PC compatible system and a key component of every PC compatible
system is the BIOS. The BIOS is the only software component that is needed by the
xPC Target kernel. The generated real-time application is compiled as Windows NT
applications with a at memory model [60].
There is no way to directly program in xPC Target real-time kernel. The Simulink
model is always converted to source code by Real Time Workshop, and then that code
is compiled by the Visual C/C++ or Watcom C/C++ compiler. Also two computers
are necessary to implement a real-time simulation. Required software are MATLAB,
Simulink, Real Time Workshop, and Visual C/C++ or Watcome C/C++ compiler.
Since the parameters of a real-time systems are often referred to in a misleading manner,
it is worthy of summarizing the most important parameters [41]. These parameters are
described in Figure 4.1.
TET
t
Figure 4.1: Task switching with the Real-Time Kernel from [41]
Interrupt Latency (t
IL
)
The interrupt latency time is the time from the activation of the interrupt signal to
46
when the rst instruction of the interrupt service routine (ISR) is executed. In the
case of enabled interrupts, this time depends solely on the hardware of the processor.
Task Switching Time (t
TS
)
This describes the time from the occurrence of the tasks trigger signal to the execution
of the rst instruction within the task. It includes the interrupt latency time and the
time that passes until the scheduler actually starts the task. Since this time is largely
determined by the system load, it is often set as the minimal task switching time
during single-tasking applications.
Task Execution Time (t
TET
)
This indicates only the execution time of a task. Interruptions by other tasks or events
are not included.
Task Turnaround Time
This is the time from the occurrence of the task trigger to the completion of the task.
This means that the task turnaround time also includes all times when the task was
interrupted. For periodic tasks, it determines the minimum sampling time with which
a task can be triggered.
In this thesis, xPC Target real-time kernel and QNX are selected as RTOSs. Because
both have complete real-time simulation tools from modelling to execution such as xPC
Target and RT-Lab, respectively. Section 4.2 explains these two simulation tools in detail.
4.1.2 Modelling and Modelling Software for RT Simulation
Modelling is an important aspect of RT simulation. If the model is not accurate enough,
the result of RT simulation is useless. But the accuracy can be achieved at the calculation
times cost. In RT simulation, real-time time constraints are also important. The trade-o
between these two should be well selected.
Various kinds of modelling software have been developed since a computer was invented.
The ordinary dierential equations (ODEs) of models are written into the codes to integrate
47
those dierential equations in order to run simulations. Recently, in order to replace writ-
ing code, graphic interfaces are developed. Simulink is a famous simulation tool which uses
block diagrams to model and in preparation for simulation. Modelica is an object-oriented
modelling language. Also Modelica can be used to solve problems that can be expressed
in terms of dierential-algebraic equations (DAEs) describing the behavior of continuous
variables. The ability to formulate problems as DAEs rather than ODEs reduces develop-
ment time because less eort is involved in formulating equations. Modelica, which is a
language specication, needs a translator to solve and simulate the system. [62]. Simulink
and Dymola are explained below :
Simulink
Simulink is a software package for modelling, simulating, and analyzing dynamic sys-
tems. It supports linear and nonlinear systems, modelled in continuous time, sampled
time, or hybrid of the two. Systems can also be multirate, i.e., have dierent parts
that are sampled or updated at dierent rates.
For modelling, Simulink provides a graphical user interface (GUI) for building models
as block diagrams. Using block diagrams to build models is easier than formulating
dierential equations in a programming language. Simulink includes a comprehen-
sive block library of sinks, sources, linear and nonlinear components, and connectors.
Simulink also allows user to create and customize their own blocks.
After a model is dened, it can be simulated. Simulation results can be displayed in
scopes or other display blocks while the simulation is running. In addition, parameters
can be changed while the simulation is running. The eects of changing parameters
are shown immediately. The simulation results can be put in the MATLAB workspace
for postprocessing and visualization [33].
Modelica
Modelica is an object-oriented language for modelling of large, complex physical sys-
tems. It is suited for a multi-domain modelling. There are a lot of standard com-
ponents in Modelica such as motors, pumps and valves. If the specic component
48
does not exist, it could be constructed using existing components. Modelica is both
a modelling language and a model exchange specication. Modelica is not a program
but a language specication. In order for Modelica to solve actual modelling prob-
lems, a modelling and simulation environment is needed. At this time there are two
commercial packages providing modelling, compilation and simulation environment
which are Dymola and MathModelica [61]
Dymola from Dynasim has a Modelica translator which is able to perform all
necessary symbolic transformations for large systems as well as for real time
applications. A graphical editor for model editing and browsing, as well as a
simulation environment are included. Convenient interfaces to Matlab and the
popular block diagram simulator Simulink exist. For example, a Modelica model
can be transformed into a Simulink S-function C mex-le which can be simulated
in Simulink as an input/output block.
MathModelica from MathCore provides a Modelica simulation environment which
is closely integrated into Mathematica and Microsoft Visio. The tight integra-
tion with Mathematica also makes it possible to perform complex analysis tasks,
advanced scripting, and other technical computations on models and simulation
results. MathModelica has a graphical editor for model editing and browsing,
which is an extension of the Microsoft Visio diagramming tool. Internally, Dy-
mola symbolic and simulation engine is used for the symbolic transformations
and for the simulations.
4.1.3 Auto Code Generator and Compilers
A traditional approach to real-time design and implementation typically involves multiple
stages, including an algorithm design, a software design, a hardware design, and an imple-
mentation of the afore mentioned.. These stages are repeated until the implementation goals
are satised. This traditional approach takes so much time because the software design is
completely dierent from an algorithm design.
A rapid prototyping approach combines an algorithm and software, sometimes even
49
hardware. The rapid prototyping begins with developing block diagram plant models of
sucient delity for preliminary system design and simulation. Once simulations indicate
acceptable system performance levels, the controller block diagram is separated from the
plant model and I/O device driver blocks are attached to it. An automatic code generator
converts the entire system to real-time executable codes, which can be automatically loaded
onto target hardware.
To achieve auto code generation, The MATHWORKS, Inc. provides Real-Time Work-
shop. This subsection summarizes auto code generation in [32, 31].
Real-Time Workshop automatically generates optimized and customizable C codes from
Simulink model. The generated codes are processor independent and support any single
or multitasking operating system. Using the generated codes, a stand-alone executable
program can be created. Real-Time Workshop is an open system designed for use with a
wide variety of operating environments and hardware types.
The building process by Real-Time Workshop is following:
1. Analyze the Simulink model
During this phase, Real-Time Workshop reads the Simulink model (model.mdl) and
compiles an intermediate representation of the model which is stored in the ASCII le
(model.rtw)
2. Call the Target Language Compiler(TLC) to generate code
TLC transforms the intermediate model description into target-specic codes. TLC
is an interpreted programming language designed for the sole purpose of converting
a model description into code. TLC executes a TLC program comprising several
target les. The TLC scripts specify how to generate code from the model, using the
model.rtw le as input
3. Generate a customized Makele
Real-Time Workshop creates a customized makele, model.mk. The generated make-
le instructs the make utility to compile and link source code generated from the
50
model, as well as any required harness program, libraries, or user-provided modules.
Real-Time Workshop provides many system template makeles, congured for spe-
cic target environments and development systems such as UNIX, DOS(4GW), Tor-
nado(WxWorks), Windows, and so on.
4. Create the executable
The creation of the executable, if enabled, takes place after the model.mk le has
been created. At this stage, the build process invokes the make utility, which in turn
runs the compiler. To avoid unnecessary recompilation of C les, the make utility
performs date checking on the dependencies between object and C les.
Optionally, make can also download the executable to your target system.
Because of Real-Time Workshops open structure, RT-Lab and dSpace use Simulink,
Real-Time Workshop, and TLC as their development tools. Figure 4.2 illustrates the ar-
chitecture of Real-Time Workshop.
4.2 Implementation of RT Simulation for HAL system
xPC Target and RT-Lab are PC-based real-time simulation tools. This section shows the
implementation of the real-time simulation of the HAL with them. The HAL is modelled by
Dymola, and the model is converted to the Simulink model. Using Real-Time Workshop,
the Simulink model can run in xPC Target real-time kernel and in QNX by xPC Target
and RT-Lab, respectively.
4.2.1 Modelling of the HAL
Figure 4.3 illustrates the schematic diagram of the HAL, and the components used are
a pump, a cylinder, a motor, two pressure relief valves, and two servovalves from the
gure. Dymola provides HyLib which is a library of general hydraulic components [6]. The
components in HyLib are utilized to model the HAL, and those components are described
in Figure 4.4. The parameter values in each component are default values in HyLib except
values of step components. For a vertical direction, the desired position is 1 meter. A desired
51
Figure 4.2: Real-Time Workshop Architecture from Real-Time Workshop Users Guide [32]
52
wheel rotation for a horizontal motion is 1 radian. Figure 4.5 and 4.6 show simulation results
in Dymola using the Dassal variable integration solver.
4.2.2 Integration methods
Dymola and Simulink provide a number of dierent integration methods for the simulation
of dynamic systems. Because no single method of solving a model suces for all systems,
one should not rely on just one integration method for simulation experiments. The solvers
in Dymola and Simulink fall into two basic categories [14, 33]:
Fixed step solvers
These solvers compute a models states at equally spaced time steps from the simula-
tion start time to the simulation stop time. The solvers use numerical integration to
compute the continuous states of a system from the state derivatives specied by the
model.
Variable step solvers
These solvers decrease the simulation step-size to increase accuracy when a systems
states are changing rapidly and increase the step size to save simulation time when a
systems states are changing slowly.
If fast and slow signals are present in the solution of a model, the usual integrators cannot
solve this model. For linear dierential equations this corresponds to problems where the
system matrix has eigenvalues whose real part is negative and large in magnitude, compared
to the reciprocal of the time span of interest. Such systems are called sti. For a sti
problem, solutions can change on a time scale that is very short compared to the interval
of integration, but the solution of interest changes on a much longer time scale. Methods
not designed for sti problems are ineective on intervals where the solution changes slowly
because they use time steps small enough to resolve the fastest possible change.
In a real-time simulation, xed step solvers must be used due to real time constraints.
There are ve dierent xed step-size integration methods, intended for real-time simula-
tions in Simulink:
53
Figure 4.3: The HAL schematic diagram
54
Tank1
Flo...
Q
P T
B
ServoVa...
Cylinder...
Fixed1
InertialSystem1
x
y
BoxBody1
r={0,0.1,0}
Prismatic...
S
t
e
p
1
s
t
a
r
t
T
i
.
.
.
s
PositionSensor1
PID1
Ti=0.5 -
F
e
e
d
b
a
c
k
1
P T
B
ServoVa...
Con...
PID2
Ti=0.5
-
Feedback2
Step2
startTim...
R
e
l
i
e
.
.
.
Tank2
Inertia1
J=1
AngleSen...
phi
Figure 4.4: The Dymola model of the HAL
55
Ti me[second]
P
o
s
i
t
i
o
n
[
m
]
Figure 4.5: The simulation result of the HAL model in Dymola for a vertical direction
56
Ti me[second]
A
n
g
l
e
[
r
a
d
i
a
n
]
Figure 4.6: The simulation result of the HAL model in Dymola for a horizontal direction
57
ode5, the Dormand-Prince formula
ode4, RK4, the fourth-order Runge-Kutta formula
ode3, the Bogacki-Shampine formula
ode2, Heuns method, also known as the improved Euler formula
ode1, Eulers method
But above solvers are not suitable to sti systems. Therefore OPAL-RT has developed
a plug-in technology called ARTEMIS(Advanced Real-Time ElectroMechanical Simulation)
as a plug-in module to improve the xed time step behavior of sti systems. The ARTEMIS
algorithm allows xed time step simulation to obtain results almost identical to those of
variable time step simulation, but in constant time suitable for HIL simulations [5].
4.2.3 RT Simulation of the HAL
The model in Figure 4.4 is converted into a Simulink model, and the Simulink model is
described in Figure 4.7. Two PID controllers are added to the HAL model with position
feedback. Then RT simulation of the HAL is implemented by two simulation tools being
studied, namely xPC Target and RT-Lab. All processes are handled by the simulation tools
without writing any low-level code.
4.2.3.1 xPC Target
Figure 4.8 illustrates the procedures of real-time simulation by xPC Target which is seam-
lessly integrated with Matlab. First, a C-mex le is generated by Dymola. Then the C-mex
le is wrapped as a Simulink block. After wrapping, real-time C code is made by Real-
Time Workshop (RTW). Using Microsoft Visual C/C++, an executable le is made from
the real-time C code. The executable le is downloaded to a target PC via serial (RS232)
or network (TCP/IP) communication.
xPC Target Remote Control Tools (RCT) is provided in order to interact with the target
PC. RCT controls a target PC and a executable le in the target PC. Beside RCT, the
command line interface in Matlab and the xPC Target API are also provided to allow users
58
Figure 4.7: The Simulink Model of the HAL
The Dymolamodel
Serial/
Ethernet
Executable file
Real-time C code
The Simulinkmodel
by RTW
by Microsoft
Visual C/C++
by C-mex file
Serial/
Ethernet
Host PC Target PC
xPCTarget Real -Time Kernel
(Loaded from a boot disk)
by xPCTarget
RCT
MatlabEnvironment
xPCTarget
Figure 4.8: xPC Target conguration
59
to create custom GUI applications running on the host PC. With xPC Target, everything
can be done within Matlab.
4.2.3.2 RT-Lab
RT-Lab uses either of Matlab/Simulink or MATRIXx/Systembuild tools as a front-end for
editing and viewing graphic models in block-diagram format. Real-Time Workshop or MA-
TRIXx code generator is used for auto code generation. RT-Lab implements distributed
simulation in the form of a PC cluster. Starting with Simulink or Systembuild models, com-
plex simulations can be subdivided for execution on separate processors. Simply subdivide
the models and add the inter-processor connection blocks supplied with RT-Lab.
The procedures are described in Figure 4.9. Because RT-Lab supports distributed sim-
ulation, before using the Simulink model of the HAL created by Dymola must be divided
into subsystems. Each of subsystems represents one node in the real-time network, and
three types of which are available [40]:
The Dymolamodel
Serial/
Ethernet
Real-time C code
The Simulinkmodel
by RTW
by C-mex file
Serial/
Ethernet
Host PC Target PC
MatlabEnvironment
QNX
Executable file
RT-Lab
by gcc
RT-Lab
Data retrieval by ftp
RT-Lab
Figure 4.9: RT-Lab conguration
Console: The Console subsystem is the station operating under Windows OS, where
the user interacts with the system. It contains all the Simulink/SystemBuild blocks
60
related to acquiring and viewing data. There can be only one Console subsystem per
model.
Master: The Master subsystem is responsible for the models real-time calculation,
for the overall synchronization of the network, and for I/O communication. There
can be only one Master subsystem per model.
Slaves: Slave subsystems are also responsible for performing calculations in the model,
and are driven by the Master subsystem, which synchronizes the whole network. Slave
subsystems can include I/O blocks, but while these will be synchronized within the
Slave subsystems, they will not be synchronized with I/O communication within the
Master subsystem. There can be as many Slaves subsystems as there are CPUs.
In the HAL model, one Master and one Console subsystem are used. The grouped model
which is converted into real-time C code for QNX is shown in Figure 4.10. The grouped
model is converted into real-time C code for QNX. Then the code is transferred to the target
PC which runs in QNX by ftp protocol. After that, an executable le is made by GCC in
the target PC. Start and stop commands are sent to the target PC from the host PC. To
obtain all data after the simulation, data should be stored on the target PCs hard drive.
The data can be transferred to the host PC, but this transfer is not automatic. Therefore
a separate ftp client program is utilized in the data transfer.
Table 4.1 summarizes the comparison of xPC Target and RT-Lab.
The implementation of a real-time simulation of the HAL is attempted, but the HAL
model in Dymola itself could not be used in real-time. When implementing a real-time
simulation, the integration solver must be a xed step solver in xPC Target and RT-Lab.
If xed step size is larger than 0.000002 seconds(2 seconds) with Rkx4 (Runge-kutta
4th order method), the simulation cannot be run. Because the large xed step size makes
the system unstable. But the xed step size is too small, it cannot be implemented in a
real-time simulation. The HAL model in Dymola takes more than 30 minutes with Rkx4
when the total time of the simulation is 10 seconds.
61
(a) Main model (b) SC HAL
(c) SM HAL
Figure 4.10: The simulink model for RT-Lab of the HAL
Table 4.1: The comparison between xPC Target and RT-Lab
Section xPC Target RT-Lab
User Interface Matlab GUI Stand alone program
Modelling Tool Simulink Simulink
Code Generation Real-Time Workshop Real-Time Workshop
RTOS xPC Target Real-Time Kernel QNX
Compiler Visual C/C++ or Wacom C/C++ gnu GCC
Data Retrieval Included A separate ftp program
Distributed Simulation Not available Available
62
4.3 Real-Time implementation of simple models
Because the calculation of the HAL model in Dymola cannot be completed in the xed step
size, 0.0005 seconds, the real-time simulation of the HAL model cannot be implemented.
The xed step size can be longer than 0.0005 seconds, but that leads the model to a dierent
result compared to the result using a variable step size solver. To understand more about
this problem, we tried to use several simple mechanical and hydraulic models in Dymola.
Then we attempted to implement real-time simulations of the models. Following subsections
show the models and the results. Task Execution Time(TET) is calculated and compared
for each model, because time constraints are the most important aspects in a real-time
simulation. Also the results of real-time simulations should be the same as simulations
which use variable step size solvers. So the results are compared in order to verify the
accuracy of the simulations. The sampling rate is 2kHz if it is not specied, and default
values in Dymloa are used in simulations
4.3.1 Simple mechanical models
A Simulink model which is converted from a Dymola model, is a C-mex le. To compare
a pure Simulink model which is made by only Simulink blocks with a Simulink model
which is converted from a Dymola model, a simple mechanical model is created in Dymola
and Simulink. Figure 4.11 illustrates a simple mechanical model in Dymola. Figure 4.12
describes the model in Simulink. Mass is 1 kg, the spring constant is 1 N/m, and the
damping constant is 1 N/(m/s). A force is given to the system as a sinusoidal input whose
magnitude is 1 N and frequency is 1 Hz.
Fixed1
f
Force1
SpringDamper1
SlidingMass1
Sine1
freqHz={1}
Figure 4.11: Simple mechanical system model in Dymola
The position of the mass is compared in order to evaluate the accuracy of simulations
63
(a) Mass, spring, damper subsystem
(b) Simple mechanical system
Figure 4.12: Simple mechanical system model in Simulink
64
which use several dierent integration solvers. Figure 4.13(a) and 4.13(b) show the results
of the simulation of the model in Figure 4.11 and Figure 4.12, respectively. DOPRI5 in
Figure 4.13(a) and ode45 in Figure 4.13(b) are variable step solvers, and Rkx4 and ode4
are xed step solvers. In variable step solvers, the step size is calculated in the solvers. The
Simulink ode45 solver only calculates 52 times for 10 seconds. This is too small to show
the response of the model but the results obtained are accurate. In contrast, the Dymola
variable step solver shows enough information for the response of the model. DOPRI5 and
ode45 use the same algorithm to solve integration problems, and Rkx4 and ode4 use the
same algorithm to solve the problems with a xed step size. The results tell us that ode4
whose step size is 0.0005 seconds, can be used in real-time simulations if total calculations
are completed within the step size.
The real-time simulation of models in Figure 4.11 and 4.12 are implemented with xPC
Target and RT-Lab, and Figure 4.14 shows TET of the real-time simulation of the models.
A xed step solver is Rkx4 and a xed step size is 0.5 milliseconds. From the Figure 4.14,
the maximum TET at each experiment is constant, and the TET is very small compared
to the step size. In Figure 4.15, the maximum TET at each time is varied from 0.0350
to 0.1700 milliseconds using RT-Lab. In real-time simulations, the worst case should be
considered. Therefore xPC Target and RT-Lab show similar TET.
RT-Lab does not handle the Simulink model which is converted from the Dymola model
well. At this time, the Dymola model is not tested in RT-Lab.
The results from the Figure 4.13, 4.14, and 4.15, the real-time simulation of the simple
mechanical model can be implemented within the sampling time(0.0005 seconds) with good
accuracy.
A higher order system is tested to see how the TET increases when the system order is
increased with xPC Target. Figure 4.16 illustrates the higher order system, and Figure 4.17
shows TET in xPC Target. The dierence between the worst TETs in the simple mechanical
system and in the higher order mechanical system is 0.0025 milliseconds (0.1827-0.1802).
Therefore the order of the system may not aect the worst case calculation time signicantly
for this case. However it will be noticed that the typical and minimum computation times
65
are increased from 0.1802 to 0.1827 milliseconds.
4.3.2 Simple hydraulic models
A simple hydraulic model is illustrated in Figure 4.18, and this system is also implemented
in real-time using xPC Target. All components are ideal components in Dymola, meaning
there are no hidden but realistic eects that would be present in an actual piece of hardware.
The results provided by a angle sensor are compared in three simulation environments, i.e.,
Dymola, Simulink, and xPC Target. The integration solvers are DOPRI5, ode45, and ode4(a
xed step size is 0.0005 seconds), respectively. And the results provided by the sensor in
the simulation environments are the same. TET of the model is shown in Figure 4.19.
The other simple hydraulic model consists of the same components, but non-ideal com-
ponents are used instead of the ideal components. In Dymola, the angle position is identical
to the ideal component model when the Dassal solver is used. The DOPRI5 solver is at-
tempted to solve the non-ideal model, but it fails. The error message during the execution
in Dymola says that it should use Lsodar or Dassal solver, because the non-ideal model
needs the integration method with root nder. But DOPRI5 does not have a root nder.
Also xed step solvers do not have this function, therefore the results of the real-time sim-
ulation are dierent from the results using Dassal solver. Figure 4.20 shows the dierent
results. AngleSensor1 is the result of the non-ideal hydraulic model using the Rkx4 solver,
and AngleSensor2 is the result of the ideal hydraulic model using the Dassal solver. Due to
the lack of root nding in ode45(DOPRI5), in Simulink the model takes much time to sim-
ulate 10 seconds. Because of this dierence, the real-time implementation of the non-ideal
components is not worthwhile.
4.3.3 F14 model
To see how a complex system is handled in xPC Target and RT-Lab, a F14 model, shipped
with Matlab, which is modelled by only Simulink blocks, is tested in both simulation tools.
Figure 4.21 shows a F14 model, and the modied model for RT-Lab is described in Fig-
ure 4.22. In the RT-Lab Simulink model, the OpSimulinkInfo block which is supplied by
Opal-RT is added to calculate task execution time for the model.
66
0 1 2 3 4 5 6 7 8 9 10
0.04
0.02
0
0.02
0.04
0.06
0.08
0.1
0.12
time[second]
p
o
s
i
t
i
o
n
[
m
]
The results of the simple mechanical model in Dymola
DOPRI5
Rkfix4 with 0.0005s fixed step size
(a) The result of the Figure 4.11 model
0 1 2 3 4 5 6 7 8 9 10
0.04
0.02
0
0.02
0.04
0.06
0.08
0.1
0.12
The results of the simple mechanical model in Simulink
p
o
s
i
t
i
o
n
[
m
]
time[second]
ode45(DormandPrince)
ode4 with 0.0005s fixed step size
(b) The result of the Figure 4.12 model
Figure 4.13: The result of the simple mechanical model
67
0 1 2 3 4 5 6 7 8 9 10
0
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
0.18
0.2
time[second]
T
a
s
k
E
x
e
c
u
t
i
o
n
T
i
m
e
[
m
i
l
l
i
s
e
c
o
n
d
]
Implementation of the simple mechanical system(Dymola block)Five times
max 0.1794
max 0.1794
max 0.1794
max 0.1802
max 0.1794
(a) TET in xPC Target using the Figure 4.11 model
0 1 2 3 4 5 6 7 8 9 10
0
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
0.18
time[second]
T
a
s
k
E
x
e
c
u
t
i
o
n
T
i
m
e
[
m
i
l
l
i
s
e
c
o
n
d
]
Implementation of the simple mechanical system(Pure Simulink block) Six times
max 0.1702
max 0.1702
max 0.1702
max 0.1702
max 0.1702
max 0.1702
(b) TET in xPC Target using the Figure 4.12 model
Figure 4.14: TET of the simple mechanical model in xPC Target
68
0 1 2 3 4 5 6 7 8 9 10
0
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
0.18
time[second]
T
a
s
k
E
x
e
c
u
t
i
o
n
T
i
m
e
[
m
i
l
l
i
s
e
c
o
n
d
]
Implementation of the simple mechanical system(Simulink block) in RTLab
max 0.1680
max 0.1690
max 0.1700
max 0.0380
max 0.1680
max 0.0350
(a) TET in RT-Lab using the Figure 4.12 model
Figure 4.15: TET of the simple mechanical model in RT-Lab
69
SpringDamper1
SlidingMass1
SpringDamper2
SlidingMass2
SpringDamper3
SlidingMass3
SpringDamper4
SlidingMass4
SpringDamper5
SlidingMass5
SpringDamper6
SlidingMass6
SpringDamper7
SlidingMass7
SpringDamper8
SlidingMass8
SpringDamper9
SlidingMass9
f
Force1
s
PositionSensor1
Figure 4.16: High order system model in Dymola
0 1 2 3 4 5 6 7 8 9 10
0
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
0.18
0.2
Implementation of the mechanical system(Dymola block)
time[second]
T
a
s
k
E
x
e
c
u
t
i
o
n
T
i
m
e
[
m
i
l
l
i
s
e
c
o
n
d
]
max 0.1827
max 0.1802
max 0.1811
max 0.1811
max 0.1802
Figure 4.17: TET in xPC Target using the Figure 4.16 model
70
IdFlowSource2
Q
IdConMot2
TankNoRes2
Inertia2
J=1
AngleSen...
phi
OrificeNoStates1
Figure 4.18: Simple hydraulic system model in Dymola
0 1 2 3 4 5 6 7 8 9 10
0
0.05
0.1
0.15
0.2
0.25
time[second]
T
a
s
k
E
x
e
c
u
t
i
o
n
T
i
m
e
[
m
i
l
l
i
s
e
c
o
n
d
]
Implementation of the simple hydraulic system(Dymola block)
max 0.219
max 0.2163
max 0.2255
max 0.2179
max 0.2171
Figure 4.19: TET in xPC Target using the simple hydraulic model in Dymola with ode4
solver
71
Ti me[second]
A
n
g
l
e
[
r
a
d
i
a
n
]
Figure 4.20: The results of the ideal and the non-ideal hydraulic models in Dymola
72
The Figure 4.23 shows the TET of the model in both tools. The maximum TET in
xPC Target is similar to that in RT-Lab. Using a real-time simulation in a HIL simulation,
requires that there be an added interface to the outside real world. When this interface is
added to the real-time simulation, TET may increase. Therefore interface blocks are added
to the F14 model. Figure 4.24 displays TET of the F14 model with IO blocks in both tools.
These IO blocks are supplied by Mathworks and Opal-RT. In Figure 4.24(b), the Maximum
TET is greater than 3.0 milliseconds. This strange value is investigated in Figure 4.25.
From Figure 4.25(a) this maximum TET only comes at the initialization process. xPC
Target does not include this process. So, if this process is excluded, both simulation tools
show similar TET.
Figure 4.21: F14 Simulink model
4.3.4 xPC Target and RT-Lab
xPC Target and RT-Lab are rapid prototype development tools for a HIL simulation. xPC
Target is well integrated with Matlab, and RT-Lab is a stand alone windows program. Both
73
(a) Main Model (b) SC F14
(c) SM F14
Figure 4.22: F14 Simulink model for RT-Lab
74
5 10 15 20 25 30
0
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
0.18
Implementation of the F14 model in xPC Target
time[second]
T
a
s
k
E
x
e
c
u
t
i
o
n
T
i
m
e
[
m
i
l
l
i
s
e
c
o
n
d
]
max 0.1727
(a) Task Execution Time of F14 model in xPC Target
0 5 10 15 20 25 30
0
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
0.18
Implementation of the F14 model in RTLab
time[second]
T
a
s
k
E
x
e
c
u
t
i
o
n
T
i
m
e
[
m
i
l
l
i
s
e
c
o
n
d
]
max 0.1690
(b) Task Execution Time of F14 model in RT-Lab
Figure 4.23: TET of the F14 model in xPC Target and RT-Lab
75
5 10 15 20 25 30
0
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
0.18
0.2
Implementation of the F14 model in xPC Target
time[second]
T
a
s
k
E
x
e
c
u
t
i
o
n
T
i
m
e
[
m
i
l
l
i
s
e
c
o
n
d
]
max 0.1811
(a) Task Execution Time of F14 model with IO blocks in xPC Target
0 5 10 15 20 25 30
0
0.5
1
1.5
2
2.5
3
3.5
Implementation of the F14 model in RTLab
time[second]
T
a
s
k
E
x
e
c
u
t
i
o
n
T
i
m
e
[
m
i
l
l
i
s
e
c
o
n
d
]
max 3.0230
(b) Task Execution Time of F14 model with IO blocks in RT-Lab
Figure 4.24: F14 Simulink model with IO blocks in xPC Target and RT-Lab
76
0 1 2 3 4 5 6 7 8 9 10
0
0.5
1
1.5
2
2.5
3
3.5
Iteration number
T
a
s
k
E
x
e
c
u
t
i
o
n
T
i
m
e
[
m
i
l
l
i
s
e
c
o
n
d
]
Implementation of the F14 model from 0 to 9 iteration in RTLab
max 3.023
(a) Task Execution Time from 0 to 9 iteration number
0 5 10 15 20 25 30
0
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
0.18
Implementation of the F14 model except a initialization step in RTLab
time[second]
T
a
s
k
E
x
e
c
u
t
i
o
n
T
i
m
e
[
m
i
l
l
i
s
e
c
o
n
d
]
max 0.1790
(b) Task Execution Time except a initialization time in RT-Lab
Figure 4.25: Task Execution Time of the F14 model with IO blocks in specied time in
RT-Lab
77
need two computers, a host PC and a target PC, and use Simulink, RTW, and TLC for
their add-on tools. The dierence between xPC Target and RT-Lab are as follows:
1. Installation of software and conguration of host and target PCs.
xPC Target can be installed during installation of Matlab, and does not need a special
conguration for a target PC. The target PC is booted from a boot disk which is
created in the host PC. Because of this, a target PC can be used in other ways if not
used in simulation without installing a new operating system.
RT-Lab utilizes QNX as RTOS of the target PCs. After installing QNX in the target
PCs, some programs should be installed on a host PC and target PCs. This process
uses ftp and tar programs.
2. Modifying Simulink model
xPC Target can use the Simulink model without modifying it, but RT-Lab must
change the Simulink model to use it. The Simulink model must be divided into sub-
systems such as Control, Master, and Slaves subsystems. This comes from supporting
distributed simulation. xPC Target does not support distributed simulation at this
time.
3. Development Environment
xPC Target only supports Matlab, but RT-Lab supports Matlab as well as MATRIXx.
xPC Target uses Visual C/C++ or Watcom C/C++, on the other hand, RT-Lab uses
GCC. Data retrieval is done within Matlab in xPC Target, but RT-Lab does not have
a data retrieval function. Therefore a separate ftp client program must be used to
transfer data from the target PC to the host PC.
4. Dymola model
A Dymola model is converted into a Simulink model, and the Simulink model can be
used in xPC Target without modifying the Simulink block. But RT-Lab needs several
steps to use the Simulink model. At this point, the steps are not successful.
78
If the real-time simulation is implemented with both simulation tools, the result and
TET are similar to each other. Therefore the performance of the both simulation tools
are good enough to use in real-time simulation. But non-ideal hydraulic models which are
converted from a Dymola model cannot be implemented in real time using both simulation
tools. This originates from the integration solvers. The non-ideal hydraulic models need
integration solvers which have a root nder. The xed step solvers in the both simulation
tools dont have this function. Therefore the HAL model cannot be implemented in real
time, and the simulation of the non-ideal hydraulic model shows dierent results with
dierent integration solvers such as Dassal and Rkx4.
When a real-time simulation needs distributed simulations, there is no choice but RT-
Lab. If distributed simulations are not needed, xPC Target is the best choice for a real-time
simulation tool.
79
CHAPTER V
CONCLUSIONS AND FUTURE WORK
5.1 Concluding Remarks
The work done in this thesis is developing a new software framework of the VAL system
and implementing the real-time simulation of the HAL. Each is summarized as below:
1. The New Software Framework
Four programs and one web site are made to successfully build the VAL system. The
RTOS was changed to RTLinux from Windows NT with Hyperkernel. The client
program was written in Java 2 and Swing for better performance. For easy upgrade,
maintenance, and better performance, each program is separated to perform a single
task.
The VAL Web Site: user login, data retrieval, plotting results, and time reserva-
tions are done through the VAL web site.
rt hal.o: this program, based upon POSIX and Multi-thread programming,
controls the HAL every 1 millisecond with the PID controllers through the STG
I/O card.
hal trajectory: hal trajectory programmed in C checks the input values,
generates the homing positions, and runs rt hal.o
hal server: hal server accepts a connection and receives appropriate parame-
ters from the client program (UI hal.class), and sends the status of experiments
are sent back to UI hal.class
UI hal.class: UI hal.class, programmed as a Java Applet, is a client program
and communicates with hal server using TCP/IP protocol. Using Swing com-
ponents, the client program is designed to provide GUI to students.
80
New software platform of the VAL system is better than the previous one in that:
New VAL system has the web site, and this web site has login and scheduler
systems. Data retrieval system is now included in new VAL system. WebCT
was used as Login system in previous VAL system, a separate ftp program was
used to retrieve data from the previous system, and time reservation was done
manually.
New client program does not have a plotting function. The previous client pro-
gram did, but students couldnt print out the result. This function is now in-
cluded in the new web site.
Now the plotting function is included in the VAL web site not in the client
program. The function of plotting several results in one image le is added, and
the image is incorporated with an html le. Students can print out and save the
image. The previous system didnt have these functions.
The previous system didnt have data retrieval system, therefore a separate ftp
program was used to receive data from the system. Now the data retrieval system
is included in the web site, so students dont need any other program to retrieve
data from the VAL system.
Every program is well designed for easy upgrade and maintenance. For exam-
ple, hal data.conf takes an important role in the VAL system. A connection
between the client program and the RTLinux program is only hal data.conf.
A direct connection between these two programs can be made, and it is easy
to implement compared with the current VAL system. But the VAL system
could be more dicult to upgrade and maintain if the direct connection was
used. When a new control law is needed to test in the HAL, rt hal.o and
hal trajectory are changed without modifying the server and the client pro-
gram due to hal data.conf or vice versa.
2. The Real-Time Simulation
81
The real-time simulation of the HAL is implemented by the following procedures:
(a) Dynamic modelling of the HAL in Dymola
HyLib is used to model the HAL in Dymola. HyLib supports the necessary
components such as a pump, a servovalve, a relief valve, a motor, and a cylinder.
(b) Converting the Dymola model to the Simulink model
(c) Real-Time simulation with xPC Target and RT-Lab
We attempted to implement a real-time simulation of the HAL using the above pro-
cedures. But the resulting model of the HAL in Dymola could not be run in real
time. Simple mechanical models in Dymola show that the process can be used in
real-time simulation, but simple hydraulic models in Dymola cannot be implemented
in real time. This comes from non-ideal hydraulic components. The hydraulic model
which is composed of non-ideal hydraulic components should be integrated with a
integration solver which has a root nder. But the xed step solvers in xPC Target
and RT-Lab dont provide this feature. Due to this reason, the non-ideal hydraulic
model cannot be implemented in real time.
The performance of xPC Target and RT-Lab is similar to each other in TET(Task
Execution Time) and accuracy. Both simulation tools use Simulink, RTW(Real-Time
Workshop), and TLC(Target Language Compiler) for their add-on tools. But the use
of xPC Target is easier than that of RT-Lab. xPC Target is well integrated with
Matlab, so the procedure of using xPC Target is familiar to Simulink users. Also a
Simulink model which is made by C program, called a C-mex Simulink model, is used
just like a pure Simulink model which is composed of only Simulink blocks like the
F14 model. But RT-Lab doesnt handle the C-mex Simulink model automatically.
Users should take care of it. When the result of a real-time simulation needs to be
transferred to the host computer, xPC Target can use the Matlabs workspace, but
RT-Lab should use a separate ftp program. On distributed simulations, xPC Target
doesnt provide this feature, however RT-Lab provides this. Also RT-Lab can work
with MATRIXx, but xPC Target only works with Matlab.
82
In considering all of dierences between xPC Target and RT-Lab, both simulation
tools have their own advantages and disadvantages. When the simulation needs to
be distributed, RT-Lab is the choice. But if that is not needed, the selection of xPC
Target is better than that of RT-Lab as a real-time simulation tool.
5.2 Future Work
Future works can include:
1. The VAL system
Adding sound
Students can see live motion of the HAL from the network camera, but they
cannot hear the sound from the HAL. Listening to sound can make students feel
that they are at the site of the experiment.
Controlling the Network Camera
The network camera is xed to show live motion of the HAL. If the angle and
the zoom of the network camera could be changed by students, they may feel
more comfortable than now.
Adding Force Feedback Function
Currently the position feedback is used in the VAL system, but a force trans-
ducer is provided in the HAL. Adding force feedback function requires changing
rt hal.o, hal trajectory, and UI hal.class.
Improving hal trajectory
Pre-dened parameters of the VAL system and messages on errors and status of
the experiment are hard coded into hal trajectory. Saving the parameters and
the messages in les would allow an instructor and T.A. to change them without
modifying the programs.
2. The Real-Time Simulation
83
Examine Integration Solvers
Using non-ideal hydraulic components in Dymola requires an integration solver
which has a root nder. The result of a simulation including a real-time simu-
lation may be dierent when dierent integration solvers are used. If we have
DAE(Dierential Algebraic Equation), we have to use a DAE-solver. In Model-
ica, we can use DAE, so we need to know the details of the integration solvers.
Investigate HyLib components
HyLib components may be categorized as ideal components and non-ideal com-
ponents. The ideal hydraulic model in Dymola can be implemented in real time,
but the other cant. In order to understand this problem, we need to investigate
HyLib components.
Use Dymola model in RT-Lab
A Simulink model which is converted from a Dymola model cannot be used
in RT-Lab at this time. Opal-RT provides necessary steps in order to use the
Simulink model, but the steps are not successful. Therefore there should be more
investigation in the use of the Simulink model in RT-Lab.
3. Implications of this work on modelling and control of dynamic systems.
The hardware and software components for advanced development of control systems
is available and capable. Some of the desired functions for rapid development are not
well integrated and will require further work if they are to be useful. An example
is the generation of real time simulation code via Modelica models. Also, a better
understanding of the worst case TET and how this could be reduced would be helpful,
since the worst case is many times larger than the average.
84
APPENDIX A
DATA CONFIGURATION FILE
# Experiment Type (1 -> PID, 2 -> Trajectory Planning)
;1
# Feedback Type (1 -> Position Feedback)
;1
# Input Type (1 -> Step Input, 2 -> Sinusoidal Input, 3 -> PRBN)
;1
# Amplitude (Maximum is ... [milli-inch])
;10000
# Frequency (Maximum is 1.0 [Hz])
;0.0
# P Gain for X axis (Maximum is 200.0, Minimum is 0.0, If negativ, not use this axis)
;100.0
# I Gain for X axis (Maximum is 100.0, Minimum is 0.0)
;0.0
# D Gain for X axis (Maximum is 100.0, Minimum is 0.0)
;0.0
# P Gain for Y axis
;-1.0
# I Gain for Y axis
;0.0
# D Gain for Y axis
;0.0
# Move 1 (Total Time, Ramp Time, Maximum Velocity, Axis(0->X, 1->Y))
;0.0, 0.0, 0.0, 0.0
85
# Move 2
;0.0, 0.0, 0.0, 0.0
# Move 3
;0.0, 0.0, 0.0, 0.0
# Move 4
;0.0, 0.0, 0.0, 0.0
# Move 5
;0.0, 0.0, 0.0, 0.0
# Move 6
;0.0, 0.0, 0.0, 0.0
86
REFERENCES
[1] Abourida, S., Dufour, C., and Belanger, J., Real-time pc-based simulator of
electric systems and drives, in Seventeenth Annual IEEE Applied Power Electronics
Conference and Exposition, vol. 1, pp. 433 438, IEEE, 10 14 March 2002.
[2] Aktan, B., Bohus, C. A., Crowl, L. A., and Shor, M. H.,
Distance learning applied to control engineering laboratories.
http://www.ece.msstate.edu/hagler/Aug1996/009/cd/.
[3] Antsaklis, P., Basar, T., DeCarlo, R., McClamroch, H., Spong, M., and
Yurkovich, S., Report on the nsf/css workshop on new directions in control en-
gineering education, IEEE Control Systems Magazine, vol. 19, pp. 5358, October
1999.
[4] Babbitt, G. R. and Moskwa, J. J., Implementation details and test results for a
transient engine dynamometer and hardware in the loop vehicle model, in Proceedings
of the 1999 IEEE International Symposium on Computer Aided Control System Design,
pp. 569 574, IEEE, August 22 27 1999.
[5] Baracos, P., Murere, G., Rabbath, C. A., and Jin, W., Enabling pc-based hil
simulation for automotive applications, in IEEE International Electric Machines and
Drives Conference, pp. 721 729, IEEE, June 17 20 2001.
[6] Beater, P., Hylib Tutorial.
[7] Brennan, S., Alleyne, A., and DePoorter, M., The illinois roadway simulator-a
hardware-in-the-loop testbed for vehicle dynamics and control, in Proceedings of the
1998 American Control Conference, vol. 1, pp. 493 497, IEEE, June 24 26 1998.
[8] Buchholz, B. M., Lei, X., and Retzmann, D., Advanced solutions for power
system analysis-computer study and real-time simulation, in International Conference
on Power System Technology, vol. 2, pp. 613 618, IEEE, December 4 7 2000.
[9] Butenhof, D. R., Programming with POSIX Threads. Addison-Wesley, 1997.
[10] Champagne, R., Dessaint, L.-A., Sybille, G., and Khodabakhchian, B., An
approach for real-time simulation of electric drives, in 2000 Canadian Conference on
Electrical and Computer Engineering, vol. 1, pp. 340 344, IEEE, 7 10 March 2000.
[11] Cho, S. M. and Kim, T. G., Analysis of feasibility for real time simulation of rt-devs
models, in 2001 IEEE International Conference on Systems, Man, and Cybernetics,
vol. 5, pp. 3069 3074, IEEE, October 7 10 2001.
[12] Corporation, N., Hyperkernel : Real-time for windows nt/2000.
http://www.nematron.com/Software/HyperKernel.shtml.
87
[13] Dufour, C. and Belanger, J., Discrete time compensation of switching events for
accurate real-time simulation of power systems, in The 27th Annual Conference of
the IEEE Industrial Electronics Society, vol. 2, pp. 1533 1538, IEEE, 29 November
2 December 2001.
[14] Dynasim AB, Dymola Users Manual.
[15] Elmqvist, H., Mattsson, S. E., and Otter, M., Modelica a language for physi-
cal system modeling, visualization and interaction, IEEE Transactions on Education,
vol. 46, pp. 79 87, February 2003.
[16] Ferreira, J. A. and de Oliveira, J. E., Modeling of hydraulic systems for
hardware-in-the-loop simulation:a methodology proposal, in 1999 International Me-
chanical Engineering Congress & Exposition, 14 19 November 1999.
[17] FSMLabs, I., Real-time linux. http://www.rtlinux.org/.
[18] Fung, Y. F., Ho, T. K., and Cheung, W. L., Real-time simulation for power
systems based on parallel computing - an empirical study, in International Conference
on Advances in Power System Control, Operation and Management, vol. 2, pp. 517
521, IEE, 30 October 1 November 2000.
[19] fur Automatisierungstechnik und Prozessinformatik, L., Real systems in
virtual laboratory (rsvl). http://www.esr.ruhr-uni-bochum.de/Rsvle/Rsvl.html.
[20] fur Automatisierungstechnik und Prozessinformatik, L., Virtual control lab
3.1. http://www.esr.ruhr-uni-bochum.de/VCLab/.
[21] GRAY, J. S., INTERPROCESS COMMUNICATIONS IN UNIX: The Nooks and
Crannies. Prentice Hall PTR, 1998.
[22] Grega, W., Hardware-in-the-loop simulation and its application in control educa-
tion, in 29th Annual Frontiers in Education Conference, vol. 2, pp. 12b67 12b612,
IEEE, 10 13 November 1999.
[23] Grehan, R., Moote, R., and Cyliax, I., Real-Time Programming. Addison-Wesley,
1998.
[24] Henry, J., Resource center for engineering laboratories on the web.
http://chem.engr.utc.edu/defaultf.htmlV.
[25] Hildebrand, D., A Scalable Microkernel POSIX OS for Realtime Systems. QNX
Software Systems Ltd.
[26] Karweit, M., A virtual engineering/science laboratory course.
http://www.jhu.edu/ virtlab/virtlab.html.
[27] Kesseler, E., Deploying networked real-time simulation, putting the virtual enter-
prise to work some aerospace experience, in Proceedings of the 35th Annual Hawaii
International Conference on System Sciences, pp. 3739 3746, IEEE, 7 10 January
2002.
[28] Koeppen, K. B., Virtual access hydraulics experment for system dynamics and con-
trol education, Masters thesis, GEORGIA INSTITUTE OF TECHNOLOGY, 2001.
88
[29] Lee, J.-C. and Suh, M.-W., Hardware-in-the loop simulator for abs/tcs, in Pro-
ceedings of the 1999 IEEE International Conference on Control Applications, vol. 1,
pp. 652 657, IEEE, August 22 27 1999.
[30] Ltd., Q. S. S., Qnx realtime operating system. http://www.qnx.com.
[31] Mathworks, Inc., Real-Time Workshop for Use with Simulink, Getting Started.
[32] Mathworks, Inc., Real-Time Workshop for Use with Simulink, Users Guide.
[33] Mathworks, Inc., Using Simulink.
[34] Mathworks, Inc., Writing S-Functions.
[35] MATTHEW, N. and STONES, R., BEGINNING Linux Programming. WROX
PRESS, 1996.
[36] Mattsson, S. E., Otter, M., and Elmqvist, H., Modelica hybrid modeling and
ecient simulation, in Proceedings of the 38th IEEE Conference on Decision and
Control, vol. 4, pp. 3502 3507, IEEE, 7 10 December 1999.
[37] Mianzo, L., A transmission model for hardware-in-the-loop powertrain control sys-
tem software development, in Proceedings of the 2000 IEEE International Conference
on Control Applications, pp. 1 8, IEEE, 25 27 September 2000.
[38] Microsystems, S., Overview of the swing api.
http://java.sun.com/docs/books/tutorial/uiswing/mini/overview.html.
[39] Negri, A., Scannicchio, D., Touchard, F., and Vercesi, V., Multi Thread pro-
gramming.
[40] Opal-RT, RT-LAB v6.1 Users Manual.
[41] Otterbach, R. and Leinfellner, R., Real-time simulation, requirements and the
state of technology, Elektronik, August 1999.
[42] Pollini, L. and Innocenti, M., A synthetic environment for dynamic systems con-
trol and distributed simulation, IEEE Control Systems Magazine, vol. 20, pp. 4961,
April 2000.
[43] Powell, B. K., Sureshbabu, N., Bailey, K. E., and Dunn, M. T., Hardware-
in-the-loop vehicle and powertrain analysis and control design issues, in Proceedings
of the 1998 American Control Conference, vol. 1, pp. 483 491, IEEE, 24 26 June
1998.
[44] QUANSER, Weblab. http://www.controlab.com/.
[45] Rabbath, C., Abdoune, M., and Belanger, J., Eective real-time simulations of
event-based systems, in Proceedings of the 2000 Winter Simulation Conference, vol. 1,
pp. 232 238, IEEE, December 10 13 2000.
[46] Rabbath, C., Desira, H., and Butts, K., Eective modeling and simulation of
internal combustion engine control systems, in Proceedings of the 1998 American
Control Conference, vol. 2, pp. 1321 1326, IEEE, June 25 27 2001.
89
[47] Raman, S., Sivashankar, N., Milam, W., Stuart, W., and Nabi, S., Design and
implementation of hil simulators for powertrain control system software development,
in Proceedings of the 1999 American Control Conference, vol. 1, pp. 709 713, IEEE,
2 4 June 1999.
[48] Rouse, M. D., Design and evaluation of a remote access hydraulic manipulator for
system dynamics and controls education, Masters thesis, GEORGIA INSTITUTE
OF TECHNOLOGY, 2001.
[49] Rugh, W. J., Real systems in virtual laboratory (rsvl). http://www.jhu.edu/ sig-
nals/.
[50] Schaffnit, J., Sinsel, S., and Isermann, R., Hardware-in-the-loop simulation for
the investigation of truck diesel injection systems, in Proceedings of the 1998 American
Control Conference, vol. 1, pp. 498 502, IEEE, June 24 26 1998.
[51] Schupbach, R. and Balda, J., A versatile laboratory test bench for developing
powertrains of electric vehicles, in 2002 IEEE 56th Vehicular Technology Conference
on Vehicular Technology Conference, vol. 3, pp. 1666 1670, IEEE, September 24 28
2002.
[52] Senta, Y., Sato, Y., and Okamura, E., Hil simulation system for hdd servo
rmware, IEEE Transactions on Magnetics, vol. 38, pp. 22042206, September 2002.
[53] Servo To Go Inc., ISA Bus Servo I/O Card Model 2 Hardware Manual.
[54] Shaw, A. C., Real-Time Systems and Software. JOHN WILEY & SONS, INC., 2001.
[55] Shiakolas, P. S. and Pityabongkarn, D., Development of a real-time digital
control system with a hardware-in-the-loop magnetic levitation device for reinforcement
of controls education, IEEE Transactions on Education, vol. 46, pp. 79 87, February
2003.
[56] Singh, S., Narayana, B., Mishra, A., Banavar, R. N., and Srinivasan, K. V.,
Controller synthesis and real-time simulation of the net recovery phase of a prmotely
piloted vehicle, in the 2002 IEEE International Conference on Control Applications,
pp. 278 283, IEEE, September 18 20 2002.
[57] Stevens, W. R., UNIX NETWORK PROGRAMMING. Prentice Hall PTR, 1998.
[58] Team, T. R. D., Diapm rtai - realtime application interface.
http://www.aero.polimi.it/rtai/.
[59] The Mathworks, I., Stateow 5.1. http://www.mathworks.com/products/stateow/.
[60] the Mathwworks, xpc target real-time kernel.
http://www.mathworks.com/access/helpdesk/help/toolbox/xpc/ch intr3.shtml#16018.
[61] the Modelica Association, Modelica tools.
http://www.modelica.org/tools.shtml.
[62] Tiller, M. M., Introduction to Physical Modeling with Modelica. Kluwer Academic
Publishers, 2001.
90
[63] Venturcom, I., Real-time extension(rtx). http://www.vci.com/.
[64] Wells, R. B., Fisher, J., Zhou, Y., Johnson, B. K., and Kyte, M., Hardware
and software considerations for implementing hardware-in-the loop trac simulation,
in The 27th Annual Conference of the IEEE Industrial Electronics Society, vol. 3,
pp. 1915 1919, IEEE, 29 November 2 December 2001.
[65] Wunnava, S. V., Boppana, N., Saka, A., and Kodiparthy, B., Web based
interactive education and learning scheme(wbiel), in Proceedings IEEE SoutheastCon,
pp. 142 146, IEEE, 5 7 April 2002.
91