This project has moved. For the latest updates, please go here.

Subscription to Alarms

Sep 10, 2012 at 6:07 PM

I've been successful in subscribing to an alarm measurement; that is, I created an alarm with an associated measurement, getting in return a new measurement associated with the alarm. However, I'm not sure how  to tell when the alarm has cleared, as I get a stream of measurement values with only the new timestamp and the data value changing. Is a cleared alarm indicated by a delta between subsequent alarms, or no alarm measurement for some interval? Is there a better, more 'solid' indicator of a cleared alarm?

Coordinator
Sep 10, 2012 at 6:28 PM

Alarm measurements are generated only when an event occurs. That is, only when the alarm is set or cleared. The value of the alarm measurement that is generated indicates whether the event caused the alarm to be set or cleared. A value of 1 means the alarm is set, and a value of 0 means it is cleared.

This strategy is used so that the system does not generate superfluous alarm measurements, however this is problematic if one would simply like to query the state of all alarms. For that purpose, a web service has also been provided that allows you to access information about all the raised alarms in the system. The default URL for this web service can be one of the following.

http://localhost:5018/alarmservices/raisedalarms/all/xml
http://localhost:5018/alarmservices/raisedalarms/all/json
http://localhost:5018/alarmservices/raisedalarms/severe/xml
http://localhost:5018/alarmservices/raisedalarms/severe/json

The URLs marked with "severe" instead of "all" will only expose alarms for each measurement with the highest severity. That is, if two alarms were set while monitoring the same signal, then the alarm with higher severity will mask the other.

Sep 10, 2012 at 8:32 PM

Thanks... that explains why I wasn't getting any measurements for my subscribed alarms. Is the status of the alarms only held in memory of the web service, unavailable elsewhere?

Coordinator
Sep 10, 2012 at 8:56 PM

The status of alarms is actually held by the ALARM!SERVICES adapter in the openPDC service. The web service simply queries the adapter in order to obtain the list of raised alarms that it exposes. This is simple since the ALARM!SERVICES adapter is actually hosting the web service, so they are tightly coupled. It is possible to create custom adapters that have access to the same information, if that is what you had in mind. The ALARM!SERVICES adapter, however, currently only exposes the raised alarms in the system.

Sep 11, 2012 at 3:27 PM

Thanks for your help. Hopefully my last question on this topic: is there any way to pragmatically create new alarm definitions? What I'd really want is a connection string similar to the flatline and range tests, with wild-cards for many names/values. In the absence of  this, creating 100s or more individual alarms manually seems tedious; is there a way to create them with a program? I briefly considered simply inserting rows into the Alarm table, but I doubt that that is sufficient.

Coordinator
Sep 11, 2012 at 4:19 PM

In TimeSeriesFramework.UI.dll, there is a class called Alarm in the TimeSeriesFramework.UI.DataModels namespace that is used by the openPDC Manager and therefore provides all the same functionality. In order to use this in your own application, you will need to modify the configuration file for your application. The configuration file should include the following settings.

<?xml version="1.0"?>
<configuration>
  <configSections>
    <section name="categorizedSettings" type="TVA.Configuration.CategorizedSettingsSection, TVA.Core"/>
  </configSections>
  <categorizedSettings>
    <systemSettings>
      <add name="ConnectionString" value="" description="" encrypted="false" />
      <add name="DataProviderString" value="" description="" encrypted="false" />
    </systemSettings>
  </categorizedSettings>
  <startup>
    <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
  </startup>
</configuration>

The values for ConnectionString and DataProviderString can be copied from the configuration file used by your openPDC installation.