Organizing your PLC/RTU Data for Efficient Polling
This article deals with organizing your SCADA database for efficient communications to the PLCs and RTUs on your SCADA system. Many SCADA systems are plagued with inefficient communications that result in slow response times or even erroneous operation. A system that is marginally working when all of the PLCs/RTUs are communicating may slow dramatically or even halt operation if several PLCs/RTUs experience communications problems. This article will outline some strategies that should help make your SCADA system communicate as efficiently as possible. Subjects include: Factors that contribute to inefficient SCADA communications Drawbacks of an Unorganized PLC/RTU Database Example of an Unorganized PLC/RTU Database Benefits of an Organized PLC/RTU Database Example of an Organized PLC/RTU Database A Sample Specification to Define a Scannable Range Example of a Specification to Define a Scannable Range - Poll #1 Example of a Specification to Define a Scannable Range - Poll #2 Organize your Data for Efficient Polling How is NetSCADA designed to make PLC/RTU communications efficient?

Factors that contribute to inefficient SCADA communications

Some system integrators blame low SCADA system communications performance to inadequate bandwidth. In some cases this analysis may be correct. However, in my career, I have found the lack of database organization in the PLC/RTU to be the largest contributor to poor system communications performance. I have seen PLC systems where 20+ polls of a single PLC by the SCADA application was necessary to acquire all of the PLC’s data. Put that PLC out on a half duplex 1200 baud radio system and the screen updates will probably slow to a crawl. Throw in 10 more PLCs on that same radio system and communications performance will get even worse, maybe even stalling out completely. And what if one of these PLC fails to communicate due to a problem? I hope you get the picture. The best strategy I have found is where the SCADA database for the RLL (Relay Ladder Logic) for the PLC is completed to execute the applications control functionality, add RLL rungs to organize the data necessary for the SCADA application in consecutive PLC registers. We can call these target PLC registers for SCADA data the scannable range. Most PLCs have the capability to do some sort of LET statements in their RRL syntax that allows the integrator to organize the data necessary for SCADA in consecutive registers in the PLCs memory (However, note that some older PLC/RTU devices may not allow the mapping of I/O points to another different location in memory). By doing this your SCADA application may be able to acquire all necessary data in one or two scans vs. up to 20+ scans. Many PLCs SCADA protocols allow reading up to 100+ registers with a single poll. It takes much less time to acquire 100 resisters of data with a single poll vs., for example, 5 polls at 20 registers/poll. Take advantage of the protocol's ability to handle long, multiple-register packets. Below is an example of how organizing your PLC/RTU database can make your SCADA communications more efficient.

Drawbacks of an Unorganized PLC/RTU Database

In this case the integrator let the data reside in the PLC memory where it fell out when the RLL code was written. In this example, we are utilizing a radio system operating at 9600 baud half duplex. Note that it takes 7 polls and 4.5 seconds to acquire all of the PLCs data vs. 1 poll and 0.78 seconds for the organized example.

Example of an Unorganized PLC/RTU Database

Poll # Type Data required Amount of Data Required Request poll from host ms Radio key time-ms Data trans time - ms Protocol Overhead - ms Total poll time - ms 1 2-64 point Discrete Input card status 8 registers (16 bit) 500 ms 100 ms 14 ms 10 ms 624 ms 2 1-32 point Discrete Output card status 4 registers (16 bit) 500 ms 100 ms 7 ms 10 ms 617 ms 3 4-16 point Analog Input card values 64 registers (16 bit) 500 ms 100 ms 107 ms 10 ms 717 ms 4 1-8 point Analog Output card values 8 registers (16 bit) 500 ms 100 ms 14 ms 10 ms 624 ms 5 16 point Discrete internals from RLL logic 1 registers (16 bit) 500 ms 100 ms 3 ms 10 ms 613 ms 6 12 registers Analog internals from RLL logic- integers 12 registers (16 bit) 500 ms 100 ms 21 ms 10 ms 631 ms 7 6 registers Analog internals from RLL logic- reals 12 registers (16 bit) 500 ms 100 ms 21 ms 10 ms 631 ms 8 Totals 109 reg. 3500 ms 700 ms 187 ms 70 ms 4457 ms

Benefits of an Organized PLC/RTU Database

In this case the integrator organized the SCADA data in the PLC memory from where it fell out when the RLL code was written to consecutive PLC registers (a scannable range). In this example we are also utilizing a radio system operating at 9600 baud half duplex. Note that it takes 1 poll and 0.78 seconds to acquire all of the PLCs data vs. 7 polls and 4.5 seconds for the unorganized example. By organizing your PLC/RTU database in to in consecutive PLC registers (a scannable range) the integrator cut the amount of time necessary to acquire the SCADA data from the PLC by 82% as well as reduced the amount of traffic on the radio system by 86%! Additionally if you factor in the probability of all 7 polls in the inefficient example being successful additional gains will be achieved by organizing your SCADA database in your PLCs and RTUs.

Example of an Organized PLC/RTU Database

Poll # Type Data required Amount of Data Required Request poll from host time & turnaround time-ms Radio key time-ms Data trans time-ms Protocol Overhead (CRC + header+ tailer ) -ms Total poll time-ms 1 Mix of I/O + internals 109 registers (16 bit) 500 ms 100 ms 187 ms 10 ms 797 ms

A Sample Specification to Define a Scannable Range

Adopting a specification to define a scannable range could be one solution that may improve system communications performance. If your systems integrators adheres to a spec such as the below when developing RLL applications, SCADA systems communications will not suffer due to unorganized data. The below example assumes that the SCADA protocol allows maximum reads of 120 16 bit registers with a single poll. It also assumes that registers used by the RLL application are in the low register area and the spec allows start of the SCADA data in higher, unused 16 bit registers. The specification is an example only, and it will probably be necessary to resize the allowable data type allowances for registers to fit your applications. Additionally, your PLC protocol will probably require you to use different registers numbers than I have used here. The specification is designed to allow for a single poll to read the entire database from a typical small to midsize PLC system. See the second table for larger systems. For systems that have multiple distinct applications running in the same PLC, the specification may be used to poll each application as a separate poll. This will help separate data for the different applications minimizing confusion. A point to be made is that I would recommend that the specification be used for wire or cable media as well as wireless communications.

Example of a Specification to Define a Scannable Range - Poll #1

Poll# Type Data required Amount of Data Allowed Start Register Stop Register # of Points allowed Total Registers in Poll #1 1 Discrete Input card status 12 registers (16 bit) 41000 41011 192 12 1 Discrete Output card status 4 registers (16 bit) 41012 41015 64 16 1 Discrete internals from RLL logic 2 registers (16 bit) 41016 41017 32 18 1 Discrete internals from PLC diagnostic registers 2 registers (16 bit) 41018 41019 32 20 1 Analog Input card values 64 registers (16 bit) 41020 41083 64 84 1 Analog Output card values 8 registers (16 bit) 41084 41091 8 92 1 Analog internals from RLL logic- integers 12 registers (16 bit) 41092 41103 12 104 1 Analog internals from RLL logic- reals 12 registers (16 bit) 41104 41115 12 116 1 Analog internals from PLC diagnostic registers 5 registers (16 bit) 41116 41120 5 120

Example of a Specification to Define a Scannable Range - Poll #2

Poll# Type Data required Amount of Data Allowed Start Register Stop Register # of Points allowed Total Registers in Poll #2 2 Discrete Input card status 12 registers (16 bit) 41121 41132 192 12 2 Discrete Output card status 4 registers (16 bit) 41133 41136 64 16 2 Discrete internals from RLL logic 2 registers (16 bit) 41137 41138 32 18 2 Discrete internals from PLC diagnostic registers 2 registers (16 bit) 41139 41140 32 20 2 Analog Input card values 64 registers (16 bit) 41141 41204 64 84 2 Analog Output card values 8 registers (16 bit) 41205 41212 8 92 2 Analog internals from RLL logic- integers 12 registers (16 bit) 41213 41224 12 104 2 Analog internals from RLL logic- reals 12 registers (16 bit) 41225 41236 12 116 2 Analog internals from PLC diagnostic registers 5 registers (16 bit) 41237 41241 5 120

Organize your Data for Efficient Polling

Include in the specification for your RLL program the organization your PLC/RTU data into sequential registers so they may be polled with the fewest number of polls from your host. Failure to do so is the single most frequent cause of poor performance in SCADA systems. Many integrators fail to take the time to organize the process database in these PLCs or RTUs. They rely on making the host system scan the remotes multiple times to get required data for the user's application. This may be tolerable on fast, hardwired systems but will usually not work on systems where wireless media has been deployed. I have seen systems that required the host to poll a single PLC >20 times to acquire all of the SCADA data. The SCADA data was mapped into a sequential group of some unused registers which allowed the host to acquire the data in 2 scans or a 10 fold improvement. Many PLC and RTU protocols support the reading of 100 or more registers with a single poll. Take advantage of this capability to make your system as efficient as possible!

How is NetSCADA designed to make PLC/RTU communications efficient?

NetSCADA is designed to work with all media types and has special features that make communications to remote PLCs & RTUs easy and efficient. NetSCADA allows each communications drop and poll to be configured individually to take into consideration poll frequency, communications time-out time, media delays, and bandwidth. Additionally, NetSCADA is designed to allow the developer to organize the PLC & RTU database to facilitate efficient communications when using limited bandwidth media such as radios. NetSCADA promotes organization of the PLC/RTU database to minimize the number of communication polls necessary to acquire data from or control a PLC/RTU. Click here to see more on how to set up NetSCADA for efficient PLC/RTU communications.

Definitions

Request poll from host time & turnaround time – This include the amount of time that it takes for the host to the insert the poll into its queue, for the radio to transmit the poll, and for the remote PLC/RTU to process the request for the data. Radio key time – May also be called radio key delay time or possibly called RTS-CTS delay time . This include the amount of message time that it takes for the radio to key the transmitter and become ready to transmit data. This time typically can be from 10ms to 100ms for data radios. Check your radios specification for the proper setting for radio key delay. Data trans time - This include the amount of message time that it takes for the bytes for the requested remote’s SCADA data. Protocol overhead (CRC + header+ tailer) – This include the amount of message time that it takes for the host or remote to calculate error checking bytes such as a CRC or Check Sum, these error checking bytes, plus with typical header and tailer bytes in the packets.

Additional Resources