An apple to apple comparison between OSI PI system and Ignition for efficient plant management and operation

General Discussion
1

OSI PI system has been in use in tens of 1000's of plants as per their data. Perhaps its called AVEVA PI systems now due to take over or whatever. I think Ignition on prem and/or cloud edition can do the job of whatever PI system has been doing in a much more efficient manner. I searched thru the forum for any such discussion but couldn't find one.

PI systems are legacy systems and are based on windows platform and lack the modern features such as web interface, mobile interface, variety of reports and dashboards, analytics capabilities etc which are present in Ignition 8+. Various module in PI system such as Process Chart, Asset Framework etc can be easily replicated with Ignition perspective, SparkPlug/UDT type definition of objects in Ignition Tags DB, the built in support for OPC UA/DA in ignition to connect to as built systems, the Ignition Edge and OPTO 22 IOT additional connectivity etc etc.

I would like to know if anyone has done this type of comparison/migration from PI to Ignition? What do you think, is it feasible or makes sense? Or it's not an apple-to-apple comparison?

Of course, Ignition can do much more than that and its primary function is SCADA and controls, but additional functionality can be built upon to with latest features and addons in it.

2

As a former OSIsoft & AVEVA employee, I'm also interested in discussions around this topic! I thought I stumbled across posts like this before, but it may have been on another site.

I didn't get the chance to learn about much of AVEVA's product line outside of PI, but I know the products from the OSIsoft side pretty well. I'm relatively new to IA, so I'm not able to offer a thorough comparison, but I do have some thoughts. I do think Ignition could replace a lot of PI System deployments at a fraction of the cost, with the added SCADA and controls functionality that PI lacks.

I think Ignition on prem and/or cloud edition can do the job of whatever PI System has been doing in a much more efficient manner.

From my understanding, the PI historian (PI Data Archive) is much more capable than the historian offered by IA. Our 8.3 release will set the foundation for Ignition to close this gap, and it remains a company focus.

The only other gap that I have personally noticed is the PI Asset Framework. The context it provides to tag data seems really useful. Event frames are really useful for batch processes. Building out templates in PI AF is relatively easy and very powerful when working with large deployments.

That being said, I'm sure these gaps can be mostly bridged within Ignition. I've seen integrators build displays that show context and relationships similar to AF. I'm sure there's a similar feature to Event Frames that I don't know about.

Asset Framework can be easily replicated with Ignition perspective.

This is a pretty bold statement. :sweat_smile: Although, I would agree many of the features can be replicated with a fair amount of effort.

PI Systems are legacy systems and are based on windows platform.

This is true for the flagship PI Data Archive and the PI Asset Framework. This is not true of the OSIsoft/AVEVA Edge Data Store or PI Adapters. EDS and Adapters were initially designed to be deployed in containers and edge environments where connectivity is not consistent. They are meant to be fault tolerant.

While adapters are beginning to scale and overlap with many use cases for interfaces and connectors, EDS is not a replacement for PI. As you mentioned, the core of a PI System is stuck on Windows.

[PI lacks] the modern features such as web interface, mobile interface, variety of reports and dashboards, analytics capabilities, etc

PI Vision has been around for sometime, and offers a fairly nice web interface. I was never a front-end guy, but I would assume you could build displays and dashboards that fit nicely on a mobile screen as well. Although, to my knowledge there is no native mobile client.

PI Analytics is pretty capable and seemed to be very popular. From my (limited, new to Ignition) understanding, the analytics features in both systems seem on par with each other. Although, I don't know how performance compares across the two. Neither offer the same level of capability as something like Seeq.

Some of the above may sound like a short sales pitch for PI, but Ignition definitely has its own strengths. Ignition definitely leads in modern connectivity. This used to be a strength for OSI PI, and if you're OK with the legacy products that haven't seen a release in years, then PI still has a lot more options. If I remember correctly, we touted over 350 connectivity products, but the vast majority of those are legacy PI Interfaces that are not compatible with Edge Data Store or OSI Cloud Services (now part of AVEVA Connect). AVEVA's modern connectivity products (PI Adapters) are pretty lackluster compared to Ignition, as they still only offer a subset of the features for their legacy counter parts. While some of those features (like failover) are improving, OSI had a firm policy on not writing back to the data source, which is a pretty big limitation. AVEVA also offers control software outside of PI, so I'm curious to see if the policy will change in the future for PI Adapters.

PI has pretty good OPC DA support with the PI Interface, but OPC UA support is pretty limited. You have 3 options: 2 generations of PI Connector or the PI adapter. Each of them have interoperability issues, and neither offer the ability to write back to the data source. Ignition's OPC UA interoperability is top notch, and I'm greatly looking forward to helping improve IA's connectivity product offering (mostly drivers) while I'm here.

I'm not an Ignition expert (yet), but I'm happy to answer any questions I can about PI and the possibility of migrating to Ignition.

2 Likes
3

Wow this is the kind of detailed comparison that I was hoping to get from someone! Thanks a lot Cody it came from someone like you who is ex-OSI PI user and an expert! I hope AVAVA dosen't mind such a comparison on an open forum like this!

I think you are yet to get a complete understanding yet of what Ignition and its partners have to offer, in Ignition, though you are an expert in PI, having mentioned many good aspects of it. So I would like to comment on some of them, as I know Ignition at least better than you (as of now) as I have been using it for 10 years now! I am sure you will surpass me soon in Ignition. I request IA and its partners and other experts to also contribute to the discussion.

Is it due to SQL based historian in IA rather than more optimized file based their own storage methodology? I also thought so in the beginning, I thought IA's initial developers didn't have SCADA background and approached it as an IT product using JAVA and SQL technology! All other SCADAs 20 years ago when Ignition started, had proprietary files based historians. However SQL approach offers openness and non-vendor lockin which is the hall mark of Ignition.

I think the UDTs and SparkPlug based definition of component metadata and grouping all associated parameters is equvelant or even better than the AF of PI. It allows you to define all context parameters of components. MQTT's ability to populate the digital twin data in the cloud with its cloud injection modules is a huge advantage over AF. I was once a skeptic of MQTT and I am a transform now! It's an important piece of jigsaw puzzle of digital transformation now! So I think you may also realize it as you become an expert in Ignition.

I am not sure what are event frames in PI. If you can throw some light then we can try to figure how Ignition can achieve it.

I said Process Vision (or some similar name ) module that allows process visualization in PI can be replaced by Perspective and I think its not an over statement, especially with new SVG editor coming up in Ignition 8.3.

Ignition edge does exactly that in my opinion. All kinds of device drivers OPC UA are all available there including store and forward! This more than PIs EDS offers.

With use of latest front end technology like REACT I think IA is on the right track. It offers so many dash boarding tools for charting, dashboards,SVG for P&IDs and so many user developed UI elements in EXCHANGE , I think it's difficult for any other product to keep pace with Ignition.

Ignition's cloud injection module allows us to leverage the AI/ML/DT features offered by could providers. Also cloud data store and analytics service providers like snowflake allow us to use all the analytics tools available in the world once we inject the Component data into it thru the MQTT bridge modules. I am not sure if SEEQ is also supported by them. However it will be nice if Ignition or SIs can natively integrate the Historian with some tools like SEEQ.

I think IA has focus on Connectivity with support for all kinds of drivers and cloud ingestion of data where as PI which is Legacy product which has not seen new releases in recent past and we don't know their future plans the definitely IA is a product to sail with.

OPC DA is also supported by IA as an add on module I think! This is important for integration with legacy SCADA system which may be in use for past over 20 years! So there are no interoperability issues between OPC DA and UA in Ignition.

Hope you come up to speed and become an Ignition expert soon especially from PI comparison point of view. I am glad that we have some one like you in IA team whom we can approach for any issues related to PI system.

4

The open approach is great! My understanding is there is a big performance difference, however. I worked with customers that had millions of PI Points in the historian, and I've seen PI sustain ~600k events/second of ingress. Pulling data out of PI is even faster. It was very common for users to migrate decades of data into PI and have hundreds of clients consuming the data from a single PI Data Archive. I honestly don't know what the performance of Ignition's historian is like, but my understanding is that this would be too much to ask from a SQL based data store.

That being said, my experience with these large systems is slightly skewed. Due to the nature of the products I worked on at OSI, I often worked with our largest customers. The average PI System is much much smaller. The systems I mentioned above are definitely outliers in near-ideal conditions.

MQTT

Admittedly, I don't know a lot about MQTT, but I have heard similar suggestions before. OSI/AVEVA has products that they are continuing to focus on that help with creating these "digital twins" and representing or moving your on-prem PI System with some cloud native products. I am not very familiar with all of their cloud offerings, though. I would not be surprised if Ignition's integration with MQTT does a better job than the proprietary stuff.

I said Process Vision (or some similar name ) module that allows process visualization in PI can be replaced by Perspective and I think its not an over statement, especially with new SVG editor coming up in Ignition 8.3.

Ah, I misunderstood. I thought you were saying PI Asset Framework could be easily replaced with Perspective. I would agree, Perspective could easily replace PI Process Book or PI Vision. Again, I'm not a front-end guy, but I believe the visualization tools in Ignition likely surpass those in a PI System.

Ignition's cloud injection module allows us to leverage the AI/ML/DT features offered by could providers. Also cloud data store and analytics service providers like snowflake allow us to use all the analytics tools available in the world

There are products that were branded as "PI Integrators" at OSI that allowed similar integrations with cloud tooling. It was outside of my domain, but I think it was pretty common for customers to integrate their business-level PI System with cloud tooling. AVEVA Connect seems positioned to continue to improve on this as well.

Event Frames

Event Frames are a feature of PI AF that allow users to capture information related to a specific real-world "event" rather than just a specific tag. For example, you may be interested in data from many tags when something happens (maintenance, shutdown, process exceeds a limit, etc.). An Event Frame allows you to capture a start and end time, capture dynamic and/or static data from tags/elements that otherwise have no relation, perform some analysis on that data (when paired with PI Analytics), and notify whoever (when paired with PI Notifications).

I think you get some similar features with Ignition's Alarms, but I don't know how exactly they compare. Probably close enough for a majority of use cases.

I hope [AVEVA] doesn't mind such a comparison on an open forum like this!

Me too! I'm obviously not in a position to ask my former product managers for permission to discuss these things anymore, but I believe everything I have shared is well-known publicly already. I'd certainly like to stay on good terms with them.

I am glad that we have someone like you on the IA team whom we can approach for any issues related to PI System.

Thanks! I am also happy to be part of the IA team, and I would be happy to help as much as I can. It would be nice if all this knowledge of PI continues to be useful somehow :sweat_smile:

5

I tend to agree that a binary file based custom approach can be designed to be very efficient for a specific job of historization compared to use of a general purpose SQL approach. A time series data base perhaps could be somewhere in between the two approaches. But it does matter in a use case like PI which has to offer fast historical data access for analysis in a repeated manner. Perhaps in addition to SQL based Historian, IA can build an OPC HDA for Ignition or use a third party OPC HDA which will perhaps be as fast as PI's historian!

MQTT looks great solution to PIs AF, however I don't know how flexible AF is interns of modification of an asset once defined in AF. I think MQTT and UDT allows definition of such components easily but if we have to modify them I don't know how easy it will be. The changes should propagate to UDT/SparkPlug model and the historian !

Oh , makes sense! In Ignition we have tag change scripts which can be used to write a group of tags in DB. I think even Transaction Groups allow you to do just that! Ofcourse alarms are also very powerful in Ignition but that's not equivalent to Event frames that you described.

I think US laws allow a healthy competition and there is nothing you are saying that's false information, it may look biased to someone, buts its your honest opinion and impressions.

This will be a useful help during SCADA migration projects to ignition where legacy SCADA has PI connected to it which also gets merged in a single platform of Ignition.