feat(alarms): scripted condition Quality from worst-of-input tag quality (Layer 3 of #477) #478
Reference in New Issue
Block a user
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?
Summary
Deferred Layer 3 from #477 (condition source-data
Quality). #477 shipped Layers 1+2:Qualityis now an explicit, plumbed field, and native conditions track their driver's connectivity (comms lost →Bad, restored →Good) viaDriverInstanceActor.ConnectivityChanged→DriverHostActor.OnDriverConnectivityChanged→OpcUaPublishActor.AlarmQualityUpdate→OtOpcUaNodeManager.WriteAlarmQuality.Scripted alarm conditions were left reporting
Quality = Goodunconditionally (seeScriptedAlarmHostActor.ToSnapshot— hardcodedOpcUaQuality.Goodwith 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 carriesOpcUaQuality). When any input tag isBad/Uncertain, the script's inputs are not trustworthy, so the resulting condition'sQualityshould reflect the worst of its input qualities rather than alwaysGood— mirroring the native OT semantic ("can I trust this condition's state?").Sketch
OpcUaQualityper input). Computeworst = inputs.Max(by badness)at evaluation time and carry it on the emittedScriptedAlarmEvent.AlarmConditionSnapshot.QualityatScriptedAlarmHostActor.ToSnapshot(replace the hardcodedGood). The rest of the path (WriteAlarmCondition projectssnapshot.Quality, delta-gate fires on a bucket change) already handles it — Layer 1 built that.Test
Extend the scripted-alarm wire/host tests: drive an input tag
Bad, assert the scripted condition event reports non-GoodQuality; restore the input, assertGood.References
Qualityfoundation.docs/AlarmTracking.md§"Condition source-data Quality (#477)".docs/plans/2026-07-17-alarm-condition-quality-477-design.md.