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

docs: alarms-over-gateway plan banner — record A.2 dev-rig finding

Browse Source 
Replaces the "ships as a follow-up gated on dev-rig validation"
banner with the actual finding from the dev-rig inspection: the
MXAccess COM Toolkit on this AVEVA install does not expose any
alarm-event family, and the AVEVA alarm-subscription managed
assemblies (aaAlarmManagedClient, ArchestrAAlarmsAndEvents.SDK)
are x64-only and incompatible with the worker's x86 bitness.

Two operator-facing paths forward documented inline:

1. Stay on the value-driven sub-attribute path (current production
   behaviour). Operator-comment fidelity is the only v1 regression.

2. Add an x64 alarm-helper sub-process alongside the worker that
   loads aaAlarmManagedClient and forwards transitions over a
   named-pipe IPC. Recovers full v1 fidelity but adds operational
   complexity.

The full architectural notes live in the mxaccessgw repo at
src/MxGateway.Worker/MxAccess/MxAccessAlarmEventSink.cs.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Joseph Doherty
2026-04-30 21:29:16 -04:00
parent 439b39463b
commit 5ed26d2ec6
1 changed files with 27 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
docs/plans/alarms-over-gateway.md
View File

@@ -1,16 +1,32 @@
# Plan — alarms over the mxaccessgw gateway # Plan — alarms over the mxaccessgw gateway
> ✅ **Completed 2026-04-30 — historical record.** > ✅ **All 19 PRs merged 2026-04-30 — historical record.**
> The 14-PR sequence (A.1 / A.3, B.1 / B.2 / B.3 / B.4, C.1 / C.2, > A.1 / A.2 / A.3 / A.4 (gateway proto + handlers + worker scaffold),
> E.1 / E.2 / E.3 / E.4 / E.5 / E.6 / E.7) shipped. The gateway-side > B.1 / B.2 / B.3 / B.4 / B.5 (driver, server, docs), C.1 / C.2
> public RPC surface, the driver-native ack path, the sidecar alarm > (sidecar alarm historian writer), D.1 (deploy script),
> historian writer, and the five client SDKs are all live. **A.2** > E.1 / E.2 / E.3 / E.4 / E.5 / E.6 / E.7 (5 client SDKs + lmxopcua
> (worker MxAccess alarm subscription) and **A.4** (worker > client surface). Public contract surface is live; client SDKs ship
> ConditionRefresh command) require the AVEVA worker host's MxAccess > the new RPCs; the sub-attribute fallback path keeps Galaxy alarms
> Toolkit C++ SDK and ship as a follow-up gated on dev-rig > functional today.
> validation. **D.1** (refresh `C:\publish` + smoke-run on the dev >
> rig) ships once A.2 is hardware-verified. The remainder of this > ⚠️ **Worker-side native alarm subscription blocked on a dev-rig
> document is preserved as the design record. > finding (2026-04-30):** the MXAccess COM Toolkit at
> `C:\Program Files (x86)\ArchestrA\Framework\Bin\ArchestrA.MXAccess.dll`
> exposes no alarm-event family — only `OnDataChange`,
> `OnWriteComplete`, `OperationComplete`, `OnBufferedDataChange`.
> AVEVA's `aaAlarmManagedClient` / `ArchestrAAlarmsAndEvents.SDK`
> assemblies are x64-only and incompatible with the worker's x86
> bitness. **Operator decision needed before
> `MX_EVENT_FAMILY_ON_ALARM_TRANSITION` carries any events:** either
> accept the value-driven sub-attribute path as the production
> architecture (operator-comment fidelity is the only v1 regression)
> or add an x64 alarm-helper sub-process alongside the worker. See
> `src/MxGateway.Worker/MxAccess/MxAccessAlarmEventSink.cs` in the
> mxaccessgw repo for the architectural notes. Live
> `aahClientManaged` alarm-event write call site
> (`SdkAlarmHistorianWriteBackend` placeholder from PR C.1) and the
> D.1 smoke artifact ship once those decisions resolve. The
> remainder of this document is preserved as the design record.
Coordinated epic across two repos: Coordinated epic across two repos: