Repository navigation
P7.6B #446: canonicalize SCD/Discovery DataSet member ordinals in parity fingerprint - #483
Conversation
…ing corrupt indexes
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 Verified field facts (both ingress runs):
Important acceptance separation:
|
P7.6C workstream ownership / IEC 61850 continuity milestone — 2026-10-08New stacked draft PR #484, base = P7.6B PR #483 HEAD 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 |
Exact HEAD CI qualification (2026-10-08)
5a05ab2187e04aaf70106ef5c59a0c625503aaef(not the previous failed compile commit).ARSAS.Tests.675dec9had test-fixture-only CS0029 (BindingsexpectsList, not array), corrected on this HEAD; preserve failure in history rather than falsely claiming it was green.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 FCDA1..N, Discovery IP MMS directory0..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 originalLiveIedDataSetMemberModel.Index, but emit canonical zero-based ordered positions intoSemanticLines/SHA256 only. Never rewrite, renumber, or mutate the engineering/SCL/MMS source model. Engine remains pinned at352c81e6a798635c6addcee0683235ca87ad416d.Anti-naive safeguards
longdelta to avoid overflow.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 yieldAWAITING 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.