Custom Data Stores

In AspenTech Inmation, custom datastores can be configured. They are used for the 3 main types of data:

  • Timeseries data

  • Events data

  • Production Tracking data

Master- and Local-Core Stores

For the GXPC deployment, the following schema is used for Custom Data Stores:

  • 6 Stores are created for each Core, in a Data Store Group identified by the Site-Code (or GLOBAL for the Master)

  • The SITECODE Data Store Group object is created below another Data Store Group object under the Core object "Data Stores"

  • For Local-Cores, the stores are generated below the Local-Core AND the Master-Core, with the same retention times.

  • An additional infinite GxP store is created for each Local-Core on the Master.

Purpose of this setup is, that sites do not need to create infinite stores. This allows to scale down the MongoDB hardware requirements, since the MongoDB will only grow to a defined size. Also backups are not required, because the Master-Core has a 1:1 copy of the sites datastores. A datastore with infinite retention is available on Master, and is backed-up there.

Example configuration:

Custom Datastores for reference system

The store objects are created by IaC installation scripts of a Master- and Local-Core object, by using the built-in library 'esi-mongo'.

GxP vs. Non-GxP Stores

All types of Data Stores exist in the GxP and non-GxP variant. This is done to allow different retention times for the data. Retention times can be specified for each store separately, but the following defaults will be used for the GXPC deployment:

Store Type Retention Time

Timeseries GxP

1 year

Timeseries non-GxP

1 year

Events GxP

1 year

Events non-GxP

1 year

Production Tracking GxP

1 year

Production Tracking non-GxP

1 year

The defaults are configurable in the IaC script xml input files, and have to be agreed upon before installing a Local-Core. An additional infinite storage is always created on Central-Core level, as part of the deployment standard.

Custom Timeseries Store

All objects with ItemValue and ArchiveSelector property can archive to a custom timeseries store (for example IO-Item).

The following configuration approach is used:

  • Custom Timeseries Stores and datasets are created (as explained above) by IaC scripts when a Local- or Master-Core is installed.

  • The ArchiveSelector property defines the used datasets (GlobalLocal GxP and GlobalLocal nonGxP is available).

  • The Administrator that creates archiving timeseries objects needs to configure the property according to a site’s storage needs.

It is not allowed to configure sets to store site data only locally on this site, or only on Central-System. Since backups for the MongoDB databases are running on the Central-System, this would otherwise break validation aspects of the deployment.

Custom Event Store

All objects with EventValue property (OPC Eventstream, Script Event and Script Generator), can enable the EventHistorization property to archive data in custom event stores.

Since events in the Store-And-Forward system arrive on all event stores, the filtering options need to be used to prevent storing events in incorrect stores.

The following configuration approach is used:

  • System event store archiving is switched off. This done with IaC scripts of the Master-Core.

  • Custom event stores are created by IaC scripts when a Local- or Master-Core is installed. They are set to mode CONFIGURATION, therefor NO events will be stored.

  • When creating event sources in the system, administrators have to configure appropriate event source filters in the relevant stores, and set the store to OPERATION mode.

Custom Production Tracking Store

Production tracking data is created by batch tracker objects and batch record datasources. This data is always historized, and processed by the Store-And-Forward system.

The following configuration approach is used:

  • When Custom production tracking stores are created by IaC scripts. They are set to mode CONFIGURATION, therefor NO production tracking documents will be stored.

  • When creating sources for production tracking data, administrators have to modify the S95 Owner Objects property to match records created by the new batch tracker objects and set the store to OPERATION mode.

The filtering script uses the production tracking document as input, and needs to return true or false (FALSE: Will not be stored).