Hi everyone!
I am new to the Ignition world, currently learning more about the system and its implementations and most importantly its performance and functionalities compared to PI System.
I am an OSI PI Engineer, but I'd like to learn more about Ignition as it seems like a solid alternative that some customers would prefer over PI.
The main reason I see customers choosing Ignition over PI is due to reduced costs in implementing Ignition. I've yet to see Ignition deployed and running on multiple sites with 50k+ tags and hundreds of assets though. So I'm wondering where there are overlaps between Ignition and PI and how they are compared.
From what I see, Ignition is mainly used for HMI and SCADA, but it does provide visualization capabilities and a Historian, which is what PI does very well.
If anyone has experience with Ignition, would you be able to clarify the following points?
Just to make things a bit more clear, I thought of a scenario: a company has hundreds of assets and 40k tags. Let's say 15k tags are process variables that store data every 1 sec and PI exception and compression are kept to a minimum. 25k tags are from calculations/analysis and have better compression and save a data point every 1 minute to 1 day (e.g., daily averages, status etc). The rest are tags that are not very well managed or old tags that people do not really use and need to be reviewed and decommissioned ideally, but the effort is too big for team to take care of it. Users mostly use PI Vision to see data on the web and PI AF have some assets hierarchy and analytics. Currently 70 users use PI Vision daily. They also use Excel and PI DataLink to retrieve data from PI.
From my experience, if this PI System is properly managed, users can get a years worth of process data within a few seconds and trend that (5-20 secs to retrieve over a million data points). PI Vision displays can also retrieve large amounts of data for trends, charts, graphs and bars within seconds.
My main doubts are:
- How is the performance of Ignition tags compared to OSI PI tags (disk space required, time to retrieve points in the past).
- How good is Ignition's compression algorithm?
- Can Ignition have databases of 100k to 1million tags and still perform well?
- How much time would it take users to build a display (reports/dashboards) to see data and calculations (in PI Vision this can be done in minutes).
I appreciate anyone that has some knowledge that could be shared on this subject.
-
Don't know--haven't actually used PI in many years.
-
Modest. No compression on the backend, as Ignition uses conventional databases. (But the schema is published, and anyone can directly query if they choose.)
-
Yes. There are many known users with millions of tags, particularly in the oil and gas sector.
-
This very much depends on the original designer. There are numerous openly-shared kits within the Ignition wider ecosystem (particularly via Ignition's Exchange site) that can be blended into a deployed system to make drag-n-drop dashboards and ad-hoc charting simple, for users to customize in minutes. Ad-hoc calculations would be a different story--I haven't see that anywhere. Possible to construct a resource for that, but non-trivial.
You didn't ask, but you should know that Ignition has two very different user interface tools, with fundamentally different features and weaknesses.
-
The modern Perspective tool, which displays via a client browser, has the more friendly user interface in almost all cases, and the tool that supports mobile devices, but it struggles when attempting to chart or export more than a few thousand samples per tag.
-
The older Vision tool must be installed in a client machine, with no mobile support, but leverages local java technologies for unmatched large dataset handling. I've personally deployed projects that handled millions of rows in seconds, and tens of millions of rows with local caching, for instant drawing of huge datasets as a user pans and zooms across large time frames.
(There are more differences worth knowing--see the Perspective vs Vision topics on this forum--but these seem applicable to your question.)
1 Like
Most of the complaints that I've heard from between traditional historian users and Ignition is the increased space required for ignition. Although, I'd also argue a lot more could have been done to prevent unnecessary data storage, for example increase minimum time to store, use on change vs poll, set appropriate dead bands, etc.
Storage space was a deliberate design trade-off openly discussed at Inductive Automation's founding--disk space is cheap and only getting both cheaper and faster, and conventional databases with standardized drivers make it easy.
The argument then, still true today, is that the difference in both short-term and long-term licensing cost permits purchase of sufficient high-performance disk storage to far exceed the project requirements while remaining less expensive overall. Direct external SQL access to the data is a bonus.
It was a slam dunk argument nearly twenty years ago, and I haven't seen anything in anyone's pricing to change that dynamic since. Just one of many reasons people choose Ignition.
3 Likes