Q&A with Red Lion on field-to-cloud networking

In response to Control's questions about field-to-cloud networking for the "Alternate Paths" cover story in the June 2017 issue, two experts from Red Lion Controls provided some thorough and comprehensive responses. They are Colin Geis, product management director at Red Lion, and Teresa Benson, product marketing manager at Red Lion.

QUESTION: What's the state of the most prevalent methods for transferring process data from sensors and field instruments to PLCs, DCSs and higher-level MES, computing, Internet- and cloud-based solutions?

GEIS: We see three common ways to collect data, and a best method hasn’t yet emerged. Each method has a pro/con balancing point, and customers will likely deploy a combination of them.

The most prevalent method is still employing powerful protocol gateways to collect data from PLCs, RTUs, DCSs, etc. While this can be the easiest method to collect data, the challenge is that typically the only data collected through these processes are used for control applications. So any data that could be collected by one of the protocol gateways is typically limited.

Another method is to tap directly into existing sensors deployed in the process. This method doesn’t require existing controllers to be reprogrammed. The sensors themselves would simply split the signal, and transmit the same data to two different data devices. One of the devices would be an IIoT gateway that would securely transmit the data to a cloud environment. The challenge with this method—similar to the first method—is you're relying on existing sensors that were likely deployed for a control application. In reality, the IIoT is about collecting a lot of data to measure differences in the process, not just the end results.

The final method is an overlay with new sensors strategically deployed in a process to collect relevant data. These sensors may be capable of transmitting directly to an IIot platform or through a local IIoT gateway. This method is the most expensive as there may be duplicate sensors, but it can also yield the best data as sensors are purposefully placed. This method can result in little to no process downtime, but requires the highest capital expense.

BENSON: We continue to see two key considerations—simplicity and security—driving decisions in this area.

While some sensor and instrument manufacturers offer IoT-enabled technology (for example, cables with built-in power sensors and network connectivity or small Raspberry Pi-like cellular devices bolted onto sensors), most customers still use a simpler aggregate-and-act architecture. Even in applications where we see LPW/WPAN sensor networks, ultimately there are one or more gateway devices that act as converter, aggregator and occasionally actor, although they usually send data upstream (if even just upstream in a plant to an edge device) for decision and action.

This aggregation architecture also gives customers a lower cost of entry into IoT, as they're usually able to start with existing sensors versus requiring new and potentially more costly sensing equipment or instrumentation.

While the choice of backhaul medium (such as cellular versus wired Ethernet) is usually driven by geography of deployment, we’re increasingly seeing it as a choice about network security. Sometimes, especially for OEMs deploying machines with a ‘remote service’ feature or built in recurring revenue stream, manufacturers are building cellular communications into equipment that may be installed on premise. The most common reason we’re seeing is that they want to offer connected services (remote diagnostics and maintenance). Offering cellular connectivity, and therefore a completely separate, owned and managed network connection, is a way to reduce concerns of their customers’ IT teams about having to provide and maintain a secure, accessible node on the network for a third party.

QUESTION: How much control in the field is happening these days? Has the long-ago promise of distributed control finally gone mainstream?

GEIS: The IIoT is evolving quickly and can be classified in a few stages. At first, IIoT was seen as a data visualization tool in the cloud. Data would be transmitted to a cloud repository, and the IIoT platform would present a data dashboard allowing anybody, anywhere to see system data easily. These cloud dashboards could be considered "IIoT v1.” However, IoT v2 took the data visualization and added intelligence, reporting and alarming. This functionality allowed more autonomous operation, notifying if a system or process outside of programmed conditions and didn’t require an operator to monitor screens 24/7.

IIoT v3 is opening the way for distributed control, or bidirectional control with systems and processes. This phase of the IIoT is expanding on data dashboards, centralized alarming and also creating a feedback loop with the edge of the network. While some customers are allowing the feedback loop control equipment, more customers are simply allowing this feedback loop to modify a local database in the field (e.g. confirming that an alarm was received or an action was taken by the cloud platform).

Another practice we’re seeing is having edge devices alert and alarm locally based on their programming, even as they’re communicating information upstream to a cloud platform where further action may be taken. Customers must place a large amount of trust in their equipment and network to allow for full, autonomous control of their equipment by an IIoT platform, and this hybrid model gives customers greater confidence. We're seeing more customers asking questions about this functionality, and our equipment is capable of performing these tasks, but it's still a little early to call it mainstream. Customers are deploying more edge control with IIoT connectivity because the visibility to the system and process has improved so much, but it isn’t standard practice to deploy platform-driven edge control yet.

QUESTION: What alternative methods are being developed and implemented to shorten these pathways, such as using Internet-enabled devices to tie field devices more simply and closely to higher-level systems for data gathering, process monitoring and control?

GEIS: The process of collecting data from field devices will occur through the adoption of several technologies in the industrial space. There isn’t a single method to connect sensors, equipment and factories to the cloud, but a toolbox of technologies that will solve the problem. From an architecture standpoint, customers can either use a clustered approach, where a number of sensors/devices are connected to a single IIoT gateway, or they can deploy a one-to-one network. There are arguments for both architectures, and just like the technologies used, there isn’t a one-size-fits-all approach. One of the biggest concerns regardless of architecture is security. Do you trust that a cloud-connected sensor or relay has adequate security, or do you think that a network gateway may be a more secure solution? As we said earlier, cellular is probably one of the fastest and easiest methods to connect process equipment to a cloud or an IIoT platform, not requiring a path through a company’s existing network. Cellular can be deployed simply by applying power and connecting desired equipment. Operators and IT don’t need to worry about affecting the control network, opening firewalls, or segregating traffic on VLANs. Cellular is secure, ubiquitous and highly scalable. The downside however, is the signal doesn’t penetrate buildings terribly well. There are a number of different wireless technologies (LPWAN, Bluetooth, and Wi-Fi) that are being used, but they face challenges of adoption, coverage and interference. The reality is that cellular and traditional wired solutions will likely represent the largest share of connected devices because they're familiar and easy to deploy solutions.

QUESTION: What are the benefits and risks of bypassing PLCs and DCS on the way to MES, computing and the cloud?

GEIS: Probably the largest three arguments about using existing equipment versus bypassing equipment is security, access to relevant data and impacts to current equipment/processes.

Using existing equipment to access data can be an easy integration point, but how secure is the device (PLC, RTU, drive, etc.)? PLCs and most automation equipment were never designed to be deployed on a publicly accessible network, and lack effective security from external threats. Integrating existing equipment to a secure IIoT gateway can provide security, but also may open up the control network if not properly configured.

Does the device have access to all the data or sensors necessary to allow for a systematic approach to process improvement? Existing equipment was deployed for an application, such as control, monitoring, maintenance, etc. As such, the data collected from that equipment is likely to be application-specific. IIoT is about breaking that paradigm, and allowing data to be accessible to any application that requires it. What customers are finding is that, while using existing equipment is an easy first step in the process, unfortunately this method doesn’t often provide enough data for a clear picture. Finally, customers need to evaluate the impact on the current process for installation of the new data collection system. Does the system/process need to be shut-down for the installation of new sensors, or to tap into existing sensors? Do new PLCs, RTUs, DCSs, I/O, Ethernet, and power need to be run to the new locations?

BENSON: If a customer’s primary desire for gathering data from a sensor is to send it to the cloud for publication to dashboards or other applications and it needn’t be acted on by a PLC or other intermediary within the network, directly communicating to a cloud application can been seen as ideal for many of the reasons our OEMs would give for why deploying with a cellular connection on their machines benefits an IT network deployment. The structure becomes almost a star topology, with the IIoT platform at its core. It is “shortest path,” bypasses the process signal chain and likely has the lowest latency, potentially reduces network traffic, and offers rather simple fault identification.

Further, if sensor manufacturers offer fully integrated software or a cloud-based management solution that a company elects to implement, that manufacturer may have made an effort to build in ease of direct connection to that platform versus teasing the data out of a data stream aggregated by an intermediary. The same arguments presented by machine builders integrating cellular apply here.

However, there are a few drawbacks. The greatest of these are the added cost and complexity of implementation. Using an example where sensors can directly connect via cellular to a sensor manufacturer’s IIoT platform (or even into a company’s own IIoT platform), for every connection point, someone has to manage SIM cards and data plans. With a sensor failure, there is the cost of the time associated with replacing the sensor, reconnecting the device to the network, and registering it with the cloud platform. There is a cost, too, associated with the cellular hardware implemented with the connected sensor, which heavily burdens the total hardware cost versus traditional wired- or LPWAN-to-gateway implementation.

Further, with a one-to-one “star” network back to the platform, there is no media or equipment redundancy built in. Lastly, customers need to consider the level of security built in to these endpoint connections. Are they relying on somewhere further upstream to manage security? Can they afford to? Are these alternative methods being used for data gathering, process monitoring and perhaps even control?

GEIS: Yes, these methods are being used for all aspects of the IIoT, but the highest IIoT adoption method is simply connecting existing equipment to an IIoT platform through some sort of data aggregator as a first step. As mentioned earlier, the first and easiest foray into the IIoT is simply visualizing existing data in the cloud so more people can view it. Connecting more devices to the cloud, and gathering more granular data to help form a picture of the entire system or process happens when enough disparate points are collected. Once an organization is comfortable that they're accurately visualizing the system, control can be layered in.

QUESTION: Do you know of any specific examples and case studies data gathering, process monitoring and/or control that bypass PLCs and DCSs? Are any graphics or photos available?

QUESTION: How are the alternative-path networking methods likely to evolve in the future?

GEIS: The general trend in IIoT is security and scalability. The future of this industry is one-touch deployments with auto-detection/auto-registration features. Deployed devices will sniff out network traffic and will securely push it to an IIoT cloud. Control is coming, with more reliable operation with less latency and increased intelligence of dependent processes.

BENSON: However, sensor gateways, edge devices, PLCs, drives, networked I/O, and protocol converters all place new challenges on distributed industrial systems. Companies have to come up with a way to ensure an optimal path back to their MES or IIoT platform without risking significant added data costs or adding unnecessary complexity to their architecture. Sometimes the solutions are simple, such as moving from unmanaged to managed switches and learning how to employ the built-in features that inhibit bandwidth-stealing broadcast storms, implementing QoS, VPN, etc., or developing a report-by-exception strategy for communicating data to a cloud platform. However, more work can be done in the areas of path optimization, congestion detection and multi-path routing.

Read the full cover story from Jun 2017, "Alternate paths from the field to cloud."