How can data read and log local data base as well as global (cloud) data base through Ignition gateway?

Dear All,

We have a two Siemens DCS (DCS-01 & DCS-02) and we have a two Ignition Platform with OPC-UA and tag historian. (One at local station and one at cloud as per attachment)

We have read data from siemens DCS through OPC-UA in Ignition Server.

Our thing is how can log data in local data base as well as cloud data base through tag historian (Data log in both data base in same time).

Need to guide and explain it with example.

Thanks for including the diagram. Luckily, Ignition has this feature built right in. You can both ship history from Ignition Gateway to Ignition Gateway using Remote History Providers, and you can also send tag history to two different providers simultaneously using the Tag History Splitter.

I'll take a shot here at the configuration steps at a high level, but someone else could certainly chime in with more details. For each of these steps, Inductive University and the user manual both have a lot of good information on how to accomplish them too.

On your Cloud Azure Ignition Server

  1. Database: Set up a database connection to your Azure Cloud Database Server. Verify it shows 'connected'.

On your Local Ignition Server

  1. Database: Set up a database connection to your Local Database Server. Verify it shows 'connected'.
  2. Gateway Network: Set up a Gateway Network connection to your Cloud Azure Ignition Server. Go through the steps to approve the connection and ensure the connection is active.
  3. Remote History Provider: Add a tag history Remote History Provider. Point it to the database in the Cloud Azure Ignition Server.
  4. Tag History Splitter: Add a Tag History Splitter as another history provider. Point it at two different history providers: The database connection for the Local Database Server, and the Remote History Provider.

After you have this set up, just point your tags at the Tag History Splitter you set up, and those tags will go to both places. It runs through Store & Forward for both connections too, so if one of your connections from the Local Ignition Server goes down and comes back up, you shouldn't lose any data, and it should backfill when the connection is restored.


Hi Kevin thanks for clarification.

but one thing is >> it can be possible without Tag history Splitter ?

You might be able to avoid the splitter configuration if you can set up replication of your local DB to the cloud. Not sure what is possible for that with Azure.

Hi pturmel,

how it can work, pls explain it with example for better understanding and better clarification.


On your diagram, draw the line from your local database server directly to the Azure Cloud database server. You don't need a Cloud Ignition server at all for this part. You probably will need help from Microsoft to set up replication.

If you are going to have client UI connections in the cloud (to the Cloud Ignition), and you want those to have history access, you would:

  • Set up a Remote Tag Provider in the Cloud Ignition gateway, pointing at the tag provider in the Local Ignition gateway (via the gateway network), then

  • Configure the Remote Tag Provider in the Cloud Ignition gateway to use Database for history access mode, pointing at Azure in the cloud. See this part of the manual:

1 Like

Hi, Kevin

I've done all configuration in both server and test data log both side successfully.

I have set partition Day-wise in tag history provider, because our requirement is Day wise table create in daily basis in both database at midnight.

I have test and check with both database, 1st table created in database, when 1 tag log in tag historian and 2nd table create after 24 hr.'s of 1st tag data log, but that is not creating in midnight.

So, Our thing is how it can be possible to create table in daily basis at midnight without any disturbance.

Need to help for table generate at every midnight through day wise table partition.


Anyone faced these issues and found a solution?

Why is the tag history splitter being avoided?

not yet,

we are working tag history splitter.

Hello Kevin,

Any Solution regarding Day wise table partition ??

Apologies for the delay.

The daily partitions work the way you indicated; it creates a table every 24 hours, counted from the first inserted record.

Ignition's Tag Historian isn't designed with an easy way to have your database tables go midnight-to-midnight, but you might be able to have it do that if you do the following:

  1. Set up Tag Historian. Start recording a single tag.
  2. Shut down Ignition
  3. Open up the sqlth_partitions table in the database.
  4. For the single row you have in that table, change the start_time to be midnight of the prior day. (Keep in mind it's formatted in ms since the epoch.)
  5. Start Ignition back up.

You'll probably get exactly what you want from that, at least initially.

All that said, since it's not designed for that specifically, as it's meant to abstract away the data storage, and the partitioning is intended to keep database table sizes down for quick querying, not worrying about what date or timezone your system is in. If you follow the steps above, there's a chance you may end up with 'drift' if you have Ignition shut down for more that a day or if your logging isn't consistent for some reason. Chances are, what I described would work fairly well, but know that it's not a guarantee of tables that include just the specific date.

If you need a guarantee that the low level raw database tables are created one per day, your best bet may be simply to use something other than the Tag Historian, like creating scripting inside Ignition with database INSERTs. You could run a creation script once per day to create new tables, and run your insert scripts at whatever interval you choose, which would take specific tag values you choose in your script and insert them into the most recent database table. Clearly, if you do this, you're repeating work the Tag Historian already does, but if you need a guarantee of a new table per midnight-to-midnight in your specific timezone, that might be the best approach.

1 Like