Designing SCADA Application Software

A Practical Approach

Stuart G McCrady

• Publisher: Elsevier
• Year: 2013
• ISBN:
  9780124170353
• Topic: Computer Science
• Subtopic: CAD-CAM
• Index: Computer Science

Automation systems, often referred to as SCADA systems, involve programming at several levels; these systems include computer type field controllers that monitor and control plant equipment such as conveyor systems, pumps, and user workstations that allow the user to monitor and control the equipment through color graphic displays. All of the components of these systems are integrated through a network, such as Ethernet for fast communications.

This book provides a practical guide to developing the application software for all aspects of the automation system, from the field controllers to the user interface workstations. The focus of the book is to not only provide practical methods for designing and developing the software, but also to develop a complete set of software documentation. Providing tested examples and proceducres, this book will be indespensible to all engineers managing automation systems.

• Clear instructions with real-world examples
• Guidance on how to design and develop well-structured application programs
• Identification of software documentation requirements and organization of point names with logical naming system
• Guidance on best practice of standardized programming methods for SCADA systems

1

Introduction

Objectives

Explain the origin of SCADA

Summarize the processing of input/output signals

Identify the scope and function of the software in SCADA systems

Explain the importance of documentation for software systems

Highlight two major reasons for the development of this book

Today’s Supervisory Control and Data Acquisition (SCADA) systems incorporate Programmable Logic Controllers (PLCs), Human Machine Interface (HMI) workstations and network communication systems into a complete integrated system. Each of the major components requires one or more form of programming from program logic to configuration to process graphic displays to communication configuration. Since there are many aspects to the SCADA application software, it is important to use a structured organized approach to the design and development of this software; hence, the establishment of standards is very important.

1.1 SCADA: Convergence of Evolving Technologies

Before identifying and discussing the elements of SCADA software, let us first take a brief tour of what SCADA is, where the term came from, and how it came to be. The term means Supervisory Control and Data Acquisition. The term was first used in the late 1980s but did not become a common term until the 1990s, as the technologies to be discussed evolved. There have been Distributed Control Systems (DCSs) since the 1960s and 1970s, but they were tightly integrated and proprietary control systems confined to a single plant or facility.

1.1.1 Early Automation Systems

In the 1960s and 1970s, the minicomputer served as the predecessor to the current day PLC; the minicomputer was programmed in assembly or machine language and interfaced directly with plant devices. The minicomputer was a general purpose digital computer, capable of being programmed in a few different languages, but it was primarily used for automation systems in plants. I have programmed many such systems, mostly in machine language, but some even used FORTRAN and ALGOL!

The PLC first came into being around 1971, designed and built by Gould Modicon, and was intended to replace the traditional relay ladder logic electrical circuitry. The programming language was developed to mimic the relay logic of the electrical circuits, with ‘power’ and ‘return’ rails on the left and right, respectively. By around 1977, Allen–Bradley introduced their first major PLC, by which time the idea of a programmable controller had become quite widely accepted. The minicomputer was being replaced with these new programmable devices, primarily because the language was already familiar to the electricians, and hence learning to ‘program the circuits’ was pretty straightforward. These controllers were also digital computers but were designed to interface to the basic field signals we still use today: discrete inputs and outputs, and analog inputs and outputs.

The PLC hardware and software continued to develop and evolve until the programming became much more than the original electrical circuitry that they were meant to replace. With the introduction of Microsoft Windows and the Graphical User Interface (GUI), more intuitive and graphical programming became possible. Today, the PLC programmer expects an easy to use yet feature rich programming environment.

1.1.2 The Human Interface

Back to the 1970s, the user or human interface to the early minicomputer systems consisted of a monitor and a keyboard, with alphanumeric text only. Getting the computer to display a line of text was an accomplishment, and when colour came along, ‘special effects’ were possible; for example, having different coloured text and some basic shapes like a square could now be produced. Once again, the introduction of Windows and the graphical interface made many things possible, not just coloured text. By the late 1990s, extensive process control graphic displays were possible with animation and graphical representation of field conditions.

The first personal computers were developed for commercial use by IBM, and companies like Intellution developed complete user interface software packages which executed on the personal computers, and could be interfaced to the PLCs. This SCADA software provided a graphical interface into the system, as well as, both current and historical database files which could be accessed for reporting information. Other companies developed personal computers, of course, and today there are many different brands available, all of which can serve as a user interface workstation to the process world of the plant or system.

1.1.3 Communications and Integration

However, the communication technology had to develop in order to integrate or combine the software on the personal computer with the programmable controllers in the plant. Initially, the communication involved proprietary protocols between the computer software and the PLC, but now Ethernet with TCP/IP has become one of the industry standards. The personal computer software, which became known as the HMI software, could then be integrated seamlessly with any of the brands of PLCs on the market. High-speed networks and communication systems are standard today, but in the 1970s and 1980s, a dial up modem with 1200 bits per second was considered great!

So, by the 1990s, all of this technology had developed to the point where almost any PLC brand and any HMI software brand, could be integrated into a system of any number of workstations and PLCs. By this time, the term SCADA had become a common term, even though there were automation systems using minicomputers and custom-designed hardware interfaces in the 1970s, which were the early versions of SCADA systems.

A SCADA system, therefore, can be considered any combination of PLCs and HMI workstations, supported by a communication network for both in-plant facilities and remote sites that functions as a fully integrated system. The communication facility now extends to the Internet for Wide Area Networks (WANs) and regional systems.

1.2 Basics of SCADA Signal Processing

Before getting into any details on the software involved in SCADA systems, it might be helpful to review some basic concepts on how field signals are processed and interfaced with the field controllers, such that the application software can work with and interact with the physical electrical world for which these controllers were designed. The field controller, commonly referred to as a PLC, is a specialized computer which works with binary information. The purpose of the input and output modules of the PLC is to convert signals from the physical world to and from the internal software world.

There are only four basic data types which are connected to the PLC: discrete input, discrete output, analog input and analog output. All input signals processed by the PLC and all output signals driven by the PLC are in one of these four forms. Hardware modules in the PLC chassis or rack use electronics and firmware to process the input signals and generate the output signals.

The discrete input is a two-state signal, represented by electricity flowing (True) or not flowing (False). The binary system relates this to the ‘1’ and ‘0’ values of software. A discrete or digital input might be a switch, photocell, pushbutton, contact, or proximity sensor; the signal is either on or off. The discrete input module would represent this presence or absence of the electrical signal as ‘1’ or ‘0’.

The discrete output is a two-state signal, represented by electrical flow also, but is sent to devices such as lamps, motor contactors and solenoid valves. The ‘1’ or ‘0’ state in the internal software is converted to the presence or absence of an electrical signal to the device; the electrical circuit is either on (1) or off (0). Hence, devices can be turned on or off, depending upon the state of the binary point in the PLC program.

Analog inputs are represented by a range of electrical signals, such as 1–5 Volts Direct Current (VDC) or 4–20 milliamps (mA). This electrical signal is generated by a transducer, which converts a field value to a proportional electrical signal. The analog input module samples the input signal, and converts it to a 16-bit binary number in the range of 0–32,767. The low end of the signal, 0 VDC or 4 mA, would be stored as a value of zero (0); the high end of the signal, 5 VDC or 20 mA, would be stored as a value of 32,767. The current value of the voltage or current is converted to a binary number which is proportional to the electrical signal between the two limits mentioned. Hence, the PLC works with binary numbers in the range of 0–32,767, representing the field signal of 1–5 VDC or 4–20 mA.

Analog outputs begin as internal 16-bit values, and are then converted to an electrical signal in the range of the 1–5 VDC or 4–20 mA; these signals in turn drive speed controllers, valve positioners, and any other variable control device. The output signal is in the same proportion as the internal 16-bit value. So the analog output works the same as the analog input signal but in reverse.

The field controller therefore works entirely in software using the binary number system. Discrete and analog data are represented by either a single binary digit, or a group of 16 bits called a word or integer. In this binary form, programs can then perform calculations and comparisons to perform control operations.

Working with analog data values, for example, turning an oven on or off can be determined based upon the temperature of the oven; following is a structured programming version of the logic involved:

IF Furnace.Temperature>High.Temperature.Limit

THEN

Turn off the heat to the oven.

ELSE

IF the Furnace.Temperature<Low.Temperature.Limit

THEN

Turn on the heat to the oven.

ENDIF

Working with discrete data values, a motor start/stop control output can be turned on or off based upon the required states of specific input signals, as shown in the following programming sample:

IF Motor.Remote=True .AND. Motor.Alarm=False .AND. Motor.Start=True

THEN

Turn on motor run control output.

ELSE

Turn off motor run control output.

ENDIF

Throughout this book, there are references to discrete and analog data; it is important to understand where this data comes from, and to remember that input and output modules are used to convert or translate between the physical or electrical world and the internal software world of binary numbers. A discrete input or output is the presence (on) or absence (off) of an electrical signal, while an analog input or output is a varying signal between two limits, such as 1–5 VDC or 4–20 mA.

1.3 Defining the Scope of SCADA Software

Traditionally, the PLC was programmed by electricians, as the ladder logic programming was designed to resemble electrical diagrams. At first, this approach worked well, as the electrician already understood how a program should work. But as the PLC software evolved into more complex features and operations, the programming extended well beyond what could be done in an electrical wiring diagram. With this added functionality, there was a need to better organize and design the software for the PLC.

At the same time, HMI, developed from simple meters, chart recorders, and pushbutton and selector switches, into very sophisticated graphic interfaces. First there was the Cathode Ray Tube (CRT), which was combined with a keyboard. Then the CRT led to Liquid Crystal Displays (LCDs), which required much less space with better resolution. As this user interface evolved, there was again a need to better organize and design the images and information being displayed to the user.

With both user interfaces (i.e. HMI) and sophisticated field controllers (i.e. PLC), the combination of these devices evolved into what is now referred to as a SCADA system. Interconnecting the HMI and PLC equipment required more advanced methods of communication, such as networks and special driver software. And then came the issue of interconnectivity with other systems: the result was Local Area Networks (LANs) and WANs.

SCADA software involves much more than a set of engineering drawings; as will be explained in subsequent chapters, the application software for a SCADA project involves spreadsheets, design documents, user reference manual material and detailed program information. Thus, the software for these systems is very extensive and requires a combination of design documents.

Today, designing, developing and implementing SCADA systems requires a...

Table of contents

• Cover image
• Title page
• Table of Contents
• Copyright
• About the Author
• Preface
• 1. Introduction
• 2. The Elements of SCADA Software
• 3. Practical Procedures for SCADA Software Development
• 4. Documentation for SCADA Systems
• 5. Tagnames and Signal Naming Conventions
• 6. Developing the Application Program Databases
• 7. Process Control Logic Descriptions
• 8. User Operations Reference Manual
• 9. Guidelines for Controller Application Programming
• 10. Guidelines for Workstation Application Programming
• 11. System Integration, Commissioning and Checkout
• 12. Sample Project – Applying the Principles
• Appendix A. Glossary of Technical Terms
• Appendix B. TSNC Dictionaries
• Appendix C. Sample Process Control Logic Description
• Appendix D. Program Listings for PPC Program