Page 36

Industrial Ethernet Book 103

Technology capabilities to take existing equipment and systems to create a robust IIoT infrastructure. Depending on specific needs, be it an edge gateway, an MQTT server, or enabling MQTT functionality, the Cirrus Link MQTT modules will create a solid solution. Ignition architectures with MQTT are comprised of several elements: edge devices, MQTT servers, and MQTT clients. Each of these elements plays an important role in your ability to take a legacy system and migrate into a cutting-edge SCADA system. Edge-of-network devices The edge-of-network device is the first important component of the MQTT architecture. Edge devices which include edge gateways (also known as directors) allow you to communicate to legacy devices such as PLCs and RTUs, to collect tag and state data, convert it to MQTT, and publish that data onto an MQTT server. Edge gateways, along with MQTT, allow you to decouple devices from applications, thus improving bandwidth usage. There are four methods for implementing an edge-of-network device. The first method is to use a dedicated edge gateway to bridge legacy devices to new devices or to an MQTT server. The second method is to install a brand-new edge device that natively communicates via MQTT. Several manufacturers are now embedding the Sparkplug specification onto their devices, allowing for direct communication with an MQTT server. The third method is to use the Cirrus Link MQTT Transmission Module on an Ignition server. The module turns the server into an edge gateway, allowing you to collect and publish edge data to the MQTT server. The fourth method is to use Edge MQTT, a limited, lightweight solution that turns touch panels, client terminals, or virtually any embedded PC or field device into an MQTT-enabled edge gateway. MQTT servers The second piece of the architecture is the MQTT server, often called the broker. This is where the message-oriented middleware (MOM) resides. All edge-of-network devices in the MQTT architecture publish MQTT tag and state data to the MQTT server. The MQTT server then enables MQTT clients to securely connect and subscribe to the device’s published data. Since MQTT is an open standard, there are many companies making their own brand of MQTT servers. For example, there’s AWS IoT from Amazon, Azure IoT Hub from Microsoft, and Chariot from Cirrus Link, as well as HiveMQ, CloudMQTT, Red Hat AMQ, and VerneMQ. There are many options to choose from, whether it be a locally hosted or cloudhosted solution. As a best practice, use the Cirrus Link MQTT Distributor Module. The MQTT Distributor Module is launched by the gateway and is a small, self-contained MQTT server. It provides you with a complete MOM solution that is best suited for an on-premise MQTT infrastructure with a limited number of edge-of-network devices. The module provides rapid development and is ideal for situations where communications are restricted or costly. It’s designed to simplify and speed up the process of getting a complete MQTT infrastructure going. It’s also very effective at increasing data throughput for high-performance plant-floor solutions. MQTT clients The third piece of the MQTT architecture is the MQTT client, which connects to the MQTT server and subscribes to one or more topics of information, bringing that data right into an application. While there are many MQTT client tools available, it is recommended to use the Cirrus Link MQTT Engine Module for Ignition. The MQTT Engine Module is the key component that enables Ignition to act as a native MQTT citizen. The MQTT Engine allows the platform to communicate bidirectionally with MQTTenabled edge-of-network devices via the MQTT server, which can be sent securely all the way down to the device. It takes data from the MQTT server and injects it into industrial SCADA applications. Now that we have covered all the available options, resources, and best practices, it is time to look at how to bring everything together. In the last section, we’ll take a look at the best migration strategy to take when implementing an IIoT infrastructure. Optimal IIoT migration strategies Migrating to a new IIoT infrastructure takes time and careful planning. As we discussed in the first best practice, you must approach the migration transition slowly. There are many pieces involved with an IIoT infrastructure and when you factor in the added complexity of a legacy system, you need a slow transition to ensure that downtime is minimized. Many organizations face a Catch-22 when implementing a SCADA infrastructure upgrade. Current SCADA solutions still use the poll-response protocol drivers that are directly connected to field devices over a communications channel or a TCP/ IP network. Because of this, they cannot replace or upgrade the poll-response protocol on the SCADA host until the new protocol is in the field and, vice versa, they cannot upgrade devices until they have a new protocol on the SCADA host. Best way to migrate systems There is a proven four-step migration strategy that uses the Ignition platform, the MQTT Engine Module and an edge gateway. The four steps are installing an edge gateway, starting the poll-response, enabling MQTT local masters, and switching over to the pure MQTT solution. Step 1: Install and set up an edge gateway, such as an Elecsys Director. The edge gateway acts as a TCP/IP cellular, VSAT, or Ethernet IP endpoint. In this step, you are setting up the edge gateway to communicate with PLCs or edge devices using the poll-response protocol. The edge gateway then connects to an MQTT server using a TCP/IP link and sends collected data via the MQTT protocol. Step 2: Start the conventional poll-response by connecting to the internal terminal server and keeping poll-response going. You will enable both the serial and Ethernet connections between Ignition and the field devices using the edge gateway. Step 3: Enable MQTT local masters. Once the conventional poll-response protocols have been enabled, legacy SCADA users can start to see the conventional use of Ignition. The resulting parallel communication system can compare values coming in from the conventional poll-response and publishsubscribe of MQTT. Step 4: The system is now ready to switch over to a pure MQTT solution. Once the organization is happy with the final, pure MQTT infrastructure, you can remove the OPC poll-response components. This will greatly simplify the network topology and creates a clean and pure MQTT solution. Furthermore, since the solution provides a plug-and-play SCADA system, it is easily scalable and can quickly grow with your organization’s needs. Best practices recap To recap the best practices for a successful IIoT implementation, we recommend: • Planning the strategy and adding to your infrastructure in pieces, giving opportunities for testing and making sure everything is working. • Choosing MQTT as your IIoT messaging protocol since its feature set is ideal for an IIoT infrastructure. • Leveraging stateful awareness to help maintain the health of your IIoT infrastructure. • Employing a redundant strategy throughout your solution. • Using advanced technology in the MQTT engine, transmission and distributor modules to simplify integration. • Finally, following the optimal migration strategy to ensure a smooth transition to a new IIoT infrastructure. The best practices discussed in this article are proven methods for success. Even with a legacy system, the solutions offered reduce friction and offer the resources needed to move an existing installation into a state-ofthe art IIoT and SCADA solution. Technology report by Inductive Automation. 36 industrial ethernet book 11.2017


Industrial Ethernet Book 103
To see the actual publication please follow the link above