ci-server-engineer/knowledge/manuals/IM36K10E30-01EN.md
cliu bf7d88a027 R1.05 re-check batch 3: alarms, audit, authorization, classes, HAC, reporting, pyTOOLS
Full manual diffs (L15, C20, E30, L25, J40, C10 §2, L10, P10, P11, J20,
C30, P20, R40, E10) and read-only checks on the shared R1.05 test server.
Skills and summaries moved to R1.05; new skill pytools (IM 36K10P40) from
docs (no Python on the test server). Issues ISS-132..181; corrections to
version-differences (E10, E30, P11, dss_ath_grp_u0104); C10 summary lists
the 3 new authorization actions; r105-verification V10-V17.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-09 10:21:36 +11:00

90 lines
5.5 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
manual: IM 36K10E30-01EN
title: Alarm System Performance Analysis
edition: 4th Edition, Feb. 2026 (R1.05; first summarized from the 3rd Edition, Sep. 2023, R1.03)
version: R1.05 (first written for R1.03)
status: from docs; launcher and fetch limits (jwuiaan.sup) checked read-only on R1.03 (2026-10-01); R1.05 - full text diff against R1.03 (2026-10-09): only the KPI chart labels of §3.2 changed; launcher, debug launcher, template and jwuiaan.sup identical to R1.03 by file hash (2026-10-08); GUI not practiced on either version
---
# Alarm System Performance Analysis (R1.05)
**R1.05 changes** (full text diff against the R1.03 edition, 2026-10-09; the revision table
lists only contact information): §3.2 *Acknowledge* tab, *KPI Grid* sub tab — the four alarm
count charts now carry the labels *In Time*, *Too Late*, *Not Ackn* and *Nuisance*. The third
chart was described in R1.03 as alarms acknowledged within the analysed period; R1.05 corrects
it to alarms **not** acknowledged within the period. Nothing else changed. The ASPA GUI was not
opened on the R1.05 test server.
The **ASPA tool** fetches alarm events from a CI Core and analyses them with views based on
EEMUA 191 and ISA 18.2: operator load, acknowledgement times, floods, top offenders, long
standing, repeats, consequential alarms, and a summary of KPIs against targets. Section numbers
refer to the manual.
## 1. Start and limits (§1)
- Start from the CI Server program menu (installed launcher `%TLS_ROOT_PATH%\tls\com\jwuiaan.cmd`,
debug variant `jwuiaan_debug.cmd`) and log on with a CI Server user.
- Workflow: define filters → *Get alarms* → tabs fill automatically (sequentially by default;
can take hours on big data) → adjust the fields under each tab → print / export → repeat.
- Fetch limits protect the PC and the server: `jwuiaan.sup` (*Tuning* tab).
**Installed:** `JDSS_MSG_FETCH_NUMBER_REMOTE = 50000`, `JDSS_MSG_FETCH_NUMBER_LOCAL = 100000`.
- An *alarm* belongs to one item and lasts from arising to return to normal; repeats and status
changes (HIGH → HIGH HIGH) are *alarm events* of the same alarm.
- Menus: print, export chart (PNG, current zoom) or table (CSV, XML), export/import user
filters (`.filter`), save/load ASPA database, tab filling control (parallel / sequential /
stop and disable auto-fill / current tab), big font, save application log (for support).
## 2. Filtering area (§2)
| Part | Use |
|---|---|
| Time filter | Main period (start < end) plus optional comparison periods (same length, own start) |
| Filtering mode | Use only the selected group-filter tab, or AND of all tabs |
| Group filter | Up to 9 groups (number + colour), each by *User (ASA)* (the ASA of a user), *Item name* (section drill-down or typed), *ASA*, *AOI*, *Coll*; *ColorAndVisibility* tab; counts per period shown after fetching |
| Acknowledge filter | Only unacknowledged; min / max duration to acknowledge |
| Save/Load filter | In memory only (lost on exit); use *Export User Filters* to keep them |
Users, ASAs, AOIs and collections come from the Engineering Module (C20 summary §A8, §A6).
## 3. Reporting tabs (§3)
| Tab | Shows | Main settings |
|---|---|---|
| Load | Max/average alarm rate and % time above the acceptable rate per group (KPI, timelines, grid, distribution pie) | Acceptable *A* alarms per *B* minutes, interval (h) |
| Acknowledge | KPI charts *In Time* / *Too Late* / *Not Ackn* (not acknowledged within the analysed period) / *Nuisance* (cleared before ack within the acceptable time; labels named in R1.04+), average ack time; detail per alarm | Acceptable acknowledge time, interval |
| Count | Alarms per interval per group | Interval, stacked, labels |
| Floods | Only intervals above a minimum count (trips, start-ups) | Measure period, min. alarms |
| Top Ten | Items with most alarms (Top 1–100), durations | Absolute / percent |
| Long Standing | Longest (or shortest) standing alarms; still-standing alarms ignored | Long/short, top N |
| Repeat | Items with most repeats | Top N |
| Item status | Alarms per status (HIGH, HIGH HIGH, …) | Period |
| Consequential | Pairs A → B within *Max. Seconds*: total, consequential count, correlation % | Max seconds, min correlation, same status only |
| Time Line | Periods of alarm activity per group, per priority, for the top N | Top N |
| All Alarms | Every fetched alarm with arise / ack / normal times and durations | — |
| Summary | KPIs vs targets (needs ≥ 30 days of data) | Chattering period (s) |
Charts zoom with drag (Shift-drag zooms out) and pan with right-drag; tables sort, resize and
filter by column (funnel icon).
## 4. Summary KPIs and targets (§3.12)
| Metric | Target |
|---|---|
| Average annunciated alarms per day | 150–300 at most |
| … per hour | 6–12 at most |
| … per 10 minutes | 1–2 at most |
| % hours with more than 30 alarms | < 1 % |
| % 10-minute periods with more than 10 alarms | < 1 % |
| Maximum alarms in a 10-minute period | < 11 |
| % time in flood (starts above 10 alarms / 10 min, ends below 5) | < 1 % |
| Top 10 alarms as % of all alarms | < 1 % to 5 % |
| Chattering and fleeting alarms | 0 |
| Alarms standing > 24 h | < 5 per day |
| Priority distribution | low > 80 %, medium < 15 %, high < 5 %, highest < 1 % |
| Unauthorised suppressions / attribute changes | 0 |
Priority categories 0–15 are not fixed to an importance; `alm.sup` `HIGHEST_PRIO` decides which
end is most important (L15 summary §6).
Not practiced: the ASPA GUI (needs a logged-on user session and meaningful alarm history; the
test system has only a few sample alarms).