A PC-BASED OBJECT SIMULATOR FOR SUPPORTING PLC SOFTWARE

DEVELOPMENT
Jozef Kulisz.* Robert Czerwinski.** Jan Mocha.*** Miroslaw Chmiel.****

Silesian University of Technology, Institute of Electronics, Gliwice, Poland

* (e-mail: jozef.kulisz@polsl.pl)
** (e-mail: robert.czerwinski@polsl.pl)
*** (e-mail:jan.mocha@polsl.pl)
**** (e-mail: miroslaw.chmiel@polsl.pl)

Abstract: The paper discusses hardware and software tools used to support Programmable Logic
Controller (PLC) program testing and verification. An idea of a PC-based object simulator is presented.
The simulator consists of a PC equipped with an appropriate I/O card, and a simulator program running
on the PC. The simulator is capable of emulating behavior of real industrial objects. Thus a significant
part of software tests can be performed with the use of the simulator, instead of a physical object. This
can significantly facilitate, and accelerate development of an application.
Keywords: Industrial control, Programmable logic controllers, Program diagnostics, Debugging,
Simulation, Process simulators, Software engineering, Software productivity

1. INTRODUCTION
Testing and verification of complex applications constitutes a
serious problem for PLC (Programmable Logic Controller)
programmers. In today’s highly competitive world, where
design and construction companies compete both by reducing
costs, and time to market, control and PLC engineers often
have work under pressure. Working to tight deadlines
enforces the management to shrink time schedules. Many
parts of the design, construction and commissioning work
have to be done concurrently. Work on the program has to be
started and conducted, while essential parts of the
installation, that is supposed to be operated by the
application, aren’t yet assembled. Even during the actual
commissioning it often happens, that time slots, during which
the controlled equipment is freely available for testing, are
limited. For those reasons a substantial part of a PLC
application development process has to be conducted at
office, while the equipment that is to be operated by the
program is not accessible to the programmer.
Furthermore, performing some test on real hardware can be
either difficult, or even impossible for technological, or, what
is even more important, for safety reasons.
It’s a common practice, that at the beginning stages PLC
programs are tested using switchboards wired up to PLC
input modules. By operating switches in the proper manner
one can emulate operation of real hardware, which will later
be connected to the PLC. By observing the indicator LED-s
mounted on output modules, the programmer is able to check
whether the program generates the desired logic levels at
PLC outputs. This method can also be used with analog
signals, it demands just applying a little more complex
hardware, capable of producing analog values, e. g. voltages.
Using switchboards can be useful, if the number of PLC
inputs to emulate is not big. In some cases, where separate
devices or small groups of actuators work independently
from one another, it is also possible to separately test portions
of software controlling separate devices.
Unfortunately it often happens, that the installation has to be
operated by complex algorithms (e. g. sequences), imposing
many interlockings between various parts of the control
system, including SCADA (Supervisory Control And Data
Acquisition) for remote control, visualisation, reporting etc.
Under such circumstances testing separate devices is not
sufficient, and using switchboards to test the program as a
whole is practically unmanageable. It would require
following the algorithms, tracking the interactions, and
operating tens of switches in real time to provide adequate
simulation of real hardware.
So far the task of PLC program testing is hardly supported by
specialised software and hardware tools. The main purpose of
the paper is to propose a new approach to PLC application
testing and verification – an object simulator, which is an
independent device. The concept is presented after an
overview of the methods of PLC program testing used so far.
2. TOOLS SUPPORTING PLC APPLCATION TESTING
2.1 PLC simulators
A PLC simulator is a PC program, capable of simulating
behaviour of an actual PLC. The simulation is based on a
program code, written in the language characteristic for the
simulated PLC, which is interpreted by the simulator
program. States of inputs of the simulated PLC can be forced
using an appropriate GUI (Graphical User Interface), and in
the same manner states of outputs and internal variables can
be observed (Fig. 1).
Fig. 1. The concept of a PLC simulator.
of them simulates behaviour of the actual PLC, and the other
one – the controlled objects. The simulators exchange
information about the states of PLC inputs and outputs using
tags, i. e. variables available at the level of the operating
system.
Dedicated object simulator modules are contained, apart from
PLC simulators, in the TrySim (TrySim, 2010) and PC_Simu
(PC_Simu, 2000) programs. Both programs feature simple
graphical editors, and the simulated objects can be assembled
by the user from a number of primitive elements.
In all of the concepts presented above the object is simulated
in the same PC, together with the PLC executing the tested
control program. This approach can thus be schematically
depicted in Fig. 2.

Simulation tools are contained in some systems supporting

PLC program development, e. g. PLCSim, (2007), Unity
(2007), RSLogix (2004), RSLogix (2005). Apart from PLC
manufacturers, PLC simulators can also be supplied by third
party vendors, e. g. CoDeSys, (2003), ISAGraph, (2009),
IBHSoftec, (2010), TrySim, (2010), S7_200, (2000).
Using PLC simulation software allows the designer to avoid
inconvenient switchboards, as the states of simulated inputs
can be forced with a mouse, or a keyboard. Anyway
operating a PLC simulator for a greater number of I/O-s is Fig. 2. A PLC simulator, and a software object simulator
even more inconvenient, than using switchboards. PLC running in the same PC.
simulators can be effectively used, if the number of inputs
The TrySim (TrySim, 2010) and PC_Simu (PC_Simu, 2000)
and outputs to be simulated is not big. For applications, for
programs, in one of their modes of operation, can use an
which tens or hundreds of inputs have to be simultaneously
actual PLC instead of the PLC simulator program. In such a
operated, thorough testing with a PLC simulator is practically
case only the object is simulated in the program running on
unmanageable.
the PC, and information about states of inputs and outputs is
Another important problem, that has to be concerned by transmitted to and from the PLC through a communication
using simulation software, is, how realistic the simulation interface. This concept is schematically presented in Fig. 3.
actually is. The simulated inputs and outputs exist only
virtually in the software, and they have no physical
representation. It is thus not possible to reliably test certain
time-critical functions, like interrupts, high-speed counters,
and pulse train outputs. It may also happen that for various
reasons (e. g. bugs in the software) the simulator doesn’t
model operation of the PLC correctly.

2.2 Software object simulators in a PC Fig. 3. An object simulator running on a PC communicating

A PLC simulator is a substitute of the PLC itself, not the
devices operated by the PLC. For testing more complex
applications some kind of test automation would be desirable.
Another kind of tool is thus needed – an object simulator, i. e.
a simulator of the object to be controlled by the PLC.
Tools of this kind are quite rear. Rockwell Automation
supplies PLC simulators, which support also the functionality
of emulating feedback signals, which are normally generated
by objects controlled by the PLC. In the RSLogix Emulate
program (RSLogix, 2004), functions of the emulated
feedback signals can be described by the user in ladder
format, by using the so called “Debug Files”. In RSLogix
Emulate 5000 this functionality is achieved by launching two
instances of the PLC simulator program simultaneously – one
with a PLC through a communication interface.
2.3 Software object simulators in the PLC
A smart and low-cost solution of simulating a controlled
object was proposed by Kulisz (2004). The author proposes
to use the PLC itself as an object simulator. The idea consists
in adding a special simulator subroutine to the actual PLC
program. The subroutine is invoked at the beginning of the
main program scan. Its purpose is to simulate behaviour of
feedback signals, which are normally generated by the
controlled devices. The subroutine reads output states,
produced by the actual control program, from the PIQ
(Process Output Image) memory, and, basing on this
information, it evaluates states of feedback signals, which are
then written directly to the PII (Process Input Image) memory
(Fig. 4). The simulation subroutine overrides this way logic
states sampled at physical inputs, and provides a kind of a
“dynamic force”. As the simulator subroutine is invoked at
the beginning of the main system loop, its operation should
be transparent to the actual control program.
Simulator
routine
PII PIQ
(inputs) (outputs)
Actual
control
program
Fig. 4. Object simulator as a subroutine inside the PLC.
The solution proposed by Kulisz is cost-efficient, it doesn’t
require any extra software or hardware, and can be
immediately used for almost all PLC-s available on the
market. The programmer just needs to model operation of the
devices controlled by the PLC using the same tools, and the
same language, that are used to write the actual control
program. The approach has however also some drawbacks.
The simulator output is synchronised to the same system
loop, as the actual control program. It is thus not possible to
simulate at PLC inputs pulses shorter than the scan time.
Time-critical functions, e. g. interrupts, high-speed counters,
and pulse outputs, cannot be simulated this way. Because of
those limitations, the author recommends to use the method
only for testing control algorithms at a higher level of
hierarchy, e.g. sequences, interactions with SCADA,
networks, etc.
For some PLC-s writing any data from the control program to
the PII memory is inhibited. In such a case the method cannot
be used, either.
A similar idea was presented in Mikoś et al. (2009). The
authors use the ISaGRAF environment to develop their
applications. They add to the actual control program a
simulator block, which can be enabled or bypassed,
depending on the state of an internal variable. Although it is
possible to generate from ISaGRAF a binary code, download
it to a PLC, and execute, in the proposed approach the object
simulator is used only for simulation in ISaGRAF. This
means, that the presented method is similar to those discussed
in p. 2.2.
2.4 The concept of a PC-based object simulator
An object simulator, to be a reliable and convenient
verification tool, should satisfy the following requirements:
1. Emulation of physical objects should be as realistic, as
possible. In the ideal case the actual object, and the
simulator should be indistinguishable to the PLC.
2. The simulator should provide visualisation of the state of
simulated objects.
3. Apart from simulating normal device operation, the
software should feature also possibility of simulating
device faults.
4. The tool should be universal, in particular it should
support creating models of new objects, and adding them
to the library.
5. The software should be user friendly.
The first condition cannot be satisfactorily met for any of the
concepts discussed above. For all of the methods PLC inputs
and outputs have no physical representation. Information
about their states is exchanged between the PLC and the
object simulator using internal variables in the system, on
which the simulator is run. PLC I/O modules are bypassed,
and functions and properties characteristic for them cannot be
simulated. In particular this means, that for any of the
concepts presented in p. 2.2, 2.3, it is not possible to
realistically simulate time-critical functions, like interrupts,
high speed counters, pulse outputs. This is valid also for the
concept presented in Fig. 3, where the PLC is not simulated,
but information about PLC I/O-s is transmitted through a
communication interface.
The condition of indistinguishability can be satisfied only if
physical I/O modules are not bypassed, and information
about states of PLC inputs and outputs is sent through PLC
I/O-s. This leads us to the concept depicted in Fig. 5.
Fig. 5. Object simulator as a separate device communicating
with PLC I/O modules.
An object simulator has to be a separate device (e.g. a
separate PC), equipped with an appropriate interface to the
PLC. It should sample PLC outputs at regular intervals,
simulate operation of the controlled devices, and send
appropriate feedback signals back to the PLC. The sample
period, at which the object simulator samples data, should be
much shorter, than the PLC scan time.
Such functionality can be handled by another PLC, or, what
is more convenient, by the so-called soft PLC. A soft PLC is
a PC computer equipped with appropriate I/O cards, and
running a software capable of performing control in real time.
The software, that is normally used for developing control
applications on a soft PLC, can as well be used for writing
object models. This software should be accompanied by
visualisation tools, to provide user friendly visualisation of
simulated devices.
Using such an approach is however not very convenient for
creating object models, and can be time consuming. An
object model has to be built simultaneously in two distinct
environments. It would thus be desirable to develop a new
kind of software, dedicated specifically for constructing
object models for simulation. The software should integrate
tools, that enable describing operation of the simulated
device, and tools that facilitate visualisation. The software
should also contain a library of ready-made objects, e. g. a
drive, a valve, a tank, etc., that can be easily accessed,
possibly parametrized, and used to assemble a simulation
model for the whole installation.
3. THE PROPOSED SOLUTION OF A PC-BASED
SIMULATOR
3.1 Software description
A PC-based object simulator has been programmed in C/C++
using the Borland C++ Builder environment, and the
OpenGL library. A screenshot of the main window of the
developed object simulator is presented in Fig. 6. To
practically test the proposed concept, at first a simulator of a
belt conveyor was prepared. This enabled carrying out
experiments, and testing different configurations and
algorithms. In future a library of classes modeling various
industrial objects can be developed.
Fig. 6. Main window of the object simulator.
The engine of the simulator is based on two main classes
named TCtrl and TIOMod. The TCtrl class includes variables
bound up with controlling the belt conveyor drives, indicator
lights, photocells and buttons. The class contains two main
methods: ObjIMG() which enables refreshing button
variables, and Proc() – the main function processing data.
Elements facilitating data exchange with the I/O card (see p.
3.1), like driver handles, USB port opening and closing
functions, port reading and port writing functions, etc., are
members of the TIOMod class. The most important functions
are PortRead() and PortWrite(), which enable reading and
writing an USB port. Input and output data are stored in the
m_DII and m_DOI variables.
The main (engine) routine of the simulator operates in a
cyclic manner. It is constructed using the TTimer class of the
Borland C++ Builder. The routine is thus executed every time
the timer counts down a predefined interval. The interval is
set to 1 ms. Listing of the simulator engine routine is
presented in List. 1.
void Timer1(void)
{
Ctrl->ObjIMG();
IOMod->m_DII = IOMod->PortRead();
IOMod->m_DOI = Ctrl->Proc(
IOMod->m_Dii);
IOMod->PortWrite();
}
Listing 1. The Timer1 routine – main data processing.
At the beginning the object image (ObjIMG()) function is
executed. The function refreshes the variables connected with
object buttons. Then the inputs to the object are read from the
I/O card (PortRead()). Next the most important part of the
simulator engine is executed - the Proc() function. The
Proc() function processes all variables, and evaluates output
states of the object (e.g. signals form the simulated
photocells).
There are two important tasks of the Proc() function. First of
all, the simulator must correctly model physical aspects of the
industrial object. For example, in the belt conveyor there
might be a situation, in which both drives (left and right) are
simultaneously activated by the PLC program under test.
This could possibly damage the belt, or the drives. Such
errors are monitored in the developed simulator. The belt
conveyor doesn’t work, if both drives are active. Moreover –
the simulator indicates such a situation by making the
conveyor blink. The second important task of the Proc()
method is to refresh, and reevaluate states of variables used
for visualization of the controlled process.
The last function in the simulator engine routine is
PortWrite(), which enables transmitting outputs of the object
(evaluated in Proc()) to the I/O card.
Reliable simulation of industrial objects controlled by a PLC
is possible, if the simulator sample time is at least an order of
magnitude shorter, than shortest time periods that can be
detected or generated by the PLC. The Windows system is
not well adapted to programming real-time applications. It is
thus difficult to guarantee a predefined response time for the
simulator. Practical experiments prove, that the I/O card used
with the proposed solution can work reliably for sample rates
of 1 ms. As we can estimate a PLC scan time to several tens
of milliseconds, the simulator speed obtained is well
sufficient for testing all the functions that are programmed
using the normal serially-cyclic paradigm of PLC operation.
Reliability of testing time-critical functions, i.e. interrupts,
high speed counters, and pulse outputs, is a distinct question.
It is a realistic assumption that during a normal PLC
operation an external interrupt is not triggered several times a
millisecond. This means that also interrupt sources can be
reliably simulated using the proposed solution. PLC high
speed counters, and pulse outputs can however work at
frequencies of up to several tens of kilohertz. This means that
their functionality cannot be well tested with the proposed
simulator. Testing at so high frequencies requires in fact a
hardware-software solution. A special I/O card is necessary,
containing hardware counters, and pulse generators.
Visualization of the belt conveyor was developed in 3D
graphics using the OpenGL library (OpenGL, 2010).
OpenGL is a low-level, procedural API, requiring from the
programmer to specify the exact steps necessary to render a
scene. This task is accomplished by using a set of base
primitives. The scene is rendered cyclically using the TTimer
class of the Borland C++ Builder. Variables modified in the
Proc() function of the TCtrl class are used to provide
animation (List. 2).
void Timer2(void)
{ is simulated by a program running on the PC. The program
OpenGL->Scene(Ctrl);
} evaluates appropriate feedback signals, and sends them back
Listing 2. The Timer2 routine – visualisation.
3.1 I/O card
The USB-4750 data acquisition device from Advantech was
used as the I/O card (Advantech, 2009). USB-4750 is a
32-channel isolated digital I/O module for the USB bus. The
main advantages of the module are:
• each I/O channel corresponds to a bit in an I/O port, (it is
very easy to program this module),
• supports dry and wet contacts,
• galvanic isolation provides protection of up to 2,500
VDC,
• features a counter, or timer,
• features digital input interrupt lines to a PC,
• is compatible with the USB Plug & Play specification,
and thus is easy to use,
• internal logic is powered from the USB port (no external
power connection is required, except for an object power
supply).
The USB module used is equipped only with isolated digital
inputs and outputs, as presented in Fig. 7. Modules equipped
with analog input/output channels or thermocouple-
compatible input channels are however available, too.
Fig. 7. A simplified diagram of a digital I/O terminal of the
USB-4750 card.
4. CONCLUSIONS
The paper presents an overview of hardware and software
tools used to support PLC program testing and verification. A
concept of a PC-based object simulator is proposed. The
simulator consists of a hardware, and a software part. The
hardware part is a PC equipped with an I/O card, providing
the interface to PLC inputs and outputs. Operation of the
equipment and devices, which shall be controlled by the PLC,
reads the states of control signals, generated by the PLC,
to PLC inputs through the I/O card.
As scanning of signals generated by the PLC can be
performed at a sample rate of 1 ms, the simulator response
time is much shorter, than a typical PLC scan time. The
simulator should thus behave to the PLC in the same manner,
as a real industrial object (provided that the object is correctly
modelled in the simulation software).
As the simulator is a separate device communicating with the
PLC through physical I/O-s, most of PLC, and control
software functionality can be tested, including interrupts. The
simulation is however too slow, to reliably test operation of
high speed counters, and pulse outputs. This requires special
hardware solutions, which are planned as future
developments of the basic concept.
Quality and reliability of the tests depend mainly on quality
of object modelling. It seems thus to be good practice to
appoint the tasks of developing the model of the object, and
the actual PLC software, to different programmer teams.
The paper presents the concept using an example of a simple
belt conveyor. The authors intend to develop in future a
library of universal industrial objects, e.g. a one-direction
drive, a motor-operated valve, for the simulator. By
combining models of simple elements, the user will be able
to quickly build a simulator model for his specific
installation.
It shall be stressed, that the concept of simulation presented
here is not meant to be a full replacement for test procedures
on real objects. Ensuring reliable and fault-free operation of a
control system is never possible without tests on site,
employing all components of the system fully operational. In
the authors’ opinion the simulator can however handle all
stages of an application development process, except final
verification. It seems to be reliable enough to detect most of
errors in the software, and in particular verify correctness of
algorithms at a higher level of hierarchy, networks, data
exchange with SCADA, etc. Because using the simulator is
safe, and much more convenient, than testing with real
hardware, it can significantly shorten commissioning time.
The proposed idea of an object simulator seams to be also an
attractive option for training purposes. A set of various object
models can be prepared for a PLC programming course. The
models can be easily launched and exchanged, and the
students will have the possibility to solve various problems,
that can be faced by developing commercial applications.
Using a simulator is cheaper, safer, and much more
convenient, than using real machines and objects.

REFERENCES
Advantech (2009), USB-4750 32-channel Isolated Digital I/O
USB Module, User Manual,
http://www.advantech.com/products/USB-4750/mod_1-
2MLJMR.aspx
CoDeSys (2003), User Manual for PLC Programming with
CoDeSys 2.3, 3S - Smart Software Solutions GmbH
ICS Triplex ISaGRAF (2009), ISaGRAF
http://www.isagraf.com
IBHSoftec (2010a), S7 Simulation PLC,
http://www.ibhsoftec-sps.de/english/Selection_Sim.htm
IBHSoftec (2010b), Extended Simulation S5,
http://www.ibhsoftec-sps.de/english/Selection_Sim.htm
Kulisz J. (2004), PLC Software Development supported by
utilising a Simulator Program Block, Proc. of the
International Conference on Programmable Devices and
Systems, PDS’2004, Cracow, Poland, November 18th -
19th, 2004, pp. 121-125
Mikoś Z., Wróbel G., Hayduk G., Kwasnowski P., Jachimski
M., Zygmunt H. (2009), Środowisko ISaGRAF do
tworzenia rozproszonych aplikacji sterowania i regulacji,
in Systemy czasu rzeczywistego. Postępy badań i
zastosowania, WKiŁ, Warszawa, pp. 43-62 (in Polish)
OpenGL (2010), The Industry's Foundation for High
Performance Graphics, http://www.opengl.org/
PC_Simu (2000), http://personales.ya.com/canalPLC
PLCSim (2007), S7-PLCSim V5.4 – User Manual,
A5E00992424-01, Siemens AG
RSLogix (2004), RSLogix Emulate. Getting Results Guide
Doc ID EMULAT-GR002A-EN-P, Rockwell
Automation, www.software.rockwell.com
RSLogix (2005), RSLogix Emulate 5000. Getting Results
Guide, Publication LGEM5K-GR015A-EN-P, Rockwell
Automation, www.software.rockwell.com
S7_200 (2000), http://personales.ya.com/canalPLC
TrySim (2010), Cephalos Gesellschaft für Automatisierung
mbH, http://www.trysim.de/en/
Unity (2007), Modicon M340 PLC Automation Platform
Unity Software, DIA6ED2061001EN-US, Schneider
Electric, www.us.telemecanique.com