feat(alarms): scripted condition Quality from worst-of-input tag quality (Layer 3 of #477) #478

Closed
opened 2026-07-17 15:07:26 -04:00 by dohertj2 · 0 comments
Owner

Summary

Deferred Layer 3 from #477 (condition source-data Quality). #477 shipped Layers 1+2: Quality is now an explicit, plumbed field, and native conditions track their driver's connectivity (comms lost → Bad, restored → Good) via DriverInstanceActor.ConnectivityChangedDriverHostActor.OnDriverConnectivityChangedOpcUaPublishActor.AlarmQualityUpdateOtOpcUaNodeManager.WriteAlarmQuality.

Scripted alarm conditions were left reporting Quality = Good unconditionally (see ScriptedAlarmHostActor.ToSnapshot — hardcoded OpcUaQuality.Good with a comment pointing here).

The ask

A scripted alarm is computed from one or more input tags (read via ctx.GetTag(...), resolved through the dependency mux, which carries OpcUaQuality). When any input tag is Bad/Uncertain, the script's inputs are not trustworthy, so the resulting condition's Quality should reflect the worst of its input qualities rather than always Good — mirroring the native OT semantic ("can I trust this condition's state?").

Sketch

  • The scripted engine already reads input tags through the dependency mux (OpcUaQuality per input). Compute worst = inputs.Max(by badness) at evaluation time and carry it on the emitted ScriptedAlarmEvent.
  • Map it into the AlarmConditionSnapshot.Quality at ScriptedAlarmHostActor.ToSnapshot (replace the hardcoded Good). The rest of the path (WriteAlarmCondition projects snapshot.Quality, delta-gate fires on a bucket change) already handles it — Layer 1 built that.
  • No new sink surface needed.

Test

Extend the scripted-alarm wire/host tests: drive an input tag Bad, assert the scripted condition event reports non-Good Quality; restore the input, assert Good.

References

  • #477 (Layers 1+2, merged) — native connectivity-driven quality + the Quality foundation.
  • docs/AlarmTracking.md §"Condition source-data Quality (#477)".
  • Design doc: docs/plans/2026-07-17-alarm-condition-quality-477-design.md.
## Summary Deferred **Layer 3** from #477 (condition source-data `Quality`). #477 shipped Layers 1+2: `Quality` is now an explicit, plumbed field, and **native** conditions track their driver's connectivity (comms lost → `Bad`, restored → `Good`) via `DriverInstanceActor.ConnectivityChanged` → `DriverHostActor.OnDriverConnectivityChanged` → `OpcUaPublishActor.AlarmQualityUpdate` → `OtOpcUaNodeManager.WriteAlarmQuality`. **Scripted** alarm conditions were left reporting `Quality = Good` unconditionally (see `ScriptedAlarmHostActor.ToSnapshot` — hardcoded `OpcUaQuality.Good` with a comment pointing here). ## The ask A scripted alarm is computed from one or more input tags (read via `ctx.GetTag(...)`, resolved through the dependency mux, which carries `OpcUaQuality`). When any input tag is `Bad`/`Uncertain`, the script's inputs are not trustworthy, so the resulting condition's `Quality` should reflect the **worst** of its input qualities rather than always `Good` — mirroring the native OT semantic ("can I trust this condition's state?"). ## Sketch - The scripted engine already reads input tags through the dependency mux (`OpcUaQuality` per input). Compute `worst = inputs.Max(by badness)` at evaluation time and carry it on the emitted `ScriptedAlarmEvent`. - Map it into the `AlarmConditionSnapshot.Quality` at `ScriptedAlarmHostActor.ToSnapshot` (replace the hardcoded `Good`). The rest of the path (WriteAlarmCondition projects `snapshot.Quality`, delta-gate fires on a bucket change) already handles it — Layer 1 built that. - No new sink surface needed. ## Test Extend the scripted-alarm wire/host tests: drive an input tag `Bad`, assert the scripted condition event reports non-`Good` `Quality`; restore the input, assert `Good`. ## References - #477 (Layers 1+2, merged) — native connectivity-driven quality + the `Quality` foundation. - `docs/AlarmTracking.md` §"Condition source-data Quality (#477)". - Design doc: `docs/plans/2026-07-17-alarm-condition-quality-477-design.md`.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: dohertj2/lmxopcua#478