Technology 32 industrial ethernet book 4.2018 Technology Windows-only process exchange, COM/ DCOM. Most systems and devices connecting to the IoT are not Windows-based devices. For example, take your smartphone. It’s likely an Apple or Android device, both of which run modified versions of the Linux operating system, where COM/DCOM process exchange does not exist. OPC UA has been released, but it’s merely a wrapper for existing OPC drivers built on Windows architecture. It requires design engineers to build an OPC UA client adapter into their products. And even then, modern network and internet assets such as web servers, databases, smartphones, and tablets do not speak OPC UA. PLCs, OPC servers, proprietary drivers, and protocol gateways quickly become a convoluted IIoT architecture. These layers of complexity not only require time, money, and specific domain expertise to install and maintain, but also the data being sent from the physical world has been converted by so many different pieces of hardware and software that data integrity can be jeopardized. Imagine the difficulty in provisioning and troubleshooting these IIoT systems. And then consider that today’s automation architectures often do not address information security. Sending data generated at the edge through so many layers of conversion opens up complex information security concerns as the data is transported to the cloud. Multiply these architectural issues across the billions of devices we expect to connect, and you see the communication challenge the IIoT faces. Flattening the IIoT architecture One way to simplify this complex IIoT architecture is to consider a different communication model. Most devices on a computer network today communicate using the request-response model. A client requests data or services from a server, and the server responds to the request by providing the data or service. This is the model company computer networks use, and it’s also the typical model for that biggest of all networks, the internet. Each client on the network opens a direct connection to each server and makes a direct request. A client doesn’t know when the data changes, so it sends requests at intervals (in automation, as fast as once per millisecond), and the server responds each time. This communication model works very well on a network where the number of clients and servers is not large. But the IIoT poses problems of scale. If each client must be connected to each server it uses and must constantly request and receive data, network traffic can quickly become an issue. Another model may be more effective in IIoT applications: publish-subscribe, or pub-sub. In the pub-sub model, a central broker becomes the clearinghouse for all data. Because each client makes a single lightweight connection to the broker, multiple connections are not necessary. Clients can publish data to the broker, subscribe to data going to the broker from other clients, or both. In addition, clients publish data only when it changes (sometimes called report by exception), and the broker sends data to subscribers only when it changes. The broker does not hold data but immediately forwards it to subscribers when it arrives, so multiple data requests are not necessary. These two factors, just one connection per client and data traveling only when it changes, shrink network traffic substantially, making pub-sub an effective communication model if you have many clients and many servers. Pub-sub can also be effective when it's difficult to set up a direct connection between a client and a server, or when the network is low-bandwidth or unreliable— for example, when monitoring equipment in remote locations. The pub-sub transport protocol MQTT is frequently mentioned for IIoT applications, especially when used with Sparkplug messaging, which was designed for industrial applications. Secure data communications using MQTT/ Sparkplug can help flatten IIoT architecture and more easily produce the results we need. Architectural changes As we’ve seen, for the IIoT to reach critical mass, internet protocols and technologies need to be driven into systems at the edge, where the physical and digital world connect. Layers of complexity must be removed from the communication process between digital systems and physical assets. Modern IIoT system architectures must be flattened, streamlined, optimized, and secured. Edge computing systems must easily and securely access the cloud through the open, standards-based communication technologies the internet is based on. That means: • Internet technologies like MQTT/ Sparkplug, TCP/IP, HTTP/S, and RESTful APIs —the dialect of the internet—must be built directly into devices at the edge. • Internet security technologies like SSL/ TLS encryption and authentication must be built in directly to edge systems. • Cloud-based systems must be able to make RESTful API calls to access data, or use a publish-subscribe communication model like MQTT/Sparkplug to get data from remote edge devices, without the layers of complexity and conversions that exist in industrial applications today. The power of interoperability The standard technologies used by the internet for transmitting information have created a cohesive system for communication. But we have not always had this cohesive system. Before the internet and the worldwide web, many different internet-like protocols and architectures existed. Computer systems all ran different operating systems, requiring different programming languages. Small pockets of interconnectivity existed, but for the most part systems were disconnected from each other. It was very similar to the way industrial systems communicate today, with the need for converters, adapters, and gateways. The internet was designed to allow input/output and information systems to share data through a common interface, removing layers of complexity and allowing for greater interoperability between systems designed and manufactured by different vendors. That’s why an Apple computer or Android phone today can send an email to a Windows computer: despite their incompatibilities, they speak the same internet languages. Today’s internet uses a common set of protocols, tools, and routines designed to make the transportation, acquisition, and analysis of digital information a seamless process, no matter what device you’re using. Although sensors and other physical assets installed at the edge may not have been designed with internet interoperability in mind, there’s still a massive opportunity to collect meaningful data from the huge installed base of existing things. But it will require a solution that understands both sides of the OT and IT convergence and that can: • Locally translate the physical world of currents and voltages (OT) into the secure communication protocols and languages the digital world (IT) understands. • Process and filter mountains of data, sending only the necessary data to the cloud for analysis. • Provide communications interfaces and processing power to maintain the closedloop, real-time control requirements of industrial applications. • Deliver all of the above in a package suitable for challenging industrial environments. Conclusion We’ve seen that edge computing is the sensor on-ramp to the IIoT. Once the communication, security, and computing technologies of the internet find their way into computing at the edge, the IIoT will begin to reach its potential. Internet technologies are available in some industrial systems today. And some vendors have already started bridging the gap between OT and IT by adding IIoT technology like MQTT and RESTful APIs directly into their controllers. The shortest path to a successful IIoT is to leverage the existing interoperability technologies of the internet in industrial automation products and applications. Technology report by Opto 22.
Industrial Ethernet Book 105
To see the actual publication please follow the link above