From Past to Present: How Open Architecture Drives Innovation

From the early roots of industrial automation to the open and interoperable standards that exist today, the evolution of industrial communication protocols has followed a gradual yet purposeful trajectory. Early systems were largely isolated, designed to control specific machines or processes without the capacity to communicate with one another. However, as industries grew more complex and the demand for efficiency increased, it became clear that the ability of different systems to share data could unlock significant advantages. As a result, today’s industrial environments are increasingly connected, adaptive, and capable of supporting complex operations to drive innovation.

Laying the Groundwork for Industrial Networking: PLCs and Modbus

Programmable logic controllers (PLCs) entered the automation scene in the late 1960s. As their popularity grew, the drive to develop communication pathways between PLCs began to rise. System designers started to see the advantages of having multiple devices communicate with each other.

In 1979, Modicon (now Schneider Electric) released the Modbus standard. Modbus is a client-server protocol that allows communication between intelligent devices. Modbus is still one of the most widely used protocols, with over 7 million users in Europe and North America. Its success is due to its openness, a theme that will lead to Industry 4.0.

However, Modbus’ limitations do not stem from the protocol itself. Instead, they result from most PLCs requiring more enhanced features, such as higher data transfer rates, improved real-time control, and larger and more complex data sets. This led to many PLC vendors creating their own proprietary extensions. For example, Siemens developed PROFINET/PROFIBUS to facilitate faster data rates, while Mitsubishi developed CC-Link for improved deterministic data collection and control. Many third parties created extensions like these, tying users to a specific vendor and reducing interoperability between systems.

The Evolution of OPC UA and Its Role in Industrial Interoperability

The rise of proprietary protocols made it difficult to develop a single application, as it would need to interface with each of these protocols. One of the first successful third-party extensions was Microsoft’s Object Linking and Embedding (OLE), specifically targeted for process control. This was the first OPC, or Open Platform Communication standard.

OPC was another method of client-server communication. Developed by Microsoft and released in 1996, many automation companies provided OPC servers to enhance interoperability, while others resisted the open platform in favor of proprietary products.

While OPC is an open standard, it is still reliant on Microsoft. As a result, there were no Linux-based servers. This became a growing problem in the late 1990s as Linux gained popularity among engineers. OPC Unified Architecture (UA) was developed in 2008 to address these concerns; OPC UA is platform independent. The original OPC was renamed “OPC Classic.” Platform independence was made possible through the use of secure internet protocols, such as TCP/IP.. Not only did this allow for Linux-based servers, but embedded systems could now be included in an integrated control system. OPC UA is still commonly used due to its interoperability and open protocol.

The Distributed Control System Migration Toward Open Solutions

Historically, PLCs were designed to control individual machines or operations. As systems became more integrated, the need emerged to manage entire facilities, rather than just specific machines. Therefore, DCS became the architecture that integrated all of these pieces into one system while still maintaining some local control of machines.

DCSs were typically designed by a single vendor for deployment across the facility. While integration and compatibility were nearly guaranteed, the system was not easily customizable after initial installation, and third-party support was non-existent. Ultimately, companies were locked into a particular vendor, reducing interoperability.

Figure 1. An example map of DCS. Image used courtesy of Wikipedia Commons

Frustrated at aging architecture and vendor-specific solutions, ExxonMobil developed the Open Process Automation Standard (O-PAS). The goal of O-PAS was to establish industry standards that improve interoperability and reduce the vendor-specific nature of DCS. Since the project began in the mid-2010s, O-PAS has tested several systems and established a forum for collaboration with other industries outside of oil and gas, such as pharmaceuticals, chemical processing, and others.

Once again, the pattern emerges: open, unified architecture drives innovation. Currently, companies can purchase DCS components from different vendors and operate them using O-PAS.

The Rise of MQTT In Data Communication

The need for efficient data communication grew throughout the 1990s. Sensors became more advanced and affordable, easing data acquisition and data-based decision-making. However, this expansion in data collection meant that a more efficient method of communication was necessary.

One major example is found in the oil pipeline industry. Numerous sensors are spread out over a large geographic area. Around this time, the Global Positioning System (GPS) was made available to the general public, and so the industry began looking at satellites as a means of communication.

Message Queuing Telemetry Transport’s (MQTT) development coincided with the increased use of satellites for communication. Satellite communication requires compact messages and low error rates. Polling PLCs over this kind of connection is expensive, both in terms of bandwidth and latency. Small message headers, a compact framework suitable for microcontrollers, and the ability to maintain continuous sessions all contribute to increased reliability.

With these criteria in mind, Andy Standford Clark (IBM) and Arlen Nipper (Arcom/Eurotech) developed MQTT in 1999. MQTT is a publish/subscribe protocol for data transfer. In this model, sensors publish data that can be accessed by multiple subscribers.

Figure 2. MQTT architecture example. Image used courtesy of Wikipedia Commons

By its very nature, MQTT is an open architecture. As it evolved, data could be published to the cloud and subscribed to by smartphones and tablets. Ultimately, MQTT was an important stepping stone to today’s Industrial Internet of Things (IIoT).

Leveraging Unified Namespace for Data Integration and Management

Automation morphed from a few, limited sensors and tiny data sets to the “big data” era, where sensors are inexpensive and plentiful. Data has to be treated differently than in previous times. Unified Namespace (UNS) is an architecture that acts as a real-time “Single Source of Truth”, meaning that all devices can publish or subscribe to data from this source. All data is standardized and communicated through a centralized namespace, making it platform- and vendor-independent.

Figure 3. UNS allows for custom architecture that interfaces with all plant hardware. Image used courtesy of Wikipedia Commons

UNS is also based on a publish/subscribe model. In this, PLCs, edge-of-network devices, manufacturing execution systems (MES), and all other hardware can interface with the UNS. Instead of connecting these devices to SCADA, SCADA is a consumer of data deposited in the UNS. This drastically reduces the complexity and cost of deployment and data management.

The Path to Industry 4.0

The emergence of open communication protocols has accelerated innovation and driven widespread acceptance of new technologies within the industrial sector. Historically, tech markets have been riddled with short-lived companies offering proprietary solutions that initially showed great promise, only to fade into obsolescence. This cycle left industrial players burdened with inflexible systems and "abandonware," severely diminishing return on investment and long-term viability.

Platforms like Inductive Automation’s Ignition have embraced an open philosophy at their core. Ignition is built on a foundation of complete interoperability and open architecture, enabling engineers and developers to design custom control systems. Rather than forcing users into rigid, pre-defined solutions, Ignition provides the tools and flexibility necessary to craft scalable, future-ready architectures. To explore more about what Ignition offers and how it supports modern industrial transformation, visit the Inductive Automation website.