Skill Alarm Pipeline

---
title: "Alarm Pipeline — Groups, Areas, and Items"
tags: [alarm, alarms, alert, notification, group, area, limit, digital, pipeline, monitoring]
description: "Configure a complete alarm system: groups for severity, areas for organization, items for individual tag monitoring with limit and digital alarm types"
version: "1.0"
author: "Tatsoft"
---

Set up a complete alarm system from scratch: Groups for severity classification, Areas for plant organization, and Items for individual tag monitoring with limit-based and digital alarm types.

AlarmsGroups (severity, colors, sounds)
    ??? AlarmsAreas (plant hierarchy — optional)
         ??? AlarmsItems (one per tag condition)
              ??? Watches UnsTags values at runtime

When to Use This Skill

Use this skill when:

• The user wants to add alarms or alerts to a solution
• The user mentions "alarm", "alert", "notification", "limit", "out of range"
• The user wants to monitor tags for abnormal conditions
• Building on top of an existing solution that has tags but no alarms

Do NOT use this skill when:

• The user wants ML-based anomaly detection (use skill-edge-ml-pipeline)
• The user only needs to view existing alarms (use designer_action('navigate', 'AlarmsMonitor'))

Prerequisites

• Solution must have tags (UnsTags) configured
• Tags should have realistic values (simulator or real device)

MCP Tools and Tables Involved

Implementation Steps

Step 1: Create Alarm Groups

Groups define severity levels and shared behavior. Create at least Critical, Warning, and Info.

get_table_schema('AlarmsGroups')

{
  "table_type": "AlarmsGroups",
  "data": [
    {
      "Name": "Critical",
      "Description": "Immediate action required — safety or equipment risk"
    },
    {
      "Name": "Warning",
      "Description": "Attention needed — process approaching limits"
    },
    {
      "Name": "Info",
      "Description": "Informational — logged but no immediate action"
    }
  ]
}

Key decisions:

• Group names should reflect severity, not equipment (alarms from any area can belong to "Critical")
• Keep the number of groups small (3-5). More granularity comes from Areas.

Step 2: Create Alarm Areas (Optional)

Areas organize alarms by plant location or process unit. They can be nested. Skip this step for simple solutions.

get_table_schema('AlarmsAreas')

{
  "table_type": "AlarmsAreas",
  "data": [
    {
      "Name": "Plant",
      "Description": "Entire plant"
    },
    {
      "Name": "Plant/Reactor1",
      "Description": "Reactor 1 process area"
    },
    {
      "Name": "Plant/Utilities",
      "Description": "Utility systems"
    }
  ]
}

Key decision: Area paths mirror the tag folder structure for consistency. Plant/Reactor1 area contains alarms for Plant/Reactor1/* tags.

Step 3: Create Alarm Items

Each item monitors one tag for one condition. The two main types are Limit (analog thresholds) and Digital (boolean state).

get_table_schema('AlarmsItems')

Limit alarms — trigger when a value exceeds a threshold:

{
  "table_type": "AlarmsItems",
  "data": [
    {
      "Name": "Reactor1_TempHigh",
      "Group": "Critical",
      "TagName": "Plant/Reactor1/Temperature",
      "Type": "HighLimit",
      "Limit": 90.0,
      "Description": "Reactor 1 temperature exceeded 90°C"
    },
    {
      "Name": "Reactor1_TempWarn",
      "Group": "Warning",
      "TagName": "Plant/Reactor1/Temperature",
      "Type": "HighLimit",
      "Limit": 75.0,
      "Description": "Reactor 1 temperature approaching limit (75°C)"
    },
    {
      "Name": "Reactor1_PressureHigh",
      "Group": "Critical",
      "TagName": "Plant/Reactor1/Pressure",
      "Type": "HighLimit",
      "Limit": 4.5,
      "Description": "Reactor 1 pressure exceeded 4.5 bar"
    },
    {
      "Name": "Reactor1_LevelLow",
      "Group": "Warning",
      "TagName": "Plant/Reactor1/Level",
      "Type": "LowLimit",
      "Limit": 10.0,
      "Description": "Reactor 1 level below 10%"
    }
  ]
}

Digital alarms — trigger on a boolean tag:

{
  "table_type": "AlarmsItems",
  "data": [
    {
      "Name": "Reactor1_AnomalyDetected",
      "Group": "Warning",
      "TagName": "Plant/Reactor1/ML/IsAnomaly",
      "Type": "Digital",
      "Description": "ML model detected anomaly on Reactor 1"
    }
  ]
}

Key decisions:

• One alarm item per condition. A tag can have multiple alarms (high-warn at 75, high-critical at 90).
• Type values: HighLimit, LowLimit, HighHighLimit, LowLowLimit, Digital. Always verify with get_table_schema.
• Limit is required for limit-type alarms, ignored for digital alarms.
• The Name should be descriptive and unique across all alarm items.

Step 4: Verify Configuration

get_objects('AlarmsGroups')
get_objects('AlarmsItems')

Then start or hot-reload runtime:

designer_action('hot_reload')

Verification

1. get_objects('AlarmsGroups') — confirm groups exist (Critical, Warning, Info)
2. get_objects('AlarmsItems') — confirm all alarm items are configured
3. get_designer_state() — no errors
4. Start runtime → navigate to AlarmsMonitor → verify alarms trigger when thresholds are crossed
5. browse_namespace('Alarm.Group.Critical') — check alarm counts at runtime

Common Pitfalls

Related Skills

• skill-getting-started — Create tags and simulator (prerequisite)
• skill-edge-ml-pipeline — Add ML-based anomaly detection that feeds into alarms
• skill-historian-configuration — Log alarm history for analysis

In this section...