Study Overview

A cryogenic gas plant approached Plow to address significant challenges stemming from a legacy Wonderware control system.  The plant was suffering  from reliability issues, including frequent network outages, untrustworthy information, persistent display of obsolete lines on the interface, and the inability to integrate new lines and equipment due to technological incompatibilities – the standard issues of aging systems. Plant admins were looking to update the system; Plow built  an upgrade for half the expected update cost. How?

There are many studies available to the public about different technical approaches to a migration. Instead, our analysis begins at the end – with what we know about the final pricing. This case study leverages hindsight from a successful Plow Technologies project to understand where costs accrue, and how common assumptions generate costly, recursive,  and entirely unnecessary pitfalls. 

First, take a look at the the final cost summary of the project:

Cost Summary

• Proposal: Update existing Wonderware system
  • Initial install – up to $200K
  • No cloud extension
• Proposal: Ignition on-site + Ignition cloud: 
  • $150K for the first year (including installation, hardware, labor, and extra modules for cloud features)
  • $30K annually for subscription costs
  •  Additional costs: full-time on-site engineer + annual service plan
• Implementation: OnPing cloud interface + Ignition on-site deployment –
  • $92K for the first year
  •  $20K annual subscription costs
  • with significant improvements in reliability, adaptability, and access to cloud technologies

First glance reveals an unexpected result for many people: The cost estimate for the legacy system is twice the cost for the completed project. Equally surprising, a pure Ignition platform play could have built a system with similar functionality – at a 50% premium. What’s going on here?

The Numbers

Legacy System: Wonderware 

Upgrade Cost: ~200K

The estimated cost of modernizing the Wonderware system was approximately $200,000 USD. This cost accounted for:

• Maintaining legacy features 
• Modernized onsite installation
  •  New hardware, new licensing, and modern communication protocols 
• No cloud capabilities included 

Saving money by moving to a new platform, improving and building on the existing toolset, and integrating a new cloud interface seems counter-intuitive. Let’s explore what may be happening. 

‘Plug and Play’ Today, Gone Tomorrow

Wonderware often appears as a legacy installation in oil field or water/wastewater jobs. On deployment, the installations were ‘plug and play’ options designed to account for common, industry specific challenges of that moment. The convenience of this design philosophy is well tailored to suit the traditional breakneck pace of oil business, but the costs of up-front convenience are long term instability and eventual obscolesence.

Eventually, today’s problems give way to tomorrow’s. Pre-built tool sets scale poorly to the demands of a quickly evolving data environment.  What was a valuable asset before has transformed into a constant source of frustration – as had occurred at this cryogenic plant. 

What happens when Operators lose faith in temperature readings on an HMI because the connection between the old SCADA system and a new sensor isn’t quite right? Do engineers spec jobs with 15 year old equipment to ensure it works with legacy systems? Does development of new technologies halt because a plant bought into a particular SCADA platform?

The old ‘plug and play’ systems are simply not viable as long-term, scalable solutions for data-centric operations. They are temporary solutions for situational problems.

‘Modernizing’ plug-and-play tools

So, the old Wonderware install served its purpose but is now obsolete. Now what?

Well, it’s time to ‘update’. How does a closed or ‘complete’ product become updated? It doesn’t. Instead a new license is installed, or a new ‘version’ is brought in to replace what was there – but does the pricing seem to reflect that? Here, the $200,000 estimate reflects what we know to be true – that is the cost of an entirely new system!

Some technology developers use clever language to obfuscate the obscelence of their product. Some write explicit expiration dates into service/support agreements. Some use periodic licenses to keep Users engaged. Licenses, in particular, can make the customer feel like they own something and are in control of their organization, but the license doesn’t suddenly make new technologies work with your older system.

Whatever label is used – the facts remain the same. The original system is obsolete, and a new bill is due for the modern tools you need. The ‘update’ costs as much or greater than a new installation, because it is a new installation.

Ignition, or Ignition + OnPing?

Plow seeks to formulate a plan based on what best suits the situation. We develop automation technologies but are not limited to our own tools. Sometimes, a project require adaptation – such as this one.

Cryogenic gas plants must adhere to certain regulatory restrictions. One particularly relevant to Plow is a requirement for a true on-site controls solution. While architecting the solution, our team identified Ignition as the best on-site infrastructure to build around.

Let’s look at the pure Ignition and Ignition + OnPing cloud project outlines, then compare them to the earlier cost summaries.

Ignition + OnPing: Total Install – $92K, and $20K annually

On-site:

• Redundant racks and Servers
  • Dual Ignitions Master Gateways
    • Ignition server creates a self-image every 24 hour cycle, then stored by OnPing
  • Dual PostgreSQL
  • Docker Container structure
  • 1 second writes to PostgreS from Ignition time-series historian
  • 5,000+ tags
  • 1 month on-site history for every data point
• Lumberjack
  • 1 second polling from Ignition
  • 1 second publishing to OnPing cloud interface of all tags
• Failovers for Gateway and PostgreS
• 4 Local historians
  • 2 Ignition time-series historians
  • 2 Lumberjack historians (Local TachDB)

OnPing Cloud Architecture:

• OnPing cloud TachDB
  • Replicates data from local interface
  • Synchronizes OnPing and LJ TachDBs
  • Publishes data to OnPing
    • 1200 tags per second
    • Each tag stored for 7 years
  • Enables Automatic Reports
• OnPing Cloud back-up (operated by LAS)
  • Additional layer of reliability enhancement
  • Grabs then stores Ignition and Lumberjack configurations
• OnPing Alarm Communications System
  • Dual Call-Order priority system
    • Low priority: Text Call-Order
    • High Priority: Phone Call-Order
• 24/7 perpetual Tech Support included

Ignition: Total Install – $145K, and $30K annually

On-site:

• Redundant racks and Servers
  • Dual Ignition Master Gateways
    • Ignition server creates a self-image every 24 hour cycle, stored in Ignition Cloud
  • Dual PostgreSQL
  • Docker Container structure
  • 1 second writes to PostgreS from Ignition time-series historian
  • 5,000+ tags
  • 1 month on-site history for every data point
• Failovers for Gateway and PostgreS
• 2 Local historians
  • 2 Ignition time-series historians

Ignition Cloud

• Ignition Cloud Modules
• Ignition Cloud technical service agreement
  • Ongoing annual subscription fee after the first year

Cloud Native vs Cloud, Potentially

As we go through the project plans, we notice a lot of similarties between both. In the end, a pure Ignition install appears to provide the same potential set of capabilities as using OnPing, so what is missing? Like with Wonderware before, this is a matter of distinction between what a thing is and what a thing is called.

Ignition is a quality on-prem control system. OnPing is the only native, true industrial cloud automation platform. There are no modules inside of OnPing. If you have OnPing, you have a full cloud infrastructure. No additional purchases of hidden features – what exists in OnPing is yours to build with. This distinction is massive (approximately 30%, to be frank).

Using a platform in it’s native space will always provide better results than a tool forced to adapt to suboptimal conditions. OnPing was designed from day one to have direct, simultaneous connection with the cloud and with on-site equipment. The tools a system like Ignition needs to replicate a cloud environment similar to OnPing are intrinsic to the necessary developments within the platform. Ignition simply isn’t playing the same game as OnPing when it comes to the cloud.

Building with Tomorrow in Mind

We discussed the inherent obsolescense of off-the-shelf options, earlier. Does it apply here?

Ignition faces the same hurdles as any product operating in an insulated evironment. As a non-cloud native tool, Ignition does have a licensing structure, but Ignition licenses are structured to allow some growth and scalability with technological advancements. There will be required updates, but the Ignition model is generally accepted as a workable option for a closed, on-site platforms.

Where the big difference in this project has occurred, though, is in access to cloud technologies. The cloud’s primary difference to closed onsite sytems is perpetual access to latest and greatest technologies.

For example, this job was completed long before the recent wave of GPT-related AI tools. However, where disconnected systems cannot retroactively integrate these new technologies, connected cloud systems (like OnPing) absolutely can! When using a tool like this, you have access to the fruits of development in near real-time. In the case, for half the cost.

Summary

The Ignition + OnPing approach proved to be the most cost-effective and efficient solution for our cryogenic plant project, delivering significant cost savings and a future-ready system that allows the cryogenic gas plant to adapt to emerging technologies and maintain a competitive edge in the industry.

Challenges were addressed by devising a comprehensive, fully integrated on-site to cloud solution focused on enhancing reliability, improving efficiency and adaptability. This cost analysis of the project is meant to reveal where some common assumptions lead people astray, and how to understand where more value can be obtained during project design.

Contact us at info@plowtech.net with any questions or feedback.