Repository navigation
P0 SG7_BCU: 21/77 static Report values pending, 3/4 RCB streams have no proven ingress #707
Description
Reproduced physical evidence (2026-10-23)
Local ARSAS v1.6.40+9ade132 diagnostic + GUI: 3/3 IED associations connected; SG7_BCU selected 77 static DataSet process rows, no cyclic MMS process polling (intentional report-only policy). Only 56/77 values displayed, 21 remain Awaiting, and 1/4 exact static RCB targets actually ROUTED. This is not WPF viewport lag and not “0 unresolved” proof of live traffic.
SG7_BCUMaster/LLN0.BR.BrcbA01→TT6DataSet3: 56/56 live [ROUTED]....BrcbB01→TT3DataSet02: 0/3 unique pending....BrcbI01→TT6DataSet4: 0/18 pending (Meter/ACsrcMMXU/ACsrcMMXN; screenshot Unknown)....BrcbD01→TT3DataSet01: [PENDING], mostly shared metering members.- All 4 show RCB setup/GI requested, but only one has observed InformationReport; do not infer all RptEna accepted or GI succeeded.
BrcbA01also reportedBufOvfl=true; cannot claim SOE continuity. - SCL declares six DataSets, but
TT6DataSet1andTT6DataSet2have no configured RCB. No cyclic process polling should be silently activated to mask this limitation.
Required diagnosis, remediation, acceptance
- Per planned RCB log distinct stages: matching configured DataSet, binding/ownership, reservation status, ConfRev, successful RptEna/GI write/readback, association epoch, first InformationReport timestamp, count of successfully routed members, BufOvfl/Seq/OptFlds, and actionable non-routed reason (not a generic “Unknown”). Distinguish
Armed (no Report)fromReceivingandActivation rejected; do not treat absence of traffic as an RptEna failure or a success. - Read-only bounded per-RCB investigation of
BrcbB01/I01/D01on the same association with fresh typedRptEna,DatSet,Resv/ResvTms,Owner,ConfRev,OptFlds,TrgOps,IntgPdand GI evidence where supported. Respect existing MMS single-flight, reservations and competing clients; avoid infinite retries and a full NameList scan. - For values without proven Report ingress, allow explicit bounded one-shot initial-image MMS Read of exact selected ST/MX primary leaves as a separate
Snapshot Readstate, never mislabeledLive Report. Continue report-only as default until operator chooses otherwise; no background cyclic poll fallback/dynamic DataSet mutation without explicit policy. Preserve q/t, FC, source, freshness and association in canonical SSOT, then project to all workspaces. - For RCB-backed values actually received, immediately publish to canonical model, verify independently Browser/Explorer/Global render identical value, quality, timestamp. No WPF-copy-as-authority. Handle offline/reconnect, report overflow and stale snapshots with explicit state transition.
- Acceptance with physical SG7: 4 RCB targets each show truthful acquisition state; all 77 selected signals either proven Report, explicitly labeled one-shot snapshot, or explicitly awaiting/unavailable with reason; never 21 permanent unlabeled Unknown. Test SOE continuity separately; no fabricated traffic or guessed status. Measure IED switching/GUI p95 and backlog; RCB/Poll adapters not allowed to freeze UI.
Integration guard: This is separate from perf draft #705 and Control/FAT #704. No engine lock or Command/Write changes without current-head review, exact-SHA Windows CI and field evidence.
Activity
masarray commentedon Oct 24, 2026
Resolved P0 static Report visibility / per-RCB ingress — operator field FAT 2026-10-24 10:07 WIB
The specific 2026-10-23 reproducible defect described in this issue is now resolved in the accepted field source tree, NOT a claim of global SOE continuity:
P0_STATIC_UI_WORKSG7 inventory 2123.465ms, authority 680.303ms, selection 121.410ms, total 2941.283ms. These are performance measurements, not automatic proof of zero UI stalls.checkpoint/arsas-ssot-performance-field-accepted-20261024@b136b927636219e03c9ce092311f673c46201645; source tree2e1a209b72039e2277b2d8af621f812416307ad7. Merged PR P0: Responsive Static DataSet reporting and green IED progress (SSOT preserved) #724 into isolated integration branch, merge SHAb1d177885ff8cba6515e19f0aec33d1fc887519b, identical source tree; no change to main, external SMV, or other PR heads.Explicit residuals are separate, not hidden by issue closure: SG7 21 report continuity findings including BufOvfl on all four BRCBs, ZIV 1 BufOvfl, GR_X 1 GI-context sequence discontinuity. These observations cannot certify lossless SOE. Preserve #544/#520 continuity work. Open SCL peer parity wasn't captured. Remaining UI inventory work ~2.12s may merit profiling if operator sees freeze, but does not invalidate the resolved 21-pending/3-unrouted issue.
The linked PR is merged to an isolated non-main integration branch by design; mainline R10 acceptance gate remains intact.
masarray commentedon Oct 27, 2026
D31 — SAME SG7_BCU symptom recurred in operator's RC EXE on 2026-10-28; regression investigation, NOT a new coding request
Do not start from an invented fix. The 2026-10-24 #707 closure was supported by real operator FAT: SG7 77/77 displayed, 4/4 routed configured RCBs, and later 2026-10-25 five-IED diagnostic reported 391 SG7 frames; checkpoint
b136b927636219e03c9ce092311f673c46201645, five-IED tested source4c7d833a85437037418a5f4e1fbe2c08034b1581/ identical source tree3abde5fb34ed915a32ec60a4bacdf682ab1bddbf.The user has now run
ARSAS_1.6.42_ExactRC_d4598619_x64.exeand supplied a full new diagnostic and screenshot. Assembly version is1.6.42+66076ce7a7b4b94955490b0ab74e1f50a298f709; this synthetic merge-test commit's Git tree3551f4dd3c3269220481ab02e6eaafb247c60df5exactly matches RCd4598619b1b8fc21487cf5beb83a8a8284d0e9cf. Pinned ARIEC engine isf75e323e9f8443aa20e0a3818a1d5d77255b2c0f, same as accepted October 24/25 FAT.Strong source finding: live Git blob SHA comparisons prove these files are BYTE-IDENTICAL between the 2026-10-24 successful checkpoint, the 2026-10-25 5-IED acceptance source, and current RC:
Services/Iec61850MonitorRuntime.cs,Services/NativeIec61850Client.StaticDataSetReporting.cs,Services/NativeIec61850Client.cs,Services/StaticDataSetReportProjectionAccumulator.cs,Models/MonitorModels.csandengines/ARIEC61850.lock.json. The application's relevant monitoring/RCB code was not modified by D27–D30 PR cleanup or RC reconciliation.New run symptom (2026-10-28 03:27 WIB): SG7 77 selected, 4 RCBs planned and apparently armed; 56/77 visible, 21 pending, only 1/4 proven routed.
BrcbA01 / TT6DataSet3emitted 1 GI-tagged Report covering 56, BufOvfl=true.BrcbB01 / TT3DataSet02has 0/3 unique,BrcbI01 / TT6DataSet40/18,BrcbD01 / TT3DataSet010 proven traffic. Log reports setup writes=2 each, but absent routed Report cannot be treated as proven end-to-end value activation. No cyclic process MMS polling in intentionally static report-only mode. Association healthy, initial MMS reads successful, no transport error. Diagnostic route says target IP192.16.1.73is also assigned to the local Windows host/NIC, so endpoint may be a local IED simulator; do not assert simulator blame, device bug or client routing root cause on present evidence.Decision: reopen this same issue as recurring runtime/field behavior needing root-cause attribution, not as permission to reimplement old 21-pending fix, silently enable cyclic polling, replay GI, mutate RCB ownership, alter engine pin, or demand a fresh PCAP/capture from the operator. Work from existing accepted FAT and today's full diagnostic first. Separate potentially missing on-wire Report, receive/decoder/routing ambiguity, and RCB ownership/readback from value projection. Successful past CI/field run does not establish deterministic 4/4 RCB startup in each new association. User already provided today's evidence and explicitly does not want to repeat previous FAT cycles.
No source, release,
main, RC or binary changes were made in this audit. Do not mark resolved until the exact regression mechanism is demonstrated or the environmental/IED-state variance is confirmed with existing evidence.masarray commentedon Oct 27, 2026
D32 — investigation progressed without reopening old SG7 fix or asking for another capture
b136b927...and 2026-10-25 5-IED successful source3abde5fb...have byte-identical ARSASIec61850MonitorRuntime.cs,NativeIec61850Client.cs,NativeIec61850Client.StaticDataSetReporting.cs,StaticDataSetReportProjectionAccumulator.cs,Models/MonitorModels.csand ARIEC engine lock to current RCd4598619.... No proof exists that D27–D30 cleanup changed the working MMS acquisition code. The intermittent 56/77 result needs attribution to this live association's report delivery/routing, not blind reapplication of old code.Iec61850MonitorRuntime.ProcessReportHealth. The existing Copy Diagnostic prints stream lifecycle only for observed streams, while 0-frame targets appear separately as pending initial-image groups. Therefore it lacks a single per-RCB summary explicitly showing zero routed frames and whether RptEna/GI evidence was actually surfaced. An accepted write remains not equal to Report delivery;unverifieddoes not imply rejection.f22704b859d7bf7a7afa207a03a21231215b13d4, base RCd4598619...; 2 files changed only. The existing Copy Diagnostic will now show bounded 16 per-RCB image groups includingroutedvsnoRoutedFramesand no borrowed RptEna/GI/frame evidence. Positive and absent-snapshot regression fixtures. No MMS reads/writes, GI retry, cyclic polling, SSOT mutations, report routing, engine changes, hardware retest or stable release changes. CI outcome pending; this PR is not a fix for the current 21 missing values.UnroutedPersistentReportCount), or (d) routed frame but schema/value projection rejected. Read-only evidence from the existing 2026-10-28 log/diagnostic first; do not guess or disable report-only policy.Retain this issue OPEN until actual cause supported, independently of draft #761's diagnostic-only change. Operator does not need to recapture prior FAT just for this audit.
P0 #707: read-only static RCB zero-ingress Copy Diagnostic
masarray commentedon Oct 27, 2026
D33 implementation progress — 28 Oct 2026: no speculative RCB reset or polling fallback
Exact-source reconciliation: user-accepted Oct 24 SG7 (77/77 values, 4/4 RCB routed) and Oct 25 (391 SG7 report frames) both pin ARIEC
f75e323e9f8443aa20e0a3818a1d5d77255b2c0f. The Oct 28 failed session (56/77; 1/4 routed) runs the same relevant ARSAS code/engine lock. Operator's original 98 KB diagnostic file already supports the case: all four plan startups returned success at approximately 03:26:54.772–.793 WIB; A01 had one routed GI Report at 03:26:55.251, other plans B01/D01/I01 had zero proven routed frames through later diagnostic 03:27:31. No evidence yet proves no Report was emitted on the wire, nor that a malformed/abbreviated DatSet was present. Do not state the new engine fix caused/repaired this incident.Actual delivered ARSAS: PR #761 MERGED into Integrated RC at
e7b1943792488af4a4dd03841c39abfe017f121aafter exact-head Windows Build #40584997333 SUCCESS and advisory CI PASS. It adds bounded per-RCBrouted / noRoutedFrames, image coverage, and activation-evidence visibility to existing Copy Diagnostic, without MMS I/O or source-value changes.Separately discovered engine correctness hole: ARIEC
SelectPersistentReportMonitorpreviously rejected contradictory full domain-qualified DatSet with matching RptID, but could accept contradictory abbreviatedLLN0$DS_Bwith RptID of another planIEDLD0/LLN0.DS_A. This can cross-wire member-order projection for some peers; it is a real source-level fail-open risk, not proven to have occurred on SG7's one-frame trial. ARIEC PR #198 contains a minimal fail-closed routing change + four-SG7-RCB deterministic tests, 2 changed engine/test files, headca502b89989b5d5eb137ed7b1fa70b7a98eda658, draft until independent .NET CI and review. It preserves matching full, LN.DataSet, tail-only vendor compatibility and absent DatSet compatibility. No extra GI/RptEna/RCB mutation, retry, cyclic MMS process polling, IED filter, or changes to ARSAS engine pin.Next decision gate: CI/negative regression for engine #198; preserve engine #192 mainline physical gates. For SG7 recurrence, attribute one of: accepted activation with no transmitted Report, receive/decoder quarantine, RptID/DatSet mismatch, exact point projection rejection, or association/IED state variance. Use original evidence and non-intrusive generated fixtures. Do not close #707 or advertise 77/77 recovered without proof. No new field capture required merely for PR cleanup.
masarray commentedon Oct 27, 2026
D34 integrated engineering milestone (2026-10-28): read-only RCB triage + fail-closed engine routing
ARSAS source: #761 MERGED into integrated RC
e7b1943792488af4a4dd03841c39abfe017f121a. Windows Build run 40584997333 success. Existing Copy Diagnostic now includes up to 16 immutable RCB rows withinitial image visible/pending, proven frame count, positive/unknown RptEna/GI data and explicitNO ROUTED FRAMES(not falsely treating successful setup as packet receipt). No report processing or MMS traffic changed; artifact 12771461603 is a candidate diagnostic Windows build only.ARIEC source: #198 MERGED into engine
staging5923029a8b98ea841cc36db6f20c2ea80d21547c. Fresh exact-head .NET CI #40601716558 SUCCESS: 1,279 tests, zero compiler warnings/errors. Engine now rejects a contradictory abbreviated DatSet when an exact RptID identifies another RCB; positive vendor-compatible full/LN.DataSet/tail-only/omitted DataSet selection remains tested. Negative four-SG7-RCB fixture guards cross-membership and plan-order independence. No GI/RptEna/Resv change, polling, WPF, or platform code.Source guards: ARSAS engine pin remains previous
f75e323e9f8443aa20e0a3818a1d5d77255b2c0f(the version used by both the successful and failed SG7 field runs); no automatic repin to new staged engine. ARSAS main14e5dddfbaae012b61a021366c1a864d83d316f2and stable v1.6.42 unchanged; no new public release or user FAT requested. ARIEC #192 is a separate draft main-promotion lane and remains subject to original physical authority guards.Root cause NOT yet proven: Original field diagnostic showed all four report monitor setups accepted in ~21ms, with A01's one GI-tagged Report but zero routed B01, I01, D01 frames. Nothing yet proves contradictory shortened DataSet occurred on SG7; this fix closes a genuine independently verified routing safety defect but is not called the cause of 56/77. #707 remains OPEN. Required future decision depends on established reception facts: absent Report at source/association vs decoder quarantine/unrouted vs DataSet/RCB mismatch vs value rejection; do not fabricate 77/77 or add silent MMS polling. Operator's earlier successful evidence remains authoritative for its measured scope and no repeat historical capture is demanded.
Backlog after checkpoint: ARSAS 0 open PR / 1 open issue (#707).
P0 SG7: preserve exact RCB activation-vs-report evidence for silent s…
masarray commentedon Oct 28, 2026
D35 verified P0 reporting milestone — exact RCB activation evidence in Integrated RC
Actual integration: PR #762 MERGED (not draft/closed-only) into
release/arsas-integrated-rc0-20261024at833dbe328deb2b925ffe0a61823285b24499b37f. Only 6 application/model/test files changed. NewIec61850RcbActivationEvidenceis a bounded (64 plans), immutable, association-local snapshot of native setup-call success and actual RptEna/GI write-step outcomes; NOT evidence of GI Report delivery or IED physical readback. Published atomically after each setup, cleared on Start/Stop/Reconnect, exact RCB+DataSet matching and collision fail-closed; Copy Diagnostic keeps write outcomes separated from real Report frame counts and per-point initial value completeness. Regression fixtures cover SG7 A01 routed vs I01 silent with accepted RptEna/rejected GI, mismatched DataSet, duplicate RCB identity and no association evidence. No new MMS wire traffic, RCB rewrite, retry, cyclic polling, control or projection change.Independent CI passed at exact PR HEAD
11365f59e976100db0abf69e59cd5b59baf661bc: Windows Build #40605214182 SUCCESS — ARSAS 2990/2990 tests, pinned ARIEC 24/24, packaged managed smoke 6/6 and native CTest 9/9. SCL R7 Build #40605214110 SUCCESS for source/regression test. The CI checked-out synthetic mergea8f1e9cd7dbb8cf02ef66f5f3c2c6eabe6ca159d, PR HEAD and actual merged RC have the same exact Git tree46ba93905babdf32dbdb6f49be70cd10bb33b922, so the built source is the final RC source, not a different mainline merge.Real Windows test artifact GitHub Actions artifact ID 12779739145, name
ARSAS-1.6.42-win-x64-portable.exe— confirmed 79,358,686-byte PE32+ Windows x64 GUI portable binary, SHA-256a373bb98b58af1d82ae7bed29981f3a5cfa2691f9d5d7f9f7d6e9f8232ed6d09matching sealed Windows workflow logs. The assistant also supplied a directly downloadable renamed EXE and checksum. It is a diagnostic candidate, not a new published stable release.Protected baseline:
mainremains14e5dddfbaae012b61a021366c1a864d83d316f2; pinned ARIEC remains proven/previousf75e323e9f8443aa20e0a3818a1d5d77255b2c0f. ARIEC engine staged fix #198 (commit5923029a8b98ea841cc36db6f20c2ea80d21547c) is separately code/test green but NOT included in this portable app. Published stable tag/release unchanged.SG7 56/77 true root cause remains open. The Oct 28 existing diagnostic showed A01 1 Report, B01/I01/D01 zero proven routed traffic; all four setup calls succeeded at application API boundary. This new snapshot will distinguish whether individual
RptEnaand GI writes actually succeeded and no frame was routed, without conflating absence of receive frame with write rejection. No claim that values are restored to 77/77, that every IED emitted Reports, or that SOE losslessness has been proved. No request to repeat earlier FAT/capture. #707 stays OPEN.Final fresh GitHub check: 0 open ARSAS PR, 1 open issue (#707).