the real-time implementation of hardware-in-the loop systems on
TRANSCRIPT
The Real-Time Implementation of Hardware-In-the Loop
Systems on Different RTOS Platforms
A ThesisPresented to
The Academic Faculty
by
Young Joon Lee
In Partial Fulfillmentof the Requirements for the Degree
Master of Science
School of Mechanical EngineeringGeorgia Institute of Technology
July 2003
The Real-Time Implementation of Hardware-In-the Loop
Systems on Different RTOS Platforms
Approved by:
Dr. Wayne J. Book, Adviser
Dr. Chris Paredis
Dr. William Singhose
Date Approved
To my mother and my grandmother,
Chun-ja Kim and Mak-yeop Park
iii
ACKNOWLEDGEMENTS
First of all, I would like to express my deepest and sincerest gratitude to Professor Wayne
J. Book, my thesis adviser for his abundant guidance and inspiration he has given to me
throughout the courses of my Master Degree research. During my school year Professor
Wayne J. Book has been always supportive, helpful, and patient, and he has had an im-
portant effect on my work. He has led me to aim at perfection on every research by asking
constant efforts to try everything that could be done possibly. Without doubt his profes-
sional knowledge and enthusiasm has accelerated me to turn my clumsy, incomplete work
into expert, complete work. It was luckiest and greatest opportunity for me to study under
his advice, which help me to achieve such success.
I also would like to thank to my committee members, Dr. Chris Paredis, and Dr.
William Singhose for their valuable suggestions and comments. Special thanks are given to
Dr. Sooyong Jung for the many hours of discussion, advice, and assistance. The Intelligent
Machine Dynamics Laboratory group also provided many opportunities for me to present
my work and get number of feedback.
I thanks to all my friends for their encouragement and concern they have given to me
during my school year. In particular, Donghoon Lee’s family and Jinho Paik’s family gave
me true warmth of family. My utmost gratitude goes on Younghoon Lee, my brother and
rest of my family in Korea whose unconditional love have guided me to a right track at
every step of my life.
And finally, my appreciation extended to teachers and friends in my life.
iv
TABLE OF CONTENTS
DEDICATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii
ACKNOWLEDGEMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv
LIST OF TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
LIST OF FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii
SUMMARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
I INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Outline of Thesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
II LITERATURE REVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1 Remote Access Laboratory . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Real-Time Simulation and Hardware-In-the-Loop . . . . . . . . . . . . . . 7
III VIRTUAL ACCESS LABORATORY(VAL) . . . . . . . . . . . . . . . . . 10
3.1 System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 Hardware Components of the VAL System . . . . . . . . . . . . . . . . . . 13
3.3 Software Development Environments . . . . . . . . . . . . . . . . . . . . . 16
3.3.1 Portable Operating System Interface(POSIX) . . . . . . . . . . . . 18
3.3.2 Multi-thread(MT) programming . . . . . . . . . . . . . . . . . . . . 19
3.3.3 Linux Application programming and Linux Device Driver program-ming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.4 RTLinux and Linux Device Driver(LDD) programming . . . . . . . 22
3.3.5 Communication between RTLinux program and Linux program . . 23
3.3.6 Network Programming . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.4 Software Implementation of the VAL system . . . . . . . . . . . . . . . . . 24
3.4.1 RT program and Linux program . . . . . . . . . . . . . . . . . . . . 25
3.4.2 Server System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4.3 Client System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
v
3.5 Experimental Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5.1 Performance Test of RTLinux . . . . . . . . . . . . . . . . . . . . . 36
3.6 Response of the HAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
IV REAL-TIME SIMULATION . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1 Development of RT Simulation . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.1 Real-Time System and RTOS . . . . . . . . . . . . . . . . . . . . . 43
4.1.2 Modelling and Modelling Software for RT Simulation . . . . . . . . 47
4.1.3 Auto Code Generator and Compilers . . . . . . . . . . . . . . . . . 49
4.2 Implementation of RT Simulation for HAL system . . . . . . . . . . . . . . 51
4.2.1 Modelling of the HAL . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.2.2 Integration methods . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2.3 RT Simulation of the HAL . . . . . . . . . . . . . . . . . . . . . . . 58
4.3 Real-Time implementation of simple models . . . . . . . . . . . . . . . . . 63
4.3.1 Simple mechanical models . . . . . . . . . . . . . . . . . . . . . . . 63
4.3.2 Simple hydraulic models . . . . . . . . . . . . . . . . . . . . . . . . 66
4.3.3 F14 model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.3.4 xPC Target and RT-Lab . . . . . . . . . . . . . . . . . . . . . . . . 73
V CONCLUSIONS AND FUTURE WORK . . . . . . . . . . . . . . . . . . 80
5.1 Concluding Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.2 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
APPENDIX A — DATA CONFIGURATION FILE . . . . . . . . . . . . 85
REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
vi
LIST OF TABLES
3.1 The specifications of the HAL server computer . . . . . . . . . . . . . . . . 16
3.2 The specifications of the network camera . . . . . . . . . . . . . . . . . . . . 16
4.1 The comparison between xPC Target and RT-Lab . . . . . . . . . . . . . . 62
vii
LIST OF FIGURES
3.1 Procedures for students and an instructor . . . . . . . . . . . . . . . . . . . 12
3.2 VAL System Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 The HAL image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Specification of Velocity Profile . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.5 Conceptual program flow between rt hal.o and hal trajectory . . . . . . 26
3.6 Functions and threads in rt hal.o . . . . . . . . . . . . . . . . . . . . . . . 29
3.7 Flow chart of hal trajectory . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.8 Screen images of selecting data and plotting the selected data . . . . . . . . 33
3.9 Putting UI hal.class and a Network Camera screen together . . . . . . . . 34
3.10 Java applet frame for Velocity specification . . . . . . . . . . . . . . . . . . 35
3.11 Deterministic feature of RTLinux . . . . . . . . . . . . . . . . . . . . . . . . 37
3.12 Task Execution Time of process thread and output thread . . . . . . . 38
3.13 Task Execution Time of sampling thread, process thread and output thread 38
3.14 Step response of the HAL in a horizontal direction . . . . . . . . . . . . . . 40
3.15 Step response of the HAL in a vertical direction . . . . . . . . . . . . . . . . 41
4.1 Task switching with the Real-Time Kernel from [41] . . . . . . . . . . . . . 46
4.2 Real-Time Workshop Architecture from Real-Time Workshop User’s Guide [32] 52
4.3 The HAL schematic diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.4 The Dymola model of the HAL . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.5 The simulation result of the HAL model in Dymola for a vertical direction . 56
4.6 The simulation result of the HAL model in Dymola for a horizontal direction 57
4.7 The Simulink Model of the HAL . . . . . . . . . . . . . . . . . . . . . . . . 59
4.8 xPC Target configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.9 RT-Lab configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.10 The simulink model for RT-Lab of the HAL . . . . . . . . . . . . . . . . . . 62
4.11 Simple mechanical system model in Dymola . . . . . . . . . . . . . . . . . . 63
4.12 Simple mechanical system model in Simulink . . . . . . . . . . . . . . . . . 64
4.13 The result of the simple mechanical model . . . . . . . . . . . . . . . . . . . 67
4.14 TET of the simple mechanical model in xPC Target . . . . . . . . . . . . . 68
viii
4.15 TET of the simple mechanical model in RT-Lab . . . . . . . . . . . . . . . 69
4.16 High order system model in Dymola . . . . . . . . . . . . . . . . . . . . . . 70
4.17 TET in xPC Target using the Figure 4.16 model . . . . . . . . . . . . . . . 70
4.18 Simple hydraulic system model in Dymola . . . . . . . . . . . . . . . . . . . 71
4.19 TET in xPC Target using the simple hydraulic model in Dymola with ode4solver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.20 The results of the ideal and the non-ideal hydraulic models in Dymola . . . 72
4.21 F14 Simulink model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
4.22 F14 Simulink model for RT-Lab . . . . . . . . . . . . . . . . . . . . . . . . . 74
4.23 TET of the F14 model in xPC Target and RT-Lab . . . . . . . . . . . . . . 75
4.24 F14 Simulink model with IO blocks in xPC Target and RT-Lab . . . . . . . 76
4.25 Task Execution Time of the F14 model with IO blocks in specified time inRT-Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
ix
SUMMARY
Real time performance of digital communication and control systems impacts dynamic
systems in multiple ways. This thesis has studied the implementation of digital command
and control in the context of two examples that rely heavily on those technologies: Inter-
net accessed laboratory experiments and hardware-in-the-loop simulation. The operating
system and support software are examined and some alternatives are compared.
Most engineering schools provide a course on system analysis and control engineering
technology for undergraduates. The primary objective of these courses is that students fully
understand concepts of dynamic modelling, feedback control system stability analysis, and
controller design and implementation both through lectures and laboratory experiments.
Laboratory programs play an especially important role in combining the theoretical and
analytical knowledge taught in lectures into the concrete engineering skills. The Intelli-
gent Machine and Dynamics Laboratory(IMDL) in Georgia Institute of Technology has
developed and run the Virtual Access Laboratory(VAL) for the control and system related
courses. In the VAL system, access to the laboratory, supervision and all activities of the
experiment are performed virtually and remotely. In this thesis, a new software framework
of the VAL system is proposed and implemented, replacing the previous software system.
For system design and control system development, Hardware-In-the-Loop(HIL) simu-
lation is used in the various fields of research and industrial applications. HIL simulation
mainly consists of a Real-Time Operating System(RTOS), embedded software running on
it, and hardware interfaces (e.g. I/O interfaces, communication modules, etc.) which deter-
mine its capabilities. In this research, the effects of a RTOS on the performance of a HIL
system will be examined through the real-time simulations with different RTOSs. QNX and
xPC Target, two PC-based real-time solutions are selected to be RTOS platforms in this
research.
x
CHAPTER I
INTRODUCTION
1.1 Motivation
Real time performance of digital communication and control systems impacts dynamic sys-
tems in multiple ways. This thesis has studied the implementation of digital command and
control in the context of two examples that rely heavily on those technologies: Internet ac-
cessed laboratory experiments and hardware-in-the-loop simulation. The operating system
and support software is examined and some alternatives are compared.
Most engineering schools provide a course on system analysis and control engineering
technology for undergraduates. The primary objective of these courses is that students fully
understand concepts of dynamic modelling, feedback control system stability analysis, and
controller design and implementation both through lectures and laboratory experiments.
Laboratory programs play an especially important role in combining the theoretical and
analytical knowledge taught in lectures into the concrete engineering skills. The Intelli-
gent Machine and Dynamics Laboratory(IMDL) in Georgia Institute of Technology has
developed and run the Virtual Access Laboratory(VAL) for the control and system related
courses. In the VAL system, access to the laboratory, supervision and all other interfacing
activities of experiment are performed virtually and remotely.
The VAL system consists of two main parts, i.e., the Hydraulic Actuated Lifter(HAL)
system and the software system. The HAL system is an experimental testbed constructed
to functionally resemble a fork lift truck where the control system is implemented in real-
time. The previously developed software system implemented a whole virtual environment
surrounding the HAL system for students to perform experiments remotely. A Client/Server
structure via TCP/IP connection had been chosen in the software system. The server
program written in C++ ran in Windows NT. In order to provide real-time functionality,
HyperKernel was added to Windows NT. The client program was programmed as a Java
1
Applet. WebCT was selected to support the access to the client program and time slot
reservations. The experiment results were retrieved by ftp via WebCT. A camera sent live
motion of the experiment to students. [28, 48].
In this thesis, a new software framework of the VAL system is proposed and imple-
mented, replacing the previous software system. The main motivations for the new software
system can be specified as follows:
• Replace obsolescent software tools with currently recommended tools
• Separate the real-time and server programs
• Integrate data retrieval into the user sofware
• Integrate a reservation system into the server
• Integrate plotting
• Move to industry standard portable POSIX software
As another research work of this thesis, real-time(RT) simulation of the HAL system is
built and performed. RT simulation is closely related to the Hardware-In-the-Loop(HIL)
Simulator where physical hardware can be tested while it is connected to RT target com-
puter simulating complete environments and computing the control inputs to the hardware.
Therefore, a HIL simulator requires accurate modelling of environment components and its
reliable implementation of RT simulation. The IMDL at GT has built a HIL simulator
facility to test hydraulic and other drive components and their controllers. To evaluate and
improve the performance of the RT simulation system, the HAL system is modelled and
simulated in real-time.
1.2 Problem Statement
The main objects of this thesis are to develop a new software framework for the VAL system
and to implement real-time simulation of the HAL system. The new software framework
is developed to improve the performance of the VAL system. A HAL real-time simulation
2
system is built and performed on the platforms of xPC Target Real-Time Kernel and QNX.
By studying these two examples and the behavior and performance of the RT software
tools, a better understanding of the capabilites of operating systems, modeling tools and
simulation tools available today will be gained. The design of these examples illustrates
novel ways of using them in future command and control systems.
1.3 Contribution
The main contributions of this thesis include the development of a new software framework
of the VAL system and the implementation of real-time simulation of the HAL system,
and in exploring the use of RT Linux, Dymola, xPC Target, QNX, Simulink, Real-Time
Workshop, and RT-Lab for these and other command and control applications.
1. New Software Framework
One huge program which has multiple functions is very hard to maintain and upgrade.
In the new software framework of the VAL system, the software components are
divided into the smallest possible ones ensuring an easily maintanable and upgradable
software system. Compared with the previous software framework of the VAL system,
the new one has improved features which are listed as follows:
• The previous client program was built with Java 2 and Swing. In the new
framework, a plotting function is added to a HAL web site.
• The server program, written in C, receives parameters from the client program
and sends appropriate messages to it. This server program is independent of the
real-time programs.
• The Real-Time Operating System is replaced by RTLinux which supports POSIX.
The portability of the program is much improved through the POSIX standard.
• Login, data retrieval, and plotting systems are included in the HAL server com-
puter. The system does not need manual operations except creating/deleting
users which are also done in the web browser. These systems are well integrated
with the HAL web site which runs on the HAL server computer.
3
2. Real-Time Simulation of the HAL system
We attempt to implement a real-time simulation of the HAL system, but the results
are not real time. The model of the HAL system could not be reduced to real time.
Simpler models show that the process is possible for some models but it was not
possible for hydraulic models of even moderate complexity.
The real-time simulation is implemented and performed in the following procedures:
• Dynamic modelling of a model is performed using Dymola from Dynasim, Inc.
Dymola has a Modelica translator where all necessary symbolic transformations
for large and complex multi-domain systems are performed. Then, the simulation
model by Dymola is converted into a Simulink S-function block for real-time
purposes.
• Real Time Workshop from Mathworks, Inc. generates real-time codes of the
Simulink S-function model which are compiled and executed in xPC Target Real-
Time Kernel or QNX.
1.4 Outline of Thesis
The remainder of this thesis is organized as follows: Chapter 2 reviews pertinent litera-
ture in internet-based laboratory and real-time simulation. Chapter 3 provides the software
framework of the VAL system. In Chapter 4, two real-time simulation packages are exam-
ined. Also a real-time simulation of the HAL system is explored. Chapter 5 provides the
conclusions and the future work.
4
CHAPTER II
LITERATURE REVIEW
This chapter reviews the status of current remotely accessed laboratories, real-time simu-
lation, and HIL simulation, separated into those three categories. The following are brief
reviews of selected papers among a variety of published papers in such fields.
2.1 Remote Access Laboratory
Second Best to Being There (SBBT) is a network application, developed at Oregon State
University, combining new and existing software and hardware to provide remote laboratory
users the opportunity to conduct experiments in a local laboratory [2]. It is implemented
over the Internet using a Client/Server architecture with UDP/IP. SBBT has been demon-
strated on a test system comprised of a three-degree-of-freedom robot controlled from a
PC. The Remote Lab User Interface for SBBT consists of several components such as a
video window of the control experiment, a white board of showing a block diagram and
some discussion, an Xterminal window representing the local development environment,
the laboratory environment control window with the panic stop button, and the audio
configuration window.
University of Tennessee at Chattanooga runs Resource Center for Engineering Labo-
ratories on the Web [24]. This online system is composed of a dual Pentium-Pro 300Mhz
machine acting as the server, and five client machines ranging in speeds from a Mac IIx to a
Pentium Pro 200Mhz with each controlling a different physical system. The server machine
is running Windows NT 4.0 Internet information server, NT windows file server and Mac
file server. Each of the client computers communicate with the server via NT file server and
client software written with LabVIEW. The clients scan for command files to appear on the
server which are produced by the LabVIEW WEB server each time an experiment is run by
the user. The client software reads the command files off the server and decodes them into
5
variables used by the DAQ cards to control the physical systems. Once an experiment has
run, the client software writes a results file back onto the server. The WEB server creates
unique web pages with custom links to the pages and pictures produced for each experiment
that is run by the user based on the time the experiment was requested. In addition to
creating custom web pages, the WEB server graphs the results and produces JPEG images
of the graphs linked by the web pages. It is also necessary for the WEB server to stack
the commands from the users since the systems run in real time with time delays for each
experiment. If more than one user requests an experiment for the same system, the requests
are stacked in a temporary file and executed in the order in which they are received.
WebLab which is developed by Quanser integrates physical devices such as laboratory
experiments or industrial equipment into a remote teaching and/or system management
environment. With WebLab, users can access experimental hardware or client-specific sys-
tems from anywhere using an Internet connection. WebLab Visual representations of the
physical equipment being monitored are provided in several forms including VRML, 3D
graphical models, plots, and digital meters, in addition to a streaming video image of the
actual device. A user-defined control panel can be placed on a web page, enabling the
user to effect changes in the behavior of the system. The 3D animation is driven by real
data collected from the remote system thus giving the user a realistic impression of what is
actually occurring in the laboratory [44].
Virtual Control Lab(VCL) 3.1 [20] integrates plug-ins and Java Applets which use the
powerful computational engine of MATLAB/SIMULINK to do extensive simulations and
real interactive animation of control engineering experiments on laboratory plants modelled
in VRML and driven by local or Web wide information. Only Netscape Navigator is used to
display and control all actions of the user. In VCL 3.1, 14 plants are provided to the users.
Real Systems in Virtual Laboratory(RSVL) [19] is run in the same laboratory. RSVL uses
JMF and VRML to show live motions of the plant. In order to take the experiment, ID and
password are needed. The plant is the 2DOF optical tracking system and a PID controller
is implemented. Lehrstuhl fur Automatisierungstechnik und Prozessinformatik within the
Department of Electrical Engineering and Information Sciences of the Ruhr-Universitat at
6
Bochum, Germany runs these two laboratories.
Johns Hopkins University offers Interactive Learning for Signals, Systems, and Con-
trol [49]. In this site, exercise modules focusing on Fourier analysis, convolution, the sam-
pling theorem, and elementary control systems are demonstrated by Java Applets to improve
immediacy and interactivity while reducing server loads. A total of 20 demonstrations are
offered. Currently audio is integrated with the demonstrations.
A Virtual Engineering/Science Laboratory Course [26] at Johns Hopkins University
introduces students to experimentation, problem solving, data gathering, and scientific
interpretation. The experiments are also written in Java Applets and are fully interactive.
Most remote access laboratories provide software simulation. SBBT, Resource Center
for Engineering Laboratories on the Web, and RSVL provide hardware experiments. But
those laboratories utilize their own software that must be preloaded. Using their software
means that users need download and install the software. This sometimes prevents users
from using the laboratories. We also use our own software, but a client software is created
as a Java Applet. This means that users may use the software without downloading and
installing it if a Java plug-in is installed.
2.2 Real-Time Simulation and Hardware-In-the-Loop
The controller synthesis and real-time simulation of the net recovery phase of a remotely
piloted vehicle(RPV) are presented in [56]. In the real-time simulation, the host PC which
communicates with a stand alone DSP device is used to develop real-time code for the au-
topilot landing system running on the DSP device. A real-time simulation is then conducted
using the model of the RPV on the DSP device.
Senta, Sato, and Okamura [52] develop a HIL simulation system that uses a computer-
based virtual mechanism instead of an actual hard disk drive(HDD) mechanism. Due to the
small size of an HDD, its eigenfrequencies are extremely high (e.g., 1-20kHz). Therefore,
a simulation step interval may require 1 millisecond or less to achieve sufficient accuracy,
which prevents a real-time simulation. Because of the short step interval, a new simulation
methodology which employs a slower speed solver and a special timing synchronization is
7
proposed. The HIL simulation solver program on the calculation engine board and the
servo-control program cooperate as a time-shared system by program synchronization.
The implementation of a flexible laboratory test bench for developing an Electric Ve-
hicle (EV) and a Hybrid Electric Vehicle (HEV) powertrains are described by Schupbach
and Balda [51]. The test bench was implemented using relatively low-cost off-the-shelf
components which were selected to maximize the flexibility and minimize changes between
the different bench models of operation. The important components of the test bench are
MATLAB/Simulink, ADVISOR(ADvance VehIcle SimulatOR), and dSpace DS1103 PPC
single-board computer.
Rabbath, Abdoune, and Belanger [45] define a “event-based system” which has a chang-
ing dynamical behavior depending on the occurrences of so-called discrete events. A prac-
tical example of an event-based system is the internal combustion engine of an automobile.
This paper presents the problem of accuracy involved in the conventional simulations, at
fixed time steps of event-based systems and then proposes the use of a new Simulink tool-
box, RT-Events toolbox. Beside RT-Events, The Mathworks, Inc. provides Stateflow,
which is tightly integrated with MATLAB and Simulink, is an interactive design tool for
modelling and simulating event-driven systems [59]. Cho and Kim in [11] present a fea-
sibility analysis method for RT-DEVS models under the event driven scheduling policy.
Dufour and Belanger introduce new simulation software that allows the efficient and accu-
rate fixed-time-step simulation of complex event-based dynamic systems [13]. The Discrete
Time Compensation of Switching Events(DTCSE) with ARTEMIS(Advanced Real-Time
Electro-Mechanical Transient Simulator) algorithm is good at handling typically challeng-
ing fixed-time-step simulation cases, like multiple single time-step discontinuities. Real-time
determinism can only be achieved using fixed-time-step integration and without using iter-
ative solvers.
HIL simulations are implemented for powertrain plants in several papers [43, 47, 37].
The transmission and powertrain plant models are impelemented using dSPACE Alpha
processor in [37]. Powell, Sureshbabu, Bailey and Dunn discuss some of the principal
analytically related issues associated with a HIL powertrain laboratory [43]. Important
8
HIL issues related to the real-time powertrain models and the hardware signal interface
are addressed in [47]. Also Raman, Sivashankar, Milam, Stuart, and Nabi explain the
requirements for the HIL system of a powertrain application and the properties of a real-
time simulation [47].
Shiakolas and Piyabongkarn address how a real-time control system with a HIL mag-
netic levitation device is developed with Real-Time Workshop and xPC Target [55]. Grega
describes the concept of HIL design system and the integrated design and rapid prototyping
environment extended by HIL simulation [22].
The Illinois Roadway Simulator (IRS) is introduced in [7]. Various components and
subsystems are developed for IRS. An overview of real-time simulation is provided and
hardware/software constraints to implementing a controller interface device for HIL simu-
lation are also explained [64].
The HIL simulator for truck diesel engines is presented [50]. In this simulator, the diesel
engine, a turbocharger and a vehicle are the simulated parts and the engine control unit and
parts of the injection system are real components. Babbitt and Moskwa describe the engine
system which operates as it would in a vehicle [4]. All of the other components that would
normally interact with the engine are replaced by dynamic equations and the transient
dynamometer. The control system of the HIL transient engine dynamometer system is
based upon MATLAB/Simulink and dSPACE. Rabbath, Desira, and Butts propose a novel
modelling and simulation of internal combustion engine control systems with Simulink,
RT-Lab, and RT-Events [46]. Lee and Suh introduce a PC-based HIL simulator for ABS
(Anti-Lock Braking System) and TCS (Traction Control System) [29].
The real-time simulation of the gear-box model which is modelled by Modelica is imple-
mented with dSPACE [36]. Modelica is a uniform object-oriented language for modelling
of physical systems. The features of Modelica to model continuous-time systems described
by differential-algebraic equations are discussed in [15]. The hybrid features are discussed
in [36]
9
CHAPTER III
VIRTUAL ACCESS LABORATORY(VAL)
The VAL system consists of hardware components and software components. The hardware
components are the HAL, the HAL server computer, and a network camera. The software
components use RT programming, Linux programming, Network programming, Web pro-
gramming, and Java Applet programming. All of these components are explained in this
chapter.
3.1 System Overview
Scheduling time for educational laboratories and providing supervision are two major prob-
lems in increasing the experience engineering students gain with hardware laboratories.
With this laboratory, students can do experiments without going to the lab, provided that
a computer and internet access is available. Basically, experiments can be done anywhere.
This VAL system is being used in several control and system courses in mechanical engi-
neering for undergraduate and graduate students.
The VAL system uses the HAL as a testbed. The users experience non-ideal behaviors
of the HAL such as backlash, sensor noise, dead zone, and so on. The HAL system is
controlled every 1 millisecond, and this system is a hard real-time system.
Students only need a web browser and the Java plug-in to use the VAL system. Real
movement can be seen from a network camera. Students can change control gains, the mag-
nitude of step response, and frequency and magnitude of a sinusoidal input. A trapezoidal
velocity specification is used to test motion control. The results of the experiments can be
displayed in the web browser and downloaded to the user’s computer.
Automatic time reservation is another feature of the new VAL system. A calendar and a
time table are provided for users to choose their convenient time for experiments. Therefore,
users cannot see “Do experiments” on the menu when the time is not their experiment time.
10
The time slot which is given to the users is 30 minutes or 1 hour.
A client program is programmed as a Java Applet. Therefore, the user doesn’t need
to install any program except a Java plug-in. The Java plug-in needs to be installed only
once. Any web browser which can run a Java Applet program can be a client program.
Users control the HAL remotely, so the HAL may start moving without warning. These
movements can be dangerous to the people in the actual laboratory. To solve this problem,
we have a plan to move the HAL to another laboratory, and fences will be put around the
HAL to prevent people from approaching the HAL.
Another security problem is as follows. Two users could use the same id and password
from two different computers, or two users could try to do experiments at the same time.
This situation is solved in the new software system. The server computer only accepts one
connection, and if the connection is not finished, other connections are not accepted. Due
to this software system, two or more computers cannot control the HAL at the same time.
Unauthorized users may make the system dangerous. To prevent this, an enrollment
system is integrated with the VAL system. When an instructor or T.A. creates users, user
IDs are their email addresses, and the information of the VAL system and a password which
is automatically generated by the web site is sent to the users via e-mail. The users must
change their passwords when they first log in. Nobody knows the password but the user.
Sometimes the users forget their passwords. In this case, the instructor or T.A. can create
new passwords for the users without knowing the existing passwords.
Figure 3.1 shows procedures for the users and the instructor in the VAL system as
referred to above.
In Figure 3.2, the interactions of the software and hardware are shown. First a user
logs into the system and reserves his experiment time. Later the user logs into the sys-
tem during the previously reserved time. Then the user can do experiments, and live
motion of the HAL is sent to the user by HTTP protocol. UI hal.class sends parame-
ters to hal server. Then hal server saves the parameters to ‘hal data.conf’ and invokes
hal trajectory. hal trajectory checks values and runs rt hal.o. rt hal.o controls the
11
(a) For students
(b) For an instructor
Figure 3.1: Procedures for students and an instructor
12
HAL in real time. When the experiment is finished, hal trajectory writes the desired po-
sitions and the measured positions to the files. The details of this software and hardware are
addressed in following sections. Also the software development environment is explained.
3.2 Hardware Components of the VAL System
The Hydraulically Actuated Lifter(HAL) was constructed in order to represent many func-
tions of a fork lift truck(FLT). An actual FLT has three degrees of freedom, i.e., driving
motion(horizontal axis), lifting motion(vertical axis), and tilting motion(rotational axis).
The HAL is constrained to operate in driving and lifting motions but tilting motion, which
results in a two degree of freedom system. Figure 3.3 shows the HAL.
A hydraulic pump which generates hydraulic power operates at 1000 psi(6.89 Mpa) and
provides 15.0 GPM (56.78 LPM). Hydraulic power is chosen because it is widely used in
industry but seldom taught in academic courses.
The HAL uses two hydraulic actuators to move in planar motion. The one is a rotary
hydraulic motor to drive a wheel. On the opposite side of the wheel, the HAL is guided by
a rail to keep moving in a straight line for safety. The other actuator is a hydraulic cylinder
producing lifting motion. The piston in the hydraulic cylinder moves the end effector(a fork
in FLT) on a cascading simplex mast. The moving distance of the end effector is twice that
of the piston due to this configuration.
Two servovalves are used to control hydraulic power generated by the hydraulic pump
and deliver controlled power to two actuators. The type of servovalves is a two-stage four-
way electrohydraulic valve with force feedback.
A temposonic transducer measures the position of the HAL in the driving direction. The
position of the HAL in the lifting direction is sensed by a linear displacement transducer
which is mounted inside the cylinder and is concentric with the axis of piston motion. Also
a load cell measures forces generated by the hydraulic cylinder.
The data acquisition board which is mounted in the HAL server computer receives
the data via amplifiers and filters. Servo To Go Model II(STG) is selected as the data
acqusition board. A STG has encoder input which are up to 8 channels of encoder input,
13
Figure 3.2: VAL System Configuration
14
(a) Side view of the HAL
(b) Front view of the HAL
Figure 3.3: The HAL image
15
analog input/output which are up to 8 channels and 13 bit resolution each, 32 digital
input/output, and a timer/interrupt generator.
The important specifications of the HAL server computer are described in Table 3.1.
More detailed explanations on the HAL hardware are well explained in [48].
Table 3.1: The specifications of the HAL server computer
Category Content
Operating System RedHat Linux 7.1 + RTLinux 3.1Kernel Version 2.4.3 p12Processor Pentium III 500MHzMemory 640 MBI/O Card Servo-To-Go, Model II, ISA Bus
A stand alone network camera sends live motions of the HAL to the users. It has a
built-in web server and a network card. Table 3.2 explains the important specifications of
the network camera.
Table 3.2: The specifications of the network camera
Category Content
Name AXIS 2120Operating System LinuxMaximum frame rate 30(NTSC) or 25(PAL) frames/secondZoom Manual zoom 2.3xMaximum users 10 users at the same timeNetwork connection Built in LAN card or a serial port
3.3 Software Development Environments
The VAL system has several software components(i.e., programs). Each program has its
own programming development environment, and is well designed to upgrade and portable
to different operating systems(OS). Moreover, they are written according to industrial stan-
dard as much as possible such as ANSI C, POSIX(Portable Operating System Interface) and
Pthreads(POSIX Threads). The software environment of the VAL system has the following
requirements:
16
• Web server, Database, Web programming
The HAL server handles the request from the web browser which is used by the user.
The web browser is the client program in the VAL system. Only certified users can
access the VAL system. To achieve this requirement, it is necessary to implement web
programming and a database system.
• Client/Server Structure
A Java applet is provided for Graphic User Interface. It is run inside a web browser.
It communicates with the server to allow the user to tune parameters, trace and log
the signals from the HAL server.
• Portability and Easy-Upgrade
The programs for the VAL system should be easy to upgrade and portable to different
OS platforms. The portability is closely related to standardization. ANSI C, POSIX,
and Pthreads are the industry standard for this purpose.
• Real-Time Programming
The VAL system has the HAL system as the experimental testbed, and the HAL
system is controlled real-time by the HAL server. Therefore, real-time functionality
has to be implemented in the VAL software system.
Linux is chosen as the OS of the VAL system since it is a well-known open-source OS
satisfying almost all of requirements on the software environment of the VAL system. The
last requirement described above is not, however, supported by Linux. Linux shows good
performance when it is used for general purposes like a web server, mail server and data
storage, etc. To implement real-time applications under the Linux environment, RTLinux
which provides a small kernel supporting the real-time functionality is appended to Linux.
In this section, those software development environments like POSIX, Multi-thread pro-
gramming, Linux programming, and RTLinux programming are presented and discussed.
Linux Device Driver(LDD) programming is also addressed.
17
3.3.1 Portable Operating System Interface(POSIX)
Full portability of applications on the platforms of different OS is the dream of all the
programmers. Especially, the programming of control-related applications is hardware-
specific, depending mostly on the given OS. Therefore, porting the hardware-specific codes
to the different OSs is quite hard work and takes a lot of time since each OS has its own
unique API(Application Programming Interface).
The standard on portability is the POSIX standard which is being developed by IEEE.
The original POSIX standard(i.e., POSIX 1003.1), first published in 1990, is based on
UNIX. It defines the standard ways for an application to interface to the OS, that is, file
operations, process management, signals, and devices. The POSIX 1003.2 standard defines
the syntax supporting shell and utilities, utility command-line options, and output format of
those utilities. The developers with experience on a UNIX system can easily get used to the
POSIX development environment. The POSIX 1003.4 is important to control-application
programmers. It adds a set of real-time extensions and multi-threads to the POSIX 1003.1
standard. Most of the major RTOSs, i.e., QNX, Wind River, Red Hat and etc. are POSIX
compliant or compatible.
The minimal real-time system does not have a File system or User interactions in general.
Therefore, the dedicated real-time system adds a File system,“tty” device drivers, and
Support for multiple processors to the minimal real-time system. The multi-purpose real-
time system can be used to run a real-time process and a non-real time process when it
includes the POSIX standard [25].
The benefits of the POSIX standard include as follows;
• Source Code Portability.
There already exists standard API such as X3J11 ANSI C providing the Portability of
source code on the different processors and OSs. These standard API are, however, not
adequate for the very complex applications like multi-threading programs. The POSIX
standard can, then, provide better OS Portability on the more complex applications.
• Platform Independence
18
The POSIX standard allows us to choose different processors. In case an OS running in
a specific processor supports the POSIX standard, it does not matter which processor
is chosen. Then, the important factors considered in the selection of the processor
and OS are performance, cost, and development tools rather than the existing source
codes which are related to specific processors and OSs.
• Similar Development Environment
The programmers with experience using a real-time operating system(RTOS) sup-
porting the POSIX can easily apply their experiences into other POSIX-compatible
RTOSs and non RTOSs. The POSIX standard also defines non real-time API.
3.3.2 Multi-thread(MT) programming
A traditional programming paradigm is a single flow of control. The other is a MT pro-
gramming paradigm. A thread can be defined as an independent flow of control in a given
process operating within the same address space [39].
A process is created by the operating system and contains information about program
resources and execution states such as process ID, user ID, Group ID, registers, stack, heap,
file descriptors, signal actions, shared libraries, and Inter-Process Communication(IPC)
tools.
Threads scheduled by an OS exist within these resources and run as independent en-
tities within a process. A process can have multiple threads which share resources in the
given process and execute within the same address space. Therefore threads are sometimes
called Lightweight Processes. In MT programming, multiple threads can execute their
tasks independently and concurrently so that the MT program can execute multiple tasks
concurrently. Moreover, each thread can run in parallel on separate processors.
Even in case the programmer does not write code in the form of a MT-program, one
special thread is automatically generated, i.e., the initial thread. It is also the initial thread
that executes the main routine of the MT-program and ensures the compatibility between
the old processes with a unique implicit thread and the new multi-threaded processes.
Threads provide concurrent execution in a single address space and use maximum power
19
of Symmetric Multiple Processors(SMP). In order to take full advantage of the capabilities
provided by threads, a standardized programming interface has been specified by the POSIX
1003.1c standard. The threads in POSIX are named Pthreads which are a collection of C-
code functions.
The features of MT programming can be summarized as follows:
• Hardware Parallelism on SMP Machines
With MT-program, extra effort to let threads run on different processors simultane-
ously is not necessary.
• Improvement of Uni-processor Response
Threads execute even when other threads are blocked. One thread performs compu-
tational operations while others wait for I/O.
• Faster and More Efficient IPC(Inter-Process Communication) Mechanism
Internally shared memory and global variables are used to communicate each other.
The traditional IPC methods are more expensive and heavier than these. And the
context switching of a thread is faster than one for a process.
Data consistency is the most important thing in MT programming since all threads
in an MT-program share the same address space and global variables. Synchronization
is the only way to ensure the data consistency. Mutexes, Semaphores, and Condition
variables are approaches to limit the number of threads which access some data concurrently.
Mutex(Mutual Exclusion Lock) is a lock on the serial access to shared data. Only one thread
a time can lock a given Mutex and then, other threads are prevented from executing the
code until they lock the Mutex. This can happen only after the locked thread has unlocked
the Mutex; the sleeper threads will be awaked, made runnable and given the chance to
obtain the ownership. Semaphores are generally used to limit the number of threads which
can access simultaneously a given resource. They are a sort of integer counters with a built-
in Mutex lock, ensuring the safe use of resources in MT applications. Condition variables
are used to automatically block threads until a particular condition turns into true. They
also work in conjunction with a Mutex lock to protect modifications to the condition.
20
Thread Safety is the avoidance of data race situations where data are set to either correct
or incorrect values depending upon the order in which multiple threads access and modify
the data.
A program is MT safe when all shared resources can be modified by only one thread
at a time. Global and static variables must be used only when data sharing is necessary
and the variables must be protected by Mutexes. Also, the safety of any function in an
external library must be checked. A function is MT safe(reentrant) when it can be called
concurrently from different threads. A routine is MT unsafe in case it is legal in an MT
program, but cannot be called concurrently. Therefore, the programmer should be careful
which external functions are reentrant or not in MT programming.
3.3.3 Linux Application programming and Linux Device Driver programming
In general, Linux application programs cannot access hardware directly. For the hardware
access by Linux programs, there is a special programming environment named Linux Device
Driver(LDD) programming.
A LDD program is run in so-called “kernel space” level and Linux application program
is run in “user space” level. These two levels are related to a processor. Intel processors
have four levels which have different roles, respectively. Some operations are not allowed in
the lowest levels. Unix system including Linux take advantage of these features with having
only two levels. Kernel space is the highest level where the kernel executes, and user space
is the lowest level in which applications execute. In kernel space everything is allowed,
while direct access to hardware and unauthorized access to memory are prohibited by the
processor in the user space. From this structure, System Calls and Hardware Interrupts are
used to transfer execution from user space to kernel space.
A LDD program is also called a module. A module can be loaded and unloaded with ease.
Unnecessary modules can be unloaded to shorten development time, because we can test
successive versions of our new driver without going through the lengthy shutdown/reboot
cycle each time.
When we build an Linux application program, the functions which are not defined in it
21
can be called. The collection of these similar functions are named a library. The appropriate
libraries are selected to resolve these external references in the linking stage. On the other
hand, a module can call the functions which are imported in the kernel. Since a module only
links to the kernel, not to other libraries, there are limitations on the number of functions
which can be imported to the kernel.
The standard C programming always uses the main function to tell the starting point
of the program. When the main function is terminated, the program is terminated imme-
diately. The Linux applications can be written by the standard C programming. In LDD,
init module and cleanup module functions should be used instead of the main function. The
init module function is the module’s entry point which does initialization for later invoca-
tion of module’s functions. When the module program is unloaded the cleanup module is
invoked.
3.3.4 RTLinux and Linux Device Driver(LDD) programming
Regular Linux is a non-preemptible kernel which has unpredictable scheduling, depending
on system load and using virtual memory to get the good performance on general tasks.
But these features can not be used in controlling the system with hardware. RTLinux is a
real-time kernel that guarantees real-time performance and runs Linux as an idle task when
there are no real-time demands. This means that regular Linux programs do not need to
change in RTLinux so that there is no difference in them for either RTLinux or Linux.
Running a RT program means that regular Linux programs are delayed until the ex-
ecution of RT program is done. In RTLinux, real-time interrupt-handlers and tasks can
be connected to regular Linux processes via either FIFO or shared memory. In general
RTLinux programs and regular Linux programs are incorporated to handle RT tasks and
collect data, log it, and display it on X-Windows.
Dynamic memory allocation can be used in LDD programming, not in RT programming.
Therefore, in RT programming, all of the memory should be allocated at the initialization
stage. When there is not enough physical memory to save data, the hard disk is used as an
alternative, which is called “virtual memory”. This procedure takes lots of time compared
22
to the execution time since every memory allocation should be done before starting any RT
task.
3.3.5 Communication between RTLinux program and Linux program
On a local machine, there are several mechanisms to communicate between two processes. In
most Unix systems including Linux, Pipes, FIFOs, Semaphores, Shared Memory, and Mes-
sage Queues make up those mechanisms and are named Inter-Process Communication(IPC).
There are two important communication methods between rt hal.o and hal trajectory
namely FIFO(First In First Out) and Shared Memory [21].
Pipe is the general method to exchange data between two different processes. Pipe
is used when we connect a data flow from one process to another, which means that the
output of one process is fed into the input of another. Also Pipe is a special file that can
store a limited amount of data in a FIFO manner. On most systems Pipes are limited to
10 logical blocks with 512K bytes, respectively. The include file ‘limits.h’ or ‘sys/param.h’
contains a defined constant PIPE BUF that specifies the maximum number of bytes which
a pipe can hold. FIFO can be created from the command line within a program. Pipe is
uni-directional. When bi-directional data exchanges are required, the pair of FIFOs should
be used. But real-time FIFOs are specially designed to be read from and written to by
Linux processes and RTLinux threads. RT FIFOs are created during installing RTLinux.
These file names are ‘/dev/rtf0’, ‘/dev/rtf1’, etc., through ‘/dev/rtf63’. RT FIFOs should
be initialized in the program not from the command line. When the VAL programs are
explained, the detailed usage is shown.
Shared Memory allows multiple unrelated processes(not parent/child process) to access
the same logical memory and is a very efficient way of transferring data. In general, one
process creates/allocates the Shared Memory segment. Other processes can then attach
the same Shared Memory segment into their own address space. If one process changes the
Shared Memory, it is immediately seen by any other process that gain access to the Shared
Memory. The size of Shared Memory is defined not by the system but by the creator of the
Shared Memory. When there is not enough memory for making Shared Memory, swapping
23
process is occurred which takes lots of time comparing with execution time. Due to this
creation or attachment of Shared Memory should be done in init module and removal or
detachment of it should be done in cleanup module for RT program.
3.3.6 Network Programming
Network programming is an extension of the Pipes concept. It is also called Socket pro-
gramming. Sockets can be used in much the same way as Pipes, but they are generalized to
include communication across a network of computers. A process on one machine can use
Sockets to communicate with a process on other machines, which allows for Client/Server
systems that are distributed across a network. Sockets are different in that Pipes are a one
to one and uni-directional method but they implement multiple clients attached to a single
server.
The most frequently used Socket types are Streams and Datagrams. Stream Sockets are
implemented by TCP/IP(Transmission Control Protocol/Internet Protocol) connections.
They establish and maintain the connection when they are connected. They are reliable
but slow because they always check their connection status and need acknowledgement of
receiving messages.
Datagram Sockets are specified by UDP/IP(User Datagram Protocol/Internet Proto-
col) connections. These Sockets are not sequenced and unreliable in that the transmitted
message may get lost, duplicated, or arrive out of sequence. They are, however, fast and
inexpensive because they does not maintain the connection and do not require connection
setup time. More detailed explanations are in [28, 57]
3.4 Software Implementation of the VAL system
In the view of software components, the VAL system consists of several programs, i.e.,
a RT program(rt hal.o), Linux programs(hal trajectory and hal server), and Java ap-
plet(UI hal.class). A Web Server(Apache) and Database Management System(MySQL)
are also configured and compiled for the VAL system. The explanations of these programs
are the main goals of this section.
24
3.4.1 RT program and Linux program
hal trajectory uses the ‘hal data.conf’ file to get input values. Because ‘hal data.conf’ is
a plain ascii text file, these input values can be changed manually by text editors or by the
client program(UI hal.class) via Internet connection. The parameters in ‘hal data.conf’
are experiment type, feedback type, input type, PID gains, and velocity trajectory specifi-
cations, and ‘hal data.conf’ is shown in Appendix A.
Experiment type is PID or trajectory planning. When PID is selected, input type should
also be selected. Input type is step input, sinusoidal input, or PRBN(Pseudo Random
Binary Number). The magnitude or/and frequency should be given according to Input
Type. When trajectory planning is used, input type is ignored. Trajectory planning uses
velocity profiles. The input values for velocity profiles are maximum velocity(Vmax), ramp
time(tr), and total time(tf ). Figure 3.4 shows how these values are used to construct the
velocity profile. With this experiment type, users understand better the characteristic of a
PID controller and a motion control system.
rt
maxV
rt
ft
Time
Velocity
rt
maxV
rt
ft
Time
Velocity
Figure 3.4: Specification of Velocity Profile
Even though experiment type is trajectory planning, control gains(PID gains) should be
provided. Maximum and minimum P, I, and D gains are defined in hal trajectory. In order
to change the maximum values, hal trajectory must be rebuilt. Maximum magnitude of
step input is 10000 milli-inch for both axis. Maximum amplitude of sinusoidal input is 5000
25
milli-inch for both axis. The maximum frequency of sinusoidal input is set to 1 Hz. When
trajectory planning is selected, 6 movements can be made in ‘hal data.conf’. Maximum
range of driving direction is 37000 milli-inch and 15000 milli-inch is that of lifting direction
.
The communication between rt hal.o and hal trajectory is explained in Figure 3.5.
Conceptually two FIFOs and two Shared Memories are used to communicate with each
other. rt hal.o starts its RT task when FIFO1 is triggered by hal trajectory. Before
triggering FIFO1, hal trajectory calculates desired positions and move them to Shared
Memory 1. Then, rt hal.o reads values from Shared Memory 1, does experiments and
writes sampled position to Shared Memory 2. During each experiment, rt hal.o sends
the status of current experiment (“homing process”, “doing experiment”, etc.) to FIFO2.
hal trajectory reads these status from FIFO2 and displays them to the users. When “end
experiment” message is read, hal trajectory saves desired and measured position data to
the files from Shared Memory 1 and 2.
hal_trajectory1. read input values
from�hal_data.conf�FIFO1
FIFO2
rt_hal.o
Shared Memory 1
Shared Memory 2
2. write desired position
3. trigger FIFO1 4. invoke FIFO1 handler
5. read desired position
6. write status of experiment
7. write measured position
8. shows status to the user
9. save data to files
hal_trajectory1. read input values
from�hal_data.conf�FIFO1
FIFO2
rt_hal.o
Shared Memory 1
Shared Memory 2
2. write desired position
3. trigger FIFO1 4. invoke FIFO1 handler
5. read desired position
6. write status of experiment
7. write measured position
8. shows status to the user
9. save data to files
Figure 3.5: Conceptual program flow between rt hal.o and hal trajectory
rt hal.o is usually composed of several threads of execution. It has 8 threads and 12
functions including init module and cleanup module. All of threads and some important
functions are explained below.
• Functions
– init module creates FIFOs and Shared Memory, registers FIFO handler and in-
terrupt handler, initializes STG, and creates every thread. The threads are
26
suspended by themselves after being created by this function.
– cleanup module destroys all threads and FIFOs, frees IRQ and shared memory,
and turns off pump for safety.
– intr handler catches IRQ 5 generated by STG and wakes up experiment thread.
If current experiment time exceeds specified experiment time, this function turns
off the timer in STG.
– fifo1 handler is invoked whenever “/dev/rtf1” is changed. hal trajectory writes
parameters to “/dev/rtf1” when it finishes its jobs(i.e., checking, generating de-
sired position, etc.). In this function, these parameters are assigned to appropri-
ate variables such as experiment type, input type, and etc. homing thread is
awakened up by this function.
– start experiment turns on timer in STG, enables IRQ in STG, and wakes up
end experiment thread and check pump thread.
• Threads
-homing thread determines whether the experiment is homing process or experi-
ment process. In case of homing process, this thread reads current positions of
the HAL from STG, then checks whether the HAL is at the homing positions or
not. If the HAL is not at the homing positions, the thread tries to move the HAL
to homing positions. If the HAL is at the homing positions, this thread stops the
homing process and notifies hal trajectory of completing the homing process.
Homing positions are calculated in here based on experiment type and input
type. The HAL cannot be exactly at the homing position. Therefore, there are
ranges of homing positions such as ± 400 milli-inches for Y axis and ± 300 milli-
inches for X axis. Then hal trajectory proceeds to experiment process. When
process is experiment process, homing thread wakes up pump on thread if
pump is not turned on or runs start experiment if pump is turned on.
-pump on thread turns on pump and runs start experiment.
27
-check pump thread always checks pump and experiment status. If the experiment
is not taken in assigned time, this thread turns off pump for safety.
-experiment thread is waken by intr handler and wakes up sampling thread .
-sampling thread reads 8 AI channels (even though only 3 channels used) and trans-
forms read values to distance. Then it wakes up process thread which spends
most of execution time.
-process thread calculates the control input based on position errors. PID controller
is implemented in this thread. This thread wakes up output thread .
-output thread converts the control input to relevant voltage output, writes this
value to STG, and saves desired position and sampled position in Shared Memory.
-end experiment thread checks total experiment time. This thread only exists
for safety. When total experiment time reaches the specified experiment time,
intr handler stops the experiments. If this scenario does not work properly, then
end experiment thread disables IRQ, turns off timer in STG, and frees IRQ.
In Figure 3.6, init module initializes STG and registers FIFO handler and interrupt han-
dler. hal trajectory triggers this FIFO, then FIFO handler wakes pump on thread up
and executes start experiment function which initializes STG and starts the timer in STG.
By doing this, STG generates interrupt IRQ 5 every 1 milli-second. The interrupt handler in
rt hal.o catches IRQ 5 and wakes experiment thread up. sampling thread is followed
by experiment thread . process thread is waken up by sampling thread . After each
experiment time end experiment thread is run. check pump thread executes indepen-
dently. It always checks the pump status. When there is no experiment during specified
time(10 minutes), it turns off the pump. cleanup module cleans everything related with
rt hal.o in kernel space when rt hal.o is unloaded.
RT program should be as small as possible to meet real-time requirement. The effort
of making rt hal.o small is related to hal trajectory. Because most calculations and
reading/writing data to the disk are done in hal trajectory, rt hal.o spends very little
time to do its jobs at each sampling time. Its maximum task execution time is below 0.51
28
experiment_thread
sampling_thread
process_thread
output_thread
FIFO1_handler()
pump_on_thread
cleanup_module
init_module
start_experiment()
intr_handler()
init_servo_to_go()
hal_trajectorycheck_pump_thread
end_experiment_thread
STGIRQ 5
Figure 3.6: Functions and threads in rt hal.o
29
milli-second.
The features of hal trajectory are summarized below
• Checking the input values from the user
• Sending messages to hal server, then hal server relays those to the user
• Evaluating the range of desired positions
• Generating the homing positions according to the experiment type
• Running the experiments without internet connection
Because the HAL moves to the desired position relatively from the homing position, the
HAL should go through homing process before doing experiment each time. hal trajectory
runs both homing process and experiment process. Before doing each experiment hal trajectory
generates desired homing position based on input type (i.e., step input, sinusoidal input,
and PRBN). Then it runs rt hal.o using PID control laws. Since it sometimes happens that
homing process cannot be completed in one time, it repeats three times. If, even after three
trials, the HAL is not in desired homing position, then the whole experiment is stopped
with the message of “Please contact T.A.”. When everything is O.K. in homing process,
hal trajectory calculates desired positions for each experiment time based on input values.
The range of these positions are checked here. Calculated desired positions are moved to
shared memory before rt hal.o running by hal trajectory. After rt hal.o finishing the
experiment hal trajectory writes the desired and the measured data to the disk. These
data files can be downloaded and plotted by PHP programs. These are explained later in
this section. The flow chart of hal trajectory is shown in Figure 3.7. The communication
between rt hal.o and hal trajectory is not described in Figure 3.7.
3.4.2 Server System
The request from the user’s web browser is handled by Apache web server. Apache is an
open-source HTTP server for modern operating systems including Linux. It also provides
a secure, efficient and extensible server that provides HTTP services. This has been the
30
Figure 3.7: Flow chart of hal trajectory
31
most popular web server on the Internet since April of 1996. The survey of May 2003 by
Netcraft Web Server showed that 62% of internet web sites are using Apache.
The programs for login and scheduling are written in PHP (recursive acronym for “PHP:
Hypertext Preprocessor”). It is a general-purpose open-source scripting language that is
especially suited for Web development and can be embedded into HTML. PHP’s abilities
include outputting images, PDF files and even Flash movies (using libswf and Ming) gen-
erated on the fly. PHP is embedded in Apache web server to get its best performance.
The measured and desired data should be logged and plotted after each experiment. The
plotting program, also written in PHP, is designed to display, print and download those
data. This plot program is run in the HAL server computer and hands the result in HTML
format to Apache web server. Therefore the user can see the result as a regular html file.
In Figure 3.8, selecting data and plotting the selected data is shown. There is no limit to
the number of data curves to be plotted. The data can be selected as many as possible.
But it has 9 different colors according to checked numbers in selecting screen.
MySQL(Database Management System) is used to save the users’ information(login
name, password, schedule time, and etc.). MySQL is a popular open-source SQL database
which is very fast, reliable, and easy to use.
In the VAL system, Apache, PHP and MySQL make it possible to efficiently build
and maintain the login system, the schedule system, and generate the image file showing
the result of the experiment.
Besides Apache web server, hal server program written in C deals with the requests
from the user’s java applet(UI hal.class). This server program accepts the connection from
the java applet and receives the appropriate data fromUI hal.class. It loads rt hal.o once
after accepting the connection from UI hal.class.
3.4.3 Client System
Client System is the interface program between the user and hal server. The main goal
of this system is to provide an easy and understandable system to the user. Java applet
achieves this goal with lots of GUI(Graphic User Interface) capabilities and the feature
32
(a) Selecting data
(b) Plotting the selected data
Figure 3.8: Screen images of selecting data and plotting the selected data
33
of OS independency. When Java Plug-In is installed once, Java applet is automatically
downloaded by a web browser and is run inside the web browser. Figure 3.9 shows a web
browser which contains UI hal.class and the Network Camera program. UI hal.class
communicates with hal server using TCP/IP protocol.
Figure 3.9: Putting UI hal.class and a Network Camera screen together
The main features of UI hal.class are
• Connecting to hal server
• Selecting experiment type
• Tuning control gains
• Choosing input type, magnitude of input, and if necessary, frequency
• Typing trapezoidal velocity specifications
• Sending data to hal server
• Receiving appropriate messages, i.e., server status, running process, and etc.
34
• Closing connection
To input velocity specifications, a new frame is required. Figure 3.10 shows this frame.
This frame pops up when the user clicks ‘Input Trajectory Specification’ in the right bottom
of UI hal.class.
Figure 3.10: Java applet frame for Velocity specification
The Network Camera has its own OS (i.e., Linux) and a web server which sends live
motion of the HAL to the user. To receive this live motion in a web browser, Java applet
or ActiveX should be downloaded to the user’s computer. Java applet is used to watch
live motion of the HAL. Because the client program is already built by Java applet, Java
plug-in should be installed in the user’s computer. ActiveX only works with Windows OSs
and Internet Explorer. When ActiveX is used, Internet Explorer and Windows OSs are the
only choice of the VAL system.
3.5 Experimental Results
The HAL system is controlled in RTLinux, therefore it is necessary to verify whether
RTLinux is suitable to use in this system. Because a sampling rate in the HAL system
is 1 kHz, every calculation in each sampled time should be completed within 1 milli-second
at most. To check this, performance tests of RTLinux are performed.
35
3.5.1 Performance Test of RTLinux
The performance of RTLinux is evaluated by following the three cases. Case 1 shows the
performance of timing constraints in RTLinux. All three cases utilize the timer in STG and
use IRQ 5 generated by STG every 1 milli-second. Because the RTLinux program and Linux
programs coexist in the VAL system, the RTLinux program should show constant results
even though Linux programs are invoked. In all three cases, the process of reading a hard
disk is executed while the RTLinux program runs. This process is the most time-consuming
process in Linux.
Case 1. The RT program register an interrupt handler to deal with the interrupt generated.
When the interrupt handler is invoked, the time is saved. After an experiment, the
difference between the saved times is displayed in Figure 3.11. Figure 3.11 shows
consistent performance of the RT program even if a Linux process is running.
Case 2. STG generates an IRQ every 1 milli-second. The interrupt handler wakes a
process thread . An output thread follows. The time between starting the pro-
cess thread and completing the output thread is measured. The process thread
calculates control input based on the error. The output thread writes the control
input to STG. In the VAL system three channels(i.e., two position sensors and one
force sensor) are used for input and two channels(i.e., horizontal and vertical axis) for
output. Figure 3.12 shows consistent results whether the Linux process is running or
not.
Case 3. Other conditions are the same as the above cases but one more thread is added
to Case 2. The added thread reads an analog channel in STG [53]. When reading the
analog channel, it takes 38 micro-seconds. This time is taken not by RTLinux but by
STG. In the sampling thread 8 analog channels are read. Totally 304 micro-seconds
are necessary to read values from 8 analog channels. From Figure 3.13 the longest
time is about 507 micro-seconds. This means that the spent time by RTLinux actually
is 203 micro-seconds.
36
Three threads in Case 3 are used in rt hal.o. The results of tests show rt hal.o can
satisfy all RT-requirements even though the Linux process is invoked. Therefore RTLinux
is suitable to use in the VAL system.
0 50 100 150 200 250 3000.994
0.996
0.998
1
1.002
1.004
1.006
1.008Response of IRQ 5 from STG card
index
mill
i−se
cond
With Linux processWithout Linux process
Figure 3.11: Deterministic feature of RTLinux
37
0 200 400 600 800 1000 1200 1400 1600 18000.013
0.014
0.015
0.016
0.017
0.018
0.019
0.02
index
mill
i−se
cond
task execution time of processthrea and output
thread
With Linux processWithout Linux process
Figure 3.12: Task Execution Time of process thread and output thread
0 200 400 600 800 1000 1200 1400 16000.48
0.485
0.49
0.495
0.5
0.505
0.51
0.515
index
mill
i−se
cond
task execution time of samplingthread, process
threa, and output
thread
With Linux processWithout 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
different 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[milli−second]
posi
tion[
mill
i−in
ch]
Step response of the HAL
P=100, I=0, D=0P=100, I=50, D=0P=100, I=100, D=0P=100, I=0, D=50P=100, I=0, D=100P=100, I=50, D=50P=100, I=100, D=50
(a) When P=100
0 5000 10000 15000−2000
0
2000
4000
6000
8000
10000
12000
14000
time[milli−second]
posi
tion[
mill
i−in
ch]
Step response of the HAL
P=200, I=0, D=0P=200, I=50, D=0P=200, I=100, D=0P=200, I=50, D=50P=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 150000
5000
10000
15000
time[milli−second]
posi
tion[
mill
i−in
ch]
Step response of the HAL
P=100, I=0, D=0P=100, I=50, D=0P=100, I=0, D=50P=100, I=0, D=100P=100, I=50, D=50P=100, I=50, D=100P=100, I=100, D=100
(a) When P=100
0 5000 10000 150000
2000
4000
6000
8000
10000
12000
14000
time[milli−second]
posi
tion[
mill
i−in
ch]
Step response of the HAL
P=200, I=0, D=0P=200, I=50, D=0P=200, I=0, D=50P=200, I=0, D=100P=200, I=50, D=50P=200, I=50, D=100P=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 off-line
simulation which simulates non-actual time. In off-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 difficult in that complex and difficult 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 first 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 differs significantly 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 don’t 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 first 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 configures 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 flat 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.
TETt
Figure 4.1: Task switching with the Real-Time Kernel from [41]
• Interrupt Latency (tIL)
The interrupt latency time is the time from the activation of the interrupt signal to
46
when the first 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 (tTS)
This describes the time from the occurrence of the task’s trigger signal to the execution
of the first 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 (tTET )
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
time’s cost. In RT simulation, real-time time constraints are also important. The trade-off
between these two should be well selected.
Various kinds of modelling software have been developed since a computer was invented.
The ordinary differential equations (ODEs) of models are written into the codes to integrate
47
those differential 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 differential-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 effort is involved in formulating equations. Modelica, which is a
language specification, 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 different parts
that are sampled or updated at different 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
differential 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 defined, 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 effects 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 specific component
48
does not exist, it could be constructed using existing components. Modelica is both
a modelling language and a model exchange specification. Modelica is not a program
but a language specification. 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-file which can be simulated
in Simulink as an input/output block.
– MathModelica fromMathCore 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 satisfied. This traditional approach takes so much time because the software design is
completely different 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
sufficient fidelity 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 file
(model.rtw)
2. Call the Target Language Compiler(TLC) to generate code
TLC transforms the intermediate model description into target-specific 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 files. The TLC scripts specify how to generate code from the model, using the
model.rtw file as input
3. Generate a customized Makefile
Real-Time Workshop creates a customized makefile, model.mk. The generated make-
file 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 makefiles, configured for spe-
cific 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 file 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 files, the make utility
performs date checking on the dependencies between object and C files.
Optionally, make can also download the executable to your target system.
Because of Real-Time Workshop’s 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
figure. 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 User’s 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 different integration methods for the simulation
of dynamic systems. Because no single method of solving a model suffices 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 model’s 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 specified by the
model.
• Variable step solvers
These solvers decrease the simulation step-size to increase accuracy when a system’s
states are changing rapidly and increase the step size to save simulation time when a
system’s 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 differential 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 stiff. For a stiff
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 stiff problems are ineffective 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, fixed step solvers must be used due to real time constraints.
There are five different fixed 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
BServoVa...
Cylinder...
Fixed1InertialSystem1
xy
BoxBody1
r={0,0.1,0}
Prismatic...
Step1
startTi...
s
PositionSensor1
PID1
Ti=0.5 -
Feedback1
P T
BServoVa...
Con...
PID2
Ti=0.5 -
Feedback2 Step2
startTim...Relie...
Tank2
Inertia1
J=1
AngleSen...
phi
Figure 4.4: The Dymola model of the HAL
55
Time[second]
Po
siti
on
[m]
Figure 4.5: The simulation result of the HAL model in Dymola for a vertical direction
56
Time[second]
An
gle
[ra
dia
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, Heun’s method, also known as the improved Euler formula
• ode1, Euler’s method
But above solvers are not suitable to stiff 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 fixed time step behavior of stiff systems. The ARTEMIS
algorithm allows fixed 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 file is generated by Dymola. Then the C-mex
file 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 file is made from
the real-time C code. The executable file 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 file 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
xPC Target Real-Time Kernel
(Loaded from a boot disk)
by xPC Target
RCT
MatlabEnvironment
xPC Target
Figure 4.8: xPC Target configuration
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 configuration
• 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 model’s 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 file 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 PC’s 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 fixed step solver in xPC Target and RT-Lab.
If fixed step size is larger than 0.000002 seconds(2 µseconds) with Rkfix4 (Runge-kutta
4th order method), the simulation cannot be run. Because the large fixed step size makes
the system unstable. But the fixed 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 Rkfix4
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 programModelling Tool Simulink SimulinkCode Generation Real-Time Workshop Real-Time WorkshopRTOS xPC Target Real-Time Kernel QNXCompiler Visual C/C++ or Wacom C/C++ gnu GCCData Retrieval Included A separate ftp programDistributed 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 fixed step
size, 0.0005 seconds, the real-time simulation of the HAL model cannot be implemented.
The fixed step size can be longer than 0.0005 seconds, but that leads the model to a different
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 specified, 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 file. 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
Force1SpringDamper1
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 different 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 Rkfix4 and ode4
are fixed 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 Rkfix4 and ode4 use the
same algorithm to solve the problems with a fixed 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 fixed step solver is Rkfix4 and a fixed 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 difference 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 affect the worst case calculation time significantly
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 effects 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
fixed 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 finder. But DOPRI5 does not have a root finder.
Also fixed step solvers do not have this function, therefore the results of the real-time sim-
ulation are different from the results using Dassal solver. Figure 4.20 shows the different
results. AngleSensor1 is the result of the non-ideal hydraulic model using the Rkfix4 solver,
and AngleSensor2 is the result of the ideal hydraulic model using the Dassal solver. Due to
the lack of root finding in ode45(DOPRI5), in Simulink the model takes much time to sim-
ulate 10 seconds. Because of this difference, 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 modified 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]
posi
tion[
m]
The results of the simple mechanical model in Dymola
DOPRI5Rkfix4 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.12The results of the simple mechanical model in Simulink
posi
tion[
m]
time[second]
ode45(Dormand−Prince)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 100
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
0.18
0.2
time[second]
Task
Exe
cutio
n Ti
me[
mill
isec
ond]
Implementation of the simple mechanical system(Dymola block)−Five times
max 0.1794max 0.1794max 0.1794max 0.1802max 0.1794
(a) TET in xPC Target using the Figure 4.11 model
0 1 2 3 4 5 6 7 8 9 100
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
0.18
time[second]
Task
Exe
cutio
n Ti
me[
mill
isec
ond]
Implementation of the simple mechanical system(Pure Simulink block) − Six times
max 0.1702max 0.1702max 0.1702max 0.1702max 0.1702max 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 100
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
0.18
time[second]
Task
Exe
cutio
n Ti
me[
mill
isec
ond]
Implementation of the simple mechanical system(Simulink block) in RT−Lab
max 0.1680max 0.1690max 0.1700max 0.0380max 0.1680max 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
SpringDamper1SlidingMass1
SpringDamper2SlidingMass2
SpringDamper3SlidingMass3
SpringDamper4SlidingMass4
SpringDamper5SlidingMass5
SpringDamper6SlidingMass6
SpringDamper7SlidingMass7
SpringDamper8SlidingMass8
SpringDamper9SlidingMass9
f
Force1
s
PositionSensor1
Figure 4.16: High order system model in Dymola
0 1 2 3 4 5 6 7 8 9 100
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
0.18
0.2Implementation of the mechanical system(Dymola block)
time[second]
Task
Exe
cutio
n Ti
me[
mill
isec
ond]
max 0.1827max 0.1802max 0.1811max 0.1811max 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 100
0.05
0.1
0.15
0.2
0.25
time[second]
Task
Exe
cutio
n Ti
me[
mill
isec
ond]
Implementation of the simple hydraulic system(Dymola block)
max 0.219max 0.2163max 0.2255max 0.2179max 0.2171
Figure 4.19: TET in xPC Target using the simple hydraulic model in Dymola with ode4solver
71
Time[second]
An
gle
[ra
dia
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 300
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
0.18Implementation of the F14 model in xPC Target
time[second]
Task
Exe
cutio
n Ti
me[
mill
isec
ond]
max 0.1727
(a) Task Execution Time of F14 model in xPC Target
0 5 10 15 20 25 300
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
0.18Implementation of the F14 model in RT−Lab
time[second]
Task
Exe
cutio
n Ti
me[
mill
isec
ond]
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 300
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
0.18
0.2Implementation of the F14 model in xPC Target
time[second]
Task
Exe
cutio
n Ti
me[
mill
isec
ond]
max 0.1811
(a) Task Execution Time of F14 model with IO blocks in xPC Target
0 5 10 15 20 25 300
0.5
1
1.5
2
2.5
3
3.5Implementation of the F14 model in RT−Lab
time[second]
Task
Exe
cutio
n Ti
me[
mill
isec
ond]
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 100
0.5
1
1.5
2
2.5
3
3.5
Iteration number
Task
Exe
cutio
n Ti
me[
mill
isec
ond]
Implementation of the F14 model from 0 to 9 iteration in RT−Lab
max 3.023
(a) Task Execution Time from 0 to 9 iteration number
0 5 10 15 20 25 300
0.02
0.04
0.06
0.08
0.1
0.12
0.14
0.16
0.18Implementation of the F14 model except a initialization step in RT−Lab
time[second]
Task
Exe
cutio
n Ti
me[
mill
isec
ond]
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 specified time inRT-Lab
77
need two computers, a host PC and a target PC, and use Simulink, RTW, and TLC for
their add-on tools. The difference between xPC Target and RT-Lab are as follows:
1. Installation of software and configuration of host and target PCs.
xPC Target can be installed during installation of Matlab, and does not need a special
configuration 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 finder. The fixed step solvers in the both simulation
tools don’t have this function. Therefore the HAL model cannot be implemented in real
time, and the simulation of the non-ideal hydraulic model shows different results with
different integration solvers such as Dassal and Rkfix4.
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 couldn’t 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 file is added, and
the image is incorporated with an html file. Students can print out and save the
image. The previous system didn’t have these functions.
• The previous system didn’t 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 don’t 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 difficult 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 finder. But the fixed step solvers in xPC Target
and RT-Lab don’t 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 doesn’t 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 Matlab’s workspace, but
RT-Lab should use a separate ftp program. On distributed simulations, xPC Target
doesn’t 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 differences 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 fixed 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-defined 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 files 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 finder. The result of a simulation including a real-time simu-
lation may be different when different integration solvers are used. If we have
DAE(Differential 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 can’t. 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 ofelectric systems and drives,” in Seventeenth Annual IEEE Applied Power ElectronicsConference 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., andYurkovich, S., “Report on the nsf/css workshop on new directions in control en-gineering education,” IEEE Control Systems Magazine, vol. 19, pp. 53–58, October1999.
[4] Babbitt, G. R. and Moskwa, J. J., “Implementation details and test results for atransient engine dynamometer and hardware in the loop vehicle model,” in Proceedingsof 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 hilsimulation for automotive applications,” in IEEE International Electric Machines andDrives 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-ahardware-in-the-loop testbed for vehicle dynamics and control,” in Proceedings of the1998 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 powersystem analysis-computer study and real-time simulation,” in International Conferenceon 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., “Anapproach for real-time simulation of electric drives,” in 2000 Canadian Conference onElectrical 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-devsmodels,” 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 foraccurate real-time simulation of power systems,” in The 27th Annual Conference ofthe IEEE Industrial Electronics Society, vol. 2, pp. 1533 – 1538, IEEE, 29 November –2 December 2001.
[14] Dynasim AB, Dymola User’s 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 forhardware-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 powersystems based on parallel computing - an empirical study,” in International Conferenceon 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 invirtual laboratory (rsvl).” http://www.esr.ruhr-uni-bochum.de/Rsvle/Rsvl.html.
[20] fur Automatisierungstechnik und Prozessinformatik, L., “Virtual control lab3.1.” http://www.esr.ruhr-uni-bochum.de/VCLab/.
[21] GRAY, J. S., INTERPROCESS COMMUNICATIONS IN UNIX: The Nooks andCrannies. 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. 12b6–7 – 12b6–12,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. QNXSoftware 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 HawaiiInternational Conference on System Sciences, pp. 3739 – 3746, IEEE, 7 – 10 January2002.
[28] Koeppen, K. B., “Virtual access hydraulics experment for system dynamics and con-trol education,” Master’s 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, User’s Guide.
[33] Mathworks, Inc., Using Simulink.
[34] Mathworks, Inc., Writing S-Functions.
[35] MATTHEW, N. and STONES, R., BEGINNING Linux Programming. WROXPRESS, 1996.
[36] Mattsson, S. E., Otter, M., and Elmqvist, H., “Modelica hybrid modeling andefficient simulation,” in Proceedings of the 38th IEEE Conference on Decision andControl, 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 Conferenceon 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 User’s Manual.
[41] Otterbach, R. and Leinfellner, R., “Real-time simulation, requirements and thestate 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. 49–61,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 Proceedingsof the 1998 American Control Conference, vol. 1, pp. 483 – 491, IEEE, 24 – 26 June1998.
[44] QUANSER, “Weblab.” http://www.controlab.com/.
[45] Rabbath, C., Abdoune, M., and Belanger, J., “Effective real-time simulations ofevent-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., “Effective modeling and simulation ofinternal combustion engine control systems,” in Proceedings of the 1998 AmericanControl 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 andimplementation 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 forsystem dynamics and controls education,” Master’s thesis, GEORGIA INSTITUTEOF 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 forthe investigation of truck diesel injection systems,” in Proceedings of the 1998 AmericanControl Conference, vol. 1, pp. 498 – 502, IEEE, June 24 – 26 1998.
[51] Schupbach, R. and Balda, J., “A versatile laboratory test bench for developingpowertrains of electric vehicles,” in 2002 IEEE 56th Vehicular Technology Conferenceon Vehicular Technology Conference, vol. 3, pp. 1666 –1670, IEEE, September 24 – 282002.
[52] Senta, Y., Sato, Y., and Okamura, E., “Hil simulation system for hdd servofirmware,” IEEE Transactions on Magnetics, vol. 38, pp. 2204–2206, 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 digitalcontrol system with a hardware-in-the-loop magnetic levitation device for reinforcementof controls education,” IEEE Transactions on Education, vol. 46, pp. 79 – 87, February2003.
[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 prmotelypiloted 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., “Stateflow 5.1.” http://www.mathworks.com/products/stateflow/.
[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 AcademicPublishers, 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., “Hardwareand software considerations for implementing hardware-in-the loop traffic 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 basedinteractive education and learning scheme(wbiel),” in Proceedings IEEE SoutheastCon,pp. 142 – 146, IEEE, 5 – 7 April 2002.
91