Alarm Communication

In Architecture 1, alarms are created in Building Operation, Automation Server or Enterprise Server.

In Architecture 2, technically the alarms can be created in both systems, PME or Building Operation. A proper design of the alarm generation logic and communication is important for a successful solution.

PME Alarms

PME alarm data is transferred to Building Operation using EWS. It is important to understand the two possible sources of an alarm in the PME system:

  • On-board alarm – Generated and logged in the device (meter, circuit breaker, and so on)
  • Software-based alarm – Generated by the PME software and logged in the computer cache.
On-board Alarms

For important alarms, such as circuit breaker trips, power outage, or over current, try to use the device on-board alarms in circuit breakers or meters. Even for a less important alarms, on-board alarms are recommended to use to gain higher system reliability and also to make use of the device functionality.

Software based Alarms

If the device does not have on-board alarming, or additional alarms need to be created, it is recommended to create the alarm in Software Alarms in PME, rather than create an alarm in Building Operation based on real-time values read via EWS.

NOTE: VIP alarms are not exposed through EWS.

EWS Alarm Communication

The following flow chart shows the details of the alarm data flow in PME when integrating with Building Operation under Architecture 2.

PME alarms are polled only if the Alarm Polling is enabled for the EWS interface in Building Operation.

A filter can be configured to poll only the alarms that are needed.

The priority of an alarm or event can be configured in the PME system. The typical PME alarm priority categorization is:

  • High priority alarm: 193 - 255
  • Med priority alarm: 128 - 192
  • Low priority alarm: 64 -127
  • Information: 0 - 63.

NOTE: Any alarm priority setting greater than 255, in Building Operation, will be set to 255 for PME.

When a user acknowledges EWS alarms in Building Operation, the corresponding alarms in the PME system are also acknowledged automatically.

Performance: Alarm Latency

With the default software settings, an on-board alarm event is expected to be seen, in Building Operation within 90s on average. The settings can be tuned to achieve faster performance. Using the same concept, for a software-based alarm, the latency depends on the Building Operation EWS polling rate and the alarm polling rate defined for the alarm.

NOTE: Consider the impact on other parts of the system, such as the real-time data performance when tuning the polling rate to achieve a faster alarm refresh rate.

Best Practice for Using EWS Alarms in Building Operation

When choosing Architecture 2, it is not recommended to create Building Operation alarms based on real-time values read via EWS. For real-time values, EWS communication only takes place when there is a need, for instance, a graphic is opened by the user. In contrast, if an alarm is created based on an EWS tag, then the EWS real-time subscription for this value will be constantly active.

However, in Building Operation, the EWS alarm object is not the same as a regular alarm object. If there are requirements for consistent alarm messages, alarm priority, and user action associations, which EWS alarms may not meet, it is recommended to use the Building Operation Sum Alarm function to create a new alarm on top of one or more EWS alarms. Then the newly created Building Operation alarm can be managed consistently with other Building Operation alarms. Refer to Building Operation online help for more information about the Sum Alarm function.