INDUSTRIAL AUTOMATION CONTROL SYSTEM
Industrial control system (ICS) is a general term that encompasses several types of control
systems and associated instrumentation used in industrial production technology including
supervisory control and data acquisition (SCADA) systems, distributed control systems (DCS),
and other smaller control system configurations such as programmable logic controllers (PLC)
often found in the industrial sectors and critical infrastructures. Industrial control systems are
typically used in industries such as electrical, water, oil, gas and data. Based on data received from
remote stations, automated or operator-driven supervisory commands can be pushed to remote
station control devices, which are often referred to as field devices. Field devices control local
operations such as opening and closing valves and breakers, collecting data from sensor
systems, and monitoring the local environment for alarm conditions.
The control action is the form of the controller output action.
Discrete control (on/off)
One of the simplest types of control is on-off control. An example is a thermostat used on
household appliances that either open or closes an electrical contact. (Thermostats were
originally developed as true feedback-control mechanisms rather than the on-off common
household appliance thermostat.)Sequence control, in which a programmed sequence of
discrete operations is performed, is often based on system logic that involves system states. An
elevator control system is an example of a sequence
A proportional–integral–derivative controller (PID controller) is a control loop feedback
mechanism (controller) widely used in industrial control systems. A PID controller continuously
calculates an error value as the difference between the desired setpoint and a measured process
variable and applies a correction based on proportional, integral, and derivative terms,
respectively (sometimes denoted P, I, and D) which give their name to the controller type.The
theoretical understanding and application dates from the 1920s, and they are implemented in
nearly all analogue control systems; originally in mechanical controllers, and then using
discrete electronics and latterly in industrial process computers.
Sequential control and logical sequence or system state control
Sequential control may be either to a fixed sequence or to a logical one that will perform
different actions depending on various system states. An example of an adjustable but otherwise
fixed sequence is a timer on a lawn sprinkler. States refer to the various conditions that can
occur in a use or sequence scenario of the system. An example is an elevator, which uses logic
based on the system state to perform certain actions in response to its state and operator input.
For example, if the operator presses the floor n button, the system will respond depending on
whether the elevator is stopped or moving, going up or down, if the door is open or closed,
and other conditions. Early development of sequential control was relay logic, by which
electrical relays engage electrical contacts that either start or interrupt power to a device.
Relays were first used in telegraph networks before being developed for controlling other
devices, such as when starting and stopping industrial-sized electric motors or opening and
closing solenoid valves. Using relays for control purposes allowed event-driven control, where
actions could be triggered out of sequence, in response to external events. These were more
flexible in their response than the rigid single-sequence cam timers. More complicated
examples involved maintaining safe sequences for devices such as swing bridge controls, where
a lock bolt needed to be disengaged before the bridge could be moved, and the lock bolt could
not be released until the safety gates had already been closed. the total number of relays, cam
timers and drum sequencers can number into the hundreds or even thousands in some factories.
Early programming techniques and languages were needed to make such systems manageable,
one of the first being ladder logic, where diagrams of the interconnected relays resembled the
rungs of a ladder. Special computers called programmable logic controllers were later designed
to replace these collections of hardware with a single, more easily re-programmed unit. In a
typical hard-wired motor start and stop circuit (called a control circuit) a motor is started by
pushing a “Start” or “Run” button that activates a pair of electrical relays. The “lock-in” relay
locks in contacts that keep the control circuit energized when the push button is released. (The
the start button is a normally open contact and the stop button is normally closed contact.) Another
relay energizes a switch that powers the device that throws the motor starter switch (three sets
of contacts for three-phase industrial power) in the main power circuit. Large motors use high
voltage and experience high in-rush current, making speed important in making and breaking
contact. This can be dangerous for personnel and property with manual switches. The “lock-in”
contacts in the start circuit and the main power contacts for the motor are held engaged by their
respective electromagnets until a”stop” or”off” button is pressed, which de-energizes the lock in
the relay. Commonly interlocks are added to a control circuit. Suppose that the motor in the
example is powering machinery that has a critical need for lubrication. In this case, an interlock
could be added to ensure that the oil pump is running before the motor starts. Timers, limit
switches and electric eyes are other common elements in control circuits. Solenoid valves are
widely used on compressed air or hydraulic fluid for powering actuators on mechanical
components. While motors are used to supply continuous rotary motion, actuators are typically
a better choice for intermittently creating a limited range of movement for a mechanical
component, such as moving various mechanical arms, opening or closing valves, and raising heavy
press rolls, applying pressure to presses.
Computers can perform both sequential control and feedback control, and typically a single
computer will do both in an industrial application. Programmable logic controllers (PLCs)are a
type of special-purpose microprocessor that replaced many hardware components such as timers
and drum sequencers used in relay logic type systems. General-purpose process control
computers have increasingly replaced stand-alone controllers, with a single computer able to
perform the operations of hundreds of controllers. Process control computers can process data
from a network of PLCs, instruments and controllers in order to implement typical (such as PID)
control of many individual variables or, in some cases, implement complex control
algorithms using multiple inputs and mathematical manipulations. They can also analyze data
and create real-time graphical displays for operators and run reports for operators, engineers and
management. Control of an automated teller machine (ATM) is an example of an interactive
process in which a computer will perform a logic derived response to a user selection based on
information retrieved from a networked database. The ATM process has similarities to other
online transaction processes. The different logical responses are called scenarios. Such
processes are typically designed with the aid of use cases and flowcharts which guide the
writing of the software code
Automation control system
The earliest feedback control mechanism was the water clock invented by a Greek engineer
Ctesibius (285–222 BC). In the modern era, the thermostat was invented in 1620 by the Dutch
scientist Cornelius Drebbel. (Note: Early thermostats were temperature regulators or controllers
rather than the on-off mechanisms common in household appliances.) Another control
mechanism was used to tent the sails of windmills. It was patented by Edmund Lee in 1745.
Also in 1745, Jacques de Vaucanson invented the first automated loom. In 1771 Richard
Arkwright invented the first fully automated spinning mill driven by water power, known at the
time as the water frame. An automatic flour mill was developed by Oliver Evans in 1785,
making it the first completely automated industrial process. The centrifugal governor, which
was invented by Christian Huygens in the seventeenth century, was used to adjust the gap
Another centrifugal governor was used by a Mr Bunce of England
in 1784 as part of a model steam crane.
The centrifugal governor was adopted by James
Watt for use on a steam engine in 1788 after Watt’s partner Boulton saw one at a flour mill
Boulton & Watt were building. The governor could not actually hold a set speed; the engine
would assume a new constant speed in response to load changes. The governor was able to
handle smaller variations such as those caused by fluctuating heat load to the boiler. Also, there
was a tendency for oscillation whenever there was a speed change. As a consequence, engines
equipped with this governor were not suitable for operations requiring constant speed, such as
cotton spinning. Several improvements to the governor, plus improvements to valve cut-off
timing on the steam engine made the engine suitable for most industrial uses before the end of
the 19th century. Advances in the steam engine stayed well ahead of science, both
thermodynamics and control theory. The governor received relatively little scientific attention
until James Clerk Maxwell published a paper that established the beginning of a theoretical
basis for understanding control theory. Development of the electronic amplifier during the
The 1920s, which was important for long-distance telephony, required a higher signal to noise ratio,
which was solved by negative feedback noise cancellation. This and other telephony
applications contributed to control theory. Military applications during the Second World War
that contributed to and benefited from control theory were fire-control systems and aircraft
controls. The so-called classical theoretical treatment of control theory dates to the 1940s and
The 1950s.Relay logic was introduced with factory electrification, which underwent rapid adaption
from 1900 through the 1920s. Central electric power stations were also undergoing rapid growth
and the operation of new high-pressure boilers, steam turbines and electrical substations created a
large demand for instruments and controls. Central control rooms became common in the 1920s,
but as late as the early 1930s, most process controls were on-off. Operators typically monitored
charts drawn by recorders that plotted data from instruments. To make corrections, operators
manually opened or closed valves or turned switches on or off. Control rooms also used colour-coded lights to send signals to workers in the plant to manually make certain
changes. Controllers, which were able to make calculated changes in response to deviations
from a set point rather than on-off control, began being introduced in the 1930s. Controllers
allowed manufacturing to continue showing productivity gains to offset the declining influence
of factory electrification. Factory productivity was greatly increased by electrification in
Advantages and disadvantages of automation
The main advantages of automation are:
• Increased throughput or productivity.
• Improved quality or increased predictability of quality.
• Improved robustness (consistency), of processes or products.
• Increased consistency of output.
• Reduced direct human labour costs and expenses.
The following methods are often employed to improve productivity, quality, or robustness.
• Install automation in operations to reduce cycle time.
• Install automation where a high degree of accuracy is required.
• Replacing human operators in tasks that involve hard physical or monotonous work.
• Replacing humans in tasks done in dangerous environments (i.e. fire, space, volcanoes,
nuclear facilities, underwater, etc.)
• Performing tasks that are beyond human capabilities of size, weight, speed, endurance, etc.
• Reduces operation time and work handling time significantly.
• Frees up workers to take on other roles.
• Provides higher-level jobs in the development, deployment, maintenance and running of the
The main disadvantages of automation are:
• Security Threats/Vulnerability: An automated system may have a limited level of
intelligence, and is, therefore, more susceptible to committing errors outside of its immediate
scope of knowledge (e.g., it is typically unable to apply the rules of simple logic to general
•Unpredictable/excessive development costs: The research and development cost of automating
a process may exceed the cost saved by the automation itself.
• High initial cost: The automation of a new product or plant typically requires a very large
initial investment in comparison with the unit cost of the product, although the cost of
automation may be spread among many products and over time. In manufacturing, the purpose
of automation has shifted to issues broader than productivity, cost, and time.
A programmable logic controller (PLC), or programmable controller is an industrial digital
computer that has been ruggedised and adapted for the control of manufacturing processes,
such as assembly lines, robotic devices, or any activity that requires high-reliability control
and ease of programming and process fault diagnosis. They were first developed in the
automobile industry to provide flexible, ruggedised and easily programmable controllers to
replace hard-wired relays and timers. Since then they have been widely adopted as high-reliability automation controllers suitable for harsh environments. A PLC is an example of a
“hard” real-time system since output results must be produced in response to input conditions
within a limited time, otherwise, an unintended operation will result.PLCs can range from small
“building brick” devices with tens of I/O in a housing integral with the processor, to large rack-mounted modular devices with a count of thousands of I/O, which are often networked to
other PLC and SCADA systems. They can be designed for multiple arrangements of digital and
analogue inputs and outputs (I/O), extended temperature ranges, immunity to electrical noise, and
resistance to vibration and impact. Programs to control machine operation are typically stored
in battery-backed-up or non-volatile memory. It was from the automotive industry in the USA
that the PLC was born. Before the PLC, control, sequencing, and safety interlock logic for
manufacturing automobiles was mainly composed of relays, cam timers, drum sequencers, and
dedicated closed-loop controllers. Since these could number in the hundreds or even thousands,
the process for updating such facilities for the yearly model change-over was very time
consuming and expensive, as electricians needed to individually rewire the relays to change
their operational characteristics. When digital computers became available, being general-purpose programmable devices, they were soon applied to control sequential and combinatorial
logic in industrial processes. Modern PLCs can be programmed in a variety of ways, from the
relay-derived ladder logic to programming languages such as specially adapted dialects of
BASIC and C. Another method is state logic, a very high-level programming language designed
to program PLCs based on state transition diagrams. The majority of PLC systems today adhere
to the IEC 61131/3 control systems programming standard that defines 5 languages: Ladder
Diagram (LD), Structured Text (ST), Function Block Diagram (FBD), Instruction List (IL) and
Sequential Flow Chart (SFC). Many early PLCs did not have accompanying programming
terminals that were capable of graphical representation of the logic, and so the logic was instead
represented as a series of logic expressions in some version of the Boolean format, similar to
Boolean algebra. As programming terminals evolved, it became more common for ladder logic
to be used, for the aforementioned reasons and because it was a familiar format used for
electromechanical control panels. Newer formats such as state logic and Function Block (which
is similar to the way logic is depicted when using digital integrated logic circuits) exist, but they
are still not as popular as ladder logic. A primary reason for this is that PLCs solve the logic in
a predictable and repeating sequence, and ladder logic allows the programmer (the person
writing the logic) to see any issues with the timing of the logic sequence more easily than
would be possible in other formats
PLCs contain three basic sections:
- a central processing unit (CPU).
- Memory: EPROM, RAM, and so on.
- Input/output section for communication with peripherals (ADC, DAC).
A PLC is basically a black box with a number of inputs from, and a number of
outputs to, the outside world. It can make decisions, store data, do timing cycles, do simple
arithmetic, convert codes, and so on. The basic difference between this black box and a
hardware logic system using IC chips or a relay controlled system, is that specific coded
messages are stored in areas called program memory, which are PROM or ROM and RAM
chips. It is, however, much easier to change a program when a different process is required
than to rewire the control system.
For example, it may take electricians a couple of weeks to require a pipe mill,
whereas a programmer will spend only a fraction of this time reprogramming a PLC since no
wires will have to be changed. In addition, various recipes can be stored in memory and
accessed when required, making the program extremely flexible.
The system operates through interaction with the processor and program memory.
When the power to the system is turned on, the processor reads the first instruction stored in
memory and acts on this instruction. When completed, it goes back to the memory for the next
instruction, and so on until the task is complete. This operation is called the fetch-execute cycle.
The processor communicates with the outside world via input and output modules.
THE PARTS OF A PROGRAMMABLE CONTROLLER
Programmable logic controllers (PLC) can be considered to have two parts:
1 Input/output Section
The I/O section contains input modules and output modules. Functionally, the input
modules are equivalent to the signal converters (i.e. Analog to Digital or high power to low
power). All modern PLC input modules use optical devices to accomplish electrically isolated
coupling between the input circuit and the processor electronics.
Each input device is wired to a particular input terminal on the I/O section. Thus if
the switch is closed, 5v dc appears on the input terminal, converts this dc voltage to a digital 1 and
sends it to the processor via the programmable peripheral interface (PPI). Conversely, if the switch
is open, no dc voltage appears on the input terminal. Input section will respond to this condition by
sending a digital 0 to the processor. The other input terminals behave identically.
- The processor of a PLC holds and executes the user program. In order to
carry out this job, the processor must store the most up-to-date input and output conditions.
(a)Input image table:
The input conditions are stored in the input image table, which is a portion of the processor’s
memory. That is, every single input module in the I/O section has assigned to it a particular
location within the input image table. That particular location is dedicated solely to the task of
keeping track of the latest condition of its input terminal. As mentioned in an earlier section, if
the input terminal has 5v dc power fed to it by its input device, the location within the input
image table contains a binary 1(HI); if the input terminal has no 5v dc power fed to it, the
location contains a binary 0(LO).
The processor needs to know the latest input conditions because the user program instructions
are contingent upon those conditions. In other words, an individual instruction may have one
outcome if a particular input is HI and a different outcome if that input is LO.
Output image table: The output conditions are stored in the output image table, which is
another portion of the processor’s memory. The output image table bears the same relation to
the output interface of the I/O section that while terminals are analogue inputs. You can directly
connect any analogue input to the processor via these terminals. Analog signal from these
terminals is first converted to digital value via a programmable peripheral interface (PPI). The
I/O section’s output modules are functionally the same as the output amplifiers.
They receive a low power digital signal from the processor and convert it into a high power
signal capable of driving an industrial load. A modern PLC output module is optically isolated
and uses a tri ac, power transistor or relay as the series connected load controlling device.
Terminals 1 to 8 is these type of O/P terminals whereas terminal D/A is an Analog output terminal
from the processor. Each output device is wired to a particular output terminal on the I/O interface.
Thus, for example, if output module 1 receives a digital 1 by applying 5v dc to an output terminal
1, thereby illuminating LED is extinguished.
Besides 5v dc (TTL devices), I/O modules are also for interfacing to other industrial levels,
including 12v dc. The input image table bears the input modules. That is, every single output
module has assigned to it a particular memory location is dedicated solely to the task of keeping
track of the latest condition of its output module. Of course, the output situation differs from the
input situation with regard to the direction of information flow is from the output image table to
the output modules, while in the input situation the information flow is from the input modules
to the input image table.
The locations within the input and output image tables are identified by addresses,
which refers to the unique address of each terminal.
(C) Central processing unit:
The subsection of the processor that actually performs the program execution will
be called the central processing unit (CPU) with reference to input and output image table CPU
executes the user program and continuously updates the output image table.
The output image table has a dual nature; its first function is to receive immediate
information from the CPU and pass it on to the output modules of the I/O section; but secondly,
it also must be capable of passing output information “backwards” to the CPU, when the user
program instruction that the CPU is working on calls for an item of output information. The
input image table does not have a dual nature. Its single mission is to acquire information
from the input modules and pass that information “forward” to the CPU when the instruction
that the CPU is working on calls for an item of input information.
(d)User program memory:
A particular portion of the processor’s memory is used for storing the user
program instructions. We will use the name user program memory to refer to this processor
Before a PLC can begin controlling an industrial system, a human user must enter
the coded instructions that make up the user program. This procedure is called programming the
As the user enters instructions, they are automatically stored at sequential locations
within the user program memory. This sequential placement of program instructions is self-regulated by the PLC, with no discretion needed by the human user.
The total number of instructions in the user program can range from a half dozen or
so, for controlling a simple machine, to several thousand, for controlling a complex machine or
After the programming procedure is complete, the human user manually switches
the PLC out to PROGRAM mode into RUN mode, which causes the CPU to start executing the
program from beginning to end repeatedly.
As long as the PLC is left in the RUN mode, the processor executes the user program over and
over again. The figure depicts the entire repetitive series of events. Beginning at the top of the circle
representing the scan cycle, the first operation is the input scan. During the input scan, the
current status of every input module is stored in the input image table, bringing it up to date.
Following the input scan, the processor enters its user program execution and
Sometimes called “program scan”. The program executes with reference to input and output
image tables and updates the output image table.
Throughout the user program execution, the processor continuously keeps its output
image table up to date, as stated earlier. However, the output modules themselves are not kept
continuously up to date. Instead, the entire output image table is transferred to the output
module during the output scan following the program execution.
(f) Data Memory:
A PLC is a computer, after all. Therefore, it can perform arithmetic, numeric
comparisons, counting, etc. Naturally, the numbers and data can change from one scan cycle to
the next. Therefore the PLC must have a section of its memory set aside for keeping track of
variable data, or numbers, that are involved with the user program. This section of memory we
will call data memory.
When the CPU is executing an instruction for which a certain data value must be
known, that data value is brought in from data memory. When the CPU executes an
instruction that provides a numerical result, that result is put out into data memory. Thus, CPU
can read from or write to the data memory. Understand that this relationship is different from
the relationship between the CPU and the user program memory. When the user program is
executing, the CPU can only read from the user program memory, never write to it.
(g) Operating System of PLC:
The function of the operating system is to present the user with the equivalent of an extended
machine or virtual machine that is easier to program than the underlying hardware.
Due to this operating system, PLC is very easy to program. It can be programmed using
electrical schemes with familiar relay symbols so that a plant electrician can easily access the
PLC. The function of the PLC Operating system is:
1 Load the user program from the programming device to program memory.
2 To read the status of input devices.
3 To execute the user program.
4 form and update the input image table.
5 As per the status of the output image table controls the output devices.
6 To provide user-friendly functions.
This O.S. makes supervision of the entire system, so O.S. programs are said to running in
When the user completely enters his program in user memory, he transfers control from
PROGRAM mode to RUN mode. In RUN mode the control of the whole system is transferred
to the operating system. Now operating system takes care of the whole system such that the whole
system becomes automatic and appears as magic to users.
Early PLCs, up to the mid-1990s, were programmed using proprietary programming panels or
special-purpose programming terminals, which often had dedicated function keys representing
the various logical elements of PLC programs. Some proprietary programming terminals
displayed the elements of PLC programs as graphic symbols, but plain ASCII character
representations of contacts, coils, and wires were common. Programs were stored on cassette
tape cartridges. Facilities for printing and documentation were minimal due to a lack of memory
capacity. The oldest PLCs used non-volatile magnetic core memory. More recently, PLCs are
programmed using application software on personal computers, which now represent the logic
in graphic form instead of character symbols. The computer is connected to the PLC through
USB, Ethernet, RS-232, RS-485, or RS-422 cabling. The programming software allows entry
and editing of the ladder-style logic. In some software packages, it is also possible to view and
edit the program in function block diagrams, sequence flow charts and structured text.
Generally, the software provides functions for debugging and troubleshooting the PLC software,
for example, by highlighting portions of the logic to show the current status during operation or via
simulation. The software will upload and download the PLC program, for backup and
restoration purposes. In some models of programmable controller, the program is transferred
from a personal computer to the PLC through a programming board which writes the program
into a removable chip such as an EPROM
Basics of Programming
There are two types of contacts in PLC and they are normally open and normally closed
switches. A normally open contact means the contact is on when pressed/closed, and a normally
closed contact is on when open/not pressed. Contacts represent the states of real-world inputs
like sensors, switches, if the part is present, empty, full, etc. PLCs also consist of coils, which
are outputs like motors, pumps, lights, timers, etc. The PLC examines inputs and turns coils on
or off whenever it is needed. They can also be used as inputs to other rungs .in the ladder
Functionality of plc
The functionality of the PLC has evolved over the years to include sequential relay control,
motion control, process control, distributed control systems, and networking. The data handling,
storage, processing power, and communication capabilities of some modern PLCs are
approximately equivalent to desktop computers. PLC-like programming combined with remote
I/O hardware, allows a general-purpose desktop computer to overlap some PLCs in certain
applications. Desktop computer controllers have not been generally accepted in heavy industry
because the desktop computers run on less stable operating systems than do PLCs, and because
the desktop computer hardware is typically not designed to the same levels of tolerance to
temperature, humidity, vibration, and longevity as the processors used in PLCs. Operating
systems such as Windows do not lend themselves to deterministic logic execution, with the
result that the controller may not always respond to changes in input status with the consistency
in timing expected from PLCs. Desktop logic applications find use in less critical situations,
such as laboratory automation and use in small facilities where the application is less critical.
Basic and Complex functions
The most basic function of a Programmable logic controller (PLC) is to receive inputs from
status components, which can be from sensors or switches. Some of the basic components of a
PLCs are input modules, a central processing unit, output modules, and a programming device.
When an input is activated, some output will also be activated by whatever you told the
machine to do. Some examples of this are setting a timer to 10ms, activating the timer and once
10ms have passed a siren goes off. Some advantages to using a PLC over other programming
devices are the user doesn’t have to rewire anything, the PLC has very little downtime in
between running different programs, the user can program off-line, and PLCs aren’t time-constrained. If the user tells the PLC to perform output in 10ms, it will perform the output in
10ms unlike other programs like LabView which can have a delay in inactivation.
Timers and Counters
The main function of a timer is to keep output on for a specific length of time. A good
example of this is a garage light needing to be cut off after 2 minutes to give someone time to go
into the house. The three different types of timers that are commonly used are a Delay-OFF, a
Delay-ON, and a Delay-ON-Retentive. A Delay-OFF timer activates immediately when turned
on, counts down from a programmed time then cuts off, and is cleared when the enabling input
is off. A Delay-ON timer is activated by input and starts accumulating time, counts up to a
programmed time and then cuts off, and is cleared when the enabling input is turned off. A
The delay-ON-Retentive timer is activated by input and starts accumulating time, retains the
accumulated value even if the rung goes false, and resets only by a RESET contact. Counters are
primarily used for counting items such as cans going into a box on an assembly line. This is
important because once something is filled to its max the item needs to be moved on so
something else can be filled. Many companies use counters in PLCs to count boxes, count how
many feet of something is covered, or count how many pallets are on a truck. There are three
types of counters, Up counters, Down counters, and Up/Down counters. Up counters count up
to the preset value, turn on the CTU when the preset value is reached, and clear on reset.
Down counters count down from a preset value, turns on CTD when 0 is reached, and clear
on reset. Up/Down counters count up on CU, count down on CD, turn on when CTUD is
greater than the preset value is reached and clear on reset
Programmable logic relay (PLR)
In more recent years, small products called PLRs (programmable logic relays), and also by
similar names, have become more common and accepted. These are much like PLCs and are
used in light industry where only a few points of I/O (i.e. a few signals coming in from the real
world and a few going out) are needed, and low cost is desired. These small devices are
typically made in a common physical size and shape by several manufacturers and branded by
the makers of larger PLC s to fill out their low-end product range. Popular names include PICO
Controller, NANO PLC, and other names imply very small controllers. Most of these have 8
to 12 discrete inputs, 4 to 8 discrete outputs, and up to 2 Analog inputs. Size is usually about 4″
wide, 3″ high, and 3″ deep. Most such devices include a tiny postage-stamp-sized LCD screen
for viewing simplified ladder logic (only a very small portion of the program is visible at a
given time) and status of I/O points, and typically these screens are accompanied by a 4-way
rocker push-button plus four more separate push-buttons, similar to the key buttons on a VCR
remote control, and used to navigate and edit the logic. Most have a small plug for connecting
via RS-232 or RS-485 to a personal computer so that programmers can use simple Windows
applications for programming instead of being forced to use the tiny LCD and push-button set
for this purpose. Unlike regular PLCthat which are usually modular and greatly expandable, the
PLR s are usually not modular or expandable, but their price can be two orders of magnitude
less than a PLC, and they still offer robust design and deterministic execution of the logic.
The main difference from other computers is that PLCs are armoured for severe conditions (such
as dust, moisture, heat, cold), and have the facility for extensive input/output (I/O)
arrangements. These connect the PLC to sensors and actuators. PLCs read limit switches,
analogue process variables (such as temperature and pressure), and the positions of complex
positioning systems. Some use machine vision.
On the actuator side, PLCs operate electric
motors, pneumatic or hydraulic cylinders, magnetic relays, solenoids, or analogue outputs. The
input/output arrangements may be built into a simple PLC, or the PLC may have external I/O
modules attached to a computer network that plugs into the PLC.
A PLC program is generally executed repeatedly as long as the controlled system is running.
The status of physical input points is copied to an area of memory accessible to the processor,
sometimes called the “I/O Image Table”. The program is then run from its first instruction rung
down to the last rung. It takes some time for the processor of the PLC to evaluate all the rungs
and update the I/O image table with the status of outputs. This scan time may be a few
milliseconds for a small program or on a fast processor, but older PLCs running very large
programs could take much longer (say, up to 100 ms) to execute the program. If the scan time
were too long, the response of the PLC to process conditions would be too slow to be useful.
As PLCs became more advanced, methods were developed to change the sequence of ladder
execution, and subroutines were implemented. This simplified programming could be used to
save scan time for high-speed processes; for example, parts of the program used only for setting
up the machine could be segregated from those parts required to operate at a higher speed
Special-purpose I/O modules may be used where the scan time of the PLC is too long to allow
predictable performance. Precision timing modules, or counter modules for use with shaft
encoders, are used where the scan time would be too long to reliably count pulses or detect the
sense of rotation of an encoder. The relatively slow PLC can still interpret the counted values to
control a machine, but the accumulation of pulses is done by a dedicated module that is
unaffected by the speed of the program execution.
Process of a scan cycle
The 5 main steps in one complete scan cycle are reading the inputs, executing the program,
processing communication requests, executing CPU diagnostics, and writing to the outputs. To
read the inputs, the user writes values to the input image table which are reserved in bytes.
When executing the program, the ladder is read from right to left, and top to bottom. When
processing communication requests, the user processes any message received from the
communications port. To execute the CPU Self-Diagnostic test, check the firmware, check the
program, and check the status of the module
A small PLC will have a fixed number of connections built in for inputs and outputs. Typically,
expansions are available in the base model has insufficient I/O.Modular PLCs have a chassis
(also called a rack) into which are placed modules with different functions. The processor and
selection of I/O modules are customized for the particular application. Several racks can be
administered by a single processor and may have thousands of inputs and outputs. Either a
special high speed serial I/O link or comparable communication method is used so that racks
can be distributed away from the processor, reducing the wiring costs for large plants. Options
are also available to mount I/O points directly to the machine and utilize quick disconnecting
cables to sensors and valves, saving time for wiring and replacing components.
PLCs may need to interact with people for the purpose of configuration, alarm reporting, or
everyday control. A human-machine interface (HMI) is employed for this purpose. HMIs are
also referred to as man-machine interfaces (MMIs) and graphical user interfaces (GUIs). A
simple system may use buttons and lights to interact with the user. Text displays are available
as well as graphical touch screens. More complex systems use programming and monitoring
software installed on a computer, with the PLC connected via a communication interface.
PLCs have built-in communications ports, usually 9-pin RS-232, RS-422, RS-485, and Ethernet.
Various protocols are usually included. Many of these protocols are vendor-specific.Most
modern PLCs can communicate over a network to some other system, such as a computer
running a SCADA (Supervisory Control And Data Acquisition) system or web browser.PLCs
used in larger I/O systems may have peer-to-peer (P2P) communication between processors.
This allows separate parts of a complex process to have individual control while allowing the
subsystems to coordinate over the communication link. These communication links are also
often used for HMI devices such as keypads or PC-type workstations. Formerly, some
manufacturers offered dedicated communication modules as an add-on function where the
processor had no network connection built in.
PLC programs are typically written in a special application on a personal computer, then
downloaded by a direct-connection cable or over a network to the PLC. The program is stored
in the PLC either in battery-backed-up RAM or some other non-volatile flash memory. Often,
a single PLC can be programmed to replace thousands of relays.
Under the IEC 61131-3
standard, PLCs can be programmed using standards-based programming languages. The most
commonly used programming language is Ladder diagram (LD) also known as Ladder logic. It
uses Contact-Coil logic to make programs like an electrical control diagram. A graphical
programming notation called Sequential Function Charts is available on certain programmable
controllers. A model which emulated electromechanical control panel devices (such as the
contact and coils of relays) which PLCs replaced. This model remains common today.
IEC 61131-3 currently defines five programming languages for programmable control systems:
function block diagram (FBD), ladder diagram (LD), structured text (ST; similar to the Pascal
programming language), instruction list (IL; similar to assembly language), and sequential
function chart (SFC). These techniques emphasize the logical organization of operations. While
the fundamental concepts of PLC programming are common to all manufacturers, differences
in I/O addressing, memory organization, and instruction sets mean that PLC programs are never
perfectly interchangeable between different makers. Even within the same product line of a
single manufacturer, different models may not be directly compatible.
Control example shown in ladder diagram
This is a programming example in the ladder diagram which shows the control system. A ladder
diagram is a method of drawing control circuits that pre-dates PLCs. The ladder diagram
resembles the schematic diagram of a system built with electromechanical relays. As an
example, say a facility needs to store water in a tank. The water is drawn from the tank by
another system, as needed, and our example system must manage the water level in the tank by
controlling the valve that refills the tank. . Shown are:
• Two inputs (from the low and high-level switches) are represented by contacts of the float
• An output to the fill valve, labelled as the fill valve which it controls
• An “internal” contact, representing the output signal to the fill valve which is created in the
• A logical control scheme created by the interconnection of these items in software
In the ladder diagram, the contact symbols represent the state of bits in processor memory, which
corresponds to the state of physical inputs to the system. If a discrete input is energized, the
memory bit is a 1, and a “normally open” contact controlled by that bit will pass a logic “true”
a signal on to the next element of the ladder. Therefore, the contacts in the PLC program that
“read” or look at the physical switch contacts, in this case, must be “opposite” or open in order to
return a TRUE for the closed physical switches. Internal status bits, corresponding to the state
of discrete outputs, are also available to the program. In the example, the physical state of the
float switch contacts must be considered when choosing “normally open” or “normally closed”
symbols in the ladder diagram. The PLC has two discrete inputs from float switches (Low
Level and High Level). Both float switches (normally closed) open their contacts when the
water level in the tank is above the physical location of the switch. When the water level is
below both switches, the float switch physical contacts are both closed, and true (logic 1)
value is passed to the Fill Valve output. Water begins to fill the tank. The internal “Fill Valve”
contact latches the circuit so that even when the “Low Level” contact opens (as the water passes
the lower switch), the fill valve remains on. Since the High Level is also normally closed, water
continues to flow as the water level remains between the two switch levels. Once the water
level rises enough so that the “High Level” switch is off (opened), the PLC will shut the inlet to
stop the water from overflowing; this is an example of seal-in (latching) logic. The output is
sealed in until a high-level condition breaks the circuit. After that, the fill valve remains off until
the level drops so low that the Low-Level switch is activated, and the process repeats again.
| (N.C. physical (N.C. physical |
| Switch) Switch) |
| Low-Level High-Level Fill Valve |
|——[ ]——|——[ ]———————-(OUT)———|
A complete program may contain thousands of rungs, evaluated in sequence. Typically the PLC
processor will alternately scan all its inputs and update outputs, then evaluate the ladder logic;
input changes during a program scan will not be effective until the next I/O update. A complete
program scan may take only a few milliseconds, much faster than changes in the controlled
process. Programmable controllers vary in their capabilities for a “rung” of a ladder diagram.
Some only allow a single output bit. There are typically limits to the number of series contacts
in line, and the number of branches that can be used. Each element of the rung is evaluated
sequentially. If elements change their state during the evaluation of a rung, hard-to-diagnose faults
can be generated, although sometimes (as above) the technique is useful. Some
implementations forced evaluation from left to right as displayed and did not allow the reverse
flow of a logic signal (in multi-branched rungs) to affect the output.
Prior to the discovery of the Stuxnet computer worm in June 2010, the security of PLCs received
little attention. PLCs generally contain a real-time operating system such as OS-9 or VxWorks,
and exploits for these systems exist much as they do for desktop computer operating systems
such as Microsoft Windows. PLCs can also be attacked by gaining control of a computer they
In order to properly understand the operation of a PLC, it is necessary to spend considerable
time programming, testing, and debugging PLC programs. PLC systems are inherently
expensive, and downtime is often very costly. In addition, if a PLC is programmed incorrectly
it can result in lost productivity and dangerous conditions. PLC simulation software such as
PLCLogix can save time in the design of automated control applications and can also increase
the level of safety associated with equipment since various “what if” scenarios can be tried and
tested before the system is activated.
Some special processes need to work permanently with minimum unwanted downtime.
Therefore, it is necessary to design a system that is fault-tolerant and capable of handling the
process with faulty modules. In such cases to increase the system availability in the event of
hardware component failure, redundant CPU or I/O modules with the same functionality can be
added to hardware configuration for preventing total or partial process shutdown due to
PLC compared with other control systems
PLCs are well adapted to a range of automation tasks. These are typically industrial processes in
manufacturing where the cost of developing and maintaining the automation system is high
relative to the total cost of the automation, and where changes to the system would be expected
during its operational life. PLCs contain input and output devices compatible with industrial
pilot devices and controls; little electrical design is required, and the design problem centres on
expressing the desired sequence of operations. PLC applications are typically highly
customized systems, so the cost of a packaged PLC is low compared to the cost of a specific
custom-built controller design. On the other hand, in the case of mass-produced goods,
Allen-Bradley PLC installed in a
customized control systems are economical. This is due to the lower cost of the components,
which can be optimally chosen instead of a “generic” solution, and where the non-recurring
engineering charges are spread over thousands or millions of units. For high volume or very
simple fixed automation tasks, different techniques are used. For example, a cheap consumer
dishwasher would be controlled by an electromechanical cam timer costing only a few dollars
in production quantities. A microcontroller-based design would be appropriate where hundreds
or thousands of units will be produced and so the development cost (design of power supplies,
input/output hardware, and necessary testing and certification) can be spread over many sales,
and where the end-user would not need to alter the control. Automotive applications are an
example; millions of units are built each year, and very few end-users alter the programming of
these controllers. However, some speciality vehicles such as transit buses economically use
PLCs instead of custom-designed controls, because the volumes are low and the development
cost would be uneconomical. Very complex process control, such as used in the chemical
industry, may require algorithms and performance beyond the capability of even high-performance PLCs. Very high-speed or precision controls may also require customized
solutions; for example, aircraft flight controls. Single-board computers using semi-customized
or fully proprietary hardware may be chosen for very demanding control applications where the
high development and maintenance cost can be supported. “Soft PLCs” running on desktop type computers can interface with industrial I/O hardware while executing programs within a
version of commercial operating systems adapted for process control needs. Programmable
controllers are widely used in motion, positioning, and/or torque control. Some manufacturers
produce motion control units to be integrated with PLC so that G-code (involving a CNC
machine) can be used to instruct machine movements.PLC s may include logic for single-variable feedback analogue control loop, a proportional, integral, derivative (PID) controller. A
PID loop could be used to control the temperature of a manufacturing process, for example.
Historically PLC s were usually configured with only a few analogue control loops; where
processes required hundreds or thousands of loops, a distributed control system (DCS) would
instead be used. As PLC s have become more powerful, the boundary between DCS and PLC
applications has been blurred PLCs have similar functionality as remote terminal units. An RTU,
however, usually does not support control algorithms or control loops. As hardware rapidly
becomes more powerful and cheaper, RTU s, PLC s, and DCS s are increasingly beginning to
overlap in responsibilities, and many vendors sell RTU s with PLC-like features and vice versa.
The industry has standardized the IEC 61131-3 functional block language for creating
programs to run on RTU s and PLC s, although nearly all vendors also offer proprietary
alternatives and associated development environments. In recent years “safety” PLC s have
started to become popular, either as standalone models or as functionality and safety-rated
hardware added to existing controller architectures (Allen-Bradley Guard logic, Siemens F-series etc.). These differ from conventional PLC types as being suitable for use in safety-critical
applications for which PLC s have traditionally been supplemented with hard-wired safety
relays. For example, a safety PLC might be used to control access to a robot cell with trapped key access, or perhaps to manage the shutdown response to an emergency stop on a conveyor
production line. Such PLC s typically have a restricted regular instruction set augmented with
safety-specific instructions designed to interface with emergency stops, light screens, and so
forth. The flexibility that such systems offer has resulted in the rapid growth of demand for these
Discrete and analogue signals
Discrete signals behave as binary switches, yielding simply an On or Off signal (1 or 0, True or
False, respectively). Push buttons, limit switches, and photoelectric sensors are examples of
devices providing a discrete signal. Discrete signals are sent using either voltage or current,
where a specific range is designated as On and another as Off. For example, a PLC might use
24V DC I/O, with values above 22 V DC representing On, values below 2VDC representing
Off, and intermediate values undefined. Initially, PLC s had only discrete I/O.Analogue signals
are like volume controls, with a range of values between zero and full-scale. These are typically
interpreted as integer values (counts) by the PLC, with various ranges of accuracy depending on
the device and the number of bits available to store the data. As PLC s typically use 16-bit
signed binary processors, the integer values are limited between -32,768 and +32,767. Pressure,
temperature, flow, and weight are often represented by analogue signals. Analogue signals can use
voltage or current with a magnitude proportional to the value of the processed signal. For example,
an analogue 0 to 10 V or 4-20 mA input would be converted into an integer value of 0 to 32767
Current inputs are less sensitive to electrical noise (e.g. from welders or electric motor starts)
than voltage inputs.PLCs are at the forefront of manufacturing automation. An engineer
working in a manufacturing environment will at least encounter some PLCs, if not use them on
a regular basis. Electrical engineering students should have basic knowledge of PLCs because
of their widespread use in industrial applications.
NEED OF PLC
- Peace of mind
Both PLCs and PCs have come a long way since their humble beginnings but there is a big
difference in how these distinct control options continue to evolve and this has significant
implications for long term support. The managed evolution of the PLC means that vendors can
and do support their products over long periods of time, both in terms of hardware and software.
That means, with Mitsubishi Electric for example, that we could take the application program
example, from a 20-year-old FX PLC and import it straight into a brand new FX5U. A user
could install the very latest controller and have the application back up and running almost
immediately. How would you even contemplate doing the same with a PC based solution? There
are many industries where that level of support is not simply desirable but actually a baseline
requirement. There is talk in the water industry, for example, of framework suppliers having to
be able to assure the support of control systems for up to 20 years. Of course, the control hardware
will change over that time but PLC users have the peace of mind of knowing that the software
will always port to the latest controller.
- Inherently robust and reliable
The modern industrial PC provides a stable computing platform and it would be unfair to
suggest that it locked up and crashed with the unerring regularity of a desktop PC. However, it
is not on equal terms with a PLC.
The real-time operating system that runs alongside Windows on a typical industrial PC has been
designed to try to provide the same level of robustness as you get from a PLC CPU.
If a PC operated in complete isolation, perhaps that would be the end of the reliability debate.
However no controller does; there are peripherals to connect, I/O to network and other
components to talk to, each requiring their own drivers to be loaded into the PC. Will the
drivers for all of these products have been tested in combination and thoroughly proved? It
seems unlikely. Clashes can and do occur and problems can be exacerbated every time those
drivers are updated. It is almost inevitable, then, that an industrial PC will crash and what might
that mean for the control process? By contrast, when did you last hear of anyone needing to
reboot a PLC after a software crash – probably never…
the biggest selling PLCs by volume covering the largest spread of applications are those
offering 40 I/O or less. In such applications, the PLC represents a highly affordable solution,
much more so than an equivalent PC-based system. However, the same essential platform is
also scalable to tens of thousands of I/O, with users able to port control programs to bigger
PLCs, benefit from the same programming environment and take advantage of completely
modular hardware. The customisation potential of the PLC is enormous, with numerous ways to
expand the functionality but all without ever leaving a common platform.
Even today, for every engineer coming out of university who is fluent in structured text
programming and for every engineer who is comfortable working in C or C++, there are
probably ten more who only want to use ladder logic, particularly at the lower I/O end of the
application spectrum. In between, there are those applications that might start small, perhaps
written in the ladder but then grow as the application evolves – taking advantage of the scalability
of the PLC platform – benefiting from the ability to write the control program in structured text
and to drag and drop software function blocks that will take away much of the configuration
effort. At Mitsubishi Electric we offer a C++ programming option for our PLCs, so we marry a
flexible hardware platform to high-level language programming capability Of course these same
programming options are available on a PC platform, but the levels of modularity and
scalability that PLC software tools offer – in much the same way as with the hardware – simply
- Integration of other automation equipment
For many automation engineers, there is never any need to move outside the product portfolio
of a single vendor, with suppliers such as Mitsubishi Electric able to address every requirement
from HMIs, drives, servos, motion control, safety and robotics to low voltage power
distribution products, power management meters and CNC systems. Because all of these
components have been designed to work together, engineers benefit from ‘plug and work’
There are some automation vendors that sell industrial PCs who can claim to offer a broadly
similar product portfolio but certainly not many. However, the real challenge comes when
engineers need to look outside of a single brand and integrate third-party components.
With the modern PLC, integration of third-party hardware is a breeze; can the same be said for
integration on a PC platform? Are the drivers for those third-party modules guaranteed to work?
How much configuration effort will be required? Perhaps more importantly, will there be the
same assurance of ongoing compatibility through the operational lifespan of the control
In terms of power and performance, Moore’s law of computational capability is just as
applicable to PLCs as it is to PCs – indeed many people forget that the modern PLC is a
A powerful computer in its own right. The latest incarnation of the Mitsubishi Electric FX PLC,
for example, is 150 times faster than the original.
Just how powerful the modern PLC is only really becomes apparent when you look at the speed
of execution of instructions, with the latest designs offering sub-nanosecond performance. You
might be able to ‘pimp’ a PC to offer similar performance but the PLC offers you that straight
out of the box. Then there is the increased bus speed and the ability to synchronise multiple I/O
in a high-speed system, delivering a much more responsive control system. Again, this is much
more difficult to achieve outside of the PLC environment.
The arrival of high profile viruses such as Stuxnet has made us all realise that automation
systems have become targets, as malicious hackers look to cripple the operations of big
companies or vital utilities. With its familiar operating system and inherent network
vulnerabilities, the PC can represent the soft underbelly of the control system for anyone trying
to break in. The operating systems of PLCs, by contrast, are much less visible to the outside
world and this has traditionally offered a layer of insulation against malicious intent. This does
not mean, however, that PLC manufacturers take security for granted. Mitsubishi Electric, for
example, enables programs to be password protected, with different levels of access granted to
different levels of user. Further remote access preferences can be set such as access only being
granted to specific IP addresses, protecting PLC software and the wider automation system
even in heavily networked applications.
- Intellectual property
Extending the security argument, a concern for companies with global development teams or
where the end system will be installed overseas is that the control software will be copied by
unscrupulous third parties and all too quickly developed as a competitive, lower-cost product.
Where this is a valid concern across all control platform options, the PLC manufacturers have
taken significant steps to address the problem. With Mitsubishi Electric products, encrypted
code embedded in hardware and software can be set to execute at a given time. That might
mean that the system is open to developers and installers right through to the end of
commissioning of the application but then switches on to protect the system from further
Every automation system, regardless of platform, needs routine maintenance; perhaps to
manage hardware or software upgrades, as part of scaling up the system as the application
evolves, or, swapping out faulty components. The ease with which this can be accomplished is a major attraction of the PLC. Programs and configuration settings for just about any connected
component can be stored on an SD card via a slot in the PLC CPU, simplifying any maintenance
requirements. Indeed, even if the PLC CPU itself were to fail, a new unit could be snapped onto
the backplane and the original program loaded directly from a bootable backup on the SD card,
getting the system back up and running straight away. At the same time, there are none of the
requirements for ongoing firmware updates that plague PC-based systems, with the constant
worry that any one of these will clash with another and bring the system to its knees. The very
fact that the PC is a multi-purpose system is one of its greatest weaknesses in the automation
- Reduced IT requirements
One of the questions in any automation system, even more so as integration between the plant
floor and higher-level systems comes into the equation, is the allocation of responsibility
between the automation engineering team and the IT team. This can be a source of friction but
perhaps more importantly there is the almost inevitable lack of understanding from each about
the requirements of the other. With PLC-based automation, the demarcation between
engineering and IT is clear, with little or no need for the IT team to have to get involved on the
plant floor. Further, with products such as Mitsubishi Electric’s MES module – which plugs
into the PLC backplane and provides a direct connection with higher-level databases – whole
layers of PC products can be eliminated from the automation system altogether, making the
demarcation between automation and IT is even clearer. We can see, then, that there are many
good reasons why the PLC will continue as the mainstay of automation system control and
that’s before we’ve even considered issues such as redundancy, safety and more, plus the
capability of the modern PLC to perform many of the complex maths functions that could once
have only been performed in a PC-based system. Of course, the requirements of every
automation system should lead to the selection of the appropriate control solution on merit but
the PLC offers many reasons to be the platform of choice.
TYPES OF PLC
Plc can be differentiating these parameters
• Programmable Logic Controller (PLC)
• PLC Architecture.
• CPU Module of PLC.
• PLC-BUS or Rack.
• ABB PLC Power Supply.
• PLC I/O Modules.
• Integrated or Compact PLCs.
• A modular Type of PLC.
Most popular brands of plc use in big industry
Automatic air production system using plc
Supervisory control and data acquisition (SCADA) is a control system architecture that uses
computers, networked data communications and graphical user interfaces for high-level process
supervisory management, but uses other peripheral devices such as programmable logic
controllers and discrete PID controllers to interface to the process plant or machinery. The
operator interfaces which enable monitoring and the issuing of process commands, such as
controller setpoint changes are handled through the SCADA supervisory computer system.
However, the real-time control logic or controller calculations are performed by networked
modules which connect to the field sensors and actuators. The SCADA concept was developed
as a universal means of remote access to a variety of local control modules, which could be
from different manufacturers allowing access through standard automation protocols. In
practice, large SCADA systems have grown to become very similar to distributed control
systems in function but using multiple means of interfacing with the plant. They can control
large-scale processes that can include multiple sites, and work over large distances. It is one
of the most commonly used types of industrial control systems, however, there are concerns
about SCADA systems being vulnerable to cyber warfare and e/cyberterrorism attacks.
A SCADA system usually consists of the following main elements:
This is the core of the SCADA system, gathering data on the process and sending control
commands to the field connected devices. It refers to the computer and software responsible for
communicating with the field connection controllers, which are RTUs and PLCs, and includes
the HMI software running on operator workstations. In smaller SCADA systems, the
supervisory computer may be composed of a single PC, in which case the HMI is a part of this
computer. In larger SCADA systems, the master station may include several HMI hosted on
client computers, multiple servers for data acquisition, distributed software applications, and
disaster recovery sites. To increase the integrity of the system the multiple servers will often be
configured in a dual-redundant or hot-standby formation providing continuous control and
monitoring in the event of a server malfunction or breakdown.
Remote terminal unit
Further information: Remote terminal unit
Remote terminal units, also known as (RTU s), connect to sensors and actuators in the process
and are networked to the supervisory computer system. RTU s are “intelligent I/O” and often
have embedded control capabilities such as ladder logic in order to accomplish boolean logic
Programmable logic controllers
Further information: Programmable logic controller
Also known as PLC s, these are connected to sensors and actuators in the process and are
networked to the supervisory system in the same way as RTU s. PLC s have more sophisticated
embedded control capabilities than RTU s, and are programmed in one or more IEC 61131-3
programming languages. PLC s are often used in place of RTU s as field devices because they
are more economical, versatile, flexible and configurable.
This connects the supervisory computer system to the remote terminal units (RTU s) and PLC s,
and may use industry-standard or manufacturer proprietary protocols. Both RTU s and PLC s
operate autonomously on the near-real-time control of the process, using the last command
given by the supervisory system. Failure of the communications network does not necessarily
stop the plant process controls, and on resumption of communications, the operator can
continue with monitoring and control. Some critical systems will have dual redundant data
highways, often cabled via diverse routes.
Further information: Graphical user interface
The human-machine interface (HMI) is the operator window of the supervisory system. It
presents plant information to the operating personnel graphically in the form of mimic diagrams,
which are a schematic representation of the plant being controlled, and alarm and event logging
pages. The HMI is linked to the SCADA supervisory computer to provide live data to drive the
mimic diagrams, alarm displays and trending graphs. In many installations, the HMI is the
graphical user interface for the operator, collects all data from external devices, creates reports,
performs alarming, sends notifications, etc.
Mimic diagrams consist of line graphics and schematic symbols to represent process elements
or may consist of digital photographs of the process equipment overlain with animated symbols.
Supervisory operation of the plant is by means of the HMI, with operators issuing commands
using mouse pointers, keyboards and touch screens. For example, a symbol of a pump can show
the operator that the pump is running, and a flow meter symbol can show how much fluid it is
pumping through the pipe. The operator can switch the pump off from the mimic with a mouse
click or screen touch. The HMI will show the flow rate of the fluid in the pipe decrease in real-time.
The HMI package for a SCADA system typically includes a drawing program that the operators
or system maintenance personnel use to change the way these points are represented in the
interface. These representations can be as simple as an on-screen traffic light, which represents
the state of an actual traffic light in the field, or as complex as a multi-projector display
representing the position of all of the elevators in a skyscraper or all of the trains on a railway.
A “historian”, is a software service within the HMI that accumulates time-stamped data,
events, and alarms in a database that can be queried or used to populate graphic trends in the
HMI. The historian is a client that requests data from a data acquisition server.
Alarm handling further information: alarm management
An important part of most SCADA implementations is alarm handling. The system monitors
whether certain alarm conditions are satisfied, to determine when an alarm event has occurred.
Once an alarm event has been detected, one or more actions are taken (such as the activation of
one or more alarm indicators, and perhaps the generation of email or text messages so that
management or remote SCADA operators are informed). In many cases, a SCADA operator
may have to acknowledge the alarm event; this may deactivate some alarm indicators, whereas
other indicators remain active until the alarm conditions are cleared. Alarm conditions can be
explicit—for example, an alarm point is a digital status point that has either the value
NORMAL or ALARM that is calculated by a formula based on the values in another analogue
and digital points—or implicit: the SCADA system might automatically monitor whether the
value in an analogue point lies outside high and low-limit values associated with that
point. Examples of alarm indicators include a siren, a pop-up box on a screen, or a coloured or
flashing area on a screen (that might act in a similar way to the “fuel tank empty” light in a car);
in each case, the role of the alarm indicator is to draw the operator’s attention to the part of the
system ‘in alarm’ so that appropriate action can be taken.
“Smart” RTU or standard PLC are capable of autonomously executing simple logic processes
without involving the supervisory computer. They employ standardized control programming
languages such as under, IEC 61131-3 (a suite of 5 programming languages including function
block, ladder, structured text, sequence function charts and instruction list), which is frequently used
to create programs that run on these RTU s and PLC s. Unlike a procedural language such as
the C programming language or FORTRAN, IEC 61131-3 has minimal training requirements
by virtue of resembling historic physical control arrays. This allows SCADA system engineers
to perform both the design and implementation of a program to be executed on an RTU or PLC.
A programmable automation controller (PAC) is a compact controller that combines
the features and capabilities of a PC-based control system with that of a typical PLC. PACs are
deployed in SCADA systems to provide RTU and PLC functions. In many electrical substations
SCADA applications, “distributed RTU s” use information processors or station computers to
communicate with digital protective relays, PAC s, and other devices for I/O, and communicate
with the SCADA master in lieu of a traditional RTU.
PLC commercial integration
Since about 1998, virtually all major PLC manufacturers have offered integrated HMI/SCADA
systems, many of them using open and non-proprietary communications protocols. Numerous
specialized third-party HMI/SCADA packages, offer built-in compatibility with most major
PLCs, have also entered the market, allowing mechanical engineers, electrical engineers and
technicians to configure HMIs themselves, without the need for a custom-made program
written by a software programmer. The Remote Terminal Unit (RTU) connects to physical
equipment. Typically, an RTU converts the electrical signals from the equipment to digital
values such as the open/closed status of a switch or a valve, or measurements such as
pressure, flow, voltage or current. By converting and sending these electrical signals out to
equipment the RTU can control equipment, such as opening or closing a switch or a valve or
setting the speed of a pump.
Communication infrastructure and methods
SCADA systems have traditionally used combinations of radio and direct-wired connections,
although SONET/SDH is also frequently used for large systems such as railways and power
stations. The remote management or monitoring function of a SCADA system is often referred
to as telemetry. Some users want SCADA data to travel over their pre-established corporate
networks or to share the network with other applications. The legacy of the early low-bandwidth protocols remains, though.
SCADA protocols are designed to be very compact. Many are designed to send information
only when the master station polls the RTU. Typical legacy SCADA protocols include Modbus
RTU, RP-570, Profibus. These communication protocols, with the exception of Mod bus (Mod
the bus has been made open by Schneider Electric, and is now managed by the modbus.org), are all
SCADA-vendor specific but are widely adopted and used. Standard protocols are IEC 60870-5-
101 or 104, IEC 61850 and DNP3. These communication protocols are standardized and
recognized by all major SCADA vendors. Many of these protocols now contain extensions to
TCP/IP. Although the use of conventional networking specifications, such as TCP/IP, blurs the
the line between traditional and industrial networking, they each fulfil fundamentally differing
With increasing security demands (such as North American Electric Reliability Corporation
(NERC) and Critical Infrastructure Protection (CIP) in the US), there is increasing use of
satellite-based communication. This has the key advantages that the infrastructure can be self-contained (not using circuits from the public telephone system), can have built-in encryption,
and can be engineered to the availability and reliability required by the SCADA system
operator. Earlier experiences using consumer-grade
VSAT were poor. Modern carrier-class systems provide the quality of service required for
RTU s and other automatic controller devices were developed before the advent of industry-wide standards for interoperability. The result is that developers and their management created
a multitude of control protocols. Among the larger vendors, there was also the incentive to
create their own protocol to “lock-in” their customer base. A list of automation protocols is
OLE for process control (OPC) can connect different hardware and software, allowing
communication even between devices originally not intended to be part of an industrial network.
SCADA architecture development
SCADA systems have evolved through four generations as follows:
Early SCADA system computing was done by large minicomputers. Common network services
did not exist at the time SCADA was developed. Thus SCADA systems were independent
systems with no connectivity to other systems. The communication protocols used were strictly
proprietary at that time. The first-generation SCADA system redundancy was achieved using a
backup mainframe system connected to all the Remote Terminal Unit sites and was used in the
event of failure of the primary mainframe system.
Some first-generation SCADA systems were developed as “turn-key” operations that ran on
minicomputers such as the PDP-11 series made by the Digital Equipment Corporation
Second generation: “distributed”
SCADA information and command processing was distributed across multiple stations which
were connected through a LAN. Information was shared in near real-time. Each station was
responsible for a particular task, which reduced the cost as compared to First Generation
SCADA. The network protocols used were still not standardized. Since these protocols were
proprietary, very few people beyond the developers knew enough to determine how secure a
SCADA installation was. Security of the SCADA installation was usually overlooked.
Third generation: “networked”
Similar to a distributed architecture, any complex SCADA can be reduced to the simplest
components and connected through communication protocols. In the case of a networked
design, the system may be spread across more than one LAN network called a process control
network (PCN) and separated geographically. Several distributed architecture SCADAs running
in parallel, with a single supervisor and historian, could be considered a network architecture.
This allows for a more cost-effective solution in very large scale systems.
Fourth generation: “Internet of things”
With the commercial availability of cloud computing, SCADA systems have increasingly
adopted Internet of things technology to significantly reduce infrastructure costs and increase
ease of maintenance and integration. As a result, SCADA systems can now report states in
near real-time and use the horizontal scale available in cloud environments to implement more
complex control algorithms than are practically feasible to implement on traditional
programmable logic controllers.
Further, the use of open network protocols such as TLS inherent in the Internet of things
technology provides a more readily comprehensible and manageable security boundary than
the heterogeneous mix of proprietary network protocols typical of many decentralized SCADA
implementations. One such example of this technology is an innovative approach to rainwater
harvesting through the implementation of real-time controls (RTC)
This decentralization of data also requires a different approach to SCADA than traditional PLC
based programs. When a SCADA system is used locally, the preferred methodology involves
binding the graphics on the user interface to the data stored in specific PLC memory addresses.
However, when the data comes from a disparate mix of sensors, controllers and databases
(which may be local or at varied connected locations), the typical 1 to 1 mapping becomes
problematic. A solution to this is data modelling, a concept derived from object-oriented
In a data model, a virtual representation of each device is constructed in the SCADA software.
These virtual representations (“models”) can contain not just the address mapping of the device
represented, but also any other pertinent information (web-based info, database entries, media
files, etc.) that may be used by other facets of the SCADA/IoT implementation. As the
increased complexity of the Internet of things renders traditional SCADA increasingly “housebound,” and as communication protocols evolve to favour platform-independent, service-oriented architecture (such as
OPC UA), it is likely that more SCADA software developers will implement some form of
SCADA systems that tie together decentralized facilities such as power, oil, gas pipelines, water
distribution and wastewater collection systems were designed to be open, robust, and easily
operated and repaired, but not necessarily secure. The move from proprietary technologies to
more standardized and open solutions together with the increased number of connections
between SCADA systems, office networks and the Internet has made them more vulnerable to
types of network attacks that are relatively common in
computer security. For example, the United States Computer Emergency Readiness Team (US-CERT) released a vulnerability advisory warning that unauthenticated users could download
sensitive configuration information including password hashes from an Inductive Automation
Ignition system utilizing a standard attack type leveraging access to the Tomcat Embedded Web
server. Security researcher Jerry Brown submitted a similar advisory regarding a buffer
in a Wonderware In Batch Client ActiveX control. Both vendors made updates available prior
to the public vulnerability release. Mitigation recommendations were standard patching practices
and requiring VPN access for secure connectivity. Consequently, the security of some SCADAbased systems has come into question as they are seen as potentially vulnerable to cyber-attacks.
In particular, security researchers are concerned about:
• the lack of concern about security and authentication in the design, deployment and
operation of some existing SCADA networks
• the belief that SCADA systems have the benefit of security through obscurity through
the use of specialized protocols and proprietary interfaces
• the belief that SCADA networks are secure because they are physically secured
• the belief that SCADA networks are secure because they are disconnected from the
SCADA systems are used to control and monitor physical processes, examples of which are
transmission of electricity, transportation of gas and oil in pipelines, water distribution, traffic
lights, and other systems used as the basis of modern society. The security of this SCADA
systems are important because compromise or destruction of these systems would impact
multiple areas of society far removed from the original compromise. For example, a blackout
caused by a compromised electrical SCADA system would cause financial losses to all the
customers that received electricity from that source. How security will affect legacy SCADA
and new deployments remains to be seen.
There are many threat vectors to a modern SCADA system. One is the threat of unauthorized
access to the control software, whether it is human access or changes induced intentionally or
accidentally by virus infections and other software threats residing on the control host machine.
Another is the threat of packet access to the network segments hosting SCADA devices. In
many cases, the control protocol lacks any form of cryptographic security, allowing an attacker
to control a SCADA device by sending commands over a network. In many cases, SCADA
users have assumed that having a VPN offered sufficient protection, unaware that security can
be trivially bypassed with physical access to SCADA-related network jacks and switches.
Industrial control vendors suggest approaching SCADA security like
Information Security with a defence in depth strategy that leverages common IT practices.
The reliable function of SCADA systems in our modern infrastructure may be crucial to public
health and safety. As such, attacks on these systems may directly or indirectly threaten public
health and safety. Such an attack has already occurred, carried out on Maroochy Shire Council’s
sewage control system in Queensland, Australia. Shortly after a contractor installed a
SCADA system in January 2000, system components began to function erratically. Pumps did
not run when needed and alarms were not reported. More critically, sewage flooded a nearby
park and contaminated an open surface-water drainage ditch and flowed 500 meters to a tidal
canal. The SCADA system was directing sewage valves to open when the design protocol
should have kept them closed. Initially, this was believed to be a system bug. Monitoring of the
system logs revealed that malfunctions were the result of cyberattacks. Investigators reported 46
separate instances of malicious outside interference before the culprit was identified. The
attacks were made by a disgruntled ex-employee of the company that had installed the SCADA
The ex-employee was hoping to be hired by the utility full-time to maintain