Retrofitting existing systems presents many unique challenges. Planning a modern strategy for data management can be tricky when working with legacy equipment, but certainly not impossible.
Not every automation engineer gets to start fresh with a greenfield project. Sometimes, the challenge is integrating new design hardware into a system filled with legacy equipment. In order for this integration to be effective, the design team must carefully plan dataflow management to prevent data silos and fragile infrastructure, two of the most common pitfalls when dealing with existing or brownfield systems.
Existing System Challenges
Before redesigning an existing system, there are several tasks and questions to ask during the design and planning phase. First, an auditing system is used to assess the current infrastructure. Next, evaluate data flows to determine where the data is being sent and whether those destinations are appropriate or need to be adjusted. After that, analyze the risks associated with sensitive or fragile legacy systems that must remain in operation, while enhancing security measures to ensure these systems do not become potential entry points for cyberattacks.
Performing a System Audit
Before replacing equipment or investing in new hardware, software, infrastructure, and related resources, the first step in developing a dataflow management system is to perform a system audit. The system audit allows the design engineers to know what hardware is already present, what data structures and protocols are in place, and where the pain points may be in integration.
A thorough audit includes all of the hardware and software systems that will be part of the upgraded, comprehensive dataflow management system. Few issues are more problematic than discovering late in the process that a piece of legacy hardware cannot connect to the new system, especially when it could have, had different design decisions been made earlier.
Where is the Data Currently Going?
It is likely that the existing automation system already collects and stores data in some form, adding value to the production process. However, legacy systems are often designed piecemeal, with components added at different times, from different vendors, and in various states of patches and upgrades.
For these systems, it’s important to understand where that data is being sent and how it is used. This way, the new strategy can examine each piece of data and determine whether it is necessary, whether it should be sent somewhere else, and how each piece fits into the upgraded, unified system.
In some cases, data should flow vertically. This means data flows up the chain or hierarchy, from the operation floor to the IT business systems for larger decision-making purposes to meet KPIs. In other cases, data should flow horizontally. Horizontal flow refers to the transfer of data between machines or systems operating at the same level so that maintenance can be scheduled effectively and bottlenecks reduced.
How Should Data Be Transferred?
One of the trickiest areas for dataflow management with existing OT/IT is determining how data should be transferred. Ideally, hardware will all use open platforms, using the same protocols so that all components integrate easily. However, reality is far messier. Existing systems often use legacy or proprietary equipment, mixed protocols, and other such issues. There are several common approaches to integrating data transfer.
OPC-UA can be used to move data between OT hardware and software systems. It provides secure, platform-independent communication methods for complex data structures and models. OPC-UA is typically used for point-to-point data transfer.
Another strategy is to use Message Queueing and Telemetry Transport (MQTT). In this system, data is treated not as point-to-point contact, but instead operates on a “publish and subscribe” model. Sensors produce and “publish” data, and devices needing to see the data can “subscribe” to the data service. MQTT is also platform independent and is great for low bandwidth situations and instances where some devices need data updates more often than others. Edge gateways can be placed near legacy hardware to convert the data into the MQTT format. By doing so, the legacy hardware is effectively an MQTT data publisher.
SQL databases are another popular tool for managing data. They are great for archiving data of specified formats, such as tool metrics across multiple machines. Then, if there is a problem, the database can be called and the archived data analyzed. SQL databases are best suited for long-term data storage, and not recommended for streaming data and quick process control decisions. It is most useful when data has a well-defined structure or template.
Rest APIs use a similar approach to the publish/subscribe model. They are perfect for making operator dashboards, where the API polls data and displays only the relevant data to the user. Based on HTTP, it integrates easily with cloud services, is highly customizable, and offers multi-device support. It is not really designed for large datasets and rapid polling, but it allows metrics to be displayed at a glance.
There are some middleware and DataOps that act as a central hub for routing, converting, and controlling the flow of data. These software packages are usually available off the shelf and do not need to be developed in-house.
The idea is not to find a “one size fits all” approach for data transfer, but rather to leverage some or all of these techniques as they fit the business needs of the organization. Perhaps MQTT with edge computing is the backbone, but SQL databases maintain archived data for machine metrics.
Minimizing Unnecessary Impact to Legacy Devices and Systems
Legacy devices, such as older PLCs, may not allow for faster polling and onboard data conversion. Perhaps there will be a day when these systems are phased out of plants, but they are usually stable, so it is wise to keep them running instead of replacing them.
This is where leveraging edge computing can provide the real advantage. The edge computer sits near the device, converting its data from proprietary, legacy formats into something that is far easier to integrate. Behind the scenes, the data transfer is cleaner and more organized, but the user interface/user experience (UI/UX) does not have to change. Dashboards may remain the same, meaning there is no need to train the end users on new software.
Through Ignition!, HMIs and dashboards, even from legacy devices, can be made portable. Image used courtesy of Inductive Automation
One possible method, though it has some risks, is collecting data from SCADA and using OPC-UA to work with the data independent of the platform. It can be effective, provided the extra load on the SCADA system is not already running at capacity. It may also require the setup and configuration of an additional SCADA server, which is not necessarily a barrier, but another consideration.
Keeping the System Secure
Developing a dataflow management strategy means more security, as threat handling can be built into the system. This is true even if a legacy system has never been the victim of an attack.
Edge computing adds a new layer of security that can protect the legacy devices and create another barrier between threats and the system. It can provide secure, read-only paths that were not available in previous configurations. Judicious use of firewalls and network segmenting can protect assets as well.
For More Information
Ultimately, the goal of integrating and organizing dataflow across existing systems is to transfer data where it is needed to make more optimized business decisions. The data should drive system development rather than the software or hardware, though the system designers may have to work around some practical limitations of either or both.
Recent developments in edge computing allow for easier data conversion and smarter, more efficient dataflow management strategies. To see how you can develop a new dataflow management strategy while maintaining system integrity with legacy devices, reach out to the experts at Inductive Automation. The team has years of experience in developing integrated dataflow management systems and can help you make sense of all of the technical details to make your plant work effectively.