Ignition as a Site Historian vs. Others (Canary, OSI PI, AWS)

For a Site Historian requirement, I am exploring the historians available in the market and understanding where each Historian fits well. Can anyone throw light on the following questions?

  1. Ignition vs. Canary
    Q: Under what circumstances would an Ignition customer choose Canary as the target historian or embed Canary’s charts/applications into Ignition Designer?. I see that Ignition has its Historian, asset modeling through partner modules, and two visualization systems.
    Q: Does Ignition also directly compete with Canary?

  2. Ignition vs. OSI PI
    Q: Are there any significant advantages in choosing Ignition over OSI PI? (OSI PI has 400+ interfaces, Historian, asset framework, and visualization)

  3. Ignition vs. AWS
    Q: With Greengrass, Timestream, and SiteWise, AWS offers robust connectivity, Historian, asset modeling, and visualization. With AWS Outposts, they can also be a Site Historian (apart from being a Cloud Historian). What are the use-cases where one would prefer Ignition over AWS, and what are the unique advantages?

That is a question I would like to see answerred as well!

IMO, using Ignition and OSI PI together is a pain if you want real time data alongside your historical data.

For realtime there are a few “out of the box” options, but none of them work great.

  1. OPC-DA COM Connection - Was working but would break frequently. Once we updated PI it stopped working altogether and would throw errors in Ignition.
  2. PI JDBC Database Connection - Works well enough, but not really feasible at scale

We ended up just rolling our own solution. I built a C# service that grabs all the tags from PI and publishes them to a MQTT broker, which is then consumed by Ignition. It works great in comparison to the other two options.

For Historical data using an OPC-HDA connection in Ignition works great with PI, we’ve been using it for years with no issues (other than the occasional restart of the PI HDA service).