Internet of things (IOT) and Industrial IOT (IIOT) do not specifically identify Ethernet in the names themselves. but there is no disputing that it is a key enabler to making the concepts even possible. Unfortunately, like so many things, the majority of people using the technology do not have any idea of how it works. We as automation professionals are not so lucky, since not only do we have to design, build and maintain these systems, we must also do so without disruption to service, making maintenance and upgrading a challenge.
To be able to connect to anything, anywhere, it’s also a foregone conclusion that at least part of the network will have to be wireless. The form of wireless network will be largely driven by bandwidth requirements and distance between nodes. For higher bandwidth and intermediate distances, wireless Ethernet (Wi-Fi) will be part of the equation.
Most of us now take wireless Ethernet for granted, and expect to be able to access it with sufficient bandwidth almost anywhere. Wireless has become so reliable in the non-industrial setting that many houses and smaller offices are no longer running copper (i.e. CAT5e cable)—unless, of course, it is power over Ethernet (PoE) and the device power supply, simply connect everything to the Wi-Fi network. A good example of this is the streaming media player I purchased over holidays that only supports Wi-Fi, with a USB connection for power only.
Regrettably, the plant environment, with its fixed and mobile “canyons of steel,” EMI/RFI emission sources due to medium- and high-voltage equipment, high humidity, and high and (as we are finding out this year) low temperatures is not quite as friendly as the family room at home. Fortunately, the latest 802.11 standards now support and take advantage of multipath routing, so the effect of those steel canyons has reduced impact on overall reliability.
Of course, control systems must have end-to-end connection with the right data going to and from the right place at the right time, over what is inherently a non-deterministic network. Making all the packets and information move across the systems is the responsibility of higher layers of the networking framework. However, just like any control signal, if Ethernet, the physical layer, is not reliable, the protocols and messages will not be reliable.
The role of system architect is therefore becoming increasingly important to ensure that new system designs incorporate the necessary features to provide the required end-to-end connectivity between the various nodes and protocols. When integrating a new and legacy system, understanding the potential interactions between different network elements makes this role even more critical. The majority of system architects understand business networks and the systems associated with them, however, because of the relatively small number of control networks, it is unlikely that an individual other than one employed by the control system supplier will be able to consider all the system nuances to deploy a rugged reliable network.
The resulting system must be designed for heavy traffic loads between certain nodes (i.e. updating HMI) as well as slower analog or serial connections and gateways, along with, of course, reliability and cybersecurity.
A well-designed system architecture must perform for present as well as anticipated future loading. As we know, estimating future loading is a “best guess” situation, because the amount of data flowing continues to grow exponentially – not only in the business world, but also within the “closed” control system environment.
The architect must also stay abreast of constantly evolving standards and capabilities of new software, hardware, equipment and vulnerabilities. Considering all this, is it any wonder that if it’s possible to use Ethernet and IP-based systems to move all the data packets about, they’ll remain as the common denominator?
Ethernet is not a protocol. It is, however, an enabler for not only today’s control systems, but also those of the foreseeable future; where, if the vision of the Open Process Automation group is correct, the control system (other than the edge device signal processing equipment) will all be based on software modules communicating to each other over Ethernet and IP-based networks.
