Read historian from external software

Simple question here. Can an external MES connect to the Ignition’s historian to get data?


The data is stored in whatever database you point it at, so yes, if the external MES can talk to a database.

There’s an older reference for how the tables are set up here:

I’ll update if I can find anything more current, but I’m not sure anything has changed since that was written.

Hello Kevin,

Et already have GE Proficy as MES. We are looking to add Ignition as SCADA. I’m wondering if GE could connect to the Ignition’s historian to get the data. Maybe using OPC_HDA connection or something like this that is standard and will not change with the Ignition’s versions.

Ignition can make HDA connections as a client but does not offer any access as an HDA server.

Ok. And can OPC-UA be use to access historical data from an external software?

No, but if we do ever add an OPC-based way to get history it would be OPC UA HA and not OPC Classic HDA. There’s nothing on the roadmap right now though.

Aside from querying the tables directly, the only other option would be to use the Web Dev module to build web endpoints that in turn accessed history via the queryTagHistory scripting function.

Thanks for the answer. Getting data directly from tables seems a mess to me because of data partitionning. I’m a bit sad because this is the first time I hit a limit in connecting Ignition with another software. This limit is putting the historian on the road side…

Feel free to add a vote here:

Pulling historical data out of Ignition and into another system just hasn’t been a common enough request to implement yet.

Kevins response about using the WebDev module is very easy to implement.
We are using it for numerous systems to get data from the Ignition historian.

1 Like

I have developed a Stored Procedure (SQL Server) that is currently being accessed from within Ignition and other external software like Spotfire, Power BI, etc. Also being called from C# applications.

Since Ignition Historian tables are indexed appropriately, the performance is very good. Faster than builtin tag history function in Ignition when amount of data is large, since it runs at data persistence layer.

The parameters to be passed are StartDateTime, EndDateTime, Tagpaths (CSV), Interval (between rows)

The returned result consists of rows of data at each interval between Start and EndDateTime. Columns are DateTime and one column per Tagpath. Basically identifies the partitions, fetches the data and packages it for consumption.

Also created simple version of the Stored Procedure that returns raw values for above supplied parameters. Except you need to pass a single Tagpath.

Working on a wrapper that takes AggregationMode as additional parameter and returns either Average between intervals, Max, Min, Last Value, etc. This is great for daily and hourly rollups.

I have a third Stored Procedure that provides the same data in first SP, but the data is in Tall format. This is very useful for reporting application like Spotfire that has Trellis feature.

I have a working C# based Stored procedure that has even better performance than standard Stored Procedure.


It’s easy to pull multiple JSON data objects cyclically from ignition server using our RWS module which is based on the amazing webdev module of ignition ! This can then be used for displaying dashboards etc on HTML page or for logging in a JSON based Data base such as mongodb or influx dB etc for further processing such as use in an MES package . Only downside is that you can use history from what is stored in new database not past history stored in Ignition’s sql data base and secondly the webdev module is not free! It costs about 1600 usd!

Very interesting !