You can configure application objects to store process data in Historian Server. The stored data can be retrieved and viewed using standard Historian Server database utilities.

Historian Server may be installed on any PC on a local or remote trusted network. A single Historian Server can receive historical data from a single Galaxy only. 

Application Server History Components

A Historian Server database can be installed on any computer outside the Galaxy, but on the same network.

The following figure shows the major ArchestrA components to save process data from a production device to the Historian Server.

The figure shows a single Historian Server. This may be a common configuration, but other Application Server configurations support multiple Historian Server databases for a Galaxy. Sending Historical Data Between Application Server and Historian Server

Application Server communicates with Historian Server through an interface called the Historian Client Access Layer (HCAL). HCAL can establish and maintain a connection to one or more historians either synchronously or asynchronously. If a disconnection from the historian occurs, HCAL attempts to restore the connection.

If HCAL cannot communicate with the historian, all data currently being processed can be stored locally on the computer running HCAL. This hard drive location is called the store-and-forward path Historical data is stored until the threshold capacity of the path is reached or communication to the historian is restored. In the event that all store-forward disk capacity is used to store historical data, no more data is stored.

Configuring the engine for historization

General configuration to historize Galaxy attributes is done at the engine level. The engine will be in charge of sending all data to the historian from its hosted objects configured for historization.

WinPlatform and ViewEngine objects are not hosted by other engines, so if there are any attributes within this objects configured for historization, you need enable historization for each of them. 

The following are the history attributes in the engine:

1. Historian – String to use for the connection to the historian. For Historian Server, this is the node name. If two Historian Servers are configured as partners, the node identified by this string becomes the primary historian for this engine. The partner information is configured and maintained on the Historian Server. Click the ellipse button to browse for the historian on the network.
2. TCP port – The TCP port on the Historian Server node to which history data will be sent. The TCP port is configured when the Historian Server is installed. The default is 32568.
3. Enable compression – If enabled, history data is compressed before it is sent over the network to the Historian Server.
4. Throttling network bandwidth – Specifies limit of bandwidth usage, in kbps, for network communication used by HCAL when communicating with Historian Server.
5. Wait to send incomplete packets – Specifies the maximum time, in milliseconds, for keeping a partially-filled Historian Client Access Layer (HCAL) buffer before sending it to the Historian Server. If the buffer is full, then it is sent immediately, regardless of any value configured in this field. If you have fast-changing data, this setting is irrelevant. If you have slow-changing data and limited network bandwidth, you might want to increase this value so that you have less chatter on the network. The default is 1,000 milliseconds. Valid values are between 1,000 and 30,000 milliseconds.
6. Pre-processing buffer size – Total size, in MB, of all buffers used by Historian Client Access Layer (HCAL). The default and minimum value is 8. If you have very high data bursts, then you should increase this value. If this is too low, data loss occurs and error messages related to buffer overflows appear in the ArchestrA Logger. Increase this value in increments of 10 MB.
7. Store forward threshold – The size, in MB, of free space to reserve on the HCAL store- and-forward disk.
8. Store forward minimum duration – The minimum duration, in seconds, for HCAL to function in store-and-forward mode.
9. Enable late data – Specifies how disconnects between Application Server and Historian Server are reflected in the data until the disconnect period can be backfilled with store-and-forward data.