OSIPI to Canary Labs Historian Conversion for 1.8 Million Tag SCADA System

Corso Systems is no stranger to converting from one SCADA platform to another—we’re also experienced with migrating from one process historian to another! A large oil and gas company in Southern California was facing an expensive OSIPI Process Historian License renewal and were looking for a more cost effective and performant solution. We worked with the oil and gas company to consider their needs and feature requirements and both parties concluded that Canary Labs would be a great choice. Initially, Corso Systems used our experience with conversions to OSIPI to reverse engineer the process. We set up a proof of concept demo designed to show the customer that with a minimal amount of effort, we could map their entire system, move all of their data across, and have a better overall solution to meet their needs.

Canary Labs Solution

• Convert from OSIPI to Canary

  • Build out a tag map of their current system

  • Streamline the naming conventions which varied widely from site to site

  • Determine the best method to extract data for 1.8 million tags—for the past 11 years

  • Inventory all of the OSIPI visualization screens currently in use

• Canary Labs

  • Build an asset model for a streamlined enterprise-wide naming convention standard

  • Set up tags for collecting data in Canary Labs’ Historian going forward

  • Import all existing data into Canary Labs from now to the beginning of each tags’ life in OSIPI

  • Convert desired OSIPI screens to Canary Labs Axiom interface

  • Build new Axiom interfaces as required

• Ignition

  • Many of the tags came in from Ignition OPC-UA Servers and needed validation in the asset model framework

• Wonderware

  • Some of the tags came from Archestra Galaxies and needed to be validated with the asset model framework

Canary Labs is Built on Flexibility

Building a proof of concept demo was the first step. Corso Systems set up a tool to browse the existing tag structure in OSIPI. The tool also allowed us to select example tags and a timeframe to import. We built an asset model in Canary to store this data, and then began the import process. Once the demo computer was on the network, the browser-based demo t went off without a hitch. The customer realized that this system could work for them as intended.

Next, we picked a timeframe for a full stress test and comparison of the two systems to verify everything would meet the customer’s demanding requirements. After all, they were currently storing 1.8 million tags and were looking at consistently adding sites to their system over the coming years.

We quickly determined that the Canary Labs Historian could exceed the OSIPI data throughput into the historian by 19% with the same hardware and network infrastructure. Canary Labs overall storage requirements were also 68% for the same amount of data stored in the OSIPI system. This meant the overall cost of ownership of the historical data in Canary Labs was much less than in OSIPI.

Next, we constructed a tool to import the existing OSIPI visualization screens the customer wished to convert to Canary Labs Axiom environment. Then, we mapped out requirements for the new screens we needed to build.

We completed the project on time and under budget approximately ten months from inception.

Result

The result was a significantly lower cost, and higher performant system. No architecture changes were needed from the original system to get data flowing into Canary Labs historian—and now the data was cheaper to obtain and store.

The customer was able to cancel their OSIPI renewal and simply deleted the software before the renewal process would have started, since the data was already in Canary Labs.

Further phases included reducing the overall bandwidth requirements by moving from Ignition OPC-UA data collection to MQTT data collection. Then we helped them move away from more costly and less supply chain tolerant Allen Bradley hardware to made in America Opto22 Hardware.