Design and implementation of an integrated experimental control

platform using rapid control prototyping methods

Dong Zhe
1
, Shi Yuntao
1
, Li Zhijun
1
, Sun Dehui
1
1. North China University of Technology, Beijing 100144
E-mail: dongzhe@ncut.edu.cn
Abstract: This paper presents a framework for rapid experiment implementation in the field of automatic process control. Using
the proposed solution, the real-time control experiment can be carried out easily and rapidly, realizing and validating all kinds of
advanced control algorithms. MATLAB/Simulink is used for rapid algorithm development. Three different methods are
presented for realizing the real-time control of the practical plant, which are called XPC, RTW and OPC. The performance and
applicable occasions of the three methods are investigated and discussed. The implementation of the proposed real-time control
platform is depicted. A quadruple-tank process control test rig is developed. With the proposed experimental control platform,
newly created control algorithms can be prototyping and examined in the quadruple-tank process practically, instead of off-line
simulation. In the last section of the paper, a control example is illustrated.
Key Words: Rapid Prototyping, Process Control Experiment, Real-time Control, Quadruple Tank

1 Introduction
The development of modern control theory is becoming
very fast in recent years, and a large quantity of advanced
control approach is advanced. However, most of the
industrial control systems are still using classical control
methods such as PID. The applications of the modern
control approach can hardly be found in practical control
engineering. The gap between control theory and control
application seems to be insurmountable. There are two
reasons can be discovered from this phenomenon, in one
hand, the modern control theories are complicated in
calculation, thus difficult to realize in digital controller; in
another hand, many of the newly developed control methods
have not been tested in practical control engineering, the
simulation results cannot guarantee the validity of them.
Therefore, a kind of control platform is required which can
be used for carrying out real-time control experiments with
practical plants and implementing advanced control method
easily and rapidly.
Matlab/Simulink is a popular environment for the
development of modern control applicat ion and simulation.
Its rich set of toolboxes and blocksets offers powerful tools
for the design and validation of control systems. In the
research area of the control system design, most of the
simulation results are achieved by it. However, the path to
hardware implementation from the Simulink model is not
always easy and often implies a complete redesign of the
system in a hardware development environment. Although
some commercial rapid prototype systems were developed
such as DSPACE platform [1] and RT-LAB platform [2],
the high price of them and additional hardware cost for
specific plants block their way to laboratories of universities
and institutes.
This paper proposes an integrated experimental control
platform for rapid control prototyping and

*
This work is supported by Beijing Cit y Board of educat ion science
research project.
hardware-in-the-loop simulation. The paper is organize as
follow: Sect ion 2 gives an overview of the proposed
platform; Section 3 presents 3 type of implementation
approaches for rapid prototyping, and discuss their
applicable occasions; Section 4 describes the
implementation of the platform; Section 5 shows an
experiment carrying out by the platform to control a
quadruple-tank system; and future prospects and
conclusions wind up the paper in sections 6.
2 System Overview
Target (Linux/xpc-target kernel) Host (Windows OS)
PC/104
mainboard
with x86
CPU
PC/104
DAQ card
(AI, AO,
DI, DO,)
PC104
bus
Matlab Simulink
Real-time
Workshop
Ethernet
Fig. 1: Platform architecture
In this chapter, an integrated experimental platform is
proposed and formulated. As shown in figure 1, the platform
consists of 2 main partsthe host and the target. The host
machine is a PC with Windows OS, installed
Matlab/Simulink/ RTW software. The target machine is an
embedded PC/ 104 micro-computer, with linux or xpc-target
kernel OS. PC/ 104 is an embedded computer standard
which defines both a form factor and a computer bus,
intended for specialized industrial environments. The
xpc-target kernel is a real-t ime kernel, which provides the
communicat ion interface between the host and the target and
also ensures the real-t ime performance of the application
Proceedings oI the 31st Chinese Control ConIerence
July 25-27, 2012, HeIei, China
5896
running in the target. The target machine is comprised by a
PC/ 104 mainboard with x86 CPU and a PC/ 104 data
acquisition (DAQ) card. The target machine can also be
replace by another desktop PC with PCI based DAQs.
Therefore, the hardware devices of the platformfrom the
host to the targetcan be readily achieved in laboratory.
The host and the target are connected by local area network.
In this paper, an embedded PC/104 mainboard with AMD
LX800 CPU (LX-3160) and a PC/104 DAQ with 4 channel
DACs, 8 channel ADCs, 8 channel DIs, and 8 channel DOs
(ADT650) are packed together to act as the target PC. A
laptop PC is adopted to be the host PC.
3 Rapid Control Prototyping Approaches
3.1 Development environmentsThe Mathworks
software
The MathWorks' development software consisting of
Matlab, Simulink, and RTW with the targeted hardware
form an integrated and ready-to-use development
environment for real-time applications.
Matlab and Simuink have been widely used for control
system modeling, analyzing, design, and simulating by
engineers and scholars. RTW is a powerful RCP tool, which
can convert the Simulink models into executable binary
codes to run in real time on various targets. It provides a
rapid and direct path from system design to hardware
implementation, a simple and easy to use interface, an open
and extensible architecture.
The RTW includes a set of target files that are compiled
by the TLC to produce ANSI C code. The target files are
ASCII text files that describe how to convert the Simulink
model to code. To create a target-specific application, RTW
also requires a template makefile (*.t mf) that specifies the
appropriate C compiler and compiler options for the
building process.
The xPC target is a complete RCP environment customed
by Mathworks, which is an extension of RTW. It uses a
target PC, separate from a host PC, for running real -time
applications. Compared with RTW, xPC is a simpler and
more convenient way to prototype, test, and deploy
real-t ime systems using standard PC hardware. With the
xPC target, users do not have to custom their target machine,
develop hardware driver, write software code, so it is handy
than RTW. Both of the RTW and xPC target have their
advantages and shortcomings, so the proposed platform in
this paper provide multi-technique for realizing real-time
control experiment. The mechanism of each technique will
be described and the advantages and shortcomings of them
will be discussed in the following section
3.2 Three type of rapid control prototyping
approaches
i. xPC approach
Fig. 2: Structure of the xPC approach
The xPC approach is the simplest one of the three, as
shown in figure 2. In the target PC, the xPC target kernel
should be installed, which is a real-time kernel running in
the CPU without the need of any other OS. The resources on
the CPU motherboard (for example, interrupt controller,
UART, and counters) are addressed entirely through I/O
addresses. After the kernel starts running, it activates the
application loader and waits to download a target
application from the host PC. The loader receives the code,
copies the different code sections to their designated
addresses, and sets the target application ready to start.
When the target application starts, The feedback loop is
closed between the target machine and the plant.
In this approach, the host PC acts a role as engineering
station and operator station. Users use it to create their
Simulink block model, and generate the target applicable
code automatically by the xPC target tools. Then the code
will be downloaded into the target PC. After that, the user
can switch the Simulink to external mode to communicate
with the target application. This function can also be
achieved by developing custom software using Xpc target
APIs, which will be illuminated in chapter 4. By both means,
the real-t ime signals and parameters can be exchanged
between host and target PC. Accordingly, the host PC
becomes a supervisory control and data acquisition
(SCADA) system.
ii. RTW approach
Fig. 3: Structure of the RTW approach
The structure of the RTW approach is shown in figure 3.
In this approach, users create their Simulink block model
firstly, just like the xPC approach; then the Simulink model
(.mdl) will be pre-compiled to middle-type code (.rtw);
successively, the target language compiler (TLC) will
execute the TLC program which is made up of system target
file and block target file, to generate c code corresponding to
the block model; Next , the customized makefile (.mk) for
regulating the make process will be generated by the
template makefile (.t mf); finally, the appropriate compiler
5897
will be employed to build the executable binary code from
the source codes. All the code generation processes are
automatic. To use this approach, several developing tasks
should be fulfilled, which will be depicted in chapter 4. For
the sake of feasibility and flexibility, the linux 2.6 kernel
was adopted as the target PC OS. The host PC in this
approach acts as the same role as the xPC approach and the
close loop of real-time control also formed between the
target PC and the plant.
iii. OPC approach
Fig. 4: Structure of the OPC approach
The OPC approach employs OPC technique to realize
real-t ime data communication. Figure 4 shows the structure
of this approach. In the approach, the target PC acts as the
sensor and actuator of the control system; the controller is
placed at the host PC side, and the feedback loop is closed
via network. So in the target PC, we only use the DAQs I/O
function. Unlike the above 2 methods, the target application
code is not generating dynamically. Instead, it is pre-set
program that do not change when carrying out different
experiments with different algorithms. The target PC can be
based on either of the approach above. The preset program is
simple, just reading and writing I/Ossuch as AD and
DAin high frequency.
In the host PC, a data driver with OPC server should be
developed. The data driver uses data exchange APIs to
communicate with the target PCxPC target APIs or RTW
target APIs respectivelyaccording to the type of the target
PC. An OPC server should be integrated in the data driver to
exchange real-t ime data with other program. The OPC
toolbox of Matlab is used to interface with the data driver . In
Simulink, a pair of OPC client blocks (OPC read and OPC
write) should be placed in the block model, as shown in
figure 5. When start the simulation, the Simulink will run in
on-line mode, actualizing real-time control of the plant. The
changes of the block parameters will update in the OPC
server and transmit to the target PC. Customed or
commercial SCADA software with OPC client can be used
for supervision of the control performance.
Fig. 5: The block diagram of OPC approach
3.3 Discuss of the RCP Approaches
All of the RCP approaches presented above can realize
real-t ime control of the practical plants. However, they are
of different degree of difficulty, flexibility, and
performance.
The RTW approach is the foundation of the other two,
and has been reported in many literatures. It is an open and
extensible approach that various targets can be customized.
With the Linux kernel, many hardware drivers,
communicat ion protocols can be developed. With this
approach, we could not only realizing real-t ime control
experiments with different algorithms, but also carrying out
other complex and hybrid experiments. So this approach is
the most flexible one. But the approach expects the user with
some background knowledge, and the development of it is
difficult to some extent.
The xPC approach is a shortcut of RTW. The hardware
request is very common2 standard PC; the software is
completed by the vendor, thus no need for Secondary
development. At the same time, there are many restricts in
using this method. Firstly, the target PC requires x86
architecture; secondly, the supporting I/O board is limited to
a list offered by the vendor; finally, the program running in
the target is unchangeable. Therefore, the xPC approach
provides an easy but restricted way to implement RCP.
In both of the upper approaches, the control algorithm is
running in the target PC, which can guarantee considerable
real-t ime performance. The main reason to adopt Matlab
environment for implementing RCP platform is because of
the abundant algorithm libraries and toolboxes. However,
many algorithm libraries are in the form of compiled codes,
which can only run in Matlab environment, but not in target
PC. The OPC approach has settled this issue. By using the
real-t ime mode of Simulink, the algorithm libraries can be
used to control the practical plants, without compiled to the
target code. So the OPC approach provides the most
available algorithm libraries. Nevertheless, because of the
communicat ion cost of the OPC technique, the real-time
performance will degrades with no doubt.
4 Implementation
4.1 Build Environment
In the propose platform, the host PC and target PC have
the same hardware architecture (X86), so there is no need to
use cross-compiler. But the OS of the host PC and target PC
are different, to build executable code for Linux in Windows
environment, some supporting libraries are required. This
paper uses Cygwin to settle this issue. Cygwin is an imitated
Linux environment running in Windows, providing
necessary Linux libraries for build files. The complete
compiling toolchain have also been integrated in Cygwin,
such as GCC.
4.2 Template makefile (TMF)
TMFs are made up of statements containing tokens. The
RTW build process expands tokens and creates a makefile,
model.mk. TMFs are designed to generate makefiles for
specific compilers on specific platforms. The generated
model.mk file is tailored to compile and link code generated
from the user model, using commands specific to users
development system.
5898
4.3 File downloadi ng Program
After the applicable file been generated in host PC, it
should be downloaded into the target PC. To implement the
file t ransmission, we developed a C/S based file sending
program using Socket. The server side program is in target,
which is running in background after the OS boots. The
client side program is in the host, which sends connect
requests after build process finished. It is called by the
makefile script, and send the compiled file to the target
automatically. The flow chart of the server side and client
side program is shown in figure 6 and figure 7, respectively.
Create socket of
server side
Set IP address of the
server
Bind the socket with
server info
Socket get ready to the
connect request
Listen
Block state
Define receive buffer and
initialize
No request
Connet
request
Open file in real only mode, if
file name not exist, create file
Receive the data flow from client,
save to the receive buffer
The length of the
receive data
Copy the receive buffer to file
=0
The length of data
written in file
Jump out of the cycle
Close the file and socket
Startup the receive file
=0
0
0
Fig. 6: The flow chart of the server side file sending program

Create Socket and initialize
Send connect request
Connected
Y
Open file in read only mode
Define send buffer and initialize
If the pointer point to the
end of the file
Read to send buffer
Send contents of the buffer
N
Y
Close file and socket
end
N
If the pointer point to
the end of the file
Fig. 7: The flow chart of the client side file sending program
4.4 Modification of the Main Function
The the main function of the applicable code running in
the target PC has been provided by vendor (grt_main.c),
along with the complete communication code for parameters
and signals updating. grt_main.c is a non-real-t ime example
code, which cannot be used directly. It should be modified to
be adaptive to the target environment and can run in an
adjustable sample period. In this paper, we use the timer and
signal process functions of Linux to realize periodical
calling of the function. The development routines are as
follows.
i. Initializing the mode of timer
vo`d `u`t:`_ut`ouvo`d)
:tut :`_ut`ou ut
ut.:uhuud'omt`uo o`utd to th
udd:: o th :`_uu' o::`u_ mthod
ut.:u'u_:0
:`_mt):tut.:umu:l)
:`_ut`ouST0^kM,ut,\|)u:`u_ t`m
o :um'`u_ `utvu'
ii. Set the ti mer interval , call this function after
initialization
vo`d `u`tt`mu'T tu:)
:tut `t`mvu' vu'u
`ut `utu:
`utu:`ut)tu:+!000000)
vu'u.`tvu'u.tv:0
vu'u.`tvu'u.tvu:`utu: th
uu`t o t`m `: m`''`:oud
vu'u.`t`utvu'vu'u.`tvu'u
:t`t`mTTTMlkkl^,vu'u,\|)
iii. Call one-step function rt_OneStep(S) from signal
processing method
vo`d omt`uo`ut :`_uum|) th :`_uu'
o::`u_ uut`ou
:tut t`mvu' :tut,ud
u'T t`mu:
_tt`modu):tut,\|)
tOuStS)
_tt`modu)ud,\|)
t`mu:!000000+ud.tv::tut.tv:)
ud.tvu::tut.tvu:))!000000
`t`mu::):tmt`m)
:):tmt`mo!
`utt`mu:'\u,t`mu:)
`uthuu_ :d\u)
':
`utt`m'\u,t`mu:)
:):tmt`mo0
4.5 Communication Script in Host PC
To realize the communication between the Simulink
model in host PC and the application code running in the
target by TCP/IP, several codes should be inserted into the
file extmode_transports.m, as follows:
':` :tm:):Tu_l`', '_t'`uux.t'')
tuu:ot:
5899
't`', Tudx 0 `u th tm'ut mul`':
':`u'`u3?' Tudx !
mx`':
'xtomm', Ml\l`' o 't`'
'xt:`u'`u3?omm' Ml\l`' o
':`u'`u3?'
`utu: 'v'!','v'!'
4.6 Development of the User Defined Blockset
Fig.8 The user defined blockset
The user defined blockset includes blocks mainly used for
hardware interface and control data transport, shown in
Fig.8. The user defined blocks are developed by C-MEX
s_function, and masked in the form of Simulink blocks. The
blockset is provided for user to configure their real-time
control model.
The hardware interface blocks realize the call of the
bottom hardware driver, including AD, DA, DI, DO. The
communicat ion blocks realize the data transport between
targets and other devices, such as Modbus TCP slave, serial
slave, etc.
The codes was embedded in the C-MEX s_function, and
precompiled to the form of .mexw32. When building the
target application, the s_function will be compiled and
linked to the target applicable file. The common steps to
realize the hardware interface s_function are shown in Fig 9.
mdlTerminate( )
mdlOutputs( )
mdlInitializeConditions( )
Open device
initialization
Clean interrupt
Clean interrupt
Configure I/O mode
Configure interrupt mode
Real and write I/Os
Close device
Fig. 9: Flow chart of hardware interface C-MEX s_function
4.7 Development of the xPC communication Driver
The xPC Target provides COM API interface to user for
develop custom applications. Using xPC target API, the user
can establish communication between the host PC and the
target PC via an Ethernet or serial connection and monitor
the behavior of the target application. Therefore, the Xpc
data driver uses the xPC target API to exchange data
between xPC target and host. The steps of using xPC API
are as follows:
a) Initialize xPC driver, get ready for the connection
between the host and target PC;
b) Open Winsock or serial port and establish the
connection;
c) Acquire the filename of the program in xPC target;
d) Acquire the number and names of parameters and
signals in xPC target;
e) Transport parameter or signal value between host
and target PC.
The GUI of the customed xPC data driver is shown in
fig.10.
Fig.10 the GUI of xPC data driver
4.8 Development of the OPC server
Fig.11 Flow chart of developing OPC server
The core of the OPC technology is the interface standard
of data accessing(OPC DA), which is formulated by OPC
Foundation and issued by the public dynamic library. For
5900
the OPC Server development, a rapid development package
is used, which provides the dynamic link library containing
a serial of API functions with the interface standard of data
accessing. Hence, the OPC Server can be developed in
the .Net environment through the rapid development
package under the situation details of the OPCs data
accessing interface. Fig.11 is the flow chart for developing
OPC server.
5 Experiment
Fig.12 The quadruple-tank plant and target PC
The proposed platform has been used in the process
control laboratory with a quadruple-tank plant, as shown in
Fig. 12. Using this integrated experimental control platform,
various control algorithms can be implemented in practical
real-time control.
Fig.13 The Simulink model of the tank control system
Fig.13 shows the Simulink model of the tank level
control system, which is used for validate PID control and
fuzzy control algorithm. In Fig.12, the adt650AD block is
the A/D hardware driver, to collect the sensor signal;
Parmetersturn block is used to convert the 0-5v voltage
signal into 0-300 mm liquid level; fuzzy controller block
and PID controller block are control algorithm modules
respectively, which are provided by Simulink; the
adt650DA block is the hardware driver of DAC;
AD_voltage_show block is used for display sensor values in
the Linux shell.
The rapid control prototyping process using the integrated
control platform consists of the following phases:
1. Modelling of the plant in simulation environment ;
2. Model validation;
3. Designing a prototype version of the control system
with the user defined blocks;
4. Testing the prototype version of the control system
in the real plant
Fig.14 The step response of the quadruple tank fuzzy control
system using the platform
With the platform, the real-t ime control of the tank
system can be easily implemented, by either of the approach
introduced in chapter 3. The control parameters can be tuned
online, and the effect can be exhibit intuitively by graphics
and curves. Fig.14 shows the step response of the quadruple
tank fuzzy control system, which shows the validity of the
platform.
6 Conclusion
With state-of-the-art technology, the cycle from
advancing of new control theory to its application in
practical systems becomes rapid. Using the proposed rapid
control prototyping approaches, one can easily realizes
real-t ime modern control algorithm on real plant. The
methods advanced in this paper can meet the demands of
multi-purposes. The establishing of the platform is not
differentthe hardware request is ordinary, while the
development workload is moderate. The paper provides a
qualitative analysis of the real-time performance of different
approaches. The quantificational real-time index still needs
further investigation.
References
[1] dSPACE GmbH: Solutions for Control, Catalog 2003.
[2] Simon Abourida, Hardware-In-The-Loop Testing of
Aeronautic Systems with State-of-the-Art Real-Time
Technologies. International Conference on Avionics Systems
(ICAS 2008)
[3] Woon-Seng Gan, Yong-Kim Chong, Wilson Gong, and
Wei-Tong Tan, Rapid Prototyping System for Teaching
Real-Time Digital Signal Processing. IEEE Transactions on
Education, Vol. 43, No. 1, Feb 2000
[4] Rui Wang and Shiyuan Yang, The Design of a Rapid
Prototype Platform for ARM Based Embedded System. IEEE
Transactions on Consumer Electronics, Vol. 50, No. 2, MAY
2004
[5] Karl Henrik Johansson,The Quadruple-Tank Process: A
Multivariable Laboratory Process with an Adjustable Zero,
IEEE Transactions on Control Systems Technology, Vol. 8,
No. 3, May 2000
[6] Nitaigour P. Mahalik and Kiseon Kim, A Prototype for
Hardware-in-the-Loop Simulation of a Distributed Control
Architecture, IEEE Transactions On Systems, MAN, and
CyberneticsPart C: APPLICATIONS AND REVIEWS,
VOL. 38, NO. 2, MARCH 2008
5901