main menu

SCADALESS SCADA USING WIRELESS MESH RADIO TELEMETRY

Submitted January 23, 2007 by Louis F. De Silvio
President, Industrial Telemetry, Inc.
For Presentation at ISA Conference in Tulsa, April, 2007

Paper

SCADA (Supervisory Control And Data Acquisition) (or DCS – Distributed Control
Systems) systems are generally comprised of a central computer which is hard wired to a
multitude of I/O and other devices. The SCADA system is the “brains” controlling the
processes. SCADA systems, like computer systems in business, are “sized” for
processing power and memory, generally based on the number of “tags” or IO points or
devices it controls. In addition, there are PLC’s (Programmable Logic Controllers) which
can be used in the field to aggregate collections of IO devices. These PLC’s are also
programmable, and perform some of the rudimentary functions of a SCADA system,
albeit on a scaled down basis. They can also act as a “clearing house” for what data is
passed on to the SCADA system, after acting on the data locally. For example, in the
case of a PID loop (Proportional-Integral-Derivative) a controller or PID is a standard
feedback loop component in industrial control applications. It measures an "output" of a
process and controls an "input", with a goal of maintaining the output at a target value,
which is called the "setpoint". In the case where the data gathered requires action on the
part of a target device not directly connected to the PID controller, the SCADA system is
sent the data and it determines the action needed because it is connected to, and provides
control functions for, the remote target device.

It’s all about input, connectivity, decision making, and output instructions.

One final issue in design considerations is “latency”. Latency is the time lag between the
instant data is known and the time it can be finally acted upon. For example, if a pressure
sensor was connected to a PLC, and the pump which created the pressure in the vessel
was connected to the same PLC, latency would be defined as the time the PLC received a
pressure reading impulse, interpreted it, decided on an action, sent a command signal to
the pump, and the pump received it. The entire cycle of time elapsing between receiving
the initial input from the pressure sensor, and sending an output to the pump, is the
latency time. There are many factors determining latency, but in this example it would
be measured in either nanoseconds or milliseconds at worse.

If the pressure sensor was linked to a SCADA system and through it to the pump, the
time the signal traveled hundreds or thousands of feet over a wire, got processed through
the SCADA system and traveled hundreds or thousands of feet to the target, would define
the latency.

With improvements in wireless communications and the adaptation to process control

and monitoring, there is an evolution and a migration toward acceptance of these devices
where they are applicable. The two biggest issues in determining applicability of wireless
as a solution are security needs and latency.
Copyright 2007 ISA. All Rights Reserved. www.isa.org
Presented at the 53rd International Instrumentation Symposium
29 April – 3 May 2007, Tulsa, Oklahoma
Major strides have been made in the security of the packets of information as they fly
through the air, but wireless adds latency, and encryption adds even more as the packets
must be encrypted prior to flight, and decrypted upon landing. In addition, the
phenomenon of “lost packets”, a virtually non-existent issue in wired applications, must
be examined, evaluated, and dealt with.

Radios are primarily divided into two distinct categories: point to point (or multipoint)
and MESH. MESH is an acronym for “Multipoint Enhanced Signal Handling”. MESH
radios can be further broken down into two categories: Peer-to-Peer, and V. In Peer-to
Peer, one can address information packets directly from one radio to another WITHOUT
necessarily going back to a base station for processing. In a V configuration (name
derived from the shape of the letter V indicating signal path), all messages are sent to the
base station which may be connected to a SCADA system, or not, and are processed out
to the destination radio(s). In either case, the MESH protocol takes care of the routing
and signal handling, transparent to the user.

The recent move toward wireless communications and particularly MESH radios has
opened new, cost effective doors in process control and monitoring, where applicable
latency is acceptable. While point to point, and point to multipoint radios are merely
transceivers (transmitters and receivers together), MESH radios are transceivers and
repeaters in one. By combining the repeating function with the transceiver function, we
achieve greater throughput possibilities, with less equipment, and less cost. MESH
radios also incorporate auto-routing and self-healing functions, while providing dramatic
cost and functional efficiency improvements over the more antiquated, sometimes
“signally challenged” technologies of “point to point” or “point to multipoint” previously
mentioned.

The main benefit of MESH is the ability to compensate for physical interference which
would kill the other types of radios. A secondary benefit is the ability to “route around”
dead radios or interference.

Auto routing is accomplished by the radio’s ability to constantly evaluate the RSS
(relative signal strength) of the surrounding MESH radios. Each MESH radio has a
“routing table”. The purpose of the radio’s table is to rank hierarchically the proximal
radios based on their ability to communicate with it. When it needs to send out a
message, it checks its table to see if the target radio is in proximity, and if not, will send
the message to the best RSS radio it has in its table. If the target is in range, it sends
“direct”. Each time a message “hops” from one radio to another, it adds latency to the
process. Therefore, the more direct messages are possible, the faster the system operates.
Conversely the more hops a packet must take to its destination, the more milliseconds of
latency it takes to complete the cycle.

MESH radios can do their work without requiring polling of their attached devices,
although it is supported, so MESH radios can be used in a variety of situations. Greater
message throughput via MESH yields greater reliability and adds flexibility to the overall
Copyright 2007 ISA. All Rights Reserved. www.isa.org
Presented at the 53rd International Instrumentation Symposium
29 April – 3 May 2007, Tulsa, Oklahoma
system which translates to more efficiency and higher profits. Again, “true” MESH
allows for an independent “peer to peer” addressing approach for packets on the MESH
network, whereby the MESH network is the communication backbone supporting
message handling via the addressing scheme it supports.

Most people do not want to embark on the costly upgrading of a SCADA system,
especially when adding radios, without being assured of success. That is why MESH-
enabled systems can be deployed stand alone, in parallel with SCADA systems, or can be
integrated directly into the legacy SCADA. Further, most systems can be migrated
seamlessly through the three scenarios over time as end user confidence builds.

For example, a stand alone system can be developed where all sources and all targets are
on the same wireless system, with the radios communicating in either MESH or V
configuration protocols. In the parallel scenario, the base station computer can be
connected to the SCADA system where its attached computer can be polled, as with
MODBUS, and the SCADA system can record a copy of all its activities, or can be
involved in source or target activities using its previously attached devices. Finally, the
base station radio can be fully integrated with the SCADA system, which can then be
used for either monitoring, or control, and allow seamless integration with the existing
system.

In summary, then, wireless is considerably more cost effective and flexible than wiring
devices, when the environment is suitable, but the latency and packet delivery reliability
are factors to be considered.

When one designs a SCADA system, one must consider a variety of factors, not the least
of which is the number of IO points or “tags”, the number of interrelationships among
them, and the processing power and memory required to run the entire system efficiently.

As we move forward in pushing the technology envelope, it seems reasonable that one
could take the proportional processing power and the proportional memory of the
centralized SCADA computer required to support each I/O point, and distribute it to the
I/O points via a processor and memory on a board. By distributing a processor and
memory to the IO point, we achieve a localized decision functionality which is
comparable to that of the SCADA, albeit on a smaller scale. In fact, each distributed point
would have a great excess of capacity just based on processor technology. The ability to
add memory would also add functionality beyond that required to support just the IO,
decisions, and interface requirements to the radio.

At this point, a PLC can be added to the mix along with a MESH radio. Another option
would be to simply add the processor and memory to the MESH radio function, and
program the processor using standard programming languages like C++, etc. In this case
a PLC is not needed, although a higher level of knowledge of programming language is.
As time goes by, more and more people will become sophisticated in programming
languages to the point where the PLC may actually become obsolete.

Copyright 2007 ISA. All Rights Reserved. www.isa.org

Presented at the 53rd International Instrumentation Symposium
29 April – 3 May 2007, Tulsa, Oklahoma
A hybrid version of that is the PLC on a Chip, by Divelbiss. They have taken a PLC
processor and memory and scaled it down to the proportions necessary to support a
reasonable number of IO. Since it is in chip form, the chip can be easily integrated with a
board of any design. The PLC on a Chip is a fully functional PLC and uses standard
ladder logic programming. It is the step just before eliminating PLC’s altogether and
going with the processor and memory scenario mentioned previously.

At this point, we can build a single board capable of supporting a MESH radio, a PLC on
a Chip, a processor and memory, and IO connectivity. If we delete the PLC from the
board we are left with a MESH radio, a processor and memory and IO connectivity. This
approach, when combined with appropriate HMI (Human-Machine Interface – or
computer screens) software, allows us to interface the MESH radio and its board directly
with external PLC’s from various manufacturers, OR eliminate the PLC’s altogether and
just program the processor to do what we want. Since the processor is already
programmed to handle the packet formation, encryption, and addressing, its just a matter
of programming the processor to execute the instructions the PLC would.

There is one additional feature which is valuable in either case. It involves storing the
source code associated with the compiled code in use at any time either with or without
the PLCs. In the case of either the PLC on a Chip, or an external PLC, the associated
processor and memory is used first to receive and store the packets containing the new
object code for reflashing the PLCs. When all the packets are received, the processor
assembles them into the correct file format for transfer to the PLC. Since every PLC
vendor allows reflashing, usually via RS232, or more recently through an Ethernet
connection path, the reflashing is done rather quickly. Once the PLC is reflashed, the
processor sends a message to the base station requesting a copy of the source code used
to compile the newly flashed object code. The processor then stores the currently used
source code in its local memory, ancillary to, and outside of, the PLC. Once this is done,
any user from anywhere in the world a secure connection to the base station exists, can
“ping” the processor through the MESH, and receive a copy of the then-current source
code in use with the object code being executed in the PLC. Since this source code
resides outside the PLC, pinging the processor does not interfere with PLC functions, nor
does it take PLC cycle time to reply.

In the case of NO PLCs, either on board or externally, all the same functionality is
possible with just the processor, memory, MESH radio and IO connectivity, with one
exception. When the processor must reflash itself, there needs to be a reboot program
allowing this to happen, and supporting the function.

The last phase of this approach involves the higher level HMI screens. These screens
need to be written in such a way that they support the following functions:
1. Displaying all important user information in a way meaningful to the user
2. Retrieving the PLC ladder logic program needed to create source, then object
code.
3. Break down the resulting source and object files into packets appropriate to the
MESH protocol in use.
Copyright 2007 ISA. All Rights Reserved. www.isa.org
Presented at the 53rd International Instrumentation Symposium
29 April – 3 May 2007, Tulsa, Oklahoma
 4. Securely encrypt those packets.
5. Address and send packets to the appropriate radio ID which corresponds to the
processor and memory associated with the IO involved (with or without a PLC)
6. Send a schedule for reflashing to the appropriate processor.
7. Reflash associated PLC’s or reboot the processor if no PLC is in use.
8. Display information from the system.

Considering the HMI is also part of a SCADA system, the SCADA system can also
support a segregated wireless system, or integrate it with existing SCADA IO points.

Since the low level technical approach is to actually map source registers to target
registers, an I/O Mapping exercise should be performed first. IO Mapping does two
things. First it allows the user to think through all the inputs and outputs and their
requirements and relationships. Second, it allows a cross check mechanism in case of
problems.

For example, if the system does not function as expected, the first thing to check is the IO
mapping. If all the maps are correct, then the PLC or processor programming needs to be
checked. Unless there is a radio failure, any problems will be associated with one or the
other of these locations. Since retrieving the source code directly from the processor is
easy, and presents an accurate picture of current programming, the review is timely. If
flaws in the source ladder logic or program are found, they can be easily corrected and
reflashed. If the flaws are in the IO Mapping exercise, that can be corrected and
reprogramming may follow.

Finally, in the IO Mapping exercise, data from one or more source IO’s may be sent to
one or more targets. Additionally, inputs can be combined to create even more
sophisticated “conditions” for alarms or triggers.

Copyright 2007 ISA. All Rights Reserved. www.isa.org

Presented at the 53rd International Instrumentation Symposium
29 April – 3 May 2007, Tulsa, Oklahoma