Alarm Historian Architecture

The internal architecture of Alarm Historian is structured around a few core components that handle the collecting, logging, storage, and redundancy of alarm data.

The following image provides a high-level summary of the Alarm Historian architecture.

Core Components

The Alarm Historian system uses the following core components:

  • Collectors: Connect to various alarm sources (such as OPC AE, OPC UA, or BACnet) and gather alarm/event notifications.
  • Subscriptions: Define the alarm/event sources which the collectors are connected to and manage filtering based on various criteria such as severity.
  • Collections: Group multiple subscriptions. Each collection defines a table-like structure (columns/fields) for storing alarms.

  • Loggers: Store the alarm data from the collections into persistent storage. They periodically create storage files based on configurable conditions.

    The internal structure of a logger can be visualized as follows:

Each component in this chain plays a specific role in ensuring that alarms are collected, logged, and stored reliably.

Data Storage

Alarm data is stored in file-based storage (SQLite database files). Each logger creates a series of storage files that contain the logged alarms. The data can be archived or deleted based on configurable conditions. The Alarm Historian maintains an index of storage files, which helps efficiently manage archived and live data.

Client Access and APIs

Clients access the logged alarms through the FrameWorX API, which allows historical alarm data retrieval. Tools like Alarm Viewer use this API to visualize logged alarms.

Stand-Alone Collectors

A stand-alone collector is a remote collector that can run independently from the main logger process. It stores alarms locally in a buffer when there is no connection to the main logger, ensuring no data is lost. When reconnected, the collector synchronizes the buffered data.

Store & Forward

The architecture also includes features like store & forward buffering to ensure data resilience in case of temporary network outages or system issues.

Data Flow

Redundancy Architecture

The Alarm Historian supports a two-node redundancy. There is an active logger that records alarms in real time and a standby logger that maintains synchronized storage. If the active logger fails, the standby logger takes over, ensuring that there is no loss of alarm data. Redundancy is coordinated using FrameWorX communication, ensuring that both loggers share the same configuration database. This enables seamless failover and data consistency between the two systems.

The following image is an example of the redundant setting.