---
manual: IM 36K10L15-01EN
title: Alarm Management Engineering
edition: 4th Edition, Feb. 2026 (R1.05); content unchanged since the 3rd Edition, Sep. 2023 (R1.03): full text diff 2026-10-09 found only contact information
version: R1.05 (first written for R1.03)
status: R1.05 - processes, setup files, almdbg 1/9/12 and alhdbg 1 checked read-only on the R1.05 test server (2026-10-09); setup files and alarm dataset definitions identical to R1.03 except alarm_start/stop.cmd (extension scripts), alnsms.sup defaults and the new internal dataset ALARM_ATTRIBUTE_TEMP_DF; alarm behaviour not re-tested on R1.05 (shared server). R1.03 - verified for item-based alarms (acknowledgement type, AOI, ASA, ALARMING, alarm events, acknowledge, almdbg/alhdbg) on CI-Eng-Sample 2026-10-01; first-out, collections, notifications, shelving, acoustic/count destinations from docs; setup files checked read-only
---

# Alarm Management Engineering (R1.05)

**R1.05 changes**: the manual text is the same as in R1.03 (revision table and full text diff,
2026-10-09). Installed software (R1.05 test server, compared with R1.03 by file hash and line
by line): `alm.sup`, `alh.sup`, `aldprt.sup`, `aldaco.sup`, `aldcnt.sup`, `alnmgr.sup`,
`alnsmtp.sup`, `asbman.sup`, `wfladi.sup`, their templates and the alarm dataset definitions
are identical. Different: `alarm_start.cmd` / `alarm_stop.cmd` call extension scripts
`?*_alarm_start.cmd` / `?*_alarm_stop.cmd` (§1, ISS-121); `alnsms.sup` defaults (§10,
ISS-134); new internal dataset `ALARM_ATTRIBUTE_TEMP_DF` (§7, ISS-133). R1.04 added the
display-side acknowledgement with reason and approver (C50, ISS-099); the kernel is unchanged.

ALARM Service turns item status changes (and external alarms, informational events) into
**alarm events**, distributes them to **destinations** and stores them. Section numbers refer to
the manual. Engineering Module forms for the same functions: `IM36K10C20-01EN.md`.

## 1. Processes (§1)

| Process | Role | Started by default |
|---|---|---|
| `ALM` | Alarm kernel: receives item-based events from ITEM Service and non-item-based events from applications, builds alarm events, sends them to destinations | yes |
| `ALH` | Alarm storage: current alarms (time and priority) and chronological history in storage group **`ALH`** | yes |
| `ALDPRT` | Printer destination: formats alarm lines for UMH, stderr or a printer | yes |
| `ALMUPD` | Recovery process (sends *Start recovery session* to ALM) | — |
| `ALNMGR`, `ALNSMTP`, `ALNSMS` | Notification manager, e-mail, SMS | `ALNMGR`, `ALNSMTP` yes |
| `ASBMAN` | Alarm shelving | yes |
| `ALDCNT` | Count destination (counts events into an item) | no (`alarm_start.cmd`, commented) |
| `ALDACO` | Acoustic destination (WAV or command) | no (`integration_start`) |
| `ALHCUR`, `ALHCHR` | Split current / history storage (ALH becomes a router) | no |

Blocks: ALM (kernel), ALH (storage), ALD (destinations), ALC (alarm selection areas).
Installed `alarm_start.cmd` starts `alm`, `alh`, `aldprt`, `alnmgr`, `alnsmtp`, `asbman`
(R1.03 and R1.05). On R1.05 it then calls every `?*_alarm_start.cmd` in `tls\com`, and
`alarm_stop.cmd` first calls every `?*_alarm_stop.cmd`: the place to start `aldcnt`, `alnsms`
or extra `aldaco` processes without editing the installed script (ISS-121; not tested).

**Verified:** `almdbg` option 1 lists the connected destinations `ALH`, `OPXUAS` (OPC UA server
A&C), `ALNMGR`, `ALDPRT` (R1.03); on the R1.05 test server also `WFLADI` (an open alarm
overview), 2026-10-09.

## 2. Alarm sources and states (§2.1)

- **Item-based**: ITEM Service compares the value with the limits and sets the item status
  (LOW LOW < low-low limit ≤ LOW < low limit ≤ NORMAL ≤ high limit < HIGH ≤ high-high limit <
  HIGH HIGH). Each item status maps to one of four **alarm states**: Normal (N), Alarm 1–3
  (A1–A3). The mapping is system-wide in `STATUS_DF` (`ALARM_STATE`, `ALARM_PRIO`, colour,
  mnemonic, shelve flag) and can be overridden per item (up to 6 statuses, `ITEM_DF`
  `ITEM_STAT_n`, `ALARM_STATE_n`, `PRIORITY_n`, `ALARM_TEXT_n`, …).
  Installed `STATUS_DF`: NORMAL 9 → Normal/prio 15, HIGH 10 → Alarm 2/prio 2, HIGH HIGH 11 →
  Alarm 3/prio 1 (140 statuses).
- Every status change is an alarm state transition, even when old and new state are equal
  (e.g. LOW → HIGH, both A2).
- **External alarms**: OPC A&E (mapped to items, uses force to alarm/normal) and OPC UA A&C
  (EAL definitions) — see C20 summary part B and `IM36K10L45-01EN.md`.
- **Informational events**: from equipment data sources (OPC UA/A&E clients, STARDOM) or
  applications; shown only in history.

## 3. Alarm event types (§2.2)

ALARM, NORMAL, DIRECT, DELAY, REPEAT, ACKNOWLEDGE, INFORMATIONAL, DEACTIVATE, RECOVERY,
DIAGNOSTIC, QUALITY, PRIORITY, FIRSTUP. External OPC UA alarms never get RECOVERY.

**Verified** (dataset `ALARM_CHRONO`, column `EVENT_TYPE`): switching on `ALARMING` gave a
`NORMAL` event; 44.4 → 85 gave `ALARM` (HIGH, Normal → Alarm 2, prio 2, `ACK` 0); acknowledging
gave two `ACKNOW` records (the second carries the node name: `ACK_INFO` is set in `alm.sup`);
85 → 50 gave `NORMAL`.

## 4. Kernel mechanisms (§2.3)

| Mechanism | Behaviour | External alarms |
|---|---|---|
| Delay (item `DELAY`, s) | N → Ax gives DIRECT, timer starts; at expiry DELAY (with the latest state). Back to N during the delay: NORMAL, no DELAY. Another Ax during the delay: DIRECT, timer keeps running. No delay if the previous Normal was not acknowledged | yes |
| Repeat (item `REPEAT`, s) | ALARM, then REPEAT every period while in alarm; a new alarm state restarts the timer | yes |
| First-out (§2.3.3) | Group of first-out items and continuation items. While a first-out item is in alarm (*internal-active*), new continuation alarms give only DIRECT; when the group goes inactive (after the optional internal delay) still-standing continuation alarms give ALARM. Parent groups make child groups *external-active* (all new alarms DIRECT) with an external delay | yes |
| Acknowledgement (§2.3.4) | Acknowledgement matrix per **acknowledgement type**: for each (old state, old Ack/Nack) → new state, automatic or manual. Manual ack by an operator gives an ACKNOWLEDGE event; automatic ack gives none | yes (Inactive/Active matrix) |
| Change priority (§2.3.5) | `alm.sup` `PRIORITY = <old>,<seconds>,<new>`: an unacknowledged alarm of priority *old* gets a PRIORITY event with *new* after the time; chains (max 16 useful) | — |
| Force to normal / to alarm (§2.3.6–7) | Engineering Module *Update value* check boxes (authorised users); option bit, `itm_set_gen()` from programs; also for EALs after a long OPC UA disconnection | yes |
| Force an event (§2.3.8) | Criteria mask `ITM_CRI_EVENT`: event without state change | — |

Precedence (§2.3.9): delay → first-out → repeat → change priority (repeat and change priority
start together, after the ALARM).

Special events (§2.4): DEACTIVATE when alarming is switched off (or an EAL deleted) — the alarm
leaves the current overview; RECOVERY from the recovery process; DIAGNOSTIC for items marked
diagnostic; QUALITY when only the quality changed (needs `QUALITY_CODE` in `alm.sup`).

Recovery (§2.5): after queue overflows ALM sends RECOVERY events for every item in sets
(`REC_ITM`, default 25, `REC_WAIT` 500 ms, `REC_CYCL` 1). External alarms are refreshed by the
OPC UA client with *ConditionRefresh* (at connect, reconnect, redundancy switch, or *On scan*).

## 5. Acknowledgement types (dataset `ALARM_ACK_DF`)

Fields `<from><A|N>_<to>`: from state `N`, `A1`, `A2`, `A3`; `A` = was acknowledged, `N` = was
not; to state `N`, `A1`, `A2`, `A3`. Value 1 = automatic, 0 = manual (operator). 32 fields;
`EAL_ACK` 1 = external-alarm type (8 fields used). Name and the external flag cannot be changed
later; a type in use cannot be deleted (verified: `DSSP-E-NODEL … By <item> in dataset ITEM_DF`).
Items with no type behave like `AUTOMATIC`; EALs with none use `FULLMANUAL_EAL`.

Installed types: `AUTOMATIC` (all 1), `MANUAL` (only `NA_N`, `NN_N`, `A1A_N`, `A2A_N`, `A3A_N`
= 1), `FULLMANUAL` (all 0) and the `_EAL` variants (`AUTOMATIC_EAL`, `MANUAL_EAL`,
`FULLMANUAL_EAL`). `almdbg` 9/10 lists the types by number and prints the matrix.

**Verified with `CIENG_ACK` (same matrix as MANUAL):** HIGH alarm came in unacknowledged;
acknowledged, then back to normal → automatically acknowledged, gone from `ALARM_CURRENT`.
HIGH HIGH back to normal *without* acknowledgement → stayed in `ALARM_CURRENT` (NORMAL, `ACK` 0)
until acknowledged.

## 6. Kernel setup file `alm.sup` (§2.6)

`QUESIZE` (KB, default 25000), `PRIO_ACK_ABS` / `PRIO_ACK_REL` (priority after ack),
`ACK_INFO` (send node/terminal/user with acknowledgements), `QUALITY_CODE`, `PRIORITY` (change
priority list), `SUPPR_ACK_CHG`, `SYNC_COMM` (async DUR to destinations), `SYNC_MSG`,
`PRESERVE_PRIO`, `HIGHEST_PRIO` (15 or 0 = most important), recovery tab `REC_CYCL`, `REC_ITM`,
`REC_WAIT`, `RECOVER_ALL`, `RECOVER_QUEUE`.

**Installed:** `SYNC_COMM N`, `SYNC_MSG N`, `QUESIZE 25000`, `RECOVER_QUEUE Y`, `ACK_INFO`.

## 7. Storage process (§3)

- Three storage classes: current by time, current by priority, chronological (`CURT`, `CURP`,
  `CHR` in `alh.sup`; all on by default). Current alarms live in memory unless `MEM-WRT` is
  off; history is always on disk.
- `alh.sup`: `FPATH`, `ALM-PROC`, `DEF-WRT` (VMS only), `MEM-WRT`, `QUESIZE` (8000 KB),
  `MAX-OPEN-UNITS` (2–100, default 5), `MAX-SEARCH` (s per history search, default 5),
  `RECOVER_QUEUE`.
- Multi-process: copy `arh.sup` to `alhchr.sup` / `alhcur.sup`, uncomment their lines in
  `alarm_start.cmd`; the router `alh.sup` then holds only `QUESIZE`.
- **Installed `alh.sup`**: `CURP`, `CURT`, `CHR`, `QUESIZE 8000`, `MAX-SEARCH 5`,
  `RECOVER_QUEUE Y`, plus `DB-JRNL = WAL` and `DB-SYNC = OFF`, not in the manual (ISS-036).
- Datasets: `ALARM_CURRENT` (standing and unacknowledged alarms), `ALARM_CHRONO` (history; not
  exported unless named, filter with `@SELECT`). External alarm definitions are in
  `EXTERNAL_ALARM_DF`; `ALARM_EXT_CURR` is only a default report name, not a dataset.
- **Installed storage group `ALH`** (`HIS_GROUP_DF`): type Alarm, rollover 1 day, lifetime
  **52 weeks** (the C20 manual gives 2 days as the default; ISS-036). The fresh R1.05 install
  on the test server has the same 52 weeks, so this is the installed default (ISS-135).
- **Alarm attributes** (CI attributes): definitions in `ALARM_ATTRIBUTE_DF`, current values in
  `tls\dat\alarm_attribute_current.db` (R1.03 and R1.05). R1.05 adds `ALARM_ATTRIBUTE_TEMP_DF`
  (same fields, no data file, concealed on an enterprise server, header: temporary store for
  item-specific alarm attributes). On the R1.05 test server it is empty and used only by the
  RESTful API server; not described in any manual — internal, leave it alone (ISS-133).
- **Heavy load (R1.05 test server, observed by earlier work):** an alarm overview filtered by
  an ASA on `SECTION` or `UNIT` kept `ALH` at a full CPU core and timed out the alarm lists of
  every client (ISS-136). Avoid such overviews and unfiltered `ALARM_CHRONO` reads on shared
  servers.

## 8. Destination processes (§4)

- Each destination registers with ALM giving the event types it wants (`EVENTS = direct,
  alarm, repeat, ackn, info, deact, recov, diag, qual, prio, firstup`; ALARM includes DELAY and
  NORMAL) and/or an alarm selection area (`DEST-ASA`); not both.
- Alarm line (`FORMAT = <unit>,<length>,…`): `ACKN`, `NAM1`–`NAM4`, `SECTION`, `NAME`, `PRIO`,
  `TYPE`, time formats `TANS/TEUR/TGEN/TDEF/TJUL/TFMT` (and `ST…` for the original timestamp),
  `TEXT`, `NWLN`, `SPAC`, `VAL` (`VAL-PREC`), `QC_DEC`, `QC_HEX`, `ITM_DESC`, `ENG_UNIT`, OPC
  fields `EVT_CAT`, `SOURCE`, `COND`, `SUBC`, `ACTOR_ID` and combined `C_…` variants. `TIMEFMT`
  picture string (installed keyword name; the manual also writes `TIMFMT`).
- **`ALDPRT`** (setup file = process name): `LOGUMH` / `LOGSCN` / `LOGPRT` (+ `PRTDEV` or
  `PRTQUE`, `PRTBUF`), `HEADER … HEADEREND`, `DEST-TYPE`, `ALDMAN`, `PRIO-DEST`. With no log
  destination set it logs via UMH. **Installed:** `FORMAT prio,2,spac,1,type,6,tdef,18,name,40,
  text,10`, `EVENTS repeat,info,ackn,alarm,prio,firstup`, header every 10 lines. On the test
  system ALDPRT received the events (`almdbg` counter) but no alarm line appeared in
  `umhlog.log` (ISS-035).
- **`ALDCNT`**: counts events into `ITEM-NAME` (required), wraps at `MAX-COUNT` (1500); not the
  number of standing alarms. Installed file has the placeholder item.
- **`ALDACO`**: `PLAY` (WAV, Windows, needs a logged-in user) or `COMMAND`, `SILENCE =
  <item>,<ms>` repeats until the item is NORMAL, `DEF-NODE`, `QUE-SIZE` (30 KB). One process per
  sound (e.g. `-n aco_p1` with `aco_p1.sup`, each with its own ASA). On a CI Portal prefer the
  graphic alarm sound component.
- Setup files of alarm displays are read each time a display opens; removing comments speeds
  this up (keep a backup).

## 9. Debuggers (§6)

`almdbg` (menu, `-1` exit; answers can be piped):

| No. | Action | Notes |
|---|---|---|
| 1 / 2 / 3 | Destinations / detail / disconnect | read-only except 3 |
| 5–8, 27, 28 | First-out groups, children, first-out and continuation items/EALs | read-only |
| 9 / 10 | Acknowledgement types / matrix of one type number | read-only |
| 11 | Repeat/delay list | read-only |
| 12 | Statistics (events received/sent, list sizes) | read-only |
| 13 | Item recovery | |
| 14 | Item alarm parameters (by name): monitoring, ack type number, collection, first-out, repeat, delay | read-only |
| 15 | Preset an item status | changes data |
| 16 | Generate non-item-based (INFO) event: timestamp, ms, priority, name, status text, description | 6 prompts; history only |
| 17, 19, 20 | Stop ALM / ALH / ALDPRT | never without approval |
| 22 | Diagnostic message for an item or EAL | |
| 23–26 | Collections: list, detail, reset, acknowledge | |

`alhdbg`: 1 storage groups (verified: group 3, unit 80, current cell start; R1.05 test server
2026-10-09: group 3 as well), 2 units of a group, 3 force connect to kernel, 4 tidy stop (never
without approval). On R1.05, `almdbg` 1, 9 and 12 gave the same kind of output as on R1.03
(six ack types; statistics with start time and event counters).

Piping `-1` at the end makes DURTIM log `Process ALMDBG_<pid> exited unexpectedly` — harmless.

## 10. Notifications and shelving (§7, §8)

- `alnmgr.sup`: `EVENTS` (alarm, firstup), `ALM-PROC`, `QUE-SIZE` (500 KB), `DBG-LEVEL`,
  `MAX-LOG`, `MAX-LIFE-TIME`, `MAX-CLEAR-TIME`, `ACK_STOPS_REPEAT`, `INT-QUE-SIZE` (1000).
- `alnsmtp.sup`: `SMTP_SRV` (installed `localhost, 25`), `FROM_ADDRESS`
  (`admin@localhost.com`), `SMTP_TIMEOUT` 10, `EMAILS_PER_CONN` 1, `SMTP_INACTIVE`,
  `D_LEVEL`, `MAX_LOG`, `SUBJ_FORMAT` / `BODY_FORMAT` (+ `…_TIMEFMT`), `VAL-PREC`,
  `ALARM_PREFIX [ALARM]`, `CLEAR_PREFIX [CLEAR]`, `SUFFIX`. Only SMTP servers without
  authentication or encryption.
- `alnsms.sup`: `SMS_PORT` (installed `COM1:`), AT-command modem, serial line settings.
  R1.05 (installed file and template, ISS-134): the format help adds the units `SECTION` and
  `NAME`; the active defaults are now `BODY_FORMAT = PRIO,2,SPAC,1,TYPE,6,TDEF,18,TEXT,6,
  SECTION,120` (R1.03: `…,nam1,16,nam2,16,nam3,16,nam4,16,text,32`) and `ALARM_PREFIX = PRIO`
  (R1.03 `<ALARM>`; the help still describes a plain prefix string). `CLEAR_PREFIX <CLEAR>`
  unchanged. `alnsms` is still not started by default. Not tested (no GSM modem).
- `asbman.sup`: `QUE-SIZE` 500, `TICKER_INTERVAL` 2 s, `SYS_WIDE_SHELF` (installed `N`:
  shelving kept per CI View) with optional count items, `DEBUG_ON`. Same setting on every node.
  In enterprise mode use the alarm overview *Location* column.
- Known issue (IM 36K01A50 §1.6): shelving more than ~500 alarms can overflow the DURM queue.

Not practiced: notifications (no SMTP server), shelving (needs a CI View display), acoustic and
count destinations, split storage processes.