PLC DCS SCADA & HMI for Beginners
Let's see how simple we can make it - by first building a SCADA system -
and then by building a DCS system - each from the ground up.
Suppose
that we're building a brand new factory - and suppose that our first
piece of equipment is something like a big industrial oven. This thing
will be made up of heaters, and valves, and conveyor motors, and other
assorted machinery - so let's say we get to work and we build us an
oven. Now that we've got the mechanical part of the oven built - we need
some type of controller for it - something to accurately control all of
those different parts in order to turn raw material into a sellable
final product. So what type of control are we going to use? How about a
PLC - a Programmable Logic Controller?
In very simple language a
PLC is a type of computer. But the computers that most people are
familiar with use a keyboard as an input device and a screen for an
output device. PLC's don't have a keyboard. So for an input device, we
use an "input module" which is basically a little box with a row of
screws on the front of it. We wire up a bunch of pushbuttons, sensors,
switches, etc. to the little screws ... and this will serve as the input
device for our PLC "computer". We do something similar for an output
device. Instead of using a screen for an output device, we use an
"output module" which is basically another little box with a row of
screws on the front of it. We wire up a bunch of solenoid valves,
indicator lamps, motor starters, etc. to the little screws ... and this
will serve as the output device for our PLC "computer".
So for
this first example, let's say that we decide to go with a PLC system. We
buy the PLC and install it by connecting wires between the oven and the
PLC. Then we buy a copy of the programming software from the PLC
manufacturer - and then we write a program for the PLC - we'll probably
use "ladder logic" programming, since that's what most PLC's use as
their native language. And now the PLC is just about ready to properly
control the system - except that we still need some way for the operator
to set and to monitor the temperatures - and to start and stop the
conveyors and so forth.
Now for this small system, some meters
and pushbuttons and some thumbwheel switches might do just fine. We
could wire those up and build us an operator's control panel for our
oven. But another (better?) way would be to use an HMI - a Human Machine
Interface. (This used to be called an MMI - Man Machine Interface - but
now-a-days we've got to be more politically correct.) So we buy us a
nice desktop computer and some type of HMI software. We'll need to
program the HMI - and usually this is done by dragging and dropping
pictures of meters and knobs and buttons onto our computer screen. In
other words, we build a "virtual" control panel for our operator to use.
We link these on-screen controls to the PLC's memory through a
communication cable. And now we're finally ready to go. Great so far -
and we start making some money with our factory.
Later on,
business is good and we decide that our factory could use two additional
ovens. So we get the mechanical parts built - and now we need to decide
how we're going to control these new ovens. Now the original PLC that
we used for oven number one is quite capable of controlling the two
additional ovens. We just might need to add a few additional I/O modules
to the chassis - and we'll certainly need to run some more wires - but
basically the same old PLC "brain" has plenty of extra horsepower to
handle the new ovens. But - here's an idea: Suppose that we buy two new
PLC's - one for each new oven. Now that's certainly going to cost us
more money, but at least this way each oven could operate - or be shut
down - completely separately from the other two systems. That's going to
make scheduling maintenance a lot simpler - and generally give us a lot
more flexibility in all of our operations. Plus - by having three
controllers - we're not putting "all of our eggs in one basket" as the
old saying goes.
We talk the boss into it - and we buy the new
PLC's and install them - and download copies of the original program
into them - and we're just about ready to go. But how about that
operator control piece of the puzzle? Since we're already using an HMI
for our operator's control panel, all we have to do is make two copies
of the screens from our original oven - and set these new copies up on
the operator's HMI computer. Finally, we extend the communication cable
from the HMI station over to the two new PLC's - and now we're up and
running.
Next the boss hires a bean-counter - someone whose job
involves maximizing our factory's profits. Now this person requires data
- he needs to know how much it costs to operate the ovens - and how
much product we run through them - and how much of that product is
"off-spec" and wasted. The best way to get all of this production data
is to ask the PLC's - after all, they're the "brains" that are
controlling the system. So let's upgrade the old HMI that the operator
has been using - to something with more features. This will be called a
SCADA system - for "Supervisory Control And Data Acquisition". It will
still have control screens with all of the virtual buttons and meters
and other whatnots that the operator needs to control the ovens - but it
will also have some additional features beyond the HMI - features which
will allow the SCADA system to suck the production data right out of
the PLC's - and to store that data in some type of computer database.
Later, the bean-counter can retrieve that production data and analyze it
to his little heart's content. All is well.
Quick review so
far: The machinery in our factory is being controlled by PLC's. For a
little while we used an HMI (Human/Machine Interface) software package -
so that the Human operator could Interface (that is, monitor and
operate) the Machine. Later we moved from the HMI up to a more powerful
software package - a SCADA (Supervisory Control And Data Acquisition)
system. This new software still allowed our human operator to Supervise
and Control the system - and it also added some features for Data
Acquisition for the bean-counter's benefit.
Now let's start over with a new factory - and this time we'll use a DCS (Distributed Control System).
Suppose
that this time we know in advance that the factory we're about to build
is going to involve a rather sophisticated process - one which is going
to require many interrelated steps - all of which must be carefully
coordinated in order to produce a sellable final product. We're talking
about chemicals - or pharmaceuticals - or something along those lines.
(The term "continuous process" is a familiar buzzword for something like
this.)
Now yes, we COULD use PLC's for this type of factory -
and yes, we COULD use a SCADA system to supervise and control the whole
thing. But - many engineers would decide to go with a DCS for something
like this. And that's what we're going to do.
Now suppose that
our new factory still needs something along the lines of our previous
ovens - how would we control these? Instead of putting a PLC on each
oven - we'll use a separate DCS "controller" for each oven. Now at first
glance, these controllers will each look a lot like an individual "I/O
module" or "I/O card" in a PLC system. They usually slide right into a
chassis - and have wires for inputs and outputs connected to the front
of them. So most DCS systems tend to look a lot like a PLC system. The
big difference is that each of these DCS "controller/card" devices will
be individually programmed. That's where the term "DISTRIBUTED" comes
from - the control (or "brain-power" if you prefer) is DISTRIBUTED among
many individual controllers. Specifically, in a typical PLC system we
generally have only one "brain" (or processor) in each chassis - and
then several I/O (input/output) modules in the chassis to handle the
signal wires to-and-from the machinery. On the other hand, in a typical
DCS system we'll have several "brains" (or controllers) in a chassis -
and the I/O wiring associated with each particular "brain's" machinery
will be connected directly to the front of that individual controller.
Now
what about the operator control function? Well, one integral part of a
DCS system is a large computer (usually a quite powerful one) which
looks a lot like a SCADA terminal. And it does exactly the same job.
First, it gives the operator a series of control screens with all of the
virtual buttons and meters and other whatnots that he (or she) requires
in order to control the machinery. Second, it also has the features
required to suck the production data right out of the individual
controllers - and to store that data in some type of computer database.
And in most DCS systems, there is a third function of the DCS terminal:
The programming software for the individual controllers is also usually
available on this terminal - so that reprogramming the controllers is
possible right over the existing data communication cables.
Quick
review of the DCS approach: The machinery in our factory is being
controlled by many individual little controllers. Our operator uses a
DCS terminal (computer) to monitor and operate the machinery. This DCS
terminal also has features to acquire production data and store it in a
database for later analysis. Additionally, the DCS terminal usually has
the programming software required for the individual controllers
available. And all of the hardware and all of the software required for
our DCS system is generally provided by just one manufacturer. Some
people think that's a good thing - and other people think that's a bad
thing.
So which is the better approach - PLC or DCS? This is
usually decided by the engineers who initially design the factory. And
in practice, there are a lot of factories out there who use combinations
of the two approaches.
Finally: Please remember that this was
intended to be a general "beginner level" discussion - there are
exceptions to all of these "rules" ... but hopefully this will give you a
"starting point" from which to build.
God bless us all.....:)
you will probably have to modify them.
Basically what the microcontroller is doing is initializing the serial interface and then the phone. Initialization of the phone means inserting the pin number (I have put it to 1234 in the program), selecting the storage for SMS messages (it selects the phone memory and not the SIM memory) and inserting the SMS service centre address. The current address is for a Vodafone Romania prepaid SIM. These parameters are at the beginning of the program so you shouldn’t have a hard time changing them even if you have no clue of C programming. Below is the block diagram of the software. It is written in romanian but basically the idea is: