Skip to content

P7.6B #446: canonicalize SCD/Discovery DataSet member ordinals in parity fingerprint - #483

Draft
masarray wants to merge 3 commits into
feat/446-p7-6b-semantic-diagnostic-evidencefrom
fix/446-p7-6b-canonical-member-ordinal-parity
Draft

masarray wants to merge 3 commits into
feat/446-p7-6b-semantic-diagnostic-evidencefrom
fix/446-p7-6b-canonical-member-ordinal-parity

Conversation

@masarray

@masarray masarray commented Oct 8, 2026 •

Copy link
Copy Markdown
Owner

Exact HEAD CI qualification (2026-10-08)

Root cause — physically evidenced, precisely scoped

Same real IED endpoint and same app/engine build yielded real static report ingestion 13/13 visible, 2/2 exact BRCB/URCB routed, no cyclic MMS polling, but different parity hashes. Diagnostic semantic[0..2] proved the only difference was source index-origin: Open SCD FCDA 1..N, Discovery IP MMS directory 0..N-1. Ordered DataSet references, FC, selected signal binding, plan counters all exactly matched. Different concrete RCB instance is already correctly excluded.

Change

In StaticAcquisitionParityTracker.BuildEvidence, continue ordering by immutable original LiveIedDataSetMemberModel.Index, but emit canonical zero-based ordered positions into SemanticLines/SHA256 only. Never rewrite, renumber, or mutate the engineering/SCL/MMS source model. Engine remains pinned at 352c81e6a798635c6addcee0683235ca87ad416d.

Anti-naive safeguards

  • Preserve ambiguity guards from P7.6B #446: fail-closed Discovery/Open-SCL parity evidence integrity #481 (IED identity/FC/reference/coverage/RCB family).
  • Reject negative, duplicate or noncontiguous source ordinals with InsufficientEvidence, even if equal fingerprint input strings would otherwise become MATCH. Use long delta to avoid overflow.
  • Synthetic deterministic two-DataSet mixed BRCB/URCB fixture reproduces zero/one-based ordinal origins and different live RCB slots; validates exact canonical lines/fingerprint.
  • Negative regression coverage: reorder, FC drift, member-reference drift, 0/2 1/3 100/102 index gaps, and maximum-int consecutive indices.
  • Diagnostic hash basis remains source-neutral and copyable via P7.6B follow-up: copy exact bounded semantic parity basis in diagnostics #482; no UI, network, control, GI, polling, static plan or runtime mutations.

Workstream and qualification

Stacked DRAFT over #482 (exact base 0b84e81547ab8a5fded5c1f5f45e652c7dd3508b), which stacks over #481 and #480. Parent #446. Do not overwrite or merge any parallel workstream; do not promote release. CI and another same-binary physical recapture remain acceptance gates. Independent app sessions still yield AWAITING PEER INGRESS; this patch corrects fingerprint, not persisted dual-ingress traffic claims. Remaining Discovery 2 unresolved primary descriptors and control companion parity are separate follow-up issues.

masarray commented Oct 8, 2026

Copy link
Copy Markdown
Owner Author

P7.6B field revalidation — canonical ordinal fingerprint VERIFIED on real IED (2026-10-08)

Operator supplied fresh Open SCD and Discovery IP Copy Diagnostic from the same binary: ARSAS 1.6.40+04fb931747408219086cf06c71478b92d360a954 (GitHub generated PR test merge of #483 HEAD 5a05ab2187e04aaf70106ef5c59a0c625503aaef onto #482), engine 1.6.40+352c81e6a798635c6addcee0683235ca87ad416d. Same selected IED/physical MMS endpoint, independent application processes.

Verified field facts (both ingress runs):

  • semantic gate = COMPARABLE, complete semantic[0], [1], [2] lines exactly identical, and source-neutral fingerprint cb563f46ea1a61634ab67c6af4802d353d8d8f9caf8e793b7a89580525ffd206 identical. Independently re-hashing the exact diagnostic rows yields that same SHA-256 on each path.
  • requested=13, staticBRCB=7, staticURCB=6, uncovered=0, plans=2; displayed=13/13, pending=0, qNotSupplied=0, questionableQuality=0.
  • Actual routed configured static BRCB and URCB targets: 2/2 on each ingress; diagnostic states process polling disabled / scheduler 0. Different concrete BRCB slots (Rpt_ind01 Open SCD, Rpt_ind02 Discovery) intentionally remain outside fingerprint. No observed regression in SCL endpoint association or static reporting.
  • Open SCD physical domain verification: 33/33, 620 initial reads succeeded, 0 failed and 0 projection errors.
  • Control projection added rows vary (Open SCD 2 control + 3 runtime feedback versus Discovery 0 + 5), but both link 5 controllable DataSet members and preserve status-only gating. These are incremental additions, not an apples-to-apples count of all controls. Discovery inventory Primary unresolved=2 vs SCD 0 is pre-runtime descriptor status; actual runtime unresolved=0 and 13/13 report coverage remain confirmed.

Important acceptance separation:

  • P7.6B canonical semantic fingerprint false-mismatch FIX: PhysicalVerified for separately captured parity inputs and per-ingress static traffic.
  • Both in-app snapshots still report AWAITING PEER INGRESS / TRAFFIC PENDING because evidence is scoped to separate process instances. Do not claim in-app MATCH or DUAL INGRESS TRAFFIC PROVEN; paired session persistence/cross-session evidence requires its own explicit qualification.
  • Each run also records one early BRCB Report sequence discontinuity warning (Open SCD: previous 4→current 1; Discovery: previous 3→current 1). This warning must not be suppressed or called harmless without checking RCB SqNum reset/entryId/GI/lifecycle context; sequence/event continuity still needs P7.6C investigation. No proof of actual lost events from this diagnostic alone.
  • AP F physical route, longer SOE/event continuity, reconnection/replay and complete control parity remain separate gates. P7.6B #446: canonicalize SCD/Discovery DataSet member ordinals in parity fingerprint #483 remains DRAFT, no automatic merge/mainline/release, ARIEC engine lock unchanged. No private network/IED export files committed.

masarray commented Oct 8, 2026

Copy link
Copy Markdown
Owner Author

P7.6C workstream ownership / IEC 61850 continuity milestone — 2026-10-08

New stacked draft PR #484, base = P7.6B PR #483 HEAD 5a05ab2187e04aaf70106ef5c59a0c625503aaef. Code HEAD b2807ad0daf860c21ecd90d17d9fb3e15e470ed1 (CI pending). Scope ownership: Services/Iec61850MonitorRuntime.cs diagnostics-only lines, new Services/Iec61850ReportContinuityInspector.cs, new tests/ARSAS.Tests/ReportContinuityP76CTests.cs. No ARIEC engine patch or engine lock change, no RCB/GI/wire writes, no process polling, no control changes.

Real field 7SX85 evidence: Open SCD BRCB SqNum 4→1 and Discovery BRCB 3→1 during initial report activation, while 13/13 process values and both BRCB/URCB routed on each independent ingress. These two anomalies remain unverified, not dismissed as harmless and not asserted as SOE loss.

IEC 61850-7-2 semantics underpin this patch: 16-bit SqNum, only maximum→0 is rollover; first sequence number after enabling is zero; segmented report starts SubSqNum 0 and continues in sequence under same SqNum; BRCB BufOvfl=true means possible buffered information loss; EntryID is an opaque resume identity and ConfRev changes need schema revalidation. Old consumer code falsely permitted every SqNum→0 as ordinary rollover; this patch corrects that while retaining warnings for real field backward moves.

A per-association exact-RCB continuity inspector only emits evidence warnings, does not alter report acceptance/ordering/value/quality/timestamp or suppress warnings. Tests cover standard rollover/segmentation, duplicate/forward/backward, early 4→1 and 3→1, overflow, ConfRev, opaque EntryID, out-of-range metadata and lifecycle isolation. CI and long-running GI/reconnect/BRCB replay/SOE field verification are still pending; remain draft/no merge/release.

Multi-thread coordination: other threads should not edit Iec61850MonitorRuntime.cs continuity state or these new files without reconciling PR #484. Control companion and 2 unresolved discovery inventory descriptors are separate workstreams; no speculative corrections.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant