A Brief History of the Evolution of the Plant Floor Network Infrastructure

Have you ever asked a young automation engineer to crawl on the floor to search for the lost token because someone removed the terminating resistor from the token passing network? Maybe you were that young engineer? In the early days of automation networking, we relied on custom protocols and physical layers that were quite limiting. However, since then, manufacturing networks have evolved to look like those used in business systems and even in our homes.

Networking in the early days of automation was indeed constrained. There were no drivers, so that left programmers to write code for send and receive commands to access basic data from devices. Suppliers provided extensive documentation on their protocols, requiring custom programs to gather data.

These connections were often serial point-to-point or multi-drop serial, allowing one device to poll multiple others for data. In these arrangements it was not generally possible for two devices to access data on another device.

As the number of devices on the plant floor grew, manufacturers began offering custom multi-drop networks, enabling multiple devices to initiate communication with others on the network. Networks like DH+ or Modbus Plus facilitated peer-to-peer communication or multiple polling devices. However, with these advancements came increased complexity in the physical layer, necessitating adherence to rules like maximum distances, terminating resistors, and minimum cable lengths.

Data collection on computers or networked computers was achieved using specialized add-on cards and software drivers (no more custom code for communication), which were costly and restrictive in terms of device placement. To overcome this limitation, computers with these cards were connected to both the proprietary network and the office or business network or a standalone plant floor network. This marked the initial integration of Ethernet into automation. Keep in mind the term Operational Technology (OT) would not be coined until 2006.

With the decreasing cost of office networking hardware, there arose a demand for native Ethernet connections on automation hardware. Many questioned why they couldn't have network cards in their PLC racks, leveraging existing plant infrastructure managed by the IT department. When these network cards or native Ethernet connections became available, they were quickly embraced for their simplicity.

However, the rush to adopt new hardware sometimes led to improper network design and infrastructure investment. Mixing automation networks (OT) with business networks (IT) or improper Ethernet cabling installations by untrained personnel resulted in eventual problems. Even today, you can still find conventional office grade switches inside control panels. Cybersecurity implications were often underestimated, with many assuming they weren't a target or that specialized hardware was immune to cyber threats, a misconception that has been debunked by numerous cybersecurity incidents.

Today, most automation professionals and manufacturing companies have learned from past experiences, although legacy implementations still pose challenges. Wireless implementations undergo careful planning and hardware selection, while new wired Ethernet networks adhere to best practices with experienced installation teams. Proper separation of IT and OT networks and cybersecurity measures are now standard considerations.

Despite these advancements, some sites lag behind in upgrading to Ethernet or have only implemented temporary solutions for cybersecurity concerns. These sites could benefit from the expertise of automation professionals like Applied Control Engineering to address physical installation challenges and design networks that meet best practices.

Understanding the history of Ethernet in automation sheds light on the current landscape, even if you've never found yourself on the hunt for a lost token. 

Read more about ACE's network and design services here.