YoungJoonLee_Thesis_2.pdf

8/10/2019 YoungJoonLee_Thesis_2.pdf

1/101

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


2/101

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


3/101

To my mother and my grandmother,

Chun-ja Kim and Mak-yeop Park

iii


4/101

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 Lees family and Jinho Paiks 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


5/101

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


6/101

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


7/101

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


8/101

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 betweenrt hal.oand hal trajectory . . . . . . 26

3.6 Functions and threads inrt 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.classand 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 ofprocess threadand output thread . . . . . . . 38

3.13 Task Execution Time ofsampling 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 Users 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 604.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


9/101


10/101


11/101


12/101

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


13/101

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 illustratesnovel 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


14/101

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


15/101

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


16/101

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 tocreating 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


17/101

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 improveimmediacy 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


18/101

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 Schupbachand 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


19/101


20/101


21/101


22/101

(a) For students

(b) For an instructor

Figure 3.1: Procedures for students and an instructor

12


23/101


24/101

Figure 3.2: VAL System Configuration

14


25/101

(a) Side view of the HAL

(b) Front view of the HAL

Figure 3.3: The HAL image

15


26/101

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 Linux

Maximum 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


27/101

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 webprogramming 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-UpgradeThe 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


28/101

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


29/101

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 sourcecodes 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


30/101

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


31/101


32/101

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 functionswhich 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 moduleandcleanup modulefunctions should be used instead of the main function. The

init modulefunction is the modules entry point which does initialization for later invoca-

tion of modules functions. When the module program is unloaded thecleanup 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 whenthere 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


33/101

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 constantPIPE BUFthat 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 byLinux 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


34/101

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 moduleand removal or

detachment of it should be done in cleanup modulefor 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


35/101

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

max

V

rt

ft

Time

Velocity

rt

max

V

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


36/101


37/101

suspended by themselves after being created by this function.

cleanup moduledestroys all threads and FIFOs, frees IRQ and shared memory,

and turns off pump for safety.

intr handlercatches 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 trajectorywrites

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 threadturns on pump and runs start experiment.

27


38/101

-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 handlerand 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 upprocess 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 handlerstops the experiments. If this scenario does not work properly, then

end experiment threaddisables IRQ, turns off timer in STG, and frees IRQ.

In Figure 3.6,init moduleinitializes STG and registers FIFO handler and interrupt han-

dler. hal trajectory triggers this FIFO, then FIFO handler wakes pump on thread up

and executesstart experimentfunction 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.ocatches 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 threadexecutes 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.oin 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


39/101

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


40/101


41/101

Figure 3.7: Flow chart of hal trajectory

31


42/101


43/101

(a) Selecting data

(b) Plotting the selected data

Figure 3.8: Screen images of selecting data and plotting the selected data

33


44/101

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 serverusing TCP/IP protocol.

Figure 3.9: Putting UI hal.classand a Network Camera screen together

The main features ofUI hal.classare

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 tohal server

Receiving appropriate messages, i.e., server status, running process, and etc.

34


45/101

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

ofUI 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 users 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 users 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


46/101

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, thedifference 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 threadand completing the output thread is measured. The process thread

calculates control input based on the error. The output threadwrites 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 thesampling thread8 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


47/101

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

millisecond

With Linux processWithout Linux process

Figure 3.11: Deterministic feature of RTLinux

37


48/101

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

millisecond

task execution time of processthrea and output

thread


Figure 3.12: Task Execution Time ofprocess threadandoutput 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

millisecond

task execution time of samplingthread, process

threa, and output

thread


Figure 3.13: Task Execution Time of sampling thread, process thread and out-put thread

38


49/101

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


50/101

0 5000 10000 150002000

0

2000

4000

6000

8000

10000

12000

14000

time[millisecond]

position[milli

inch]

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 150002000

0

2000

4000

6000

8000

10000

12000

14000

time[millisecond]

position[milli

inch]


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


51/101

0 5000 10000 150000

5000

10000

15000

time[millisecond]

position[milli

inch]


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[millisecond]

position[milli

inch]


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=100

P=200, I=100, D=100

(b) When P=200

Figure 3.15: Step response of the HAL in a vertical direction

41


52/101

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


53/101

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


54/101

Reliability and Fault Tolerance.

Reliability is a measure of how often a system will fail. Fault tolerance is concerned

with the recognition and handling of failures. Errors and failures can be very costly,

causing, for example, money losses, property damage, mission failures, or loss of

human life. Consequently, it is very important to avoid failures if possible, through

techniques for reliability, and to respond appropriately, gracefully, and with as little

cost as possible to failures that do occur(fault tolerance).

Two approaches are mainly used to implement PC-based RTOSs. One uses general

OSs (i.e., Windows OSs and Linux) and adds a subsystem to them in order to get RT

functionalities. The other is a stand alone RTOS. Both of them have their advantages and

disadvantages. These are discussed here.

RTX and HyperKernel

Windows NT/2000/XP are designed as general purpose OSs. The extensive pro-

gramming tools and applications are available for Windows OSs. Depending on the

hardware, interrupt latencies under Windows OSs can be very good, averaging less

than 25 micro-seconds. However, worst-case interrupt latencies are unbounded and

can exceed 5 milliseconds. These worst-case latencies are a result of the context under

which Windows User-mode applications are running. Because of this delay, Windows

OSs cannot be used in mission critical applications. To alleviate this disadvantage, a

new strategy has been developed. RTX/Hyperkernel allow Windows OSs to be used as

RTOS. These two are real-time extensions for Windows OSs that provide high-speed

and deterministic real-time capabilities for Windows [63, 12].

Stand alone RTOSs have their own environment and require additional learning time

for software developers. RTX/Hyperkernel are seamlessly integrated with Visual

C/C++ programming environment. Software developers dont need to learn new

development tools, and only one computer is used in development and implementa-

tion.

44


55/101

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


56/101

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 kernelruns 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


57/101

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 tasks 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

times 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


58/101

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 expressedin 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


59/101

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 twocommercial 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 from MathCore provides a Modelica simulation environment which

is closely integrated into Mathematica and Microsoft Visio. The tight integra-

tion with Mathematica also makes it possible to perform complex analysis tasks,

advanced scripting, and other technical computations on models and simulation

results. MathModelica has a graphical editor for model editing and browsing,

which is an extension of the Microsoft Visio diagramming tool. Internally, Dy-

mola symbolic and simulation engine is used for the symbolic transformations

and for the simulations.

4.1.3 Auto Code Generator and Compilers

A traditional approach to real-time design and implementation typically involves multiple

stages, including an algorithm design, a software design, a hardware design, and an imple-

mentation of the afore mentioned.. These stages are repeated until the implementation goals

are 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


60/101


61/101

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 makeutility, 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, makecan also download the executable to your target system.

Because of Real-Time Workshops open structure, RT-Lab and dSpace use Simulink,

Real-Time Workshop, and TLC as their development tools. Figure 4.2 illustrates the ar-

chitecture of Real-Time Workshop.

4.2 Implementation of RT Simulation for HAL system

xPC Target and RT-Lab are PC-based real-time simulation tools. This section shows the

implementation of the real-time simulation of the HAL with them. The HAL is modelled by

Dymola, and the model is converted to the Simulink model. Using Real-Time Workshop,

the Simulink model can run in xPC Target real-time kernel and in QNX by xPC Target

and RT-Lab, respectively.

4.2.1 Modelling of the HAL

Figure 4.3 illustrates the schematic diagram of the HAL, and the components used are

a pump, a cylinder, a motor, two pressure relief valves, and two servovalves from the

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


62/101

Figure 4.2: Real-Time Workshop Architecture from Real-Time Workshop Users Guide [32]

52


63/101

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 models states at equally spaced time steps from the simula-

tion start time to the simulation stop time. The solvers use numerical integration to

compute the continuous states of a system from the state derivatives specified by the

model.

Variable step solvers

These solvers decrease the simulation step-size to increase accuracy when a systems

states are changing rapidly and increase the step size to save simulation time when a

systems states are changing slowly.

If fast and slow signals are present in the solution of a model, the usual integrators cannot

solve this model. For linear 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


64/101

Figure 4.3: The HAL schematic diagram

54


65/101

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

Ang leSen .. .

ph i

Figure 4.4: The Dymola model of the HAL

55


66/101

Time[second]

Position[m]

Figure 4.5: The simulation result of the HAL model in Dymola for a vertical direction

56


67/101

Time[second]

Angle[radian]

Figure 4.6: The simulation result of the HAL model in Dymola for a horizontal direction

57


68/101

ode5, the Dormand-Prince formula

ode4, RK4, the fourth-order Runge-Kutta formula

ode3, the Bogacki-Shampine formula

ode2, Heuns method, also known as the improved Euler formula

ode1, Eulers method

But above solvers are not suitable to 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


69/101

Figure 4.7: The Simulink Model of the HAL

TheDymolamodel

Serial/

Ethernet

Executable file

Real-time C code

TheSimulinkmodel

by RTW

by Microsoft

Visual C/C++

by C-mex file

Serial/

Ethernet

Host PC Target PC

xPCTarget Real-Time Kernel

(Loaded from a boot disk)

by xPCTarget

RCT

MatlabEnvironment

xPCTarget

Figure 4.8: xPC Target configuration

59


70/101


71/101

related to acquiring and viewing data. There can be only one Console subsystem per

model.

Master: The Master subsystem is responsible for the models real-time calculation,

for the overall synchronization of the network, and for I/O communication. There

can be only one Master subsystem per model.

Slaves: Slave subsystems are also responsible for performing calculations in the model,

and are driven by the Master subsystem, which synchronizes the whole network. Slave

subsystems can include I/O blocks, but while these will be synchronized within the

Slave subsystems, they will not be synchronized with I/O communication within the

Master subsystem. There can be as many Slaves subsystems as there are CPUs.

In the HAL model, one Master and one Console subsystem are used. The grouped model

which is converted into real-time C code for QNX is shown in Figure 4.10. The grouped

model is converted into real-time C code for QNX. Then the code is transferred to the target

PC which runs in QNX by ftp protocol. After that, an executable 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 PCs hard drive.

The data can be transferred to the host PC, but this transfer is not automatic. Therefore

a separate ftp client program is utilized in the data transfer.

Table 4.1 summarizes the comparison of xPC Target and RT-Lab.

The implementation of a real-time simulation of the HAL is attempted, but the HAL

model in Dymola itself could not be used in real-time. When implementing a real-time

simulation, the integration solver must be a 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


72/101

(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 S

Documents

YoungJoonLee_Thesis_2.pdf