2017 2nd International Conference for Convergence in Technology (I2CT)

Scripting Engine for SCADA HMI

1
MRUNALI TANDEL, 2UDAY JOSHI, 3AMIT GOLHANI

Mrunali Tandel Uday Joshi

Department of Computer Engineering Department of Computer Engineering
K J Somaiya College of Engineering K J Somaiya College of Engineering
Mumbai, India Mumbai, India
mrunali.t@somaiya.edu udayjoshi@somaiya.edu

Amit Golhani
Power Electronics and Technology Center (PEATC)
Larsen & Toubro Electrical and Automation
Navi Mumbai, India
Amit.Golhani@lntebg.com

Abstract— Conventionally, the modules of SCADA system

such as Message broker, Human Machine Interface (HMI)
Building Environment, Database Manager and drivers including
the SCADA HMI are developed in compiler-based languages
such as C/C++. Thus, the person who develops the SCADA HMI
has to be well versed with that language whose learning curve is
steep. Every time the user has to rely on the SCADA engineer to
develop the SCADA HMI for them. Customization of SCADA
HMI is a difficult task, as all the classes and the pointers in the
language has to be managed by the SCADA Engineer, thus,
increasing the time to market. Scripting Engine module with
combination of Qt technology is introduced in this study, which
enables the SCADA Engineer to develop SCADA HMI using easy
to use scripting language, balancing the time required for
development as well as meeting the performance standards. As
scripting languages are believed to be easily adoptable by the
non-programmer, the person with the non-programming
background can easily setup the SCADA screens. The
comparative analysis of the Scripting Engine approach and
conventional approach is also presented in this study.
Keywords— SCADA, Human Machine Interface (HMI),
Database Manager, compiler-based language, scripting language.
I. INTRODUCTION
Supervisory Control and Data Acquisition (SCADA)
system is an industrial software used for monitoring and
controlling processes remotely, mostly used in utility and
manufacturing industry for monitoring processes, alarms and
events [6]. The typical SCADA system consists of
components such as Human-Machine Interface (HMI),
SCADA Server, Driver, PLC and actual on-field device to be
monitored as shown in Figure 1 below:
Figure 1 Block Diagram of SCADA
From the development of SCADA system to its usage
in industry, there are three roles assigned to a person
associated with the SCADA. The first role is SCADA
Developer, who develops the core logic of data processing and
mechanism of control and communication. The second role is
of SCADA Engineer, who develops the SCADA HMI for the
user, according to the needs and requirement of SCADA
system at the user-side and the purpose for which it is used.
The third role is of SCADA Operator, who monitors and
controls the processes; acknowledge alerts and events on the
remote devices using the HMI developed by SCADA
Engineer. The SCADA HMI is easy to use because of the
efforts put in by the SCADA Engineers, who write the display
logic behind the SCADA HMI using the core libraries
developed by the SCADA Developer.
In the conventional approach of SCADA development,
the entire thing ie. Core libraries and display logic is
developed entirely using compiler-based programming
languages like C/C++. Generally, the compiler-based
languages are difficult to master in. But they provide the best
performance for the developed application and thus are
considered as first choice for real-time application
development like SCADA. Another alternative is to develop
the application using an interpreter-based scripting language.
Scripting languages are easy to adopt and use. But the
applications developed using scripting language are not

978-1-5090-4307-1/17/$31.00 ©2017 IEEE 492

performance efficient compared to those developed using
compiler-based languages. In order to make the SCADA
development approach easy and performance efficient, the
concept of Scripting Engine is introduced in SCADA
development.
The Scripting Engine is a tool/component or library
introduced in SCADA suite, which is able to load script,
interpret at runtime, execute it and fetch the result to the
SCADA HMI. The Scripting Engine is integrated with the
SCADA HMI Builder, which can be used by the SCADA
Engineer to develop the SCADA HMI. The main aim of its
introduction in SCADA development is to make the task of
SCADA Engineer much easier with easy to use small script as
well as developing application with almost same performance
efficiency compared to the application developed entirely in
C++. Thus, its introduction in SCADA reduces the
dependency on C/C++ proficient SCADA Engineer. Along
with this, it will enable the easy customization of application
according to the industrial requirements and automation of the
repetitive tasks.
The mechanism of Scripting Engine is to handle the
performance critical tasks at core library level, which is
developed using compiler-based language like C/C++ and
providing the provision for SCADA Engineer to access the
core libraries using scripting language [7]. Thus, the SCADA
Engineer can develop the SCADA HMI using script without
hampering the overall performance. The provision is given to
write the display logic using scripting language.
II. DETAILS EXPERIMENTAL
A. Module Structure
The placement of the implemented Scripting Engine in
the SCADA system is as shown below in Figure 2.
Figure 2 Scripting Engine in SCADA System
The Scripting Engine for SCADA is integrated with
SCADA HMI Builder which is the development environment
provided for SCADA Engineers. The SCADA Engineer can
use the Engine using the script and the Script Editor is
493
integrated with the each SCADA UI objects. The Scripting
Engine is responsible for interacting with the core libraries
which manages the interaction with field devices using
drivers. Thus, the events are managed to-and-fro the HMI
module using Scripting Engine. It is also responsible for
fetching the records from Historical Database, which can be
provided to the other modules of HMI such as Report &
Trends generating modules. In addition to this, the scripting
engine also provides communication facility where, the status
of the SCADA can be reported to the remote user. Thus, it
automates the remote communication process easily.
The mechanism behind Scripting Engine is as shown in
Figure 3 below:
Figure 3 Mechanism of Scripting Engine
In Figure 3, Scripting Engine is placed between
middleware module and HMI screen. On arrival of an event
(e.g. Alarming condition), the event is passed by Middleware
Broker to the Scripting Engine. The event is handled by the
GUI module and it is further passed to the library. An
appropriate function is selected by library and interpreted by
command interpreter. Once, the command is interpreted i.e. it
is decided what should be displayed on the screen (eg. Red
color display for alarming condition), the control is send back
to the GUI Module and once the properties are set, the GUI
component is rendered on the HMI screen.
B. Languages and Technology
The following are the languages and technology used
for the experimental setup of Scripting Engine for SCADA:
• Qt Framework, which is a cross-platform application
and user-interface development framework, is used to
develop development environment for SCADA
Engineer, HMI Builder, which is integrated with
Scripting Engine [8].
• Based on the previous work done of literature survey,
Python scripting language is used for Scripting
Engine for SCADA and appropriate Python binding
for Qt is used. Thus, the SCADA Engineer is given
the provision to develop SCADA HMI using Python
scripts [4].
 • The core-libraries, where performance critical task,
communication and control mechanism is
implemented, are developed using compiler-based
C/C++ language.
• SQL Server is used for historical database storage.
• SMTP protocol is used for remote notification of
SCADA status.
C. Functionality Provided
The following essential functions are implemented for
Scripting Engine of SCADA that can be used by SCADA
Engineer for SCADA HMI development based on which
evaluation is done.
• Database Functions:
The Database Function for SCADA includes function
for retrieving historical data from historical database,
which can be used for reporting, getting object (device)
and tag details (both system and user-created) from online
database. The SCADA Engineer can use it to display the
data on SCADA HMI using easy to use python script.
• Tag Functions:
This includes the set of functions mostly used for
control and monitoring of remote field devices. It includes
the function for getting and setting on field device’s tag
values as well as monitoring the live status of devices.
These functions are mainly used for displaying the field
values on SCADA UI component by SCADA Engineer.
The SCADA Engineer can also provide the SCADA
Operator to control the Tag values by writing the display
logic using this set of functions.
• Communication Functions:
These functions include the functions to notify the
remote user about SCADA status. The functions include
the function to send SMS and email and to read SMS and
Email. The SCADA Engineer can configure the functions
for SCADA UI components representing devices, to
automatically notify the remote user about the device
status.
• File Handling Functions:
These functions include functions for file handling
which the SCADA Engineer can use to design the
SCADA HMI and providing the user to handle the files
using SCADA HMI.
• Standard library extension:
In addition to above functionality provided, the
standard python library (Time and String Functions) is
also extended, which can be used by SCADA Engineer to
write display logic.
494
III. RESULT AND DISCUSSION
As the approach of Scripting Engine for SCADA
development resolves around using scripts for UI
development, unlike conventional approach, the ease of the
development of UI is enhanced and dependency on the
proficient C/C++ programmer is reduced. In order to compare
the conventional approach with Scripting Engine approach for
SCADA development, SCADA HMI screens are developed
using both approaches with no functional difference.
Following are the observations noted when Scripting Engine
approach for SCADA development is compared with the
conventional approach:
A. Standard Python Library extension
The standard python library includes String, Math, Time
and File handling functions that can be used by SCADA user
for SCADA development. Apart from that, this standard
library functions are extended in the Scripting Engine
considering the requirements of the SCADA and its users.
B. Auomated Database Connection management
For retrieving the historical data or alarm data using
the conventional approach, the users have to explicitly open
the connection, generate the query for retrieving the data from
the server and should close the connection, upon receiving the
data. The user will also have to deal with complex datatypes
of the library for programmatically accessing SQL Server to
retrieve the values from the SQL server.
Eg. Functionality in C++:
PGconn* connection=NULL;
connection=PQconnectdb("user=********** password=**********
dbname=HistoricalDB hostaddr=127.0.0.1 port=5432");
PGresult* res;
res=PQexec(conn, "BEGIN");
res=PQexec(conn, Sql_statement.c_str()); // Sql_statement is the query
res=PQexec(conn, "FETCH ALL FROM record");
Close_connection(conn);
Additionally, to convert the data from the complex
datatype to the simple format, which can be used in UI
development, complex logic has to be written and memory has
to be managed carefully, to avoid memory leakage.
Unlike the conventional approach, the user has to be
concerned about passing the proper Tag ID and Timestamp
range for query generation and the Scripting Engine will
handle the connection, query generation and handling complex
datatypes.
Eg. Functionality in Python:
data_req=DATA_REQUEST(1, b"14/10/15 09:35", b"10/12/15 17:00",
b"value_number")
retrieve_historical_data(byref(data_req))
In the above example DATA_REQUEST is the structure
defined in Scripting Engine. The value can be retrieved by
accessing the data member of the structure.
C. Automated Memory management
For retrieving the historical data or alarm data using
conventional approach, the user has to delete the memory
allocated to the data handling variable once it is given to UI
screen component, as it will lead to memory leakage.
Using the scripting engine approach, the memory is
automatically deallocated at python-level, once the variable is
out of scope. The memory management at library level is
handled by the destructor of DATA_REQUEST.
## The destructor
def __del__(self):
lib.delete_obj.restype=None
lib.delete_obj.argtypes=[ctypes.POINTER(DATA_REQUEST)]
lib.delete_obj(self)
The similar approach is implemented for all other
functions of Scripting Engine for automating memory
management, reducing the burden at user-side.
D. No exposure of Core library classes
For the development of SCADA HMI using
conventional approach, it is observed that the classes of core
libraries have to be exposed to the user, in order to get/set the
data from server. In Scripting Engine approach, only the
information needed to develop the SCADA HMI is provided
to the Engineer, and it can be accessed using script.
Eg. For getting the list of the names of the objects registered at
the Database Manager using C++ with Qt:
ElementList objElementList;
ElementDetails objElementDetails;
ObjectList pObjectList=(ObjectList)GetProcAddress(m_pHandle,
"ObjectList");
pObjectList("_Mod_Device", objElementList);
for(Luint i=0; i<objElementList.getElementCount(); i++)
{
objElementList.getElementDetailsat(i, objElementDetails);
QString objName=
QString::fromStdString(objElementDetails.getElementName());
}
In the above example ElementList and
ElementDetails are the classes of Core library in SCADA.
Thus, it would be very difficult for user to keep the track of
classes to be used as well as extracting the names using its
instance.
Using the Scripting Engine library, there is no need
to expose the core library classes and to retrieve the list using
instance of those classes. Instead, the user has to write a line
code to get the list of the object.
Eg. Python Script:
lDeviceList=getObjectName("_Mod_Device")
E. Buffer Management and Socket Communication
For sending notification to remote location via
SMS/Email using conventional approach, the user has to
manage the socket communication and will have to send and
receive buffers, interpret the command received and will have
to extract the data to and from the buffer. This requires the
495
person who is proficient with buffer management
programmatically and well versed with socket programming.
In addition, the user has to free the allocated memory space as
the amount of data received in this type of communication is
huge. And the application is more prone to memory leakage.
Eg. For sending SMS using conventional approach, the user
will have to createFile, readFile and writeFile for comport
using fileAPI and will have to extract the response received.
For doing the same task using Scripting Engine
approach, the user can open COM port, send SMS and close
COM port using a simple function.
Eg. Sending SMS using Scripting Engine:
i=openComport(3, 9600, "8N1")
sendSMS(i, "+91**********", "Message")
closeComport(i)
F. Less Coding
The amount code required to design the complex UI screen
using conventional approach is more compared to the
approach of Scripting Engine. To prove this, four complex
applications were developed using the compiler based
approach and scripting engine approach with functional
difference. Following are the difference observed in Lines of
Code (LoC):
Table 1 Comparative analysis of Scripting Engine approach and
Compiler based approach in terms of Lines of Code (LoC)
The number of lines of code required for developing
using conventional approach is almost 2.49 times larger than
those required by using Scripting Engine approach.
The reason is the complicated task handled by Scripting
Engine, no memory management at user-level coding and no
datatype handling.
G. Datatype Handling
In conventional approach, if the user has to store some
value returned by some function, it has to be declared prior to
its use.
Eg. C++ with Qt:
bool bIsChecked;
bIsChecked= ui->isPolling->isChecked()
 Using the scripting engine approach, the user is not
concerned with the declaration of the datatype and can directly
use it.
Eg. Python with Qt:
bIsChecked=self.ui. isPolling.isChecked()
H. Performance
In [[4]], the performances of the different scripting
languages are compared with respect to Kilobytes lines of
code. In SCADA screen development using Scripting Engine
approach, the typical screen size can range from 4kB to 100
kB as only the business logic is scripted and rest of the
performance critical task are managed at the library level.
Thus, the drawback of Python being slow for real-time
application development than compiler-based languages is
compensated.
The performance test has been done to check the
performance difference between the conventional approach
and Scripting Engine approach. To do this, 500 objects were
created in Database of objectType Meter and all the objects of
that object type were retrieved on SCADA screen initialization
and displayed on the screen.
Table 2 Comparative analysis of Scripting Engine approach and
Compiler based approach in terms of Performance
IV. CONCLUSION
The Scripting Engine for SCADA aims to provide a
flexible solution to the SCADA development. As interpreter-
based language is used, there is no need for the compilation at
user side, unlike the traditional approach where the object
rendering and command interpretation was done using C/C++
language. The ease with which the scripting language is
adopted and learned is nowhere closer to the compiled
language. Thus, the SCADA engineer need not be a person
496
proficient in complex compiler-based language. The
customization of application at user side is possible with the
scripting language. Thus, the Scripting Engine helps in rapid
development of SCADA and is far better than the
conventional approach of C/C++. As, all of the performance
critical tasks are managed at the library level, the performance
of the resulting application is acceptable, balancing the best of
both the languages (Compiler-based and Interpreter-based).
Acknowledgment
The authors are thankful to Dr. Shubha Pandit, the
Principal of K J Somaiya College of Engineering, Prof.
Bharthi Narayan, Head of Computer Department, Mr. Rahul
Rane and Mr. Shishir Gupta from Larsen & Toubro
Automation, Navi Mumbai, for providing the opportunity and
necessary facilities for the preparation of the paper.
References
[1] Hans Christian Woithe and Ulrich Kremer, "A Light Weight Scripting
for the Slocum Glider", IEEE Oceans 2010 Conference, Sydney,
Australia, May 2010.
[2] M. McLaughlin and M. Katchabaw, "A Reusable Scripting Engine for
Automating Cinematics and Cut-Scenes in Video Games", Proceedings
of CGSA 2006 Symposium.
[3] Milivoj Bozic, Dusan Zivkov, Istvan Pap and Goran Miljkovic,
"Scriptable Graphical user Interface Engine for embedded platform",
21st Telecommunication Forum TELFOR 2013.
[4] Mrunali Tandel, Prof. Uday Joshi and Amit Golhani, "Literature
Review: Scripting in Qt for Scripting Engine development",
International Journal of Computer Science and Information
Technologies, Vol. 7(3), 2016, 1242-1245.
[5] QiangXie, Jinfeng Liu and Pai H. Chou, "Tapper: A lightweight
Scripting engine for highly constrained wireless sensor nodes", IPSN
2006.
[6] SCADA (Supervisory Control and Data Acquisition),
http://whatis.techtarget.com/definition/SCADA-supervisory-control-
and-data-acquisition
[7] Scripting|Mono, http://www.mono-
project.com/docs/advanced/embedding/scripting/
[8] Qt Documentation, 2016, http://doc.qt.io/qt-5/index.html
[9] PyQt Whitepaper, Riverbank Computing Limited,
www.riverbankcomputing.com, 2013.