Case Study: Migrating Legacy SCADA
Plow Technologies was asked to move a set of acquired products from a legacy SCADA platform to OnPing. Migrating legacy SCADA is common challenge in automation, and poses risks for complications down the road if handled improperly.
This created an excellent opportunity to provide insight into how we observe problems, approach the situation, and what the overall solution looked like in the end. Fact finding is critical to a successful Legacy Migration – the decision makers must be involved early in the process to affirm objectives and buy-in to the necessary process to get there.
1 Existing System
To help this customer, we first needed to know what we were dealing with. Each case is unique, it is important to gather some information and become familiar with the legacy systems. Failing to do so could waste valuable time with ineffective proposals and solutions. In this case, there were two primary communications systems requiring updates: Radio Towers and Cell Networks.
1.1 Radio Towers
The existing system used a multi tower radio network and was polling remotely across these towers into a data center.
The towers were connected together using a high speed radio network. Then each individual network uses serial modems to poll.
1.2 Cell Networks
In addition to this there were around 30 individual Cell networks that also being polled. Many of these systems had
sub radio networks that were gathering into each cell modem.
2 Requirements
2.1 Schedule
In early discussions it was made clear the customer required project completion within 4 weeks. With over 200 wells and thousands of data points to transfer, the deadline was tight. Our strategy to stay within the requisite time frame was to break the project into sections and utilize the strength of our developers to …
2.1.1 Data integration
Multiple types of PLC and Measurement data devices needed to be brought into unified visualizations.
This data also needed to be integrated with other systems like accounting software.
2.1.2 Data verification
Critical data, like alarms, measurement data and control set-points needed to be checked against field data in order to make sure the right values were coming in. This was very difficult as some alarms lived in the previous SCADA, some lived in the various devices. Many alarms had duplicate instances of the same alarm with only one of the set being enabled.
2.2 Availability & Access
Multiple levels of access for different users had to be established. Engineers, Pumpers and 3rd parties all need access
to this data. The system can’t have any significant downtime as the transition happens.
2.3 Equipment Reuse
It was important to use as much existing equipment as possible. New equipment means new training. OnPing’s focus on device agnostic methodology reduces the learning curve of new automation processes – in turn removing organizational stress implicit in learning new equipment operations. Making use of embedded equipment saves on time, capital and stress among operators and process engineers.
3 Reasons for Migration
The OnPing hosted SCADA system has several points that made the difference in its choice for this project.
3.1 Reduced Infrastructure
Because OnPing is a platform with built in hosted SCADA it can scale to lots of use cases easily. Also, it doesn’t require towers talking to towers and everything coming back to a central point. The network is broken down into cooperating, but independent, systems.
This means less radio networks in total, and fewer networks means fewer opportunities for network failure. Network consistency was critical to the customer due to the high costs incurred during unplanned maintenance.
3.2 Streamlined Support
OnPing is backed by 24/7 support. We also have extensive online documentation on the features of OnPing that are available to all our users.
With this customer’s unpredictable schedule, it was important to have access to key information at all times.
3.3 More reliable data transfer
The Lumberjack transforms the various driver protocols – Modbus, MQTT, Ethernet IP, etc – into a consistent protocol optimized for fast and reliable data transfer. In addition, automated data backup occurs in the event of cellular downtime.
Decentralizing the various networks also allows for more isolated points of failure. One tower going down doesn’t take everything down, reinforcing network consistency and data integrity.
3.4 Customization
Field techs are able to make changes to the system quickly. From data integration to visualization changes the interface remains consistent. Users are also able to create their own panels and views, meaning the system can be tailored to what feels natural for a given operator.
4 Results – Success!
The migration efforts were a success. Here are some factors that were critical to obtaining the desired results:
Time Line
The full legacy migration was completed to satisfaction within the initial time frame given. Adherence to the initial goals helps maintain confidence in the product that was offered and keeps business goals on-track. Buy-in is an extremely important component when working with a tight timeline. Decision maker need to have bought into the solution at the start of the project to minimize last minute surprises. Our earlier fact finding initiatives fully involve key players at the start of the process to ensure buy-in from the beginning.
Platform Flexibility
This project was a testament to the flexibility of the OnPing Industrial Automation Platform.
The most challenging aspect of the legacy migration was the translation of a very complicated network topology into
a more streamlined and isolated system. Before the transition, 1 HMI that was dumping packets on
the network might knock down 30 wells. We isolated components of the system to create something that was much more stable.
How was this done?
In the initial phase we organized each cellular site around a local edge computing device. The Lumberjack
allows us to easily push data across a cell network without static IPs and with data redundancy.
The Lumberjacks store and compute data quickly and securely on site before sending that information to OnPing. Lumberjacks can independently communicate with OnPing, each device connected to a Lumberjack gains the ability to communicate individually with OnPing. This lowers network stress and reduces the risk of system wide failure.
This could not be achieved without the flexibility of the OnPing automation platform.
Technical Upgrades:
We put 1 Lumberjack per tower and used that device to push and pull data. For some particularly busy sites we placed a device more locally to drop the packets coming over the radio network for more reliable communication.
We translated all the SCADA alarms in the legacy system into our virtual parameters and brought the regular style alarms in.
We set up HMI as per the customers request that are visible on mobile and desktop platforms. HMI’s through OnPing may be configured remotely through the OnPing platform or locally at the onsite device.
We were able to reduce poll time from 15 minutes to 1 minute by using the Lumberjack and separated polling. The significant decrease in poll time gave the customer greater control of the granularity of data and more precise data to use in calculations.
Summary
Overall this migration demonstrates how powerful the OnPing platform has become for migrating SCADA
systems. The customer received a more reliable network, service within the desired time frame, better control of data, updated HMI’s, and a SCADA system that can incorporate any device using any protocol – perfect for scaling with future growth.
