dohertj2/lmxopcua
1
0
Fork 0
Code Issues 5 Pull Requests Actions Packages Projects Releases Wiki Activity

Galaxy alarm Severity: H6 condition read 500 for AVEVA priority 400; verify #887 bands live (expect 750) #894

New Issue
Closed
opened 2026-11-12 23:24:13 -05:00 by dohertj2 · 2 comments
dohertj2 commented 2026-11-12 23:24:13 -05:00
Owner
Copy Link
Copy Source

Seen in both H6 runs (#614): 2026-11-11 (docs/drivers/evidence/galaxy-h6-ack-2026-11-11.md) and 2026-11-12 (docs/drivers/evidence/galaxy-h6-ack-2026-11-12.md, 8e846f0e).

Observed. Target Galaxy!CVDAisle_1.TableAlarms_008.RuntimeAlert on the vd03 gateway, AVEVA priority 400 ("Run Time Exceeded"). The OPC UA condition h6gal/vd03/RuntimeAlert on docker-dev site-b-1 reported Severity 500.

Most likely already fixed by #887, but not verified live.

  • The 400 on the Galaxy side is the alarm's AVEVA priority (1 = most urgent), not a severity, so 400 vs 500 is not a like-for-like mismatch.
  • The site-b-1 image used for the 11-12 run was built 2026-11-12T16:14Z. The #887 fix (b61f3e05, AVEVA priority bands on live alarms and history alike) landed at 17:14Z, an hour later. The 11-11 run predates it too.
  • The old MxAccessSeverityMapper mapped < 500 → 500, which gives 500 for priority 400, exactly what both runs saw.
  • On current master GalaxyAlarmPriority.Map(400) = High → 750, which matches AVEVA's own severity 2 (High band 251–500).

To do.

  1. Rebuild the docker-dev host image from current master (docker-dev/compose.sh up -d --build, #893) and read the same alarm's live condition (read-only, alarms --refresh; no ack needed). Expect Severity 750.
  2. Compare with the AVEVA history row for the same alarm (Runtime.dbo.v_AlarmEventHistory2, read-only). Its priority/severity should give the same 750 via the shared table.
  3. If it still reads 500, look at the TagConfig alarm.severity (400 in the H6 config) as a possible override of the live feed value, and at the host's generic 200/500/700/900 bucket ladder (#887 comment in GalaxyDriver.cs).

Close when the live value is confirmed as 750, or fix the path that overrides it.

Seen in both H6 runs (#614): 2026-11-11 (`docs/drivers/evidence/galaxy-h6-ack-2026-11-11.md`) and 2026-11-12 (`docs/drivers/evidence/galaxy-h6-ack-2026-11-12.md`, `8e846f0e`). **Observed.** Target `Galaxy!CVDAisle_1.TableAlarms_008.RuntimeAlert` on the vd03 gateway, AVEVA **priority 400** ("Run Time Exceeded"). The OPC UA condition `h6gal/vd03/RuntimeAlert` on docker-dev site-b-1 reported **Severity 500**. **Most likely already fixed by #887, but not verified live.** - The 400 on the Galaxy side is the alarm's AVEVA *priority* (1 = most urgent), not a severity, so 400 vs 500 is not a like-for-like mismatch. - The site-b-1 image used for the 11-12 run was built 2026-11-12T16:14Z. The #887 fix (`b61f3e05`, AVEVA priority bands on live alarms and history alike) landed at 17:14Z, an hour later. The 11-11 run predates it too. - The old `MxAccessSeverityMapper` mapped `< 500 → 500`, which gives 500 for priority 400, exactly what both runs saw. - On current master `GalaxyAlarmPriority.Map(400)` = High → **750**, which matches AVEVA's own severity 2 (High band 251–500). **To do.** 1. Rebuild the docker-dev host image from current master (`docker-dev/compose.sh up -d --build`, #893) and read the same alarm's live condition (read-only, `alarms --refresh`; no ack needed). Expect Severity **750**. 2. Compare with the AVEVA history row for the same alarm (`Runtime.dbo.v_AlarmEventHistory2`, read-only). Its priority/severity should give the same 750 via the shared table. 3. If it still reads 500, look at the `TagConfig` `alarm.severity` (400 in the H6 config) as a possible override of the live feed value, and at the host's generic 200/500/700/900 bucket ladder (#887 comment in `GalaxyDriver.cs`). Close when the live value is confirmed as 750, or fix the path that overrides it.
dohertj2 added the type:testpriority:p3 labels 2026-11-12 23:24:13 -05:00
dohertj2 commented 2026-11-12 23:30:49 -05:00
Author
Owner
Copy Link
Copy Source

Verified live: Severity 750 on current master. Closing.

Read-only run, 2026-11-13 ~04:28Z. No acknowledge, no Galaxy write, no ack account configured (AlarmAck unset), no remote exec on vd03.

Item Value
Image otopcua-host:sev894 built from origin/master 8e846f0e (contains #887 b61f3e05); the host DLL is stamped 1.0.0+8e846f0e62bdb3ca8a00407ae523f0f8054a554a (#893)
Node docker-dev site-b-1 (sole node, site-b-2 stopped for the run), OPC UA opc.tcp://localhost:4844
Driver temp sev894, GalaxyMxGateway → wonder-app-vd03.zmr.zimmer.com:5120 (h2c), ApiKeySecretRef=env:GALAXY_MXGW_API_KEY (runtime env only), WatchDeployEvents=false
Tag RuntimeAlert, attributeRef Galaxy!CVDAisle_1.TableAlarms_008.RuntimeAlert, alarm = {"alarmType":"AlarmCondition","severity":400,"historizeToAveva":false}, the same TagConfig as the H6 runs, so the authored alarm.severity 400 doesn't override the live value
Client otopcua-cli alarms --refresh (built from 8e846f0e), anonymous (ACLs off on the rig)

OPC UA condition (alarms --refresh, 04:28:16Z):

[2026-11-13T04:17:25.1730000Z] ALARM  sev894/vd03/RuntimeAlert
  Condition: RuntimeAlert
  State:     Active, Acknowledged
  Severity:  750
  Retain:    True
  ConditionNodeId: ns=2;s=sev894/vd03/RuntimeAlert

The H6 runs read Severity 500 for the same alarm on the pre-#887 image 5094b682cef5.

Gateway feed (QueryActiveAlarms, read-only): severity: 400, ALARM_CONDITION_STATE_ACTIVE_ACKED, lastTransitionTimestamp 2026-11-13T04:17:25.173Z. The state is acked because of the H6 ack.

AVEVA history (Runtime.dbo.v_AlarmEventHistory2, wonder-sql-vd03, read-only, EventStamp 2026-07-28 to 2026-11-13): every row for TableAlarms_008.RuntimeAlert has Priority 400. The raise is UNACK_ALM 2026-07-28 20:02:46.830Z, "Run Time Exceeded", and the latest row is the H6 ACK_ALM at 2026-11-13 04:17:25.173Z. The view has no Severity column. Priority 400 falls in AVEVA's High band (251–500), and GalaxyAlarmPriority.Map(400) maps that band to OPC UA 750, the same table EventMapper uses for history rows. So live and history agree.

Cleanup: the temp DriverInstance/Device/Tag (sev894*) were deleted and a cleanup deploy went out (08084f75); site-b-1 logged GalaxyDriver sev894 shutting down. No API key or ACL was created. The gate deployment 3f052639 (TimedOut while site-b-2 was down) carries only the env: reference, no credential. site-b-1 was recreated from the plain compose file on otopcua-host:dev, with the committed default gateway key. site-b-2 was restarted. The scratch image tag and the override were removed.

**Verified live: Severity 750 on current master. Closing.** Read-only run, 2026-11-13 ~04:28Z. No acknowledge, no Galaxy write, no ack account configured (`AlarmAck` unset), no remote exec on vd03. | Item | Value | |---|---| | Image | `otopcua-host:sev894` built from `origin/master` `8e846f0e` (contains #887 `b61f3e05`); the host DLL is stamped `1.0.0+8e846f0e62bdb3ca8a00407ae523f0f8054a554a` (#893) | | Node | docker-dev `site-b-1` (sole node, `site-b-2` stopped for the run), OPC UA `opc.tcp://localhost:4844` | | Driver | temp `sev894`, `GalaxyMxGateway` → `wonder-app-vd03.zmr.zimmer.com:5120` (h2c), `ApiKeySecretRef=env:GALAXY_MXGW_API_KEY` (runtime env only), `WatchDeployEvents=false` | | Tag | `RuntimeAlert`, `attributeRef` `Galaxy!CVDAisle_1.TableAlarms_008.RuntimeAlert`, `alarm` = `{"alarmType":"AlarmCondition","severity":400,"historizeToAveva":false}`, the same TagConfig as the H6 runs, so the authored `alarm.severity` 400 doesn't override the live value | | Client | `otopcua-cli alarms --refresh` (built from `8e846f0e`), anonymous (ACLs off on the rig) | **OPC UA condition (`alarms --refresh`, 04:28:16Z):** ``` [2026-11-13T04:17:25.1730000Z] ALARM sev894/vd03/RuntimeAlert Condition: RuntimeAlert State: Active, Acknowledged Severity: 750 Retain: True ConditionNodeId: ns=2;s=sev894/vd03/RuntimeAlert ``` The H6 runs read Severity 500 for the same alarm on the pre-#887 image `5094b682cef5`. **Gateway feed (`QueryActiveAlarms`, read-only):** `severity: 400`, `ALARM_CONDITION_STATE_ACTIVE_ACKED`, `lastTransitionTimestamp 2026-11-13T04:17:25.173Z`. The state is acked because of the H6 ack. **AVEVA history (`Runtime.dbo.v_AlarmEventHistory2`, wonder-sql-vd03, read-only, `EventStamp` 2026-07-28 to 2026-11-13):** every row for `TableAlarms_008.RuntimeAlert` has **Priority 400**. The raise is `UNACK_ALM` 2026-07-28 20:02:46.830Z, "Run Time Exceeded", and the latest row is the H6 `ACK_ALM` at 2026-11-13 04:17:25.173Z. The view has no Severity column. Priority 400 falls in AVEVA's High band (251–500), and `GalaxyAlarmPriority.Map(400)` maps that band to OPC UA **750**, the same table `EventMapper` uses for history rows. So live and history agree. **Cleanup:** the temp `DriverInstance`/`Device`/`Tag` (`sev894*`) were deleted and a cleanup deploy went out (`08084f75`); site-b-1 logged `GalaxyDriver sev894 shutting down`. No API key or ACL was created. The gate deployment `3f052639` (TimedOut while site-b-2 was down) carries only the `env:` reference, no credential. site-b-1 was recreated from the plain compose file on `otopcua-host:dev`, with the committed default gateway key. site-b-2 was restarted. The scratch image tag and the override were removed.
dohertj2 commented 2026-11-12 23:37:53 -05:00
Author
Owner
Copy Link
Copy Source

Live data point from the #615 G6 gate, 2026-11-12. This was not the vd03 target: the run used the windev test Galaxy through mxaccessgw 447070a5, on OtOpcUa 00a5be26, which includes the #887 fix b61f3e05.

  • For Galaxy!TestArea.TestMachine_015.TestAlarm002 the gateway reported severity 500 (AVEVA priority 500, High band). The live OPC UA condition read Severity 750.
  • The authored alarm.severity was 500 for that alarm and 700 for a second one. The feed value overrode both, which rules out step 3 (a TagConfig override).
  • The second alarm, TestAlarm003, has the same priority and also read 750.

Not closing: steps 1 and 2 of this issue name the vd03 RuntimeAlert alarm and its AVEVA history row, and this run read neither. Evidence: docs/drivers/evidence/galaxy-g6-e2e-2026-11-12.md, Step 5.

Live data point from the #615 G6 gate, 2026-11-12. This was not the vd03 target: the run used the windev test Galaxy through mxaccessgw `447070a5`, on OtOpcUa `00a5be26`, which includes the #887 fix `b61f3e05`. - For `Galaxy!TestArea.TestMachine_015.TestAlarm002` the gateway reported `severity 500` (AVEVA priority 500, High band). The live OPC UA condition read **Severity 750**. - The authored `alarm.severity` was 500 for that alarm and 700 for a second one. The feed value overrode both, which rules out step 3 (a TagConfig override). - The second alarm, `TestAlarm003`, has the same priority and also read 750. Not closing: steps 1 and 2 of this issue name the vd03 `RuntimeAlert` alarm and its AVEVA history row, and this run read neither. Evidence: `docs/drivers/evidence/galaxy-g6-e2e-2026-11-12.md`, Step 5.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
auto-managed
queue management
 blocked
Blocked by dependency or external hold
 cross-driver
queue management
 cross-repo
Needs coordinated change in another family repo (wire contract etc.)
 driver/abcip
queue management
 driver/ablegacy
queue management
 driver/focas
queue management
 driver/mqtt
MQTT / Sparkplug B broker-subscribe driver
 driver/opcuaclient
queue management
 driver/s7
queue management
 driver/twincat
queue management
 migrated
Migrated from a markdown backlog (2026-11 standardization)
 phase/1
queue management
 phase/2
queue management
 phase/3
queue management
 phase/4
queue management
 phase/5
queue management
 phase/6
queue management
 priority:p0
Must-have / blocking
 priority:p1
High priority
 priority:p2
Normal priority
 priority:p3
Low priority / nice to have
 queue/blocked
queue management
 queue/done
queue management
 queue/failed
queue management
 queue/in-progress
queue management
 queue/queued
queue management
 type:bug
Defect in shipped behaviour
 type:debt
Technical debt / hygiene
 type:deploy-gate
Rollout/deploy/migration step not yet done on an environment
 type:docs
Documentation work
 type:feature
Feature implementation
 type:followup
Follow-up deferred from a plan, PR or gate
 type:infra
Infrastructure and scaffolding
 type:review-finding
Unfixed finding from an architecture/code review
 type:test
Test work
No Label priority:p3 type:test
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
dohertj2 (dohertj2)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dohertj2/lmxopcua#894
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?