Summary: Long before anyone called it OT—or talked about edge computing—industrial controllers were already evolving toward both. Follow the progression from machinery control through networking, operating systems, and the Web to something we would eventually give a much simpler name: the edge controller.
In 1985, no one was talking about Operational Technology, or OT, but it was already everywhere. [1] We knew it instead as industrial automation, process control, instrumentation, and data acquisition—the collection of hardware and software used to monitor machinery and physical processes, collect operating data, and control equipment in real time. It included everything from sensors and instruments to ladder-logic controllers, distributed control systems, operator consoles, and the communications connecting them. These were the electronic systems that didn’t merely manipulate data; they interacted directly with the physical world. What began as machinery control would steadily acquire new capabilities, new connections, and new disciplines until the controller itself became something more.
The people working in industrial automation came from remarkably diverse backgrounds. A company might hire mechanical engineers, electrical engineers, controls engineers, instrumentation specialists, or experienced electricians, with much of the specialized knowledge then acquired on the job. Ladder logic programming became another tool alongside wiring diagrams and schematics, while feedback loops and PID control required an understanding of machinery, instrumentation, electronics, and control theory. These disciplines were already converging, each contributing its particular expertise to the common task of monitoring and controlling physical processes.
Even then, not everything that needed to be monitored or controlled was conveniently located nearby. The need to connect remote sensors had already driven the widespread use of 4–20 mA current loops, which could carry analog measurements over substantial distances with greater immunity to voltage drop and electrical noise than simple voltage signaling. [2] As equipment became more widely distributed, serial communications such as RS-232 and RS-422 extended that reach to other instruments and controllers, while modems could carry communications far beyond the facility itself. But distance introduced a new complication: communications delays, transmission errors, retries, and uncertain response times did not fit comfortably with control systems built around predictable timing. Determinism became harder to guarantee as the communications path grew longer and more complex. And so another discipline began to converge with the others—the communications engineer joined the team.
By the 1990s, another communications technology was finding its way into industrial automation: Ethernet. Where earlier serial connections generally provided dedicated point-to-point or limited multidrop communications, Ethernet greatly expanded the meaning of remote. Combined with the Internet Protocol, the communications network could become a shared resource, offering obvious economic advantages over dedicated wiring and communications links. Control systems could potentially utilize data generated at multiple locations, eventually extending remote to mean virtually anywhere. But sharing the communications path introduced variable traffic, congestion, and unpredictable delays that presented an even greater challenge to determinism. [3] Even providing an Ethernet port pushed controller hardware and software into a new realm of complexity. The collection of disciplines was growing again. The networking engineer had joined the team.
That complexity extended well beyond the Ethernet connector itself. Compared with simpler communications links, a network interface demanded far more attention in the background while the controller continued performing its primary control functions. Supporting the network was no longer simply another communications task. It required increasingly sophisticated code running behind the scenes.
The microprocessor changed the control system again. Unlike ladder logic, programming a microprocessor required an entirely different set of skills and languages. The engineers and electricians who understood the process and its controls were not necessarily equipped to develop the code that made these new devices function. Computer science and software engineering skills were now needed as well. Another discipline had joined the convergence.
The code embedded in these microprocessor-based controllers evolved into increasingly sophisticated operating firmware—the software responsible for keeping the controller functioning while application code performed the intended control. As systems grew more capable, that firmware had to manage interrupts and coordinate multiple threads of execution, allowing several activities to proceed seemingly at once. This made far more sophisticated controllers possible, but it also introduced another challenge to determinism: control code was no longer necessarily the only code competing for the processor’s attention.
The growing role of firmware brought significant advantages. Functions that once required changes to circuitry, components, or wiring could increasingly be changed in code. Products could evolve without redesigning the hardware, problems could be corrected after manufacture, and new capabilities could be added to equipment already in service. Hardware established what a controller could do; increasingly, firmware determined how it did it.
But programmability and networking came with a price. The processor now had responsibilities competing with the control application for execution time, while the network could present work at unpredictable moments. Maintaining deterministic control in the presence of those asynchronous demands became an engineering problem of its own. Inside the controller, something had to manage the growing collection of software competing for the processor’s attention.
As firmware assumed more responsibilities, it began to take on the characteristics of an operating system. Rather than simply executing a control program, the software could provide common services that applications could share: scheduling execution, managing resources, and providing persistent storage through a file system. Files were particularly useful because configuration, operating parameters, logs, programs, and collected data could survive beyond the execution of any one application and could be examined or changed without modifying the firmware itself.
Once those resources existed, there was obvious value in reaching them remotely. FTP provided a practical way to move files into and out of the controller, while a command-line interface gave engineers a direct means of configuring, diagnosing, and interacting with a running system. Telnet extended that command line across the network. [4] With FTP and Telnet, the network port was no longer simply carrying measurements and control messages. It provided access to the controller itself, elevating what had been embedded operating firmware into something much closer to a complete computing environment.
By then, the network connection was already carrying control protocols while FTP and Telnet provided administrative access to the controller itself. The rapidly emerging World Wide Web captured everyone’s attention. HTTP/1.0 offered a simple, standardized way to retrieve documents across a network, and an inevitable question began to be asked of anything with an Ethernet port: Can it do the Web? [5] Suddenly there was another compelling reason to open a network port.
At first, the value of a Web server in an industrial controller was not nearly as obvious as that of the network itself. Ethernet could carry control traffic, FTP could move files, and Telnet could provide remote access to the command line. Those capabilities addressed recognizable engineering needs. But did a controller really need to serve pages to a browser? As the World Wide Web rapidly became familiar, however, the answer increasingly became: Why not?
At its simplest, a Web server did remarkably little. A browser requested a file; the server located it and sent it back. If that file contained HTML, the browser interpreted the markup and presented a formatted page containing text, images, links, and eventually forms. The sophistication of the experience was largely contained in the files being served; the controller itself needed only to understand HTTP well enough to deliver them.
Static pages could describe the controller, provide documentation, and present instructions, but they could not answer the question that made Web access truly interesting: What is the controller doing right now? To do that, information from the running control system had to find its way into the page being served. The Web server could no longer simply deliver a file unchanged; it needed a way to generate content dynamically from the current state of the controller.
The first step toward dynamic pages did not require a scripting language. A Web server could recognize special tags or placeholders within an HTML file and replace them with current values as the page was being served. For a controller with a well-defined collection of inputs, outputs, and operating values, this provided a relatively simple way to present live status in an otherwise static page. The browser still received ordinary HTML; the difference was that the controller had helped create it.
Simple substitution could display status, but more sophisticated interaction required logic. Server-side scripting allowed the controller to make decisions while constructing a page, conditionally generate content, process information submitted by the browser, and initiate actions in response. The Web interface was becoming bidirectional: it could not only show what the controller was doing, but allow someone using a browser to change what it was doing.
There was also a less technical measure of success. Once a control system was working reliably, showing the boss that he could open a browser and see for himself what it was doing could produce an entirely different kind of feedback. That smile was priceless. Suddenly Web access was no longer a novelty looking for a reason to exist.
That smile represented something more significant than a successful demonstration. The controller was still quietly performing the job for which it had been installed, but now others could independently look in on it. A manager could check production from an office, someone could bring up its status during a meeting, and employees elsewhere could monitor the process without becoming part of the control process. The controller had begun serving two worlds: the physical process immediately around it and a growing collection of people and systems beyond it.
By the turn of the century, the collection of technologies and disciplines surrounding industrial control had produced something difficult to describe with the traditional vocabulary. It was still a controller, expected to monitor and control physical processes reliably and deterministically, but it was also an embedded system with an operating environment, network connectivity, remote administration, and a Web interface capable of exposing the process to people and systems elsewhere. At the time, terms such as network-enabled embedded systems were used to describe this emerging class of device. [6] What had emerged was approaching something that, years later, would acquire a much simpler name.
The need for such a device was no longer theoretical. By January 2001, a Navy SBIR proposal from INTEG was already describing the need to connect factory-floor automation and control systems through TCP/IP networks and even the Internet. INTEG was developing small embedded devices specifically intended to connect analog and digital I/O to desktop Web browsers. The terminology was different, but the requirement is immediately recognizable today: place computing and communications capability close to the physical process, make its data available to the network, and allow that device to continue performing useful work locally. The need for the edge controller had arrived well before the name.
What ultimately makes such a device an edge controller is not any single technology inside it. It is the role that the device has come to perform. The controller remains close to the physical process, where it can monitor inputs, operate outputs, and make decisions locally. At the same time, it presents that process to a much larger networked world. People and other systems can observe it, collect data from it, and interact with it without becoming part of the control loop itself.
That distinction matters. The control system does not surrender its primary responsibility simply because others can now reach it. The machinery continues to operate locally and deterministically whether or not anyone is watching from a browser, collecting data elsewhere, or showing the system off in a meeting. The controller has become a boundary between the physical process and everything beyond it. That boundary is the edge.
In 1985, we did not call any of this Operational Technology. We had machinery, sensors, instrumentation, controllers, and people from an assortment of engineering disciplines trying to make physical processes behave. As new requirements appeared, communications, networking, and software expertise converged around that original task. The controller accumulated capabilities because those capabilities were useful, not because anyone was working toward some future technology category.
By the turn of the century, the result could control the physical world locally while independently making its data and capabilities available to people and systems elsewhere. We used terms such as network-enabled embedded systems, or whatever terminology best described the immediate application. Years later, edge controller would provide a remarkably good name for what had emerged.
Perhaps that is the more interesting lesson in looking back. Technology does not always arrive when we give it a name. Sometimes the name arrives after engineers have already spent years building it.
>>
References