RTU or PLC: Which is Right for You?

July 10, 2012
Though programmable logic controllers (PLCs) have become dominant across industry, there are still many applications using remote terminal units (RTUs). Deciding which is right for your use is a discussion that still continues.

The question of when it’s most appropriate to use an RTU or a PLC has not faded with the continued rise of the PLC and the PAC (programmable automation controller). In fact, a member of the Automation & Control group on Facebook (the Facebook counterpart to Automation World’s LinkedIn group), recently asked this very question.

The most detailed response explained that: an RTU is a “microprocessor-controlled electronic device that interfaces objects in the physical world to a distributed control system or SCADA system by transmitting telemetry data to the system and/or altering the state of connected objects based on control messages received from the system”; and that a PLC is basically “a digital computer used for automation of electromechanical processes. Because the functions of RTUs and PLCs overlap, RTUs tend to be used more for wide geographic telemetry, while PLCs are best suited for local area control.”
Other members of the group claim that the communications abilities of current PLCs “more than equal RTUs and they're considerably more flexible and versatile” — even in applications requiring wide geographic use.
Thus, the debate rages on.
One of the better — and simpler — explanations I have seen over the years comes from Tetragenics (a supplier of SCADA systems and smart remote units). Basically the explanation says: If you need a stand-alone controller with power for your application, a PLC is likely your best choice. But be aware that some level of programming skills will be required. If you need a device to control multiple processes, without direct intervention from a controller or master, an RTU can provide many of the advanced control functions needed, as it is basically a direct interface between the field sensors, actuators and a central control unit.
Like most answers either/or questions, the answer always seems to be “it depends.”
Where do you come down on this issue? Weigh in with your answers below in the comment section.

About the Author

David Greenfield, editor in chief | Editor in Chief

David Greenfield joined Automation World in June 2011. Bringing a wealth of industry knowledge and media experience to his position, David’s contributions can be found in AW’s print and online editions and custom projects. Earlier in his career, David was Editorial Director of Design News at UBM Electronics, and prior to joining UBM, he was Editorial Director of Control Engineering at Reed Business Information, where he also worked on Manufacturing Business Technology as Publisher. 

Sponsored Recommendations

Food Production: How SEW-EURODRIVE Drives Excellence

Optimize food production with SEW-EURODRIVE’s hygienic, energy-efficient automation and drive solutions for precision, reliability, and sustainability.

Rock Quarry Implements Ignition to Improve Visibility, Safety & Decision-Making

George Reed, with the help of Factory Technologies, was looking to further automate the processes at its quarries and make Ignition an organization-wide standard.

Water Infrastructure Company Replaces Point-To-Point VPN With MQTT

Goodnight Midstream chose Ignition because it could fulfill several requirements: data mining and business intelligence work on the system backend; powerful Linux-based edge deployments...

The Purdue Model And Ignition

In the automation world, the Purdue Model (also known as the Purdue reference model, Purdue network model, ISA 95, or the Automation Pyramid) is a well-known architectural framework...