Documente Academic
Documente Profesional
Documente Cultură
Development Tools
Timothy P. Creegan
ABSTRACT
Supervisory control and data acquisition (SCADA) software is
used to control and monitor processes throughout industry. The
licensing cost of software and the bundling of potentially
superfluous functionality into commercial SCADA software could
lead organizations to develop their own custom SCADA
development tools for internal use. It is important to understand
the functionality criteria unique to each organization. A method
for determining the critical functionality factors for SCADA
software is presented, along with an example study of an
organizations SCADA software base.
Keywords
SCADA, COTS, Software Functionality, Software Quality
1. INTRODUCTION
1.1 Basics of SCADA
Supervisory control and data acquisition (SCADA) software is
used in manufacturing and utility industries for control and
monitoring of industrial equipment, processes, and production
data. A typical SCADA system consists of one or more personal
computers, a software application developed with the SCADA
vendors development tools, and one or more remote devices
called remote terminal units (RTUs), which could include
programmable logic controllers (PLCs), utility meters, smart
process transmitters, or others. Features of the software
applications typically include:
and so on.
There is some confusion about the term SCADA and other similar
terms including Process Control System and Human Machine
Interface. At one time SCADA systems were primarily known
for utility monitoring, and field devices were typically far-flung
meters accessible only by modem or radio communications. At
that time the term SCADA implied remote communication with
an RTU, while Process Control System implied local
communication such as within the same physical building. Today
however there is less of a distinction between local and remote
control as digital communication (e.g. Ethernet) has become
prevalent, and SCADA no longer connotes distance between
supervisory computer and controlled device. Human Machine
Interface (HMI) is another term often used interchangeably with
SCADA, but HMI systems strictly speaking do not incorporate
control or data acquisition, only display of system data and
acceptance of human input to the system.
Commercial-off-the shelf (COTS) SCADA development software
packages can be divided into two families: proprietary and open.
A proprietary SCADA development package is intended to be
used with a specific application type and/or hardware type. Open
SCADA development packages are intended to be usable for a
wide variety of application and hardware combinations. [1]
2.
3.
4.
3. METHODOLOGY OF STUDY
A study of an organizations existing SCADA base was
conducted to determine what functionality aspects were being
used and consequently should be considered if the organization
decides to create custom SCADA development software. The
organizations existing SCADA base consisted of 25 applications,
ranging from the smallest application of 230 tags to the largest of
2651 tags. These applications were developed using a single
vendors COTS SCADA development package. Eighteen of the
applications were developed internally by the organization; seven
of the applications were developed externally and delivered as
part of turnkey projects. These applications are representative of
the organizations entire breadth of processes.
A list of 13 functionality aspects was considered. These aspects
are common functionalities typically bundled with COTS
SCADA development software. This list was derived from the
literature as well as from the features offered by the specific
vendor. The first 9 functionality aspects (input/output, alarming,
trending, animated graphics, recipe management, database access,
reporting, statistical process control [SPC] and password
protection) were considered separately for each particular
application. The last 4 functionality aspects (flexibility across all
operating systems, flexibility across Microsoft Windows
operating systems, flexibility between RTU manufacturers,
flexibility between communications networks), which were all
aspects of interoperability, were considered across the entire
SCADA base, since interoperability is not meaningful when
applied to a single application.
For each application and each functionality aspect, a Boolean test
ISO Subcategory
Suitability
Suitability
Suitability
Animated Graphics
Suitability
Recipe Management
Suitability
Suitability
Suitability
SPC
Password Protection
Suitability
Security
Interoperability
Interoperability
Network Flexibility
Interoperability
Interoperability
Decision criteria
Does the application exchange data with an RTU?
Are any tags in the application configured for automatic alarming?
Are there any real-time or historical trending displays included in the
application?
Is the appearance of any graphics programmed to vary depending on
real-world conditions?
Is the recipe manager utility provided by the vendor used to save or
load tag values?
Are data read from or written to an external database?
Are human-readable reports automatically generated by the
application?
Is the SPC utility provided by the vendor used to analyze data?
Are there multiple password-protected user accounts configured in the
application?
Does the existing SCADA base include applications running on more
than one vendors operating system?
Does the existing SCADA base include applications running on more
than one Microsoft Windows version?
Does the existing SCADA base include applications communicating
with more than one type of RTU?
Does the existing SCADA base include applications incorporating
more than one communications network?
4. RESULTS OF STUDY
4.1 Definitions
tags(n)
Operating
System
Flexibility
(all)
Operating
System
Flexibility
(MS
Windows)
RTU
Flexibility
n =1
Absolute Ratio
1.00
0.92
0.96
0.88
0.68
0.52
Tag Ratio
1.00
0.98
0.99
0.94
0.69
0.65
0.00
0.04
0.88
0.00
0.01
0.93
RTU
Flexibility
(cont.)
RTU
Flexibility
(cont.)
Network
Flexibility
Condition/
Abs. Ratio/
Tag ratio
Microsoft
Windows*/
1.00/
1.00
Windows
NT/
0.12/
0.07
Condition/
Abs. Ratio/
Tag ratio
Other OS/
0.00/
0.00
Condition/
Abs. Ratio/
Tag ratio
---
Windows 2000/
0.72/
0.75
Windows XP/
0.16/
0.18
AB** 5/03/
0.04/
0.01
AB
FlexLogix/
0.04/
0.01
AB PLC-5/
0.08/
0.06
RS-232/
0.04
0.01
AB 5/04/
0.36/
0.34
AB
CompactLogix/
0.04/
0.02
---
AB 5/05/
0.32
0.39
AB
ControlLogix/
0.12/
0.17
---
AB
DataHighway+/
0.44/
0.40
Ethernet/
0.52/
0.60
5. DISCUSSION OF RESULTS
The results indicate which aspects of functionality in SCADA
software are important to this organization. We can draw the
following conclusions from the results presented.
4.3 Interoperability
For each aspect x of interoperability functionality, the entire
application base was considered, and an absolute ratio and tag
ratio was calculated for each possible condition. The conditions
and ratios for each are listed below in Table 3. The absolute and
tag ratios for all conditions should add to 1.00; some do not due to
rounding errors.
1.
2.
3.
4.
**
Custom
SCADA
development
software
manufactured by organizations for their own use
may be a viable alternative to COTS SCADA
development packages.
2.
3.
7. REFERENCES
[1] Bailey, D., and Wright, E. Practical SCADA for Industry.
Elsevier Press, Oxford, England, 2003.
[2] Voas, J. COTS Software: The Economical Choice? IEEE
Software, 15, 2 (March 1998), 16-19.
[3] Reifer, D., Basili, V., Boehm, B., and Clark, B. Eight Lessons
Learned during COTS Based Systems Maintenance. IEEE
Software, 20, 5 (September 2003), 94-96.
[4] Furicht, R., Prahofer, H., Hofinger, T., and Altmann, J. A
Component-Based Application Framework for Manufacturing
Execution Systems in C# and .NET. In Proceedings of the 40th
International Conference on Technology of Object-Oriented
Languages and Systems (Sydney, Australia, 2002). Australian
Computer Society, Inc., Darlinghurst, Australia, 2002, 169-178.
[5] ISO/IEC 9126-1. Software Engineering-Product Quality-Part
1: Quality Model. International Organisation for Standardization,
Geneva, Switzerland, 2001.