You are on page 1of 6

A Partially Automated HiL Test Environment for

Model-Based Development Using Simulink




and OPC Technology

W. Chaaban, M. Schwarz, B. Batchuluun, H. Sheng and J. Brcsk
Department of Computer Architecture and System Programming
University of Kassel
Kassel, Germany
walid.chaaban@uni-kassel.de


Abstract This paper is concerned with the design procedures of
an automated testing tool, developed in Matlab

/Simulink


environment, that performs software verification during runtime
on a PLC (Programmable Logic Controller) or so called HiL test
(Hardware-in-the-Loop) for model-based development of control
applications. In addition to checking the semantic or
functional correctness of the automatically generated C++ -
Code with RTW (Real Time Workshop

) for algorithms designed


and developed in Simulink

on hardware targets, the tool


compares results obtained from the HiL test with the results of
the MiL test (Model-in-the-Loop) performed in early stage of
development for the same developed application. The main
purpose behind this work is to develop reliable software that
fulfil system requirements and to test its behaviour during real-
time hardware simulation, in order to achieve the validation step
which represents the terminating step of almost all projects.
Keywords-MiL, SiL and HiL Test; PADT; OPC DA;
Matlab

/Simulink

; PLC
I. INTRODUCTION
Nowadays one of the major challenges in the world of
embedded real-time system development is the integration of
different activities into a single system. The more complex and
various are the embedded activities and applications, the more
complex, time-consuming and error-prone is the belonging
hand-written software. In order to overcome all those problems
and obstacles and to produce reliable, failure reduced software
and better quality products that meet or exceed pre-specified
standards, almost all industrial sectors, such as the aircraft,
automotive industry and many others, are increasingly using
the popular model-based design (MBD) due to the great
solutions, facilities and advantages provided by this
methodology. Some of the benefits and advantages are listed
below [1]:
Reduced time to market (faster development)
Detection and elimination of errors in early
development stages and hence reduced risk of system
failures
Producing superior quality products at lower cost
Fewer system prototypes
Flexibility concerning design enhancing, processing
and last minute changes

During the model-based control design, the traditional
system engineering process steps showed in the V-shaped flow
diagram depicted in Fig. 1 are followed [2].







Figure 1. Traditional model based development process
The first step consists of modeling and simulation of the
control algorithm for the intended activity or function followed
by the rapid prototyping step. Afterwards the embedded code is
generated automatically from the application. After that a
hardware simulation is performed followed by the integration
and test step.
As mentioned before this paper is about the development
procedures of a HiL test environment for the HIMA PLCs
product family (HIMatrix and HIMax), which can be operated
and programmed with the SILworx PADT (Programming and
Debugging Tool product of the company HIMA) using
Matlab

/Simulink

and the OPC communication standard. The


paper is organized as follows. Section II is concerned with the
different testing strategies and approaches used in model-based
software development for embedded applications in order to
add to software the reliability and quality aspects required,
whereas in section III a small introduction to the used
development environment Matlab

/Simulink

is given. In
Section IV the main idea of this work and the realization of the
automated testing tool are described. In section V a
978-1-4577-0746-9/11/$26.00 2011 IEEE
performance analysis and validation of the tool are discussed
with a small example. Concluding remarks are explained in
part VI followed by future works in part VII.
II. MODEL BASED DESIGN TESTING STRATEGIES
Nowadays more and more the functionality is controlled by
software and the more the number of critical systems increases,
the higher is the degree of complexity of the driving software
and the higher is the probability of errors and failures that may
occur. For safety and quality purposes software developers
have placed over the last years their major responsibility and
work on software testing and verification in such a way that
their developed software fulfils and satisfies user requirements,
achieves a specific level of reliability required and reduces or
minimizes risk of failure and system crashes since error free
systems do not exist in reality [3] [4].
As mentioned in the previous section, generating reliable,
secure and well performing software is one of the basic tasks in
model-based development of control applications. In order to
achieve such an aim many test approaches have to be
performed throughout the different stages of the development
life cycle of a specific application. Those Tests intend to assure
and offer reliable, high-quality and healthy performing
software and thereby a good product for the market, because
defects or failures may lead to dramatic consequences in case
the software is concerned with performing a safety-critical
mission (example of embedded software failure is therac-25
radiation machine [5]). The 3 different basic test disciplines
followed to get reliable and robust software products are listed
below:
1) MiL Testing (Model-in-the-Loop),
2) SiL Testing (Software-in-the-Loop) and finally
3) The HiL Testing (Hardware-in-the-Loop).

Those 3 test approaches are explained shortly in the
following.
1) MiL Testing: This testing step is used for validation and
verification at the modeling stage, in order to test the function
of the designed control application. For MiL, a model of the
intended function or activity which is later to implement in C
or C++ code is simulated as a Model in a virtual environment.
This model represents a control algorithm and is a kind of a
simplified and an easy to process representation of the real
environment, which allows validating the functionality of the
intended activity [6].

2) SiL Testing: This is an intermediate testing approach,
which intends to test the behavior of the auto-generated
software before integration into any target hardware or real-
time hardware simulation. This testing is an important step but
it does not completely replace the HiL testing, because
previous experiences have shown that simulation and reality
always differ [6].

3) HiL Testing: This testing strategy represents a real-time
hardware simulation and the final product test (i.e. it requires
the use of hardware targets for execution). It represents some
kind of product evaluation before launching it on the market. It
intends to test if the software products still fulfill/meet
objectives and the required functionality keeps remaining in
real-time execution. One more aim of the HiL Test is to test
the harmony or interaction between the auto-generated
software and the target hardware in order to evaluate the
products performance, which represents the main objective of
model-based development.

III. DEVELOPMENT ENVIRONMENT MATLAB

/SIMULINK


Matlab

/Simulink

from MathWorks represents one of the


most widely and commonly used development tool at research
institutes and universities in model-based design, simulation
and auto-code generation of control algorithms due to the big
set of various toolboxes and facilities it provides to the
developers. During the development of the HiL test
environment the different Matlab

/Simulink

products
mentioned below have been used.
Simulink

represents an environment for multidomain


simulation and Model-Based Design for dynamic and
embedded systems. It provides an interactive graphical
environment and a customizable set of block libraries for
design, simulation, implementation and testing of control
algorithm and many other applications areas [7].
The OPC Toolbox provides a connection to OPC DA
(OLE for Process Control Data Access) servers (in this work
HIMA X-OPC server) using the Microsoft COM/DCOM based
OPC communication standard allowing the user to perform
read and write access (enterprise management level) to live
data and processes running on any target device that conforms
to the OPC Foundation DA standard, such as DCSs
(Distributed Control Systems) and PLCs [8].
In addition to the tools mentioned above the SILworX
PADT from the company HIMA, which represents the new
programming and debugging tool for the HIMA PLCs product
family and the X-OPC server are used.
IV. HIL TEST ENVIRONMENT DEVELOPMENT
A. Main Idea of this Work
The HiL test tool implemented in this work represents a
part of a project for the company HIMA running in the
department. The project intends to generate customized code
from Models developed in Simulink

for the HIMA PLC series


(HIMax, HIMatrix), in order to enable the development of
complex algorithms (e.g. a PID controller), since realizing this
kind of tasks with the standardized IEC 61131-3 Function
Block Diagram (FBD) PLC programming language is limited,
due to the poor set of blocks provided by the library defined in
this standard.
This tool performs a Hardware-in-the-Loop simulation and
defines the last completing step of the chain shown in Fig. 1, in
order to test and validate the functionality of the auto-generated
code during real-time deployment on a HIMA PLC system.
The main idea of the work was mainly to create an
automated HiL test environment in Simulink

from the
originally control algorithm developed in Simulink

, which
will be converted into a source code using a customized version
of the real time workshop embedded coder (RTW Embedded
Coder), that will be attached by its turn into a function block in
a PLC PADT (SILworX) in order to load and deploy the
algorithm on the target system in real-time.
B. HIL Test Model in Simulink

This model will be created automatically from the main
developed Simulink

Model with solely one mouse click and


consists mainly of a so called Level-2 Matlab S-Function
block, which becomes the Name HIL Test and will be attached
to an m- function that completes during setup or initialization
the following steps:
1) Determining the number of inputs in main model, in
order to add the same number of input pins to the Level-2
Matlab S-Function.

2) Determining the number of outputs in main model, in
order to add the same number of output pins to the Level-2
Matlab S-Function.

After performing these steps, so called Repeating sequence
stair blocks with number of inputs are going to be added into
the HiL Test model. The name of each block is going to be
changed according to the name of the input it has been added
for and it will be afterwards connected to the appropriate input
pin of the previously initialized Level-2 Matlab S-Function. It
is also important to notice that this function block is going to be
executed once every sample time.
A Repeating Sequence Stair block outputs or repeats,
depending on the total set simulation time of the model, a stair
sequence that the user specifies with the Vector of output
values parameter. In this tool the Vector of output values are
going to be fed automatically with test vectors from a test
matrix that has been generated previously by the user and saved
into the working directory. The sample time of the Repeating
sequence stair is set to the same sample time of the model in
such a way that each sample time a different test iteration is fed
into the test model and forwarded to the X-OPC server, which
is assumed to be configured before.
After adding and connecting the Repeating sequence stair
blocks with the appropriate input pins, outport blocks are going
to be added to the test model and their names are going to be
changed according to the outputs in the main developed model.
Finally each added outport is going to be connected
automatically with the appropriate output pins of the Level-2
Matlab S-Function block.
An example of an automatically generated HiL test
environment from a Simulink

Model with 4 inputs and 2


outputs is shown in Fig. 2.


























Figure 2. Example of a main model and its auto- generated HiL test model
C. HIL Test Model in SILworX
After generating code from a Simulink

model a function
block (so called CIF- function block type) has to be created in
the SILworX environment. The input and output pins of this
block will be imported from a file called exchange.csv, which
is supposed to be generated automatically during model
conversion. Furthermore this block will be attached to the auto-
generated code also through its import option.
It should be also noticed that during code generation a
global.csv file with global variables will be generated. The
global variables become the same names as the inport and
outport blocks of the main model and two additional control
global variables are declared: EnableIn and EnableOut. The
EnableOut variable is not that important, since the EnableIn
variable is controlled from the software that has been attached
to the Level-2 Matlab S-Function block and is used as a
control signal to activate and disable the CIF block. The
EnableIn and EnableOut will be connected to the EN input
pin and ENO output pin, which appear automatically when the
user chooses the option Show EN/ENO from the context menu
of the CIF function block in the program. The HiL test
environment in SILworX for the upper model looks is depicted
in Fig. 3.

Developed Application in Simulink Developed Application in Simulink Developed Application in Simulink






Figure 3. HiL test model represented as a SILworX program
D. How does it work
After having finished configuring an X-OPC DA interface
for the built SILworX test program, code will be generated for
both the Program and the OPC interface. The code generated
from the program is loaded on the PLC and the one generated
from the configured OPC interface is read in the X-OPC server
and finally both applications are started. The test or hardware
simulation can be started from the HiL test model generated in
Simulink

. To get a better overview how the data transfer of


the whole arrangement works, see Fig. 4.
The Level-2 Matlab S-Function implemented in the
Simulink

test model will be executed exactly once every tact


or sample time. Within one execution the following steps are
sequentially performed:
1) The values of the outputs (SILworX model) or the
values of the OPC readable items determined by the server
through read access will be given to the approriate outputs in
the Simulink

model.

2) After finishing the read process or determining the
values of outputs a FALSE value is going to be written into the
EnableIn control signal, in order to deactivate the code
execution and to begin a new write process into the SILworX
model inputs. Each new tact, the inputs are updated and a new
test value lies at each input, which is going to be written to the
appropriate item on the OPC server and forwarded to the
hardware.
















3) After writing all model inputs values into the
appropriate OPC write items, a TRUE value is going to be
written into the EnableIn control signal that serves to activate
the block and execute the code with the given test values.

As you can see each tact the read process will be performed
before the write process. Since during the first tact there is no
data to read at the outputs because no test values have been
written to the inputs yet, solely a write access will be
performed in the first tact and which appropriate results are
going to be determined during the next tact. This is the reason
why the total simulation time has been extended for one more
sample time, in which the results of the previous write process
will be read. As mentioned before the total simulation time
depends on the number of test iterations (one sample time per
iteration) intended to test plus one sample time for the last read
access. The test results or the values of the outputs for each
test- iteration on the input side are saved each sample time into
a matrix, which will be used at the end of the test to compare
results with the results of the previousely performed MiL test
and in the test documentation as described in the next session.
V. HIL TEST TOOL - PERFORMANCE EVALUATION
In this section, a performance evaluation of the tool is made
by means of a simple example consisting of an AND- and
XOR- block (see Fig 2). The Simulink

model consists of 4
inputs and 2 outputs and a sample time of 0.2. That means in
this case, all possible test iterations (total 2
4
=16) are built and
will be saved into a test matrix. It is also important to notice at
this point that a special tool for the creation of test values has
been designed as a separated tool, where different methods are
followed.
After building the HiL test environments on both sides
Simulink

and

SILworX and configuring the required OPC
interface using the HIMA X-OPC server the simulation can be
started.















Figure 4. Data transfer between Simulink and hardware (PLC)
Target Hardware or PLC
Software controlled Enable Signal
OPC DA Server
Read Access
HiL Test- Environment
Matlab/Simulink
OPC Toolbox
HiL Test- Environment
OPC DA Server
Write Access
Matlab/Simulink
OPC Toolbox
Target Hardware or PLC
Software controlled Enable Signal
OPC DA Server
Read Access
HiL Test- Environment
Matlab/Simulink
OPC Toolbox
OPC DA Server OPC DA Server
Read Access
HiL Test- Environment
Matlab/Simulink
OPC Toolbox
Matlab/Simulink
OPC Toolbox
HiL Test- Environment
OPC DA Server
Write Access
Matlab/Simulink
OPC Toolbox
OPC DA Server OPC DA Server
Write Access
Matlab/Simulink
OPC Toolbox
Matlab/Simulink
OPC Toolbox
If desired, the user just has to switch to the online
simulation in SILworX in order to follow or to watch the
simulation process in real-time mode. Some snapshots have
been taken during the online Simulation of the model and are
shown in Fig. 5. The red colored lines represent the Boolean
state TRUE.
As mentioned previously the inputs become each tact new
values, which are going to be sent to the appropriate item on
the OPC server.
After finishing online simulation, a test report will be
automatically generated. This report includes the results of the
previously achieved MiL test and the results of the HiL Test
and makes a comparison between both tests. If both tests values
match or the deviation between the MiL and the HiL values lie
within the deviation or tolerance limits the HiL test is then
deemed to be achieved successfully and the converted code
seems to be working as expected during real time simulation.













Figure 5. Some snapshots of the online view of the HiL test during
simulation (SILworX)
In the documentation all passed comparisons, i.e. identical
MiL and HiL output values for the same test vector are marked
with symbols. Failed tests are marked with symbols.
Fig. 6 shows the test report of the example taken into account.
The test report shows that all tests are passed and no failed
test has been recognized. Furthermore the test was well
performing and has been achieved in a very short time despite
the small delays, which have been inserted between the
individual tests in order to allow the user to see and to follow
the events happening on the hardware side during online
simulation, because the process is really running very fast.
For more performance and behaviour test, complex models
with digital filters have been tried using the tool. Some
hundreds and sometimes even thousands of test cases have
been generated for test purposes. The tool was performing very
well but the duration of the test was longer due to the numerous
numbers of tests generated.













Figure 6. Test report launched automatically after test is finished
VI. CONCLUSION
The HiL test environment discussed in this work represents
a very effective way to test and simulate the functionality and
behaviour of auto-generated software in runtime mode, which
has to be performed as the last step within a model-based
design project.
The aim of the tool was to offer an easy to use, partially
automated HiL test environment for devices and target
hardware that conform to the OPC DA communication
standard (DCS, PLC) using the Matlab

/Simulink

development environment for validation intentions. The tool
delivered a very good performance even with a huge number of
test cases and was working very fast and stable.
VII. FUTURE WORKS
In the near future the focus will be on enhancing and
increasing the degree of automation of the tool as much as
possible especially on the side of SILworX because in the
recent version the biggest part of configurations and actions on
SILworX side are still performed manually contrary to the
Matlab

/Simulink

side where almost all activities are


achieved automatically and a high degree of automation is
achieved.
REFERENCES
[1] Achraf Saad, Keshav Dahal, Muhammad Sarfraz, Raijkumar Roy, Soft
Computing in industrial Applications, Recent Trends, 2007, Springer
Verlag.
[2] http://www.srmtech.com/model-based-development/model-based-
development.htm
[3] B. Hailpern, P. Santhanam, Software debugging, testing, and
verification, IBM SYSTEMS JOURNAL, VOL 41, NO 1, 2002
[4] J. Brcsk, Electronic safety concepts, models and calculations,
Hthig Verlag Heidelberg.
[5] Ben Chelf, Ben Chelf, Ensuring the Integrity of Embedded Software
with Static Code Analysis, Published by the IEEE Computer Society,
2009.
Test (0 0 0 1: 0 1)
Test (1 1 0 1: 1 1)
Test (1 1 1 1: 1 0)
[6] Gnter Hommel and Sheng Huanye(Eds.), Embedded Systems
Modeling, Technology, and Applications, Proceedings of the 7th
International Workshop held at Technische Universitt Berlin, June
26/27, 2006, Springer Verlag.




































































[7] http://www.mathworks.com/products/simulink/?BB=1
[8] http://www.mathworks.com/products/opc/

You might also like