Joseph Doherty
2d20aeb779
#519 — a driver's OPC UA status code now reaches a client with its sub-code intact. DriverInstanceActor projected the driver's uint onto a 3-state Good/Uncertain/Bad enum and OtOpcUaNodeManager re-expanded Bad to a bare 0x80000000, so BadNoCommunication, BadTypeMismatch and BadNotSupported were indistinguishable on the wire and every driver's status constants (incl. the 16 #497 had just corrected) were diagnostic in logs only. Resolved by option (b): the raw uint rides AttributeValuePublished -> AttributeValueUpdate -> IOpcUaAddressSpaceSink.WriteValue, OpcUaQuality is deleted, and severity classification is a helper (OpcUaStatus.IsGood/IsUncertain/IsBad). The surface was wider than the issue costed (41 files, not "the sink and 3 implementations"): OpcUaQuality had non-driver producers with no uint to carry. Each got its natural code — BadInternalError for a failed virtual-tag script, BadNoCommunication for driver comms loss — and ScriptedAlarmHostActor's pair of mutually-inverse uint<->enum mappers is deleted, having round-tripped a code the engine already held. AddressSpaceApplier's removal writes deliberately keep the generic Bad: not losing a code the driver had is this issue; inventing one for the deploy path is a separate call. Behaviour change: WriteAlarmQuality fires its Part 9 event on a status-code change rather than a severity-bucket change. While the annotation was 3-state those were the same predicate; now a move between two Bad reasons changes what a subscriber reads. New SDK-free named constants live on Commons.OpcUa.OpcUaStatus, and StatusCodeParityTests is widened to cover them — that guard is reflection-driven, so it can only see a named constant, never an inline literal. #517 — the symptom is real but the issue named the wrong path and its fix was unsafe. ShutdownAsync cannot race: DriverInstanceActor calls it from PostStop, after the mailbox drains. (Core/Hosting/DriverHost, the one class with a concurrent GetHealth, has no production call site.) InitializeAsync can: it runs on a fire-and-forget Task.Run, and MTConnectDriver writes Healthy then starts loops that can throw into a catch which disposes the client before writing Faulted. Moving the write earlier, as suggested, inverts the terminal state — teardown drains in-flight loops that write health as they unwind, so a late loop could leave Healthy at rest with every connection closed. The fix is a bracket (conservative before, terminal after), applied to MTConnect's init-failure path only; shutdown keeps its single trailing write, and the rule plus the reachability table are documented on IDriver.ShutdownAsync. CalculationDriver.GetHealth returned a hard-coded Healthy that consulted nothing — Healthy before initialize, after shutdown and after dispose. Now derived from _running. Its test, named Health_is_always_Connected, asserted the defect and is replaced. Every new guard was falsified by breaking the production code and watching it go red. The two sub-code tests each assert two different Bad codes, since a single-code assertion could pass against a hard-coded constant under the old projection. Pre-existing failures, verified unchanged on a stashed tree and not chased: 4 in Driver.AbLegacy.IntegrationTests (slc500/micrologix/plc5 fixtures not up) and 3 in Host.IntegrationTests. Closes #517 Closes #519 Claude-Session: https://claude.ai/code/session_015p7wGqy3YpZNCpDzTpGMKo
69 lines
4.3 KiB
C#
69 lines
4.3 KiB
C#
namespace ZB.MOM.WW.OtOpcUa.Commons.OpcUa;
|
|
|
|
/// <summary>
|
|
/// The handful of OPC UA status codes the engine layer needs to spell, plus the Part 4 severity
|
|
/// classification helpers that replaced the retired <c>OpcUaQuality</c> 3-state enum (Gitea #519).
|
|
///
|
|
/// <para><b>Why these are bare <c>uint</c> literals.</b> Commons and Runtime deliberately do not
|
|
/// reference the OPC UA SDK — <see cref="IOpcUaAddressSpaceSink"/> exists precisely so the Runtime
|
|
/// project can publish values without dragging in <c>Opc.Ua.Server</c>. That is the same layering
|
|
/// decision the driver assemblies make, and it carries the same single failure mode: nothing checks
|
|
/// the literal against the name. <c>StatusCodeParityTests</c> closes it by reflection, and it can
|
|
/// only see a <b>named</b> constant — so add codes here rather than writing a literal at a call
|
|
/// site, exactly as Gitea #497 concluded for the drivers.</para>
|
|
///
|
|
/// <para><b>Severity, not equality, is what callers should branch on.</b> A status code's top two
|
|
/// bits carry its Part 4 severity (00 = Good, 01 = Uncertain, 10/11 = Bad); everything below is the
|
|
/// sub-code. Before #519 the engine collapsed every value onto a 3-state enum here and the node
|
|
/// manager re-expanded <c>Bad</c> to a bare <c>0x80000000</c>, so no driver's sub-code ever reached
|
|
/// a client. The sub-code now rides through to the SDK verbatim, and any code that only needs the
|
|
/// bucket uses <see cref="IsGood"/> / <see cref="IsUncertain"/> / <see cref="IsBad"/> rather than
|
|
/// comparing against <see cref="Good"/> or <see cref="Bad"/>.</para>
|
|
/// </summary>
|
|
public static class OpcUaStatus
|
|
{
|
|
/// <summary>The value is good. Part 4 severity <c>00</c>; the whole code is zero.</summary>
|
|
public const uint Good = 0x00000000;
|
|
|
|
/// <summary>Generic uncertain. Prefer a specific <c>Uncertain*</c> sub-code where one applies.</summary>
|
|
public const uint Uncertain = 0x40000000;
|
|
|
|
/// <summary>Generic bad, carrying no diagnostic beyond the severity. This is the value the retired
|
|
/// 3-state projection produced for <em>every</em> bad status; a caller that has something more
|
|
/// specific should say so instead.</summary>
|
|
public const uint Bad = 0x80000000;
|
|
|
|
/// <summary>No value has been received from the device yet. Written at materialisation and on every
|
|
/// address-space reset, so a freshly-deployed or just-rebuilt node reads as "not yet polled" rather
|
|
/// than as a device fault.</summary>
|
|
public const uint BadWaitingForInitialData = 0x80320000;
|
|
|
|
/// <summary>Communication with the source has been lost. The driver-connectivity annotation for a
|
|
/// native alarm condition, and the sentinel several drivers map an explicit "unavailable" reading to.</summary>
|
|
public const uint BadNoCommunication = 0x80310000;
|
|
|
|
/// <summary>An internal failure produced no usable value — the virtual-tag path's code for a script
|
|
/// that threw or timed out.</summary>
|
|
public const uint BadInternalError = 0x80020000;
|
|
|
|
/// <summary>Part 4 severity bucket of <paramref name="statusCode"/>: the top two bits.</summary>
|
|
/// <param name="statusCode">The status code to classify.</param>
|
|
/// <returns>0 for Good, 1 for Uncertain, 2 or 3 for Bad.</returns>
|
|
public static uint Severity(uint statusCode) => statusCode >> 30;
|
|
|
|
/// <summary>True when <paramref name="statusCode"/> is in the Good severity bucket.</summary>
|
|
/// <param name="statusCode">The status code to classify.</param>
|
|
/// <returns><see langword="true"/> when the value is usable.</returns>
|
|
public static bool IsGood(uint statusCode) => Severity(statusCode) == 0;
|
|
|
|
/// <summary>True when <paramref name="statusCode"/> is in the Uncertain severity bucket.</summary>
|
|
/// <param name="statusCode">The status code to classify.</param>
|
|
/// <returns><see langword="true"/> when the value is questionable but present.</returns>
|
|
public static bool IsUncertain(uint statusCode) => Severity(statusCode) == 1;
|
|
|
|
/// <summary>True when <paramref name="statusCode"/> is in the Bad severity bucket.</summary>
|
|
/// <param name="statusCode">The status code to classify.</param>
|
|
/// <returns><see langword="true"/> when the value must not be trusted.</returns>
|
|
public static bool IsBad(uint statusCode) => Severity(statusCode) >= 2;
|
|
}
|