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.
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
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 MESHenabled 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.
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.
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.