Please ensure Javascript is enabled for purposes of website accessibility
Powered by Zoomin Software. For more details please contactZoomin

AVEVA Enterprise SCADA

Set up alarm replication within DistribuSys

  • Last UpdatedApr 24, 2025
  • 2 minute read

Note: For information on overriding default configuration settings, refer to Modify configuration settings.

Follow the procedure below to enable AVEVA Enterprise SCADA to properly replicate alarms.

To set up alarm replication within DistribuSys

  1. In the %DNADataRoot%\RealTime\config\Settings directory, either create or open the RealTime.json file.

  2. In the file, ensure the following values are set to true:

    "RealTime" > "REPLICATE_DB_AND_APP_ALARMS": true

    "RealTime" > "REPLICATE_SYSTEM_ALARMS": true

    "RealTime" > "REPLICATE_ACK_ALARMS": true

    "RealTime" > "GEN_ALMACK_EVENT": true

    Note: These configuration settings must be consistent on all RealTime hosts. For example, on an Enterprise setup with three systems, either all three systems must have Alarm Replication on, or all three systems must have Alarm Replication off.

  3. Save the file.

  4. Restart the RealTime service.

Details on the Configuration Settings

  • When REPLICATE_DB_AND_APP_ALARMS is true, database and application alarms are replicated from the owning system to the non-owning systems.

    Notes: Since alarms are replicated based on dataset ownership, alarms without a dataset are not replicated.

    If the non-owning systems generate alarms for a point they do not own, the alarms are not replicated.

    To ensure that non-persistent alarms are properly replicated between two systems in a distributed environment, you must set the doas_privilege record's alarm field to flash on both systems.

  • When REPLICATE_SYSTEM_ALARMS is true, system alarms are replicated from the owning system to the non-owning systems.

  • When REPLICATE_ACK_ALARMS is true, an alarm acknowledgement from either the owning or non-owning systems is replicated to the destination.

  • When GEN_ALMACK_EVENT is true, an event is generated when the alarm is acknowledged at the destination through replication. At the destination, two events are generated: one from Historical replication; the other from the acknowledgement at the destination.

    Note: The events are only generated if the dataset is eventable.

Integrity Update

With the alarm replication feature, the system replicates the almsum table during an integrity update. This integrity update is based on dataset ownership for database and application alarms, and system ownership for system alarms.

When you turn on alarm replication, the system deletes any alarms that are not owned and that do not exist on the owning systems.

When you turn off alarm replication, the system deletes alarms generated on non-owning systems when the data is re-processed. The system deletes these alarms since they were created using slot range definitions defined for non-owning systems, and the non-owning systems do not own these alarms.

In This Topic
Related Links