Overview of History Transfer Objects in the system

There are 3 main objects that are used to perform history transfer operations. These are briefly described in the table below including the possible parent objects.

Table 1. History Transfer Objects and their parent components in the I/O
Object Name Parent Component Description



The History Controller object is created below the Core to oversee the management of history transfer operations. It is possible to create and fully configure multiple History Transporter objects (and one History Sink object) from the Object Properties panel of the History Controller.


Connector, Datasource

History Transporters are created below Connector or Datasource objects and are used to configure the interface to the historian or datasource that you wish to transfer historical data from. The particular tags in the historian/datasource that you wish to transfer data from are configured here.



History Sinks are created below Connectors and provide an interface to write history data to external historians or export data to file.

The diagram below provides an overview of the data flow when transferring historical data from a connected source external historian to another connected target external historian.

Overview of Data Flow in the History Transfer Chain
Figure 1. Overview of Data Flow in the History Transfer Chain

Tags in the source external historian are configured in the History Transporter and tags in the target external historian are configured in the History Sink.

When historical data is transferred from a source external historian, system:inmation automatically historizes the data in the MongoDB repository by creating equivalent inmation objects to represent the source tags in the I/O Model. If the user just wants to import historical data into system:inmation’s MongoDB repository (and not then further into a target external historian) then a History Sink is not needed.

Configuration of History Transfer Objects

A detailed step by step explanation of how to configure the History Transfer objects is covered in the next section, however some basic tips are introduced here.

In general, the History Controller object should be created first and used to create and configure History Transporter and Sink objects. By doing this, the user ensures that any on the fly configuration changes will be reflected in all the History Transfer objects and allows the flexibility to create or add new objects later, should you wish to.

Although Transporter and Sink objects can be created separately, their functionality is limited when working alone and it is more complicated to make configuration changes later if your history transfer strategy changes.

If you want to export already existing historical data from system:inmation’s MongoDB repository to external files, then please follow the instructions for how to export data using the History Exporter and History Controller objects.