Page 35

Industrial Ethernet Book 103

Technology 35 reliable, and contextual. Most enterprises still depend on legacy poll- response communication protocols to be able to know the state of the network connection between devices and the SCADA system. Un- fortunately, devices must be polled frequently to determine whether or not a network connection is good, which can put a strain on the system. Stateful awareness in MQTT MQTT has stateful awareness built in and it is the only stateful architecture available. It is designed with a “last will and testament”: if the device stops working and falls off the network, then the MQTT server will publish a “death certificate” and the device will be marked as being unable to publish data. On a larger scale, with thousands of devices connected to the MQTT server, it is important to know within seconds the state of each device: whether it is online and ready to publish data or if it is unavailable. Let’s say that you’re using the Ignition platform with an MQTT server and an MQTT client. When a device connects to an MQTT server, it registers its state and then it registers its last will and testament. Ignition and the MQTT client will know that the devices are online and will deliver information if and when it changes. In the event of hardware failure or environmental issue, the MQTT server will publish the fact that the device is no longer available. In Ignition, those tags are represented as stale data and the device is marked as unavailable. When the device comes back online, it republishes its birth certificate. The MQTT client knows that the device is available, and Ignition shows the updated tags and the device’s availability. Awareness improves processes Stateful awareness is a subtle but powerful feature of MQTT. There are many MQTT implementations that are stateless, but for SCADA implementations, stateful awareness is essential. MQTT uses reporting by exception (RBE), which is made possible by stateful awareness. Data is only sent when there are changes to the state of the device or when data values change, which reduces the amount of useless data taking up bandwidth resources. Knowing the device state is valuable since it helps to provide context to the data. Operators, especially, can keep track of devices and quickly pinpoint any trouble spots without having to send a technician out to a location to verify an issue. On the organizational level, data can be verified to be up-to-date and accurate. Ways to implement MQTT Now that we have established that MQTT is the ideal communications protocol for your IIoT system, our next step is to look at ways to start implementing MQTT. There are three main strategies to transition your SCADA system over to MQTT: converting existing devices to MQTT, enabling existing devices to communicate with MQTT platforms, and embedding MQTT directly onto devices. The first strategy is to convert legacy devices to use MQTT. An edge-of-network device is designed to communicate with legacy devices using their native protocol. The edge gateway then connects directly to an MQTT server. The poll-response is moved to the local level, and data is converted to MQTT and published to an MQTT server. This strategy is ideal for current installations using legacy equipment and traditional poll-response protocols. The second strategy is to enable edge devices to communicate with MQTT platforms using the Sparkplug specification from Cirrus Link Solutions. Cirrus Link provides opensource 11.2017 industrial ethernet book software, tools, and the Sparkplug reference specification to allow applications, sensors, devices, or gateways to seamlessly integrate with Ignition using the Cirrus Link MQTT modules. The third strategy, which is appropriate for newer installations, is to use devices with MQTT already embedded into them. Manufacturers have begun to offer devices that have the Sparkplug specification enabled, making them ready to install and connect to your MQTT server and to the rest of your IIoT implementation. In this strategy, these edgeof network devices do not require a separate edge gateway since the MQTT functionality is already built in. Now that we have established the importance of stateful awareness and how to implement MQTT, we can turn our attention to edge-of-network devices, which act as a bridge between PLCs and the MQTT server or “broker.” This capability makes them a critical component in the MQTT architecture and IIoT infrastructure. Redundant edge gateways Regardless of whether a location is local or remote, connectivity can pose a major challenge. Local locations tend to rely on hardline connections to transmit data. Remote locations rely on wireless services such as cellular or satellite. In either case, the main communications conduit could potentially fail. As a best practice, especially for missioncritical systems, make sure to integrate failsafes and install redundant edge gateways. Edge devices and gateways Edge gateways are a type of edge-of-network device. Edge-of-network devices are a key component in MQTT architectures, providing an entry point into an enterprise core network. Edge devices can include routers, routing switches, integrated access devices (IADs), multiplexers, and a variety of metropolitanarea network (MAN) and wide-area network (WAN) devices. An edge gateway can be thought of as a combination of a router, network box, terminal server, and a net- work arbitrator. As their name suggests, edge gateways live at the outermost edge of a SCADA system. With an abundance of legacy PLCs and devices still using poll-response communication protocols, edge gateways act as a bridge to connect to these legacy devices, converting them to MQTT, enabling them to communicate to MQTT servers, and allowing enterprise networks to access the data. Redundant edge gateways Putting in failsafes is a must for the SCADA transition. The data you’re collecting and sharing is important and any failures can lead to negative effects on your organization. Because edge gateways are critical, adding a redundant edge gateway is a best practice. It is also highly recommended that you add redundancy to your IIoT infrastructure as a whole. Make sure there isn’t a single point of failure that can cripple your operation. You should add redundancy at every point in the system where data is published. Make sure you have edge gateways that are able to communicate via cellular and satellite. Set up multiple MQTT servers and use all available channels to make sure data is available at all times. Always have backup systems Redundancy is crucial for your IIoT implementation, especially when you have installations in remote geographical areas. Having a failsafe ensures your data is safe and available when it is needed the most. If there are system failures, having backup systems ensures smooth operation and minimizes downtime, which could save your organization thousands or millions of dollars. The key to a redundant architecture is to take advantage of multiple communication channels. Having a hardline system is always preferable, but having a wireless backup such as cellular or satellite ensures your system has continual coverage to ensure your valuable data is safe and your system keeps running smoothly. Next, we’ll discuss options for the edge devices, MQTT servers, and MQTT clients in your MQTT architecture. Use MQTT modules for IIoT apps MQTT is an incredible communications protocol that is ideal for your IIoT infrastructure. Yet, you still need an industrial platform that fully takes advantage of MQTT and brings IIoT together. With Cirrus Link’s MQTT modules, Ignition becomes the ideal IIoT platform. The Cirrus Link MQTT modules leverage Ignition’s rich feature set and superb SQL database


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