Industrial controllers: past, present, future
Increasing technology integration, cross-pollination and connectivity have shaped the development of programmable logic controllers (PLCs), programmable automation controllers (PACs) and today’s edge controllers, indicating how to invest for the future.
Since the advent of the programmable logic controller (PLC), automation controllers of all kinds have made their way into industrial applications, including programmable automation controllers (PACs) and today’s edge programmable industrial controllers (EPICs). Users have many options in terms of cost, footprint, input/output (I/O) density, fieldbus compatibility, communication, programming options, and processing speed with competition among vendors looking to establish supremacy.
While it’s generally true diversity is healthy for the market, it also can be a source of frustration for engineers and end users. Selecting a control platform is often a long-term investment and carries related overhead like training and support contracts. Decision-makers want the reassurance they are putting their money to work in the right way.
Rather than taking sides on the issue, however, it’s better to look at how the industry arrived at this point. What were the trends that drove the evolution of these different control solutions? How are these trends at work now? And how should users invest their automation dollars in the future to be sure they make winning bets?
Controller and I/O system integration cycle
An obvious pattern that emerges from studying past decades of progress in automation control is how successive generations of a particular technology fed the development of new I/O and control options.
For example, when the first I/O systems were developed, the standard for control and sensing from the field relied on electromagnetic and pneumatic components, which were subject to physical degradation that limited their lifespan. Compact, low-voltage components, like solid-state relays, drove users to demand more options for integrating I/O directly into their systems. This led to the first modular I/O around the same time electronics companies were bringing high-tech computing into the mainstream. The sensitive electronics in those systems meant they needed to interface with external I/O in order to interact with the real world. This led to the first serially addressable I/O racks, which were an alternative to the chassis-based I/O used in PLCs.
Going from specialized, individual I/O devices to modular I/O to bussed I/O exemplifies a pattern repeated over and over in industrial control. Later generations of control platforms continued to combine and embed I/O processing circuitry. Individual modules expanded from a single I/O channel to 32 channels, and now I/O comes built into PLCs and other standalone devices. In some cases, I/O channels can be configured to accept a variety of different signal types on a channel-by-channel basis.
This pattern demonstrates how innovation diffuses through the industry: Over time, an individual innovation becomes modularized, partnered with other technologies, and then embedded into those technologies to become part of a new cycle of innovation.
For PLCs and PACs, this pattern has given us smaller controller and I/O module footprints. It has yielded greater computing power “per square inch” as math and programming co-processor functions have been incorporated directly into control boards, as well as other devices, like I/O, transmitters, and network gateways. The same pattern manifests in the propagation of new embedded communication interfaces and protocol standards into controllers over time.
Interwoven with the integration cycle is the parallel trend of cross-pollination: technology innovations from outside the industrial control market making their way into controllers. Continuing with the history of bussed I/O, we can see how this trend also led to the development of new controller options.
Serially-bussed I/O led to parallel I/O busses and other solutions that let mini- and microcomputers interact with I/O. However, this also spurred the idea of an independent I/O communications processor, which decoupled the I/O from the computer, allowing anything with a communications port to interact with it.
As I/O modules and I/O processors improved, these early hybrid controllers were able to offer analog signal processing options, which was something found only in distributed control systems (DCSs) at that time. Since ladder logic — used by PLCs as a programming language — wasn’t designed to handle analog data formats, this led to new programming languages for hybrid controllers.
Then low-cost IBM-PC alternatives began to flood the market. Since PCs were still the primary control option for hybrid systems at the time, this created concerns about reliability. It made sense for vendors to develop an industrially-hardened alternative, which crystallized the I/O, networking and programming components of early hybrid solutions into a system, which would later be called a PAC. Since PACs used the same processors that powered PCs, they were able to offer a feature set that filled a niche between low-cost, PLC-based discrete control and high-dollar, DCS-based process automation.
It’s worth noting how innovations from the high-tech business and consumer PC market led to opportunities for industrial control evolution. This trend has accelerated as the operations technology (OT) domain has merged more and more with the information technology domain. It appears, for example, in the wave of mobility solutions entering the market in recent years. It’s also manifesting in the push for Big Data, cloud analytics, and machine learning (ML) support, which are technologies that originated outside of industrial automation.
At the same time that control technologies have been condensing and mingling with those from outside markets, they have also become more connected. Control systems have evolved from collections of individual components to integrated intelligent networks. These trends hint at the direction the industry is heading toward, but it wasn’t always this way.
During a period known as the Fieldbus Wars, vendors had taken the concept of serial-bussed I/O and run with it through various communications media and protocols, each attempting to establish their combination as the dominant standard. During this time, Ethernet was proposed as an alternative, leading to the birth of even more standards for I/O control. Ethernet also introduced another evolution of the communication model in automation because of the way it allowed for integration with business systems. Rather than a monolithic control network, automation became part of a network of networks. With TCP/IP becoming the standard for the worldwide web, the introduction of Ethernet for control paved the way towards the Industrial Internet of Things (IIoT) and other Industry 4.0 goals, which rely on highly connected, distributed systems.
The evolution from component to serial bus to interconnected networks isn’t just about faster communication. The trend is toward greater connectivity between disparate systems. Where standards and protocols facilitate broad communication, they have found broad adoption in industrial control platforms.
Current examples include the advent of edge controllers, which combine real-time control with web-oriented technologies for native interaction with business applications and cloud-based systems. This trend also is seen in the growing support for machine-to-machine (M2M) communication standards such as ￼messaging queuing telemetry transport (MQTT) and OPC-UA.
Three tips for future controller use
As the trend toward deeper technology integration, greater cross-pollination between industries, and greater connectivity between devices and systems continues into the future, where will it take us? How should engineers invest their budgets to ensure they can ride that wave? Based on the patterns explored here, we can derive guidelines that can help companies select the right control technologies to do that.
1. Focus on design over features
Understanding that technology will continue to improve over time, becoming more tightly integrated and embedded, it makes sense to prioritize investment in the aspects of a control system that cannot be changed easily or quickly. Engineers need to emphasize the control system architecture over the whiz-bang features of the moment. Processors will get faster and I/O will get denser, so buying into these features at the cost of being locked into a network layout, data exchange format, communications protocol, or vendor-specific infrastructure that limits design options down the line is ill-advised. It creates dependencies that are difficult (read: expensive) to renegotiate later on.
2. Look for outside innovation
If engineers are looking to design systems that will evolve over time to keep up with the pace of digital transformation, reduce maintenance and rework, and impress end-users, they can remember the technologies that define the future have often come from outside the industry. When it comes to selecting vendor partners, decision-makers will get the most long-term value working with companies that are comfortable going outside of their lane. Working with a vendor that is only focused on producing the same thing a little faster or cheaper will leave users behind the times.
3. Keep an “open” mind
It’s clear from technology’s storied past that squabbling over market share for proprietary technologies stymies innovation while supporting open standards raises the ceiling on what is possible for everyone. With increasing connectivity as a goal of Industry 4.0, engineers need to invest in technologies that create the opportunity for disparate systems to work together, rather than creating monolithic systems that require additional work to open up. For the individual engineer, supporting open standards also increases the interoperability, and therefore applicability, of their own innovations.
Hopefully, the industrial market continues to provide manufacturers with a broad portfolio of options for industrial control in the future, which can open new possibilities for designers and end users. By voting with our dollars, manufacturers can steer the industry in the direction of those innovations that produce the best outcomes for everyone.
Josh Eastburn, director of technical marketing, Opto 22. Edited by Chris Vavra, associate editor, Control Engineering, CFE Media and Technology, email@example.com.
Keywords: PLCs, PACs, Edge controllers
Programmable logic controllers (PLCs) and programmable automation controllers (PACs) are converging as technology advances.
Industrial controllers are becoming more connected and useful on the edge of applications thanks to the Industrial Internet of Things (IIoT).
While they’re converging, companies need to know the difference to make the right choice for their applications.
What is the next step in the industrial controller’s evolution and what impact will it have on engineers and manufacturers?
More about MQTT:
When MQTT was adopted as a standard by OASIS and then ISO, the official name was rendered as Message Queuing Telemetry Transport, but this is a misnomer since MQTT does not employ a message queue. The MQ in MQTT actually dates back to its development under IBM as part of its Websphere MQSeries product line. It is, therefore, appropriate to render it as MQ Telemetry Transport. However, given that MQTT has moved well beyond the bounds of telemetry data, the official name among the user community, and according to the Eclipse managing foundation has, for several years, simply been MQTT with no expansion. So don’t worry about understanding how the message queue works in MQTT. There isn’t one.