Functionality Considerations in Custom SCADA

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:

graphical visualization tools for depicting and

controlling equipment and processes to an operator,
also called human-machine-interface (HMI)

drivers for PC PLC communications,

trending and archiving of process data,

synchronous and asynchronous scripting features for

basic programming tasks,

recipe management for automatic machine setup from

preset parameter recipes

and so on.

Data in a SCADA system are exchanged between the software

running on the personal computer and the RTUs in the field. Each
individual piece of data addressed in the system, including
process variables, internal calculation results, displayed values,
etc. is designated as a tag. Tags are analogous to variables in
other programming languages, and provide a means for measuring
the size of a SCADA application; applications can range from a
size of fewer than 100 tags for very small standalone systems to
tens or hundreds of thousands of tags for a system controlling a
complex system such as an oil refinery.

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]

1.2 Main Functional Points of SCADA

There are several functionalities associated with typical SCADA
systems. These are described below in detail.

Input/output: This is the ability to accept and transmit

data between the supervisory computer(s) and RTUs.
This is done by supplying the necessary network layers
between hardware (physical connection to the devices)
and application (required drivers to transfer data
between the supervisory software and hardware). Open
SCADA systems must supply functionality for a
variety of hardware types; proprietary SCADA systems
must supply functionality for a single hardware type or
family.

Alarming: This is the ability to create logic to interpret

conditions as problems requiring automated or human
intervention. Alarming can consist of notification only
or of actuating some solution to the problem.

Trending: This is the ability to graphically depict

variables as a function of time, typically in a value vs.
time line plot. Trending can be real-time (depicting
data up to the present and continuously self-updating)
or historical (depicting data from a user-selected time
window).

Reports: This is the ability to automatically generate

reports based on collected data, either locally for
viewing by the operator or archived for access through
another application such as a Web browser.

21st Computer Science Seminar

SC1-T1-1

Display: This is the ability to display data to the user,

often in a graphical format. Components of the display
may be animated or vary their appearance dynamically
depending on real-world conditions (such as the liquid
level of a tank being depicted as a tank icon partially
colored with a fraction equal to the tank level).

1.3 Development Schemes

Finished SCADA applications as deployed for end users are
developed by either automation contractors or developers at the
end user location. These applications are developed using tools
provided by COTS SCADA vendors. The developers purchase the
SCADA development tools from the vendors, and then also
purchase individual run-time licenses for each application
deployed. Application run-time licenses are typically sold on a
scale proportional to the size of the application; thus a license for
an application requiring 10,000 tags is likely to be more costly
than a license for an application requiring 100 tags. In addition,
maintenance fees on a per-application basis are usually required
to ensure technical support, version updates, etc. In summary the
cost of using COTS software can be quite high, especially as the
number of applications in an enterprise increases.

1.4 Other Development Considerations

The functionality provided with COTS SCADA development
software is typically provided as is, with needed functionality
bundled with superfluous functionality, where needed and
superfluous depend on the individual organization.
Functionality that is needed but not provided by a COTS SCADA
development package must be built or purchased elsewhere and
integrated with the original software. These concerns about COTS
software are not unique to SCADA software; [2] describes these
problems and others, including risk if the vendor drops the
product or support for the product, and quality shortcomings with
the vendor software. Also [3] observes that although custom
software is often unattractive because of long development costs,
some lessons learned though empirical findings include: the cost
to maintain COTS software equals or exceeds that of developing
custom software, and software engineers must spend significant
time and effort up front to analyze the impact of version updates
(even when the decision is made not to incorporate the updates).

2. THE CUSTOM SOFTWARE OPTION

2.1 Justification
As an alternative to the standard COTS SCADA development
approach, custom SCADA development tools created by the end
user could be considered. Custom software in this milieu is not
unprecedented; [4] describe the design and realization of a
component-based
application
framework
to
develop
Manufacturing Execution Systems (MES), where MES software
occupies a niche between SCADA software and enterpriseresource-planning (ERP) software.
Custom SCADA development tools are obviously not appropriate
for every organization given the sheer size of the engineering task
associated therewith. However for large enterprises with
substantial internal software development resources, or for
enterprises willing to purchase external software developing
capability, custom SCADA development tools may be a feasible

and even preferable alternative to COTS development tools. Some

reasons why custom software could be preferable include:
1.

The overall long-term cost may be lower if the

enterprise has a large number of SCADA
applications that would require licensing if
developed with COTS packages.

2.

The organization has control over version upgrades

to the software.

3.

The organization has a better understanding of the

software construction.

4.

The organization has control over the quality of the

SCADA development package and can choose
which aspects of quality should be emphasized.

It is the last point, that of being able to choose which areas of

quality to emphasize, that is examined in the rest of this paper.

2.2 Quality Considerations

The decision to implement a custom SCADA development
package implies that sufficient attention must be paid to quality
considerations. As described in ISO9126-1 [5], this includes
internal quality (the totality of characteristics of the software
product from an internal view), external quality (the totality of
characteristics of the software product from an internal view), and
quality in use (the users view of the quality of the software
product when it is used in a specific environment and a specific
context of use). Furthermore, the model for internal and external
quality can be divided into the broad categories of functionality,
reliability, usability, efficiency, maintainability, and portability.

2.3 Functionality Considerations

While all of these categories should be considered, the scope of
this paper is limited to the category of functionality. Functionality
is further divided into five subcategories: suitability, accuracy,
interoperability, security, and functionality compliance. These
subcategories are explained below, as they would pertain to
custom SCADA development software.
Suitability is described in ISO as the capability of the software
product to provide an appropriate set of functions for specified
tasks and user objectives. The set of functions necessary for
SCADA development software would include the key
components described above, including input/output, trending,
alarming, etc.
Accuracy is described in ISO as the capability of the software
product to provide the right or agreed results or effects with the
needed degree of precision. Accuracy with regards to SCADA
systems could include numeric or temporal precision. Numeric
precision would be the ability to provide data with the required
number of significant figures, within the required tolerance of
real-world values, etc. Temporal precision would be the ability to
read, write, or process data within an allowable amount of time.
Accuracy requirements will vary by industry or application; a
SCADA system for manufacturing inexpensive products will
probably have different accuracy requirements from one
controlling a nuclear power plant.
Interoperability is described in ISO as the capability of the
software product to interact with one or more specified systems.
There are two main aspects of interoperability that should be

21st Computer Science Seminar

SC1-T1-2

considered with respect to SCADA systems. First is

interoperability with regards to computer operating systems such
as Microsoft Windows (and its various versions), Unix, Linux,
etc. Second is interoperability with regards to various RTU types
and whether the SCADA software can interact with various
standardized (Ethernet, Profibus, etc.) or proprietary plant
communications networks.
Security is described in ISO as the capability of the software
product to protect information and data so that unauthorized
persons or systems cannot read or modify them and authorized
persons or systems are not denied access to them. Typically the
security features provided by SCADA software involve password
protected user accounts where functionality such as maintenance
screens can be limited. Other security functionality may be
present in the SCADA system but may be supplied by the
underlying operating system.
Functionality compliance is described in ISO as the capability of
the software product to adhere to standards, conventions or
regulations in laws and similar prescriptions relating to
functionality. Although SCADA software may be used to fulfill
government regulations (such as monitoring and recording of
pollutant emissions) there are no known government regulations
regarding functionality of SCADA systems.
Each category and aspect of quality of functionality will have a
different level of importance for different organizations. It is
critical for an organization to understand which functionality
aspects will be required for custom SCADA development, first to
decide whether to take on the commitment to produce the
required artifacts, and second to ensure success for this project. If
an organization already has an established SCADA application
base, then that base could be mined for indication of critical
functionalities to that organization. A study to determine the

critical functionalities of a particular organization is described

below.

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

Table 1: Functionality Decision Criteria

Functionality Aspect
Input/Output
Alarming
Trending

ISO Subcategory
Suitability
Suitability
Suitability

Animated Graphics

Suitability

Recipe Management

Suitability

Database Read/Write Access

Reporting

Suitability
Suitability

SPC
Password Protection

Suitability
Security

Operating System Flexibility (all)

Interoperability

Operating System Flexibility (MS

Windows)
RTU Flexibility

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?

21st Computer Science Seminar

SC1-T1-3

of present or not present was applied. The decision criteria for

each functionality aspect are listed above in Table 1.

4. RESULTS OF STUDY
4.1 Definitions

Table 3: Interoperability Results

Functionality
Aspect

Before discussing the results, several terms should be defined.

They are:
NT: the total number of applications examined
N(x): the total number of applications that incorporate
functionality x
Tags(n): the total number of tags in application n
Tags(total): the total number of tags in all applications =
NT

tags(n)

Operating
System
Flexibility
(all)
Operating
System
Flexibility
(MS
Windows)
RTU
Flexibility

n =1

Tags(x): the total number of tags in all applications that

incorporate functionality x

4.2 Suitability and Security

For each aspect x of suitability and security functionality, two
ratios were calculated. First, an absolute ratio of N(x)/NT was
calculated to show the pervasiveness of a particular functionality
in the organizations application base. Second, a tag-weighted
ratio of tags(x)/tags(total) was calculated to analyze whether
functionality requirements were skewed by very small or very
large applications. Results are shown in Table 2 below.
Table 2: Suitability and Security Results
Functionality Aspect
Input/Output
Alarming
Trending
Animated Graphics
Recipe Management
Database Read/Write
Access
Reporting
SPC
Password Protection

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.

There does not appear to be any skew as a result of

large or small applications. In each functionality
case the absolute and tag ratios are quite close, and
in no case is there a difference of more than 13%.

2.

Automated reporting, integrated SPC, and

interoperability between Microsoft and nonMicrosoft operating systems are not important to
this organization.

3.

Several functionality aspects are definitely

important to this organization, including:
input/output, alarming, trending, animated
graphics, password protection, RTU flexibility, and
network flexibility.

4.

Some functionality aspects appear to be

moderately important to this organization,
including: recipe management, database access,

Microsoft, Windows, Windows NT, Windows 2000, and

Windows XP are registered trademarks or trademarks of
Microsoft Corporation.

**

AB stands for Allen-Bradley. Allen-Bradley, 5/03, 5/04, 5/05,

FlexLogix, CompactLogix, ControlLogix, PLC-5, and
DataHighway+ are trademarks of Rockwell Automation, Inc.

21st Computer Science Seminar

SC1-T1-4

and operating system flexibility among Windows

operating systems.
An organization must decide on a strategy for incorporating the
results of such a survey into its functionality requirements for
custom SCADA development software. Strategies might include:

omission of superfluous functionality from the software

inclusion of critical functionality in the core of the

software

inclusion of moderately important functionality in the

core of the software, or use of third-party software for
these features as needed

Although the results show what functionality is required of

custom SCADA development software for a particular
organization, it is not comprehensive. There are several reasons
why additional functionality may be required in custom software
particular to an organization even if it is unused in the existing
SCADA base.
One case is that there may be functionality that is not offered by
the organizations COTS SCADA package. This functionality
could be generic and applicable to many organizations or specific
to a particular organization. A generic functionality might be
interaction with common enterprise-resource-planning (ERP)
software, a functionality typically not found in COTS SCADA
software (because it is accomplished by other software packages).
A specific functionality might be predictive modeling software
for an organizations process or equipment, incorporating
company-specific algorithms to improve performance. If
functionalities like these are required in existing processes, then
they are likely provided by software external to the SCADA
package, and should be considered when deciding the scope of a
custom SCADA development system.
A second case is that there may be functionality that is offered by
the organizations COTS SCADA package, but the functionality
exhibits defects in usability, reliability, maintainability, or other
quality aspects. A trending graph may be a useful functionality in
a SCADA package, yet if the implementation of the trending
functionality in practice is difficult to configure, offers poor
choices for display options, or frequently causes the system to
crash, it is unlikely to be used. However, a mitigating factor in
this case is the fact that organizations are free to choose among
COTS SCADA packages from many vendors, and it would seem
unlikely that organizations would willingly choose a package
exhibiting serious defects in the very aspects critical to their
applications.
A third case is that the existing SCADA application base for an
organization is not representative of that organizations future
needs. This could happen if the organization diversifies into other
types of processes, or because there are existing processes in
certain areas of the company that are still using technologies older
than SCADA. To be effective as a study tool, an existing SCADA
application base should of course be a good representation of

present and future needs. Major planned changes or additions to

the organizations existing process or equipment portfolio should
be considered in addition to the results of an application base
study.

6. CONCLUSIONS AND FUTURE WORK

The conclusions of this paper are as follows:
1.

Custom
SCADA
development
software
manufactured by organizations for their own use
may be a viable alternative to COTS SCADA
development packages.

2.

The quality requirements of custom SCADA

development software should be considered when
deciding whether this alternative should be
pursued. The ISO 9126-1 quality model is one tool
that can be used to define the quality requirements.

3.

The construction of functionality requirements for

custom SCADA development software can use an
existing SCADA application base to determine
critical functionality considerations. A survey of
suitability,
security,
and
interoperability
functionality in an existing application base, such
as the one presented here, can be used to
enumerate the importance of including various
functionality aspects in a custom development
package.

One area of future work that should be considered is expanding

the approach of studying an existing SCADA application base to
other aspects of quality, such as reliability, usability, and
maintainability. A survey-based approach such as was presented
in this paper may not be appropriate for these other aspects of
quality.

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.

21st Computer Science Seminar

SC1-T1-5