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

AVEVA Enterprise SCADA

TABLE OF CONTENTS

Best practices

Save PDF
Save selected topicSave selected topic and subtopicsSave all topics
Share
Share to emailCopy topic URL
  • Last UpdatedApr 24, 2025
  • 1 minute read

The AddSYSalarm Application Programming Interface (API) publishes system alarms to third-party applications. The System Alarm Routing feature enables you to configure a third-party application to override system alarms. If the third-party application calls the existing addSYSalarm API to override the original alarm, the feature can fall into an infinite recursion loop of publishing the modified version of the alarm. An UpdateSYSAlarm API exists to prevent this issue. The third-party application should only use the UpdateSYSAlarm API to raise the system alarm. Since AVEVA has no control over how a third-party application is written, AVEVA asks that you follow the guidelines below to maintain the stability and reliability of the AVEVA Enterprise SCADA system:

  • Third-party applications making use of the System Alarm Routing feature should call neither the existing addSYSalarm API nor a Business Logic Tier (BLT) to raise the system alarms: they should only call the UpdateSYSAlarm API to raise these alarms.

  • Third-party applications can call the existing addDBalarm and addAPPalarm APIs or BLTs, as these APIs are unaffected by the System Alarm Routing feature.

  • Third-party applications not making use of the System Alarm Routing feature have no restrictions as to which alarm APIs or BLTs they can call.