What are DCS, RTU, PLC, and PC functions on programmable automation controllers?

iFluids Engineering
5 min readDec 21, 2020

--

DCS, RTU, PLC, and PC functions on programmable automation controllers | iFluids Engineering >> info@ifluids.com

Distributed control systems (DCSs), remote terminal units (RTUs), and programmable logic controllers (PLCs) are control systems with hardware and programming designed to meet the requirements of specific applications. Today’s programmable automation controller (PAC) hardware runs DCS, RTU, PLC, and PC functions as software to replicate the legacy hardware that’s operated in motion systems for decades.Because controller functionality previously followed application, early-generation controls were engineered with features and functionalities to serve specific individual market segments. So for engineers and users working in segregated market segments served by these legacy controls, the way in which PACs replicate these control schemes provide a level convenience and familiarity during control implementation.

Distributed control systems (DCSs), remote terminal units (RTUs), and programmable logic controllers (PLCs) are control systems with hardware and programming designed to meet the requirements of specific applications. Today’s programmable automation controller (PAC) hardware runs DCS, RTU, PLC, and PC functions as software to replicate the legacy hardware that’s operated in motion systems for decades.Because controller functionality previously followed application, early-generation controls were engineered with features and functionalities to serve specific individual market segments. So for engineers and users working in segregated market segments served by these legacy controls, the way in which PACs replicate these control schemes provide a level convenience and familiarity during control implementation.

Schneider Electric’s Modicon M580 Ethernet Programmable Automation Controller (ePAC) has controller redundancy (hot standby CPUs) and native Ethernet in its backplane. Built for IIoT functionality, it serves as the integrated controller of the supplier’s automation architecture called PlantStruxure. Two in-rack application-specific motion options include a BMXMSP0200 two-channel pulse train output (PTO) module for servo drives and a BMXEAE0300 SSI module for interfacing with encoders.

Review of the control types — and their roles today

Due to computer processors’ increasing capabilities and declining cost, distinctions between various control types have blurred. The PAC itself is the extension of the PLC to incorporate greater data processing and communications capabilities incomprehensible when the PLC was first invented in the late 1960s.

More about DCS, RTU, and PLC setups

Originally, DCSs were a collection of RTUs operating on a network of copper phone wires. When these systems were first developed, communications were limited to simple alarm states from remote pieces of equipment.

RTUs were small standalone controllers that could execute small logical tasks — usually involving some simple information such as elapsed run time, totalizing units of flow or measuring a process value. Early systems had no ability to transmit data, but if you could rent a copper phone line from the phone company, you could create an alarm to indicate that a process value had been exceeded or the RTU needed to be read.

Designed for the global machine market, the Parker Automation Controller combines machine logic, signal handling, advanced high-speed motion, and visualization.

PLCs were invented to replace relay-based control systems and were the first standard as electricity became the dominant power source for manufacturing systems. As control requirements became more complex, hard-wired relay control became impractical because manufacturing needed more reliable and reconfigurable (programmable) systems. Given the primitive hardware and rigid focus on task execution, early PLCs were a difficult control to network. Today’s PLCs are quite easy to implement.

In fact, PLCs are still more appropriate than PACs in standalone applications such as machine axes that run preset sequences. Rule of thumb: Anywhere PAC functions would otherwise go unused, it still makes sense to use the ever-economical PLC. Pressure from plant personnel and the enduring value of ladder logic make PLCs a first choice in many applications.

Industrial personal computers (PCs) have evolved dramatically with processor advancements. Early industrial PCs were limited to programming terminals and storage devices, because their operating systems weren’t robust enough for industrial controls. This limitation has disappeared due to improved hardware and widely available realtime operating systems such as Linux.

Choosing between a traditional PLC and PAC is complicated by how they share similarities. However, PACs such as those built of SNAP PAC components from Opto22 shown here can (unlike PLCs) multitask with multiple threads — going beyond the PLC’s single program path to simply manage concurrent operations in complex installations. This is especially useful where multiple machines and systems need fast execution of advanced control algorithms and database manipulation. In fact, PACs run control programs and communicate with HMIs as well as digital and analog I/O.

The way in which some PACs have multi-processor architecture lets them support multiple programming environments — and run any or all DCS, RTU, PLC and PC functions. In addition, programmable automation controllers have high-bandwidth internal architectures that allow multiple processors and multiple tasks to execute simultaneously. In this way, designers can create myriad control-system structures to support any application requirement.

iFluids Engineering — Process Engineering, Design and Studies, Instrumentation, Piping, Mechanical, Structural Design Services >> To know more drop an email to info@ifluids.com

>> To know more drop an email to info@ifluids.com

Disclaimer: All information and content contained in this website are provided solely for general information and reference purposes. TM information, Images & any copyrighted material inadvertently published or depicted belong to rightfull owner and iFluids doesnt claim to be its own.

--

--

iFluids Engineering
iFluids Engineering

Written by iFluids Engineering

Chemical Engineering| A one stop engineering solution.

No responses yet