Electronics Guide

The Panel of Relays and What It Cost

Before 1969, the logic of an automobile assembly line lived in steel cabinets full of electromechanical relays. The principle was simple and had been understood since the earliest telephone exchanges: a relay coil, when energized, pulls a set of contacts closed or open, and by wiring contacts in series and parallel an engineer can build any Boolean function. Series contacts perform AND; parallel contacts perform OR; a normally closed contact performs NOT. Add time-delay relays, mechanical latching relays, stepping switches, and cam-driven drum sequencers, and the result is a complete sequential control system with no active devices in it at all.

The approach worked, and a great deal of the twentieth century's manufacturing capacity ran on it. It also carried costs that grew with the size of the installation. Relays wear out. Contacts pit and weld, coils burn open, and the mean time between failures of a single relay, multiplied across a panel holding several hundred of them, produces a machine that stops often for reasons that take hours to find. Diagnosis meant a technician with a meter, a set of drawings, and patience.

Worse, from the point of view of an automaker, was the cost of change. The logic was the wiring. Changing what a machine did meant physically rewiring the panel, and the annual model changeover in the automotive industry meant doing that across an entire plant during a shutdown measured in weeks. Relays that no longer suited the new sequence were scrapped. Drawings that had drifted out of step with the panel—as drawings always do, because a midnight repair rarely gets documented—had to be reconciled with reality first. The changeover was an enormous, recurring, and largely unproductive expense.

The obvious fix was to replace the relay with something solid state, and through the 1960s vendors sold exactly that. Static control or solid-state logic systems packaged transistorized NOR gates into plug-in modules that could be wired together on a rack in place of relays. Static logic was faster and far more reliable than relays, and it eliminated the contact-wear problem. It did not eliminate the changeover problem, because the logic was still the wiring: the modules were interconnected by hand, and rearranging the sequence still meant rearranging wires. Static control also introduced a new difficulty. A relay is visible. A technician can watch its armature pull in, and can hear a panel of them sequence through a cycle. A transistor module does nothing observable, and the maintenance staff who had grown up on relay ladder drawings found the new hardware opaque. Adoption suffered accordingly.

What the industry needed was a controller in which the logic was data rather than wiring, so that changing the sequence meant changing memory instead of changing copper, while the representation of that logic remained something a relay technician could read.

The 1968 General Motors Specification

The request that produced the programmable controller came from the Hydramatic division of General Motors, the operation that built the corporation's automatic transmissions and therefore ran some of the most heavily automated transfer lines in the world. In 1968, a Hydramatic engineer named Bill Stone presented a paper at a Westinghouse conference describing the reliability and documentation problems his plant faced, and setting out the criteria that a replacement for the relay panel would have to meet. Accounts of the internal history differ on which engineer authored the underlying document—one widely cited version attributes the white paper behind the request for proposals to an engineer named Edward R. Clark—so it is safest to say that the specification came out of a group at Hydramatic rather than from any single named inventor.

The criteria themselves are reproduced consistently across the retellings, and they amount to a remarkably clear statement of what industrial electronics actually requires. The new device had to end the scrapping of relays at model changeover and the unreliability of electromechanical contacts. It had to be applicable to the great majority of the machines in the plant, not to a favored few. It had to reduce downtime attributable to controls, which meant it had to be easy to maintain and to program, and the specification named the form that programming should take: it should follow the relay ladder logic that the plant's people already used. It had to be modular, so that a failed part could be exchanged and a system could be expanded. And it had to survive the industrial environment—dirt, moisture, vibration, and electromagnetic interference—without a computer room around it.

Three features of that list deserve emphasis, because they explain the shape of the industry that followed. First, the specification is a maintenance document, not a performance document. It asks for reliability, diagnosability, and ease of change; it says almost nothing about speed. Second, it deliberately constrains the user interface to something the existing workforce already understood, which is a decision about people rather than about technology. Third, it requires ruggedness as a first-class property. General-purpose computers of the period lived in air-conditioned rooms with clean power, and a device that had to sit beside a hydraulic press could not borrow their assumptions about temperature, supply quality, or grounding.

Bedford Associates and the Modicon 084

Several firms bid. The winning proposal came from Bedford Associates, a small engineering company in Bedford, Massachusetts, and the machine that resulted was built in 1969 and designated the 084. Bedford Associates formed a separate company to develop, manufacture, and support the product, and named it Modicon, a contraction of "modular digital controller." The model number is generally explained as the firm's project number: the 084 was the eighty-fourth job Bedford Associates had taken on. Among the engineers on the project was Richard "Dick" Morley, who became the person most often described as the father of the programmable logic controller.

The attribution is contested, and this article does not resolve it. Odo Josef Struger, a longtime engineer at Allen-Bradley, is also called the father of the PLC in reputable accounts, and he is separately credited with coining the acronym "PLC"—a distinction that mattered after 1981, when "PC" came to mean personal computer and the older abbreviation for "programmable controller" became ambiguous. Allen-Bradley developed its own programmable controllers in the same period, and other manufacturers, including at least one minicomputer maker, brought industrial logic controllers to market within a year or two of the 084. The honest summary is that a specific, well-documented customer requirement in 1968 drew several competent answers at nearly the same moment, that Modicon delivered the machine written into the canonical account, and that priority claims beyond that depend on how narrowly one defines the category.

What is not in dispute is what the machine did. The 084 held its program in memory rather than in wiring. It read the state of input terminals connected to limit switches, pushbuttons, and pressure switches; it evaluated a stored logic program; and it set output terminals that drove solenoid valves, motor starters, and indicator lamps. Changing the machine's behavior meant editing the program. Input and output circuits were isolated modules designed for the voltages and the electrical abuse of the plant floor, which is why an industrial controller has always cost more per point than its computing content alone would suggest: most of the price is in the interface to the real world and in the packaging that keeps the real world out.

The 084 proved the concept. The commercial breakthrough came with its successor generation, and with the wave of competitors that followed once automakers had demonstrated the savings. By the middle of the 1970s the programmable controller had spread well beyond automotive assembly, into food and beverage, materials handling, and any other industry that operated sequential machinery. Modicon itself passed through several corporate owners and became a Schneider Electric brand after the acquisition of 1997, but the name survives on products and, more durably, on the protocol the company published in 1979.

Why Ladder Logic, and Why It Lasted

The most consequential decision in the early history of the programmable controller was not an electronic one. It was the choice to present the stored program as a relay ladder diagram.

A ladder diagram is a drawing convention that predates the computer entirely. Two vertical rails represent the supply; between them run horizontal rungs, each a series-parallel arrangement of contacts terminating in a coil. An electrician reads the rung left to right and asks whether a path of closed contacts exists from the left rail to the coil. If it does, the coil energizes. Every maintenance technician in an industrial plant in 1969 could read such a drawing, because the drawing described the panel they repaired.

By rendering the stored program in that notation, the programmable controller became legible to the people responsible for keeping it running. The programming terminal displayed rungs. A technician troubleshooting a stalled machine could call up the rung that should have energized the output, watch which contacts were true, and find the failed sensor without a wiring diagram and without understanding a word about the processor inside. This capability—online monitoring of live logic—was arguably a bigger advance than programmability itself, because it attacked downtime directly. A relay panel had to be probed; a ladder program could be watched.

The abstraction was not perfect, and the differences bite to this day. A relay panel is genuinely parallel: every rung is live simultaneously. A programmable controller is sequential. It executes a scan cycle in which it samples all inputs into an image table, evaluates the rungs in order from top to bottom, and then writes the output image to the terminals. Rung order therefore matters in a way that panel layout never did, an output written twice in one scan takes the value assigned last, and a change to an input during the scan is not seen until the next one. Programmers learned to exploit the model deliberately, using latch and unlatch instructions, one-shot rising-edge instructions, and careful sequencing, and they learned that scan time is a real quantity with real consequences for how fast a machine can react. The scan cycle also supplies the determinism that industrial control depends on, because a cycle of fixed and bounded duration produces predictable timing in a way that an interrupt-driven general-purpose program does not.

Ladder logic has been declared obsolete in every decade since it appeared, and it has outlasted every declaration. Part of the reason is inertia and the enormous installed base. Part is regulatory and organizational: in many plants the ladder program is the documented, auditable description of how the machine behaves, and the people who must certify that behavior read ladder. And part is genuine fitness for purpose, because a ladder rung is a clear and checkable statement of an interlock, which is the single most common thing an industrial program has to express. The notation survived into international standardization decades later, alongside languages designed from scratch.

The Other Branch: From Pneumatics to Electronics in Process Control

While discrete manufacturing struggled with relay panels, the process industries were solving a different problem with entirely different hardware. A refinery does not sequence; it regulates. The controller's job is to compare a measured variable—temperature, pressure, flow, level—against a setpoint and to move a valve so as to reduce the difference, continuously and without oscillation.

That job was done pneumatically, and done well. A pneumatic controller uses a flapper-nozzle amplifier and bellows feedback to produce an output air pressure that is a proportional, integral, and derivative function of the error. The Foxboro Stabilog of the early 1930s added automatic reset, the integral action that eliminates the steady-state offset a purely proportional controller leaves behind, and the Taylor Instrument Fulscope of about 1940 brought all three modes together in a commercial instrument. In 1942, John G. Ziegler and Nathaniel B. Nichols of Taylor Instrument published "Optimum Settings for Automatic Controllers" in the Transactions of the ASME, giving the industry the first widely used systematic tuning rules. It is worth pausing on the fact that proportional-integral-derivative control, the most widely deployed control algorithm in existence, was developed, refined, and rigorously tuned in an entirely mechanical technology before electronics touched it.

Pneumatic instrumentation standardized on a signal range of 3 to 15 pounds per square inch. The choice of a nonzero minimum was deliberate and became one of the most durable ideas in the field: if the signal at the receiving end reads zero rather than three, the line has been cut or the transmitter has failed, and the failure announces itself instead of masquerading as a legitimate reading of the low end of the range. Pneumatic systems also had a natural fail-safe character, since a valve with a spring return moves to a defined position when air is lost.

The weaknesses were physical. Air signals travel at finite speed down small-bore tubing, and a run of several hundred feet introduces a transport lag long enough to degrade the loop it is part of. Compressed air must be dried and filtered, or moisture and oil foul the instruments. Every instrument in the control room required its own tube run back to the field, and control rooms of the era were dense with tubing. Computation beyond the standard three modes was awkward.

Electronic transmitters and controllers displaced pneumatics through the 1950s and 1960s, and they inherited the pneumatic convention rather than replacing it. The 4 to 20 milliampere current loop was conceived in the 1950s as the electrical analogue of the 3 to 15 psi standard, once solid-state electronics became cheap and reliable enough to emulate it. Twenty percent of full scale again represents the bottom of the measured range, and again a reading below the live zero indicates a fault rather than a value; modern receivers commonly treat currents below about 3.8 milliamperes or above about 20.5 milliamperes as diagnostic conditions rather than measurements.

Current, rather than voltage, was the right electrical quantity for the job. The current in a series loop is the same at every point, so the voltage drop in a long cable run does not corrupt the reading, and a current loop driven from a high-impedance source rejects the series noise voltages induced along a cable in an electrically hostile plant. Better still, the live zero left four milliamperes of headroom at all times, which was enough to power the transmitter itself. The two-wire transmitter that resulted—drawing its supply from the same pair that carries its signal, and modulating that supply current to report its measurement—halved the field wiring of a process plant and became the standard form of the industrial sensor. The Instrument Society of America codified the compatibility requirements for these analog signals in its 50 series, known today as ANSI/ISA-50.00.01.

The 4 to 20 milliampere loop is still in service in enormous numbers, and the reason is that it is very hard to improve upon for its narrow purpose. It carries one analog value over one pair, needs no configuration, degrades gracefully, is diagnosable with a handheld meter, and can be made intrinsically safe for hazardous areas by limiting the energy the loop can deliver. Later attempts to add digital communication to instrumentation had to accommodate it rather than displace it, which is precisely what the Highway Addressable Remote Transducer protocol did by superimposing a frequency-shift-keyed digital signal on the existing analog loop without disturbing the analog value underneath.

Direct Digital Control and Its Disappointments

The process industries reached for computers earlier than discrete manufacturing did, because the economic prize was larger. A refinery run a fraction of a percent closer to its optimum for a year returns more than the computer costs.

The first installations were supervisory. In 1959, Texaco's refinery at Port Arthur, Texas, put a Ramo-Wooldridge RW-300 into service on a polymerization unit, in what is generally described as the first industrial process-control computer application. The machine did not operate the valves. It computed optimum setpoints and adjusted the analog controllers that did the actual regulating, an arrangement that limited the damage a computer failure could do: if the computer stopped, the analog loops kept holding their last setpoints and the plant kept running.

Direct digital control was the more aggressive step, removing the analog controllers entirely and having the computer close every loop itself. Imperial Chemical Industries installed a Ferranti Argus 200 at its soda ash plant at Fleetwood, Lancashire, in the spring of 1962, in what is described as the first large factory controlled directly by a digital computer. The economics were compelling in principle. One computer replaced a wall of single-loop controllers, control strategies became a matter of software, and the machine could compute functions no analog instrument could.

The problem was equally plain. Every loop in the plant now depended on one computer, and computers of that era failed. Plants that adopted direct digital control kept analog backup controllers on critical loops, which cancelled much of the saving, or accepted a risk that operating managers were reluctant to accept. Availability, not capability, was the binding constraint, and the industry spent the next decade looking for an architecture that offered the flexibility of digital control without concentrating the entire plant in a single point of failure.

1975 and the Distributed Control System

The answer arrived in 1975, and it arrived twice. Honeywell introduced the TDC 2000 and the Japanese instrument maker Yokogawa introduced CENTUM in the same year, independently, and Bristol brought out its UCS 3000 in that year as well. The idea common to all of them gives the category its name: distribute the control function across many small microprocessor-based units, each responsible for a modest number of loops, and connect those units to shared operator consoles over a digital communication link.

Distribution solved the availability problem directly. The failure of one controller took out the handful of loops it owned rather than the plant, and redundancy could be applied selectively where the process demanded it. The shared link—Honeywell called its version a data highway, and the term became generic—carried measurements, setpoints, and alarms to consoles that could display any part of the plant on demand. This was itself a substantial change, because it broke the fixed relationship between panel area and plant size. A pneumatic or electronic panelboard needed physical space for every loop, and a large plant produced a control room hundreds of feet long. A display could show any loop in the plant on a screen the size of a briefcase, and the control room shrank to a handful of consoles.

Something was lost with the panelboard, and operators noticed. A wall of instruments presents the whole plant at once, in the periphery of vision, and an experienced operator reads the pattern of it without looking at any single indicator. A screen presents one view at a time and hides everything else. The human-factors literature on process control has wrestled ever since with the consequences, chief among them the alarm flood in which a single upset generates hundreds of annunciations faster than any person can read them. Modern practice in alarm management is in part an attempt to recover what the panelboard provided for free.

The distributed control system also established a commercial pattern that still holds. A DCS is sold as an integrated system—controllers, input and output hardware, operator stations, engineering tools, and historian, all from one vendor and configured with one database. That is the opposite of the programmable controller market, where the controller, the operator interface, the drives, and the software were routinely bought from different suppliers and integrated by the customer or a system house. The two business models produced two different industries, and the technical convergence that came later did not erase the commercial difference.

What the Microprocessor Did to Both Branches

The microprocessor arrived in the middle of this history and reshaped both branches, though not in the same way.

On the discrete side, the microprocessor turned the programmable controller from a specialized logic engine into a small computer that happened to speak ladder. Early machines had implemented their logic in discrete or bit-slice hardware; microprocessor-based models could execute a much richer instruction set, and vendors added arithmetic, data movement, table handling, and eventually floating-point mathematics. Analog input and output modules appeared, and with them the ability to run PID loops inside a controller that had been designed for on-off logic. That capability began the erosion of the boundary between the two branches. Memory technology moved from magnetic core, which was expensive but retained its contents through a power failure, to semiconductor memory backed by battery or by electrically erasable devices, which cut cost and size sharply. Communication ports appeared, and controllers began to talk to one another and to computers above them.

On the process side, the microprocessor moved intelligence outward twice. The first move produced the distributed control system itself. The second, in the 1980s, put a processor inside the field instrument. A smart transmitter can linearize its own sensor, compensate for ambient temperature, hold its own calibration record and tag number, and report a diagnosis of its own health. Once the instrument had a processor, the analog current loop became the bottleneck, since it can carry exactly one number and nothing else. The pressure that produced the fieldbus movement came from that mismatch: instruments now had far more to say than a single current could express.

The personal computer changed the working practice of both branches during the 1980s. Programming terminals for early controllers were dedicated, heavy, and expensive, and a plant might own one. Once the programming software ran on an ordinary personal computer, every engineer could have a copy, program archives became ordinary files, and the cost of the tools stopped rationing who could work on the system. By the 1990s the personal computer had also become the standard platform for operator interface software and for supervisory control and data acquisition packages, which brought commodity operating systems onto the plant floor and set up, unnoticed, one of the central problems of the following decades.

The Third Line: Numerical Control of Machine Tools

A third strand of industrial control developed largely apart from the other two, and it started earlier.

The problem was the machining of complex curved surfaces, particularly in aircraft manufacture, where a shape defined by a table of coordinates had to be cut accurately and repeatably. John T. Parsons, with Frank L. Stulen at the Parsons Corporation of Traverse City, Michigan, worked on the problem from wartime experience building helicopter rotor components, and reached the idea of driving a machine tool from computed coordinates rather than from a template. The United States Air Force arranged funding in 1949, and the development passed to Gordon S. Brown's Servomechanisms Laboratory at the Massachusetts Institute of Technology in the spring of that year. The laboratory bought a surplus Cincinnati Milling Machine Company Hydro-Tel mill in 1950, fitted it with servo drives on three axes, and built a control system that read instructions from punched tape. The system was publicly demonstrated in September 1952 and described in Scientific American that month. Parsons received a patent on the underlying method in January 1958.

The first control systems were assemblies of vacuum tubes and relays that filled cabinets larger than the machine tool, and they were expensive enough that only aerospace work could justify them. Programming was the second obstacle. Producing tape for a complex part by hand computation was slow and error-prone, so the same laboratory took up the problem of describing parts in a language a computer could translate. Douglas T. Ross led the development of APT, the Automatically Programmed Tool language, beginning in 1956, and the project was announced publicly in February 1959. APT let a programmer describe geometry and tool motion in symbolic terms and let a mainframe generate the tape, and it stands as one of the earliest domain-specific programming languages of any kind.

The transition from numerical control to computer numerical control followed the same economics as the rest of this history. Once a minicomputer, and then a microprocessor, cost less than the hard-wired logic it replaced, the controller became a computer with the part program in memory. That change brought editing at the machine, canned cycles, tool-offset tables, and diagnostics, and it eliminated the fragile paper tape. Direct numerical control, in which a central computer fed programs to several machines over a link, appeared as a way to manage program storage before machine-resident memory became cheap.

Machine-tool control developed its own instruction language rather than adopting ladder logic, because its problem was geometric rather than logical. The G-code convention, standardized by the Electronic Industries Association in its RS-274 series, describes motion: a preparatory code selects a mode such as linear or circular interpolation, and coordinate words give the destination. The vocabulary is still recognizably the one established in the 1960s, and every desktop three-dimensional printer and hobby milling machine sold today inherits it. Modern machine controllers usually contain both worlds, running an interpolator for the axes and a ladder-based logic processor for the tool changer, coolant, doors, and safety interlocks.

From Vendor Highways to the Fieldbus Wars

By the early 1980s every serious vendor of industrial control had a proprietary network. Distributed control systems had their data highways; programmable controller vendors had their own local networks for connecting controllers to one another and to supervisory computers. Each was well engineered for its own products and incompatible with everything else, which suited the vendors and did not suit customers, who wanted to buy a drive from one supplier, a controller from another, and an operator station from a third.

The first widely adopted crack in that arrangement came from an unexpected direction. Modicon published the Modbus protocol in 1979 as a simple way to move data between its controllers and other equipment. Modbus is minimal to the point of austerity: a small set of function codes reads and writes four kinds of data, coils and discrete inputs for bits and holding and input registers for sixteen-bit words, with no notion of data types, engineering units, timestamps, or security. That minimalism is exactly why it spread. The protocol was easy to implement on any processor, it was published rather than hidden, and it asked nothing of the equipment it connected. Modbus became the lowest common denominator of industrial communication and remains, decades later, the protocol that two devices from unrelated vendors are most likely to have in common. Schneider Electric, which had acquired Modicon in 1997, transferred the rights to the Modbus Organization in 2004, formalizing what had long been true in practice.

The ambition of the fieldbus movement went far beyond moving registers. The goal was to replace the point-to-point analog wiring of a process plant with a single digital bus running past many instruments, carrying not only measurements but calibration data, diagnostics, and configuration, and, in the more radical proposals, hosting the control algorithm itself in the field devices so that a valve positioner and a transmitter could close a loop between them without a central controller. Achieving that required a standard, because the whole point was interoperability.

The standard did not arrive. The Instrument Society of America worked on the problem for years through its SP50 committee, while manufacturers and national research programs developed competing designs: PROFIBUS out of a German government-funded project, WorldFIP out of French work, INTERBUS, and a family of buses built on the automotive CAN physical layer including DeviceNet and CANopen. Each had a constituency with money and installed base at stake, and the International Electrotechnical Commission's attempt to reconcile them consumed most of the 1990s in a dispute that the trade press named the fieldbus wars. Draft standards were written and voted down. Reputations and market positions rode on the outcome.

The resolution, reached when the relevant IEC working group met in 1999 and effective from the start of 2000, was to stop trying to pick a winner. IEC 61158 became a large standard within which each surviving fieldbus occupies a numbered type, and the companion IEC 61784 defines communication profiles that specify how the pieces combine into a working system. The 2019 edition of IEC 61158 accommodates as many as twenty-six protocol types.

Whether this counts as success depends on what one wanted from a standard. It ended the war, it gave every serious protocol a legitimate international standing, and it let customers specify equipment against a recognized document. It did not deliver the interoperability that motivated the effort in the first place, because a device conforming to one type still cannot talk to a device conforming to another. The market rather than the committee did the consolidating that followed, and by the end of the decade the process industries had settled largely on Foundation Fieldbus and PROFIBUS PA, while discrete manufacturing settled on PROFIBUS DP, DeviceNet, and the Ethernet-based protocols then arriving. The episode is a useful case study in what happens when standardization is attempted after the market has already invested, rather than before.

Ethernet Reaches the Plant Floor

Ethernet was, for a long time, considered unsuitable for industrial control, and the objection was technically sound. Classic Ethernet used carrier-sense multiple access with collision detection on a shared medium. Two stations transmitting at once collided, both backed off for a random interval, and retried. The scheme is efficient under moderate load and completely nondeterministic: no upper bound exists on how long a given frame may take to get through. A control system that must sample a position and command a servo every millisecond cannot use a network that occasionally takes an unbounded time to deliver.

Two changes removed the objection. Switching replaced the shared medium with point-to-point links, so that frames from different stations no longer contended for the same wire, and full-duplex operation eliminated collisions between the two directions of a link. What remained was queuing delay inside switches, which is bounded and manageable rather than statistical. Meanwhile, the price of Ethernet hardware fell to a level no industrial network could approach, because it was being manufactured for the office and the home in volumes the industrial market could never generate. The economics became irresistible: the same cable, connectors, switches, and silicon that the information technology department already bought, at commodity prices, with a growth curve in bandwidth that no proprietary bus could match.

Foxboro had adopted Ethernet and the UNIX operating system for the higher levels of its I/A Series distributed control system as early as 1987, but the general move to Ethernet at the control level came around the turn of the millennium. Modbus over TCP appeared in 1999 and took the simplest possible approach, wrapping the existing Modbus request in a TCP segment on port 502 and changing nothing else. Other protocols followed the same path of encapsulating an established industrial application layer over standard Ethernet and the Internet protocols, EtherNet/IP carrying the Common Industrial Protocol used by DeviceNet, and PROFINET carrying the PROFIBUS application model. Where the application demanded hard real-time performance beyond what standard stacks could offer, vendors built protocols that modified the treatment of the frame itself, EtherCAT and POWERLINK among them, trading strict conformance to ordinary Ethernet behavior for cycle times measured in tens of microseconds. IEC 61784-2 gathered these real-time Ethernet profiles into the same standards framework that had absorbed the fieldbuses.

Adjacent industries produced their own Ethernet-based standards on the same schedule. Electric utilities developed IEC 61850 for substation automation, replacing the copper multicore cables between switchgear and protection relays with a network carrying sampled measured values and fast trip messages. In the following decade the IEEE 802.1 committee developed Time-Sensitive Networking, a set of amendments to standard bridging that adds scheduled transmission, time synchronization, and traffic preemption, with the aim of letting one converged network carry hard real-time control traffic alongside ordinary data. The direction of travel is unmistakable: after fifty years of purpose-built industrial networks, the industry is converging on the general-purpose one, adding the guarantees it needs as amendments rather than as separate technologies.

Standardizing the Languages, and Making Safety Programmable

Programming languages followed a similar path from vendor dialects toward an international standard, with a similar partial outcome.

Every programmable controller vendor had implemented its own version of ladder logic, and the differences were substantial enough that an engineer fluent in one manufacturer's system was merely literate in another's. Instruction sets, addressing schemes, timer behavior, and the handling of data all varied. The IEC responded with IEC 61131-3, first published in 1993, which defines a common software model and five programming languages: ladder diagram and function block diagram as graphical forms, instruction list and structured text as textual forms, and sequential function chart as a means of organizing a program into steps and transitions. The standard also defines a type system, a scheme for organizing code into program organization units, and the function block as the unit of reuse. PLCopen, an independent vendor association formed in 1992, has promoted the standard and developed the function-block libraries built on it, notably for motion control and for safety.

The standard did not produce portability in the sense a software engineer would recognize. Programs still require substantial work to move between manufacturers, because hardware configuration, addressing, and vendor-specific extensions remain outside what the standard fixes. What it produced instead was a common conceptual vocabulary, so that structured text means the same thing everywhere and an engineer's knowledge transfers even when the code does not. Sequential function chart in particular gave the industry a rigorous way to express the state machines that describe a batch process or a machine cycle, replacing the ad hoc step counters that ladder programmers had built by hand.

The second development of the period concerned safety. Safety functions—emergency stops, light curtains, overspeed trips, burner management—had traditionally been kept in hard-wired relay circuits, deliberately outside the programmable controller, on the reasoning that a wire and a positively guided contact could be inspected and trusted while software could not. The functional safety standards of the 1990s and after changed that reasoning by giving the industry a quantitative framework: IEC 61508 as the generic standard and IEC 61511 for the process sector define safety integrity levels with associated targets for probability of failure on demand, and they describe the architectural and procedural means of reaching them. Once failure could be quantified, redundant and self-checking programmable systems could be certified to integrity levels that hard-wired relay logic could not always demonstrate, and the safety programmable controller became an accepted product category. Emergency stop logic moved into software that is diverse, redundant, continuously self-tested, and independently assessed.

Convergence with Information Technology, and the Bill That Came Due

Every step in this history made the plant floor more like the rest of computing. Ladder logic became one language among five. Proprietary highways became Ethernet. Dedicated operator terminals became personal computers running commodity operating systems. Business systems reached down for production data, and by the 1990s enterprise resource planning software expected to schedule work directly against the equipment that performed it. The reference model that organized this—the layered hierarchy of ISA-95, popularly called the Purdue model after the university where its predecessor was developed—describes a stack running from field devices at the bottom through control and supervision to plant and enterprise systems at the top, with defined boundaries between the levels.

The convergence delivered real value and an unpriced liability. Industrial protocols had been designed in an era when physical access was the security model. A controller on a plant network accepts a command to change its program because that is what the protocol is for, and the protocols that carry such commands, Modbus foremost among them, contain no authentication whatsoever. Anyone who can send a packet to the device can operate it. That assumption was defensible when the network was a proprietary coaxial cable inside a fenced facility. It ceased to be defensible when the same function rode on Ethernet, through routers, past workstations that also read electronic mail.

The consequences arrived in a sequence that the field now treats as canonical. In 2000, a contractor who had worked on the supervisory control system for the Maroochy Shire sewerage network in Queensland, Australia, used insider knowledge and radio equipment to issue commands to pumping stations, releasing large volumes of sewage into waterways over several months; the case is cited as the first well-documented deliberate attack on a control system, and its lesson concerned insiders and radio links rather than the Internet. In 2010, the malware named Stuxnet demonstrated something far more sophisticated: it propagated through ordinary information-technology channels, identified a specific configuration of programmable controllers and variable-frequency drives, altered the controller program to damage the connected machinery, and reported normal values to the operators while doing so. It was the first widely analyzed instance of software written to break physical equipment. In December 2015, an attack on Ukrainian electricity distribution companies opened breakers and left roughly a quarter of a million customers without power, using remote access to the operators' own control software. In 2017, the malware variously called Triton and Trisis was found at a petrochemical facility, where it had targeted a safety instrumented system—the layer of last resort whose entire purpose is to shut a process down before it hurts anyone.

The industry's response has been standards, architecture, and a slow retrofit. The IEC 62443 series, developed from the ISA-99 work, defines security requirements for industrial automation and control systems in terms of zones, conduits between them, and security levels, and it addresses the asset owner, the system integrator, and the product supplier separately, because responsibility in this field is genuinely divided among all three. Practice has come to emphasize segmentation, monitoring, and rigorous management of remote access rather than a defensive perimeter, because the air gap that plant engineers long believed in rarely survives contact with a vendor support connection, a maintenance laptop, or a wireless bridge installed to solve a scheduling problem.

The underlying difficulty is not technical ignorance but the time constant of the installed base. A controller commissioned in 1998 may still be running a process in 2026, because it works, because replacing it means shutting the plant down, and because the engineer who wrote its program retired a decade ago. Security features cannot be patched into hardware that has no room for them, and availability requirements make patching itself hazardous in a way that office computing never has to consider. The history of industrial control electronics is a history of durability, and durability, which is the field's greatest virtue, is also the reason its security problem cannot be solved on the schedule that information technology is used to.

Conclusion

The through-line of this history is not a sequence of components but a sequence of relocations. Logic moved from wiring into memory when the Modicon 084 answered General Motors' 1968 specification, and the change was justified by the cost of the annual model changeover rather than by any theoretical advantage. Regulation moved from air pressure into current, then into software, and it took its conventions with it, so that the live zero of the 3 to 15 psi pneumatic standard survives in the 4 to 20 milliampere loop that still wires most of the world's process instruments. Computation moved to the center with direct digital control, discovered that centralization concentrates failure, and moved back out to the distributed control systems of 1975 and then to the field instruments of the 1980s. Communication moved from proprietary highways through a decade of fieldbus warfare to a standard that ended the war by admitting everyone, and then onto the Ethernet that the rest of computing was already buying.

Two decisions from the beginning of the story explain most of its character. The first was to constrain the technology to what the existing workforce could maintain, which produced ladder logic and gave the field a notation that has outlived every prediction of its demise. The second was the pneumatic live zero, an idea about failure rather than about function, which established the principle that an industrial signal must distinguish a valid reading at the bottom of the range from no reading at all. Both decisions treat the human and organizational context as part of the engineering problem, and both have proved more durable than any of the hardware that implemented them.

The unresolved question the history leaves is the one raised by convergence. Industrial control earned its reliability by being separate: separate networks, separate protocols, separate assumptions, separate people. Nearly every advance of the past thirty years has removed one of those separations, and each removal bought real capability at the price of exposure that the original designs never anticipated. Reconciling twenty-year equipment lifetimes with a threat environment that changes monthly is the defining engineering problem of the field's present era, and nothing in its history suggests that it will be settled quickly.

Related Topics