People may not realize that the concept of the RTU is morphing. In decades past, we were merely looking for something that could report an event. But the goal-posts have moved. So what should an RTU really look like these days? Let’s look at some features:
First, the RTU needs to have a clock. As someone who participates on the DNP3 Technical Committee, I can testify that there are some who still think that clocks are optional. But as an end-user I’m adamant that an event oriented device should have a clock. Further, as an end-user, let me say that if it doesn’t have a clock, I ain’t buying it. PUT A CLOCK IN IT! It can be dirt cheap. There is no excuse not to have one.
I prefer radio clocks that will even work underground. In North America WWVB on 60 kHz is a good bet. Similar radio stations exist in other parts of the world, such as MSF, DCF77, JJY, RBU, HBG, and BPC are a few. GPS clocks are dirt cheap. If the RTU uses the cellular telephone system, it can get the time of day from there. If the RTU has access to a network, it can get the time using NTP. Even atomic reference clocks are getting less and less expensive every day.
As for accuracy, it largely depends upon what you want to do. But in general, it isn’t too difficult or expensive to get to within 10 milliseconds of accuracy. Better accuracy is certainly achievable.
And if nothing else, the DNP3 protocol itself can be used to convey the time, though in some telecommunications environments it may not be well suited for that purpose.
Next, an RTU should be able to communicate with remote I/O panels. Real time communications using DNP3 over TCP, ModbusTCP, EthernetIP, ProfiBus, DeviceNet, or other protocols should be possible.
Regarding I/O: I/O wiring is expensive and I/O panels are becoming a commodity. If possible, it makes sense not to run huge bundles of wiring all the way back to the RTU. Some I/O panels may be in places such where Class I Div. 2 (potentially explosive) environments dictate certain measures. There is no point in designing the whole RTU around that standard. So a fiber connection to a remote I/O panel in the Explosion rated housing would be appropriate. Other I/O panels may be less expensive, or even integrated in to the field devices, such as a variable frequency drive.
The RTU should be able to monitor the networks to that I/O and generate alarms if the networks are starting to misbehave. I’ll have more to say about that in a future blog.
The RTU should also have a standby power supply. How much backup time is up to you, but I would make a case that the RTU should be able to last at least long enough to report that it is going down due to a power outage.
The RTU should also be located in a secure, hardened cabinet. The cabinet should have a door switch on it. If the RTU cabinet door opens and nobody is known to be working there, it should be cause to send someone to the site to investigate.
If there are batteries for features such as keeping event buffer memory or configurations alive, they should be monitored and alarms should trigger someone visiting the site to replace them. If the RTU uses an external communications device, it should be monitored locally and events should be generated if they indicate a lack of monitored activity.
Going a bit further, if the RTU detects a lack of activity from the master, it should wait for some time and then trigger some autonomous local control software. Such features are known as “dead-man timers.” In the water utility where I work we call this mode “Local Pressure Control.” The pressure reducing valves open to a pre-determined rate, the pumping stations will shut down for several minutes, check the pressure, and then if the pressure is below some threshold, it will turn on a designated pump for some fixed period of time such as 1 hour.
Local controls are not ideal, but they turn what would be a flaming emergency in to something where we can afford to wait a few hours before we have to deal with it. This then frees us to deal with larger issues.
The RTU cabinets and remote I/O should also have an I/O termination rail where contacts are whetted, fused, surge-protected, grounded, or whatever. This also provides a great place from which one can isolate whether the problem is caused by I/O wiring or whether it is being caused by a local problem such as a blown power supply.
The latter is also a great place for start-up testing. Telling contractors to nail their I/O down to that designated rail is great because it gives them a place to power up and test each I/O point BEFORE hooking it to actual I/O. This proves their wiring is good. Why bother with this? Some devices tie lines in common. Diagnosing such I/O panels is a pain while the contractor insists that his wiring is perfect and your gear must be at fault. The designated rail is a great place to prove who is actually responsible for what.
Finally, the RTU should be durable. I can’t say this enough. Ours live in some surprising temperature extremes. In fact, monitoring the temperature inside the cabinet is not a bad idea.
Basically, I like to think of the RTU as an event reporter and recorder. It should also have a local memory that might be useful for forensic value, just in case something terrible happens at the site. You never know when someone might dump a tanker load of gasoline down the sewer…
