PLC vs RTU

[cesgibis]

I need to chose a control system for a power substation. both RTU and PLC have digital/analogue I/O. Both can comunicate through serial networks with upstream SCADA and downstream protective relays.
Could anyone please tell me what is the difference between RTU and PLC and what are the crireria of choice.

Thank you.

 

[robertjo24]

The basic difference:
RTU-assembles various analog and digital inputs into registers that may be accessed, and can have various registers set for outputs (control or analog output).
PLC-can do the same as above, and be programmed to conduct higher level functions like take actions based upon a set number of input conditions and or set points.
RTU’s have been cheaper in the past, but if you know where to look, PLC’s are getting very affordable. The one thing to remember, PLC’s will most likely require some knowledge of the operating logic, and how to program the interfaces.
If you want to see an example of an inexpensive PLC, look at the DL-05 at

http://www.automationdirect.com.

 

[ragudelo]

Just something to add to robertjo24's comment.

It's not matter of what is cheaper or how many registers it has. It's what the run inside as Operating System (OS).

PLCs are sequential devices, so they run sequential OS inside. Serial communication is a major headache for them, if the communication is directly handled by the CPU, since their ability to put a task on hold is limited (again, they are sequential). If you're thinking in using a PLC and have it talk to another device, better make sure you have a communications co-processor in it.

RTU's run preemtive-multitasking OS, so they are able to leave the communications task on hold while they are taking care of other tasks. RTUs are not the best device for sequential applications, since they cannot excecute a task without being interrupted, so their ability to do something at the right timing is limited.

Make sure you use the right tool for the problem, or will have a serious problem to deal with. As far I can recall, the use of PLCs in substations is critical, since they must exceute the operations at the right timing.

RA

 

[cesgibis]

Thank you both of you,
The general tendency in today’s modern substation control and monitoring is to have more serial communication (Modbus for instance).
The modern protection relays are smart devices capable of communicating with this control system (PLC or RTU).

So, what we require is a lot of real time communication with time critical operations to be conducted by the control system.

I understand that the best compromise would be using a PLC with a communication processor to have both sequential on-time execution of the operations (without interruptions) along with a serial communication capable of working in real time (without delay)

 

[djs]

Hello;
On most modern PLC's the serial comms are handled by the processor firmware. This is completely transparent to the user and/or PLC program. Perhaps the only place it shows up is when the PLC becomes the master and has to initiate the communication. Then an instruction will be needed in the PLC program
We design and build RTU's and RTU systems. We mostly use a standard off the self PLC. In many cases these are cheaper and better then dedicated RTU module. Also because of the off the self status, the client is not locked into one particular brand.

 

[sengn]

What about disturbances, high voltages etc that can occur in a substation. Can a off the shelf PLC handle these??

 

[cesgibis]

Good question “sengn”. RTUs used in substations (like the S9000 of Alstom) have also the ability to perform the event recording function with 1ms accuracy. Is it inherent to the RTU function ? off the shelf PLCs cannot normally perform this task (?).

Disturbance recording is normally performed by dedicated devices (disturbance recorders) to which Current Transfomrers are directly connected. Protection relays like the MICOM from Alstom can also carry out this task, but the difficulty is to retrieve the information from those relays up to the control system to be processed by the supervision or SCADA.
Serial communication like Modbus does not seem to be the appropriate serial interface to do it. Can those relays be also synchronized to 1 ms accuracy so we can work on the same time basis ? Can an RTU do it?

 

[sengn]

You are right about the disturbance recorders. I am asking abt the EMC disturbances, and PLCs, that you see in a substation.

The disturbance recorders, located in the relays that are connected to an RTU, can be retrieved by the SCADA system if you have an Ethernet connection to the RTU. Time synchronisation can also be done, at least close to 1 ms.

 

[HugoGSF]

hello,

i'm new in the forums, and about this subject i would like to tell you the the PLCs can't hanlde withe the electrical fields in a 400KV SE, and if we make the 2KV input test, i don't think that he can handle that.

i don't know but i think that the PLCs don't have a double relay output or a checkback? rtus have it.

i'm working in a DMS SCADA system in Algeria, as far as i Know in my work, the plcs don't have the possibility to emulate one protocol in each port of communication.

There are another things but if you like you should see the site Scada Gospel of ian wise, i don't remember the adress.

cumps.

HGSF

 

[ragudelo]

Either you use PLCs or RTUs, you NEVER-EVER connect them directly to test points. CTs and PTs are used to bring the measured level to a standard range suitable for input to any device.
If the devices you're using by any chance are to be connected directly, is because the CTs and PTs are inside.
I never used a device which include them, because whenever you need to calibrate or simulate your measurement, you need to take them off line and supply the simulated signal, kind of funny task talking about KVs. If you're not providing such facilities to your users, guess the Argelians will have a hard time with the system.
A "double relay check back" (also known as Check-Before-Operate) is a function that can be provided either via hardware or software, depending on the system design. The reliability of it, is matter of long arguments. If the PLC does not provide it, it's very easy to implement with two relays on the I/O.
About the inability of the PLCs of emulate different protocols, those fitted with communications coprocessor cards, can emulate as many protocols as cards have them in. Even some cards can provide different protocols to choose from, but make them talk more than one protocol at any port has never (that I'm aware of) been too successful. That also applies to most RTUs.

Finally, PLCs are usually better suited to operate in a substation or electrical plant, since that was one of their main purposes (replace the old relay ladder logic). The ability of make them communicate is a bit matter of art, since not all protocols are suited to be used in any environment. As somebody mentioned MODBUS, it's a nice simple protocol; but never expose it to a noise loaded environment. It doesn't have ANY provision (beyond simple ARQ) to handle a discontinous communication.

RA

 

[tomatge]

Maybe I'll add my thoughts to the various issues raised above.

RTUs were developed specifically for SCADA, often proprietary RTUs dedicated to each manufacturer's SCADA system. As such, the RTU would have been "tuned" in terms of hardware, software and communications to match the functional requirements of the SCADA. The advent of open protocols (IEC60870, DNP3 etc.) is a development of this whereby basic SCADA functional requirements are maintained.

PLCs were developed for simple automation tasks, relay logic replacement schemes etc. They have come a long way since then, are may be more widely applicable to process and monitoring schemes, but I question their ability to replace RTUs without loss of facility.

RTUs are usually designed to time stamp events to high resolution (typically down to 1ms). In standard PLCs this is unlikely, due to the sequential nature of PLC instruction operation. If you have a scan cycle of (say) 20ms, then realistically you cannot rely on time stamping to an accuracy better than 40ms (one complete scan to set the PLC time, plus one complete scan to measure the event).

The next major problem is communication protocol. RTUs will typically use protocols like DNP3 or equivalent, developed for high reliability, resilience and error checking. The protocol will allow time stamped events. MODBUS is relatively simple and effective, but nowhere near as reliable as DNP3. It does not support time stamping of events, nor does it support message queues or sequence of event reporting.

Usually RTUs provide select-check-actuate control sequences as standard. Whilst possible in a PLC, this would have to be created by programming and/or external hardware schemes (particularly if you want to implement multiselect rejection, for example).

Finally, RTU hardware would typically be designed for the working environment, in terms of noise immunity, signal isolation etc. This can be very important in some schemes. PLC tend to be generic, and may require more sophisticated interfacing to plant signals.

My view is that RTUs provide a better interface for basic SCADA. PLCs are better suited for process control, automated systems etc. where SCADA functionality is secondary to the task being performed.