Skip to content

P10.9Z: lossless buffered IEC 61850 events and command outcomes in SOE #544

Closed as not planned

Description

@masarray

Goal

Professional IEC 61850 Event Log parity with Siemens SICAM SCC without inventing wire evidence. Follow P10.9Y (Event Cause/Stream/Raw Reason presentation) using real ARIEC decoded report and control metadata.

Confirmed IEC facts

  • IEC 61850-7-2 BRCB may retain events and expose optional EntryID, TimeOfEntry, BufOvfl, SqNum, reason-for-inclusion; URCB does not guarantee buffering.
  • dchg/qchg/dupd, integrity, and GI are explicit report causes only when decoder supplies reason-for-inclusion. Do not infer reason from an SOE edge.
  • BRCB != historical replay. No replay label unless actual entry/connection/cursor evidence supports this categorization. EntryID is an opaque octet string, not a monotonic numeric sequence.
  • Command positive/negative is a separate IEC control-result provenance; never infer it from the resulting Pos.stVal report.

Required implementation

  1. Add association-scoped report member provenance to NativeReportValueUpdate / point/SOE: RCB reference, BRCB/URCB, report reason, EntryID (if OptFlds proves presence), TimeOfEntry, BufOvfl, SqNum with optional-field validity and source provenance. No guessed defaults or implicit MMS polling.
  2. Receive buffered backlog in order, preserve intermediate discrete transitions and IED timestamps even if UI point snapshots coalesce, report duplicates/replays only when proven, bounded ingestion/backpressure and bounded Event Log memory. Do not corrupt 8/8 static DataSet reporting.
  3. Distinguish Live BRCB, Buffered/Backlog (verified), Unknown replay status, and Buffer overflow; record chronology and data loss warnings conservatively. Preserve actual EntryID as opaque and do not resume cursor unless engine/IED session supports it.
  4. Append separate Control Outcome rows only after authoritative engine result: PositiveTermination/ServiceAccepted/feedback, negative termination, explicit LastApplError/AddCause, client-side not-sent. Do not equate access-denied with Local switch mode. Do not replace SOE process edges with guessed command causes.
  5. Event Log UI: Event, Reason/Result, Report Stream, IED timestamp, received timestamp, RCB/EntryID and key evidence on demand, with filter presets for Spontaneous, Command Positive, Command Negative, Buffer, GI/Integrity, and Unknown. CSV includes literal evidence/provenance.
  6. Regression tests on real/fixture decoded multi-entry BRCB catch-up, URI/EntryID gaps, report reordering/segmentation, missing OptFlds, buffer overflow, disabled GI/polling fallback, SBO/Operate feedback, and multiple IEDs. GUI acceptance with authorized ZIV bench. Never modify wire command sequence as a side effect.

Guardrails

Continue draft staging PR #543 and pinned ARIEC61850 engine #169; no main merge, no stable release, no unsolicited MMS controls; report-only static acquisition must remain authoritative. Prefer small, CI-qualified milestones, and measure memory/CPU and update latency.

Activity

  1. masarray commented on Oct 25, 2026

    @masarray
    OwnerAuthor

    2026-10-25 07:20 Asia/Jakarta — new five-IED diagnostic added to unresolved RCB/SOE continuity record. Tested app 4c7d833a is source-tree identical to RC 3abde5fb (GitHub compare: 0 changed files); engine f75e323e. Static ingress confirmed 14/14 planned RCB targets; selected initial image 183/183, no cyclic process polling. Decoder continuity counters across BCUGE/GR_X/SG7/SIEBCU/ZIV: total frames 427, findings 36, advertised BufOvfl=9; SG7 391 frames, 24 findings, 4 BufOvfl. On SG7 three sequenced BRCBs exhibit repeated SqNum resets (several without GIreason) and changing EntryIDs; one unsequenced BRCB omitted SqNum by OptFlds. Do not classify as 36 lost SOE events or harmless resets without independent wire-order, GI/context and replay evidence. Diagnostic notes original Open-SCL parity NOT captured and may include same-host simulator endpoints. This is an open R7/R10 qualification blocker, not a reason to degrade lossless SOE guarantees or waive guards. Sanitized per-vendor report and JSON in PR #740; release gate PR #729. Suggested next actual proof: controlled BRCB high-load/overflow/reconnect test with PCAP + original SCL and EntryID/SqNum/ReasonCode/sequence records, repeated runs, per-stream replay closure.

  2. masarray commented on Oct 27, 2026

    @masarray
    OwnerAuthor

    D29 issue-consolidation authority — keep one actionable SOE / BRCB record; no recapture obligation

    Operator decision: previously submitted latest successful ARSAS evidence is the accepted working baseline. We must not request a new PCAP, replay, IED test, or same-slot capture merely to dispose of historic #520 or resurrect archived pull requests.

    The 2026-10-25 source evidence already recorded in #520 and this issue reports 427 received frames, 36 continuity findings, 9 IED-advertised BufOvfl flags (five-IED aggregate). The BCUGE historical comparison also used non-identical RCB slots. These facts do not establish exact lost-event counts, on-wire root cause or universal lossless SOE. They also do not invalidate the operator's acceptance of actually observed monitoring/control behavior.

    Consolidate the unanswered engineering question here in #544 only; historical #520 can close as not_planned without treating the anomaly as resolved. No spontaneous hardware capture task is assigned to the operator. Future software-only work must use existing diagnostics, current code and offline tests; do not weaken R7/reference guard, suppress BufOvfl, infer EntryID numeric ordering, or claim UI stream count is physical event loss. If there is no evidence to implement a safe change, preserve truthful unknown/overflow status instead of inventing a fix.

    No application, source, engine pin, accepted release or CI workflow changed by this coordination decision.

  3. masarray commented on Oct 27, 2026

    @masarray
    OwnerAuthor

    D30 decision: retire historical lossless-SOE enhancement/capture plan as NOT PLANNED — NOT fixed, NOT certified

    The operator has explicitly accepted the latest successful ARSAS observable monitoring/control field evidence and is not performing another IED/PCAP/replay capture for this old issue. The listed objective ("lossless buffered IEC 61850 events and command outcomes in SOE") is a future unverified capability, not a demonstrated feature of current v1.6.42/RC. Since this historical feature plan is not being continued on the current schedule, close with GitHub state_reason not_planned, not completed.

    Permanent limitations preserved:

    • Existing Oct 25 evidence recorded 427 decoded frames, 36 per-stream continuity findings and 9 advertised BRCB BufOvfl flags (five-IED observation). These quantities do not establish the number of missing process events.
    • BCUGE Oct 11 ingress comparisons used different physical RCB slots; do not infer which software path is better, nor whether the IED or subscriber caused resets.
    • Non-GI SqNum resets and opaque EntryID transitions remain unqualified; EntryID must not be sorted as a numeric monotonic counter. Any overflow warning must remain truthful in the accepted UI/diagnostics.
    • Current app's accepted report-backed value acquisition is not equivalent to proven lossless buffered historical SOE replay, exact cursor recovery, or complete positive/negative control outcome journal. Do NOT advertise it as such or silently disable SOE safety warnings.
    • Source fixes previously merged (static routing/diagnostic labeling, CI evidence tooling) remain valid for their exact scopes; closing this issue does not install the retired P0-F: fail-closed RCB continuity identity across Report metadata aliases #632 RCB-alias metadata patch.

    No operator recapture, no fresh workflow, no commits, no changes to RC d4598619b1b8fc21487cf5beb83a8a8284d0e9cf or main 14e5dddfbaae012b61a021366c1a864d83d316f2, no pinned engine or published stable version modifications. The archived issue and historical #520 reports remain a durable risk record. A future SOE-lossless feature request must be treated as newly scoped software work with existing recorded evidence first, not a demand to repeat the user's historic captures.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions