General considerations

When designing a System Platform application, consider the following data storage concerns:

• Data Point Volumes: The volume is the number of points in the application that will be historized. In Application Server, data points are attributes that have history enabled.

• Data Storage Rate: At what rate will the data be changing and how quickly will that data need to be stored?

• Data Loss Prevention: What are the possible scenarios that would result in a loss of data?

• Storing System Data: In a system with multiple historians, how does changing system topology affect the location of stored data?

• Client Locations: Keep in mind the location of historization clients as you plan the network topology for your application.

• User Account: The System Platform Network account under which services run must be the same for all applications. Also, if you specify a local computer user, then the Historian Node must be in the same network domain or workgroup as the ApplicationObject Server node

Data Point Volumes

The data storage rate of a single historized attribute (i.e. point) is a function of the scan period of its hosting AppEngine and its rate of change. The attribute can be stored no faster than the AppEngine scan rate, and is only sent to the historian if the attribute changes.

For analog attributes, a deadband can also be configured to prevent storage of small changes that are not significant.

Finally, attributes can be configured to ensure that slow-changing or non-changing attributes are always stored at a minimum interval (such as once per hour) via the force storage period.

The volume of data points that must be stored is a determining factor in deciding how many historians will be required in an application. Most applications will only require one historian. Very large applications may require multiple historians.

Data Storage Rate

When configuring a data point for storage, it is possible to set a rate for that point to be stored, but keep in mind that the data cannot be stored any faster than the AppEngine scan rate. Data storage cannot occur between AppEngine scans. The data storage rate should always be whole number multiples of the AppEngine scan rate that hosts the associated object.

Data Loss Prevention

The System Platform framework protects historized data from loss. This is done by storing the data locally to disk when connection is lost to the Historian. This operation is called "Store Forward." Each AppEngine and Platform is capable of storing all of the associated acquired historical information to disk when a connection to the Historian cannot be established. Once the connection is reestablished, the data will be sent to the Historian. It is important to ensure that the AppEngine responsible for sending the data to the historian is not interrupted. To prevent data loss:

• Separate the Galaxy Repository from running AppEngines. As applications grow large, the configuration changes to that application will become CPU-intensive. It may be possible to have the configuration services on a computer starve the AppEngine from the required CPU cycles to perform the data storage. To prevent this, place the Galaxy Repository on a remote computer from running AppEngines.

• Do not deploy to running AppEngines. If an AppEngine is running and gathering information for the Historian, deploying additional objects to the AppEngine will cause a momentary interruption of the AppEngine execution. During that time incoming data changes may be missed.

  This effect can be prevented by only deploying new objects during non-critical data storage periods. Deploying large numbers of objects can have a large effect on system resources.