From Isolated Plants to Converged Networks

Before there was any programmable anything, industrial control was built from relays — electromechanical switches wired together so that closing one contact would open or close another. A single machine might use hundreds of relays, each one a physical component that could wear out, and the entire sequence of operations was hard-wired into a cabinet the size of a refrigerator. Changing the logic meant physically rewiring the panel — no small task on a production line that couldn't stop for a week.

Alongside relay logic, many process industries — refining, chemicals, food and beverage — used pneumatic controllers: air pressure, not electricity, carried both the signal and the control action. A pneumatic controller reading a tank level would adjust a valve using nothing but compressed air routed through tubing. These systems were remarkably reliable and inherently safe in explosive atmospheres (no electrical spark to worry about), which is precisely why some pneumatic instrumentation is still in service today, quietly doing its job in refineries that have modernized everything around it.

In 1968, General Motors' Hydramatic division issued a request that would define an entire industry: a solid-state controller that could replace relay panels, survive the plant floor, and be reprogrammed without rewiring. Bedford Associates — later Modicon — answered with the Modicon 084, widely credited as the first commercially successful programmable logic controller (PLC). Engineer Dick Morley and his team designed it to be programmed using ladder logic, a notation deliberately built to look like the relay ladder diagrams electricians already knew how to read. That single design decision — make the new thing look like the old thing — is a large part of why the PLC was adopted so fast: nobody had to relearn their trade from zero.

Once controllers could be networked together, two distinct architectural families emerged — not because anyone designed them in parallel on purpose, but because two very different kinds of industry had two very different problems to solve.

A distributed control system (DCS) is what you get when an entire continuous process — a refinery, a chemical plant, a power boiler — needs hundreds or thousands of control loops working together, in one facility, under one vendor's proprietary but tightly integrated architecture. A DCS is built around continuous, closed-loop control: temperature, pressure, and flow, adjusted many times a second, everywhere in the plant, all supervised from a single control room.

SCADA (supervisory control and data acquisition) solves a different problem: monitoring and supervising equipment that is spread across a wide geographic area — a pipeline running two hundred miles, a water system with forty remote pump stations, a power grid with substations across a state. A SCADA master station doesn't run tight closed-loop control the way a DCS does; it polls remote sites at intervals (seconds to minutes), gathers data, and issues occasional supervisory commands, because the sites are too far apart and the communication links too limited for anything faster.

For most of the history covered so far, none of this ran on anything you'd recognize as a computer network. Controllers talked to each other and to field devices over point-to-point or multidrop serial links — RS-232 and RS-485 — carrying protocols like Modbus RTU. These links were slow by modern standards (often 9,600 bits per second or less), but they were also simple, predictable, and — crucially — physically isolated. A serial cable running from a PLC to an RTU carries exactly one conversation. There is no such thing as an unexpected device joining a serial link the way a laptop can join a Wi-Fi network.

Ethernet changed that calculus. Once industrial vendors began offering Ethernet ports on PLCs and adapted protocols like Modbus TCP and EtherNet/IP to ride on standard IP networking, plant-floor devices could, for the first time, share a physical network — and eventually the same switches and routers — with ordinary IT traffic. This wasn't a security decision; it was a cost and convenience decision. Ethernet hardware was cheap, fast, and already being deployed everywhere else in the building.

The air gap — the idea that a plant network with no physical or logical connection to the outside world is inherently safe — was never really a security architecture that anyone deliberately engineered end to end. It was mostly just what you got by default when OT and IT grew up as separate industries using separate cabling. Once Ethernet made a physical connection between the two networks technically easy, the air gap survived only as long as nobody had a business reason to cross it. That didn't last.

Four pressures, arriving roughly together over the 2000s and 2010s, made crossing the gap look less like a risk and more like an obvious decision to any executive who wasn't thinking about security:

• Real-time visibility. Executives wanted production dashboards showing throughput, downtime, and quality metrics without waiting for someone to manually key numbers into a spreadsheet at shift change.
• Predictive maintenance. Vendors and reliability engineers wanted vibration, temperature, and cycle-count data streamed continuously so failing equipment could be serviced before it broke, not after.
• Remote vendor support. Equipment vendors wanted a network path to diagnose and patch their own controllers without flying a technician to the site every time.
• Enterprise integration. ERP and MES systems wanted production data flowing automatically into inventory, billing, and supply-chain systems instead of being re-entered by hand.

Each of these, taken alone, sounds entirely reasonable — and each one is a request to open a path between a business system and a control system that was never designed to be reachable from anywhere. Multiply that by every vendor, every dashboard project, and every "just this one connection" exception request across a decade, and you get exactly the converged, under-governed network that most OT security programs are hired to clean up today.

Click each business pressure below, in any order, to see how a single reasonable request quietly narrows the gap between the plant network and the outside world. Nothing here touches a real network — this is a model of a decision, not a network scan.

Five questions covering the lesson's key distinctions. Answer each, then select Grade My Quiz to see your score and an explanation for every item.

• Foundations of OT Cybersecurity: Asset Inventory Guidance for Owners and Operators (CISA) — a practical starting point for the asset-visibility work referenced throughout this course.
• NIST SP 800-82 Rev. 3: Guide to Operational Technology (OT) Security — the standard federal reference for OT architectures, risk, and controls; useful background for the frameworks lesson later in the week.