What is a DCS? PLC-based system vs DCS, Rockwell PlantPAx and where the SIS fits in an ICSS

A distributed control system (DCS) is a process control system in which control is spread over several controllers on one network, while operator screens, alarms, history and engineering are handled centrally as a single system. A PLC-based system can do much of the same work, and the two have moved closer over the years: Rockwell's PlantPAx, for example, is a DCS built on ControlLogix and CompactLogix controllers. When choosing, look at what the vendor defines as a system around the controller: libraries, redundant architectures, change tracking and a released set of software versions.

What a DCS is

Wikipedia describes a DCS as a process control system whose control functions are distributed among autonomous controllers linked by a network, with operator interfaces, supervisory control and alarm management usually centralised in operator stations. NIST SP 800-82r3 (section 2.3.3) places a DCS within one site, such as a refinery or a chemical plant, with a supervisory level coordinating local controllers that each handle part of the process. The usual parts:

• Field I/O and marshalling. I/O modules convert 4–20 mA and on/off signals; marshalling sits between field cables and I/O.
• Controllers run the control algorithms, such as PID loops. A DCS may use redundant controllers: a standby takes over automatically on failure, and switchover can also be manual for maintenance.
• Control network linking controllers, servers and stations, which can be made redundant over separate cable routes.
• Servers and operator stations holding displays, alarms and data connections to the controllers.
• Engineering station, which PlantPAx calls the central location for configuring the system.
• Historian, and batch where the process needs it.

In Wikipedia's level model, field devices are level 0, I/O and controllers level 1, supervisory computers with operator screens level 2, and production control and scheduling levels 3 and 4. Levels 1 and 2 form the traditional DCS, usually from one manufacturer. SCADA and the operator interface have their own articles: What is SCADA and What is an HMI.

Where PLC and DCS came from, and why the line has blurred

The PLC started in car plants. In 1968 GM Hydramatic, a division of General Motors, asked for an electronic replacement for hard-wired relay systems; Bedford Associates won with the 084, built in 1969, and set up Modicon to sell it. Ladder logic, which resembles relay schematics, became the usual way to program PLCs as programming terminals developed.

The DCS started in process plants. Wikipedia lists three systems introduced in 1975: Honeywell's TDC 2000, Yokogawa's CENTUM and Bristol's UCS 3000. Yokogawa describes CENTUM as the world's first DCS, announced in June 1975; Wikipedia does not single out one system as the first.

The two lines met early. Wikipedia records the first PLCs integrated into DCS infrastructure in the 1980s, and NIST describes PLCs as control components inside both DCS and SCADA hierarchies. Later, Wikipedia says, suppliers that had been stronger in PLCs, Rockwell Automation and Siemens among them, entered the DCS market, while new-generation systems from the traditional DCS suppliers led to a trend of combining PLC and DCS functions in one system, called a process automation system. Differences between systems remain, Wikipedia says, in database integrity, pre-engineering, maturity, communication transparency and reliability.

Wikipedia's PLC article notes that very complex process control, as in parts of the chemical industry, may need more than a high-end PLC offers. Rockwell, for its part, sells ControlLogix 5580 and 5590 and CompactLogix 5380 process controllers with dedicated process instructions and a native process objects library; they also handle standard control, motion included.

PLC-based system vs DCS: tendencies

The table states tendencies. The DCS column comes from the sources cited; the PLC column shows what is left to the project when no vendor system definition applies.

PlantPAx: Rockwell's process system

Rockwell calls PlantPAx a modern distributed control system, with one platform for single stations and large distributed architectures. Its selection guide (PROCES-SG001X, 08/2026) defines the system elements:

• PASS (Process Automation System Server), required, hosting displays, alarms and controller data connections; PASS-C, a consolidated PASS that also takes on application server functions, is for small systems under 2,000 I/O.
• OWS and EWS, operator and engineering workstations, also as thin clients of AppServ-OWS and AppServ-EWS.
• AppServ-Asset (FactoryTalk AssetCentre) for controller backup and monitoring, required except in the skid or station class.
• AppServ-Batch for batch management and AppServ-Info for historian or SQL Server.
• Controllers from the ControlLogix and CompactLogix families.

Architecture classes go by I/O count, from a skid or station under 2,000 I/O to distributed systems above 10,000 I/O with up to 10 PASS servers or redundant pairs. Server elements are typically deployed as virtual machines, on VMware vCenter or Nutanix AHV.

Process Library. The PlantPAx library reference manual (PROCES-RM200K, 06/2026) describes the Rockwell Automation Library of Process Objects as a set of tools, including process objects, HMI images, diagnostic objects, control strategies, sequencer objects and a historian Asset Framework template. PlantPAx instructions are embedded in the process controller's firmware. Each system release lists the library versions it supports, together with recommended software versions for new systems.

Redundancy options: ControlLogix controller redundancy with the 1756-RM3 module, a secondary PASS, PRP and DLR network topologies (a DLR ring recovers from one point of failure), and redundant I/O with FLEXHA 5000 and 1715 Redundant I/O.

TDL's Vinh Hoan FeedOne project page describes a new aquafeed plant on PlantPAx with redundant ControlLogix 5580 process controllers, FactoryTalk View SE with FactoryTalk Historian, and batch and recipe control; in 2025 TDL re-engineered PlantPAx equipment phases and Process Library objects and implemented FactoryTalk AssetCentre. The historian and batch layers are covered in the historian and ISA-88 articles.

Control and safety stay separate

The DCS is the basic process control system (BPCS); the safety instrumented system (SIS) is a separate layer. NIST (section 2.3.7) describes an SIS as one or more safety instrumented functions, each made of sensors, a logic solver and final elements, that bring the process to a safe state when set limits are exceeded. The SIS is often kept independent of the BPCS, so that a control system failure does not harm the safety functions; historically it stood alone, physically and logically separated.

Some newer systems let the SIS pass information to the control system. NIST calls these integrated control and safety systems (ICSS), whether one all-in-one product or devices from several vendors, and the SIS must still meet IEC 61511. Part 1 of that standard is IEC 61511-1:2016; ISA publishes it as ANSI/ISA-61511-1-2018 in the ISA-84 series. The ICSS article covers the subsystems and integration points on Rockwell.

New plant, expansion or migration: questions to ask

New plant

• How many I/O points and operator stations, and how will that grow? The PlantPAx classes above are one way to frame the size.
• Continuous, batch or both? In PlantPAx, batch adds an AppServ-Batch server.
• Which layers need redundancy: controllers, servers, network, I/O?
• Which library and which change tracking tool, and who will own them after handover?
• What does the owner's specification already fix: vendor, network, alarm and display philosophy (ISA-18.2, ISA-101)?

Expansion of a running system

• Which system release and library version is installed? New objects should match it, and Rockwell provides a Process Library Migration Tool for moving from earlier library versions.
• Is there room in the existing topology? The PlantPAx selection guide gives recommended limits per PRP and DLR topology, such as controllers per topology and switch nodes per DLR ring; check them in the guide for the installed release.
• Are the redundant pairs healthy before you add to them? See the ControlLogix redundancy pre-FAT checklist.

Migration of an old DCS or PLC system

Rockwell's DCS modernization white paper (PROCES-WP006C, 01/2021) sets four decisions to make first: hot or cold cutover, rip-and-replace or phased, horizontal or vertical, and replication or innovation. In a phased path the most obsolete part, generally the HMI, may go first, then the controllers, then the I/O, with HMI and controllers tested in simulation; I/O scanners or interface components let new controllers work with existing I/O. The paper notes that even good conversion utilities leave some manual rework, and that where none exist the configuration is converted by hand; it also warns that copying the old design carries its HMI and control problems into the new system. For the HMI, see legacy HMI/SCADA migration paths; if the old and new systems exchange data over OPC DA, see OPC DA and DCOM errors.

In oil and gas, TDL project pages describe migrations of this kind: at Phu My Gas Distribution Station a PLC-5 / HIMA system was replaced by an ICSS on redundant ControlLogix and AADvance, and at Dinh Co GPP the SLC 500 system of the CC01 turbo expander moved to redundant ControlLogix with Ex-p and Ex-e panels for Zone 2. TDL's ICSS and safety systems page lists process control on redundant ControlLogix with 1715 redundant I/O, PlantPAx and AVEVA, and the control system packages for EPC contractors page covers the control system scope inside an EPC package.