Skip to content

G2.6/G2.7 Smart Dynamic RCB: field-stable per-IED bootstrap + full eligible residual coverage - #230

Draft
masarray wants to merge 151 commits into
g2.5-a2.1-command-bound-witnessfrom
g2.6-smart-dynamic-rcb
Draft

G2.6/G2.7 Smart Dynamic RCB: field-stable per-IED bootstrap + full eligible residual coverage#230
masarray wants to merge 151 commits into
g2.5-a2.1-command-bound-witnessfrom
g2.6-smart-dynamic-rcb

Conversation

@masarray

@masarray masarray commented Aug 24, 2026

Copy link
Copy Markdown
Owner

Goal

Restore Smart Dynamic RCB as the normal ARSAS monitoring path so every eligible exact-resolved residual leaves MMS polling and is acquired through static or Dynamic BRCB/URCB. MMS polling remains only for genuine unsupported/unmapped/degraded points, real RCB-capacity overflow, or a real activation failure that opens the dynamic-write circuit breaker.

ProductionEligible remains a separate certification boundary and is never promoted by this PR.

Runtime acquisition contract

Planning order is:

  1. configured static report coverage first;
  2. exact live MMS resolution for still-uncovered selected signals;
  3. identity-bound P1.6/P1.7 field-capability authorization;
  4. fresh current-association verified-free RCB inventory;
  5. bounded 1..N Dynamic DataSet/RCB groups using deterministic per-RCB AR_HYB_<hash> identities;
  6. MMS polling only for the genuine residual set.

For native P1.7, the generic MaxDynamicReportPlans=8 budget no longer strands otherwise eligible signals on polling. The native-only plan budget expands to the freshly checked association RCB inventory with an application hard ceiling of 64 plans. ARIEC still admits only exact verified-free RCB slots.

P1.7 field-stable per-IED bootstrap

A previously unseen IED is commissioned explicitly with Ctrl+Shift+B:

G2.3 bounded Dynamic DataSet qualification
  -> exact fresh-association residue recovery when association/cleanup fails
  -> retain largest prior cleanup-safe multi-member envelope after exact residue closure
G2.4 transactional free-URCB activation + actual InformationReport proof
G2.5 strict NO-GI spontaneous dchg proof
monitor cleanup + proof-field restore + fresh-association closure
persist native DataChange InformationReportProven profile
persist separate exact native cleanup/capability sidecar

The bootstrap issues zero automatic process/control commands. At G2.5 ARMED the operator causes exactly one already-approved safe physical/status change affecting one listed proven member.

G2.3 field recovery rule

If a smaller milestone is fully cleanup-safe but a later larger DefineNamedVariableList destabilizes the association:

  • the failed exact LLN0.ARQ<8hex> residue is inspected on a fresh association;
  • delete is allowed only after exact ordered member readback matches the failed attempt;
  • closure requires proven namespace absence + completed direct-directory absence + healthy association;
  • discovery/directory exceptions never count as absence evidence;
  • after closure, ARSAS retains the largest prior IsQualificationSuccess multi-member envelope;
  • the later failed larger milestone is never generalized as safe;
  • if no prior clean multi-member envelope exists, the unchanged G2.3 ladder gets at most one fresh retry.

Retaining that envelope grants only EnvelopeQualified; G2.4/G2.5 remain mandatory.

P1.7 envelope-bounded normal runtime

Merged ARIEC PR #110 adds an envelope-bounded native runtime wrapper.

The physical dchg witness proves the Dynamic RCB mechanism for fresh exact-resolved members; it is not a permanent commissioning-member whitelist. However each individual runtime Dynamic DataSet is capped to:

min(configured MaxDynamicMembersPerReport,
    Profile.ProvenSafeMemberCount)

Therefore a relay that physically survives 4 members but destabilizes at 8 will be covered by multiple <=4-member Dynamic RCB groups instead of being asked to create an unsafe larger list.

Example when safe envelope=4 and enough free RCBs exist:

132 eligible residuals
-> 33 bounded Dynamic groups
-> 132 Dynamic BRCB/URCB signals
-> 0 MMS polling residual

If only 31 verified-free RCBs exist, at most 124 of those 132 can be Dynamic at that 4-member envelope; the remaining 8 are genuine current-association capacity residual, not an artificial planner fallback.

Two-part durable native authorization

A native DataChange profile alone is insufficient. Normal P1.7 runtime also requires a separate sidecar bound to the exact:

  • stable IED identity;
  • model fingerprint;
  • profile revision;
  • RCB and temporary DataSet;
  • activation/report evidence IDs;
  • included-member mapping;
  • actual NO-GI dchg reason;
  • association health;
  • monitor cleanup;
  • proof-field restore;
  • fresh-association cleanup closure.

Any mismatch fails closed.

Safety retained

  • static reporting precedence;
  • exact live MMS member resolution;
  • fresh current-association RCB availability before every write;
  • per-group size bounded by the physical G2.3 envelope for native P1.7;
  • native total plan count bounded by fresh RCB inventory and hard application ceiling;
  • deterministic per-RCB AR_HYB_<hash> identity;
  • isolated execution-time revalidation before mutation;
  • process-lifetime dynamic-write circuit breaker after a real activation failure;
  • cleanup/reconnect/revalidation;
  • no capability authorization from advertised MMS services alone;
  • no MarkProductionEligible call.

ARIEC engine

Current lock pins merged ARIEC:

main @ 9b60458ed910a410b843185384f0e04d3ca78ce0
source PR #110

Relevant lineage:

Current physical gate — AA1E1F06R4

Observed field baseline before this recovery slice:

static URCB coverage ~= 6 signals
dynamicBRCB=0
dynamicURCB=0
MMS polling ~=132
freeURCB=31
dynamicAllowed=True

Ctrl+Shift+B reached G2.3 and correctly failed closed when association continuity/cleanup was not proven. No profile was advanced.

Next physical sequence

Open SCL
-> Connect AA1E1F06R4
-> DO NOT Start Monitor first
-> Ctrl+Shift+B
-> G2.3 qualification/recovery
-> G2.4 activation proof
-> G2.5 ARMED
-> cause exactly one approved safe physical/status change on a listed proven member
-> P1.7 PASS
-> Disconnect
-> Connect
-> Start Monitor

Acceptance evidence

After reconnect/start monitor:

  • P1.7 native field-capability candidate loads;
  • all exact-resolved residuals that fit the fresh free-RCB capacity are assigned Dynamic BRCB/URCB;
  • Dynamic groups=N reflects however many bounded groups are necessary, not an artificial 8-plan ceiling;
  • each Dynamic group has members <= ProvenSafeMemberCount;
  • each group uses a stable AR_HYB_<hash> DataSet;
  • RptEna / report monitoring activates successfully;
  • spontaneous dchg updates are observed;
  • MMS polling contains only unmapped/unsupported/degraded/capacity-overflow points;
  • disconnect/reconnect performs fresh revalidation/re-arm without mutation loops.

Keep PR #230 DRAFT + UNMERGED until this physical bootstrap + full eligible residual runtime + reconnect evidence is reviewed cleanly.

@masarray masarray changed the title G2.6 Smart Dynamic RCB: guarded normal runtime with general field-capability coverage G2.6/G2.7 Smart Dynamic RCB: general field capability + native per-IED bootstrap Sep 2, 2026

masarray commented Sep 2, 2026

Copy link
Copy Markdown
Owner Author

G2.7 P1.7 exact-head software qualification — PASS

Exact ARSAS head qualified for the next physical gate:

96a0ccddc6dbb46299aaa96f9e1ed258d3f6b2f3

Exact pinned ARIEC engine:

c979206988ebcbaf79e62b784895e19547184369 (merged PR #107)

Exact-head CI

All four required workflows are green on 96a0ccdd...:

  • Build ARSAS #1610 — SUCCESS
    • immutable ARIEC lock/API verification PASS
    • solution restore/build PASS
    • ARSAS regression tests PASS
    • portable publish PASS
    • portable smoke test PASS
  • Validate ARSAS Windows installer #484 — SUCCESS
    • restore/build/test PASS
    • installer compile PASS
    • silent install/uninstall smoke PASS
  • Validate IO List Testing #553 — SUCCESS
  • Validate SV evidence bundles #719 — SUCCESS

The two commits after previously-green 0fffd4ae... are a TDD diagnostics probe plus its revert; compare 0fffd4ae...96a0ccdd has zero changed files, so the qualified source tree is unchanged while the current exact head is independently green.

Fixed-point review

Re-reviewed P1.7 bootstrap/persistence/runtime boundary:

  • bootstrap remains explicit Ctrl+Shift+B and zero automatic process/control commands;
  • G2.4 advances its profile only after actual InformationReport proof plus complete monitor/proof-field cleanup;
  • G2.5 native persistence requires actual NO-GI dchg, exact included-member mapping, association health, monitor cleanup, proof-field restore, and fresh-association cleanup closure;
  • native runtime requires both the exact InformationReportProven/DataChange profile and a separate sidecar bound to identity/fingerprint/profile revision/RCB/DataSet/activation evidence ID/report evidence ID;
  • advertised capability or a DataChange profile alone cannot unlock general Dynamic RCB;
  • ProductionEligible remains independent/OFF;
  • static precedence, fresh live member resolution, fresh verified-free RCB availability, bounded groups, deterministic AR_HYB_<hash>, execution revalidation, dynamic-write circuit breaker and MMS residual fallback remain intact.

Next physical gate — AA1E1F03R3

Baseline to beat:

requested=139; dynamicBRCB=0; dynamicURCB=0; polling=139; freeURCB=30; dynamicAllowed=True

Run only this sequence on the exact qualified build:

Open SCL -> Connect AA1E1F03R3 -> Ctrl+Shift+B -> wait for G2.5 READY -> cause exactly one approved safe physical/status change on a proven member -> bootstrap PASS -> Disconnect -> Connect -> Start Monitor

Then capture diagnostics proving:

  • native P1.7 candidate accepted;
  • Dynamic groups > 0 / dynamic signals > 0;
  • per-group RCB + stable AR_HYB_<hash> DataSet + member count;
  • successful activation / RptEna / monitor active;
  • spontaneous dchg updates;
  • MMS fallback only genuine residual/degraded points;
  • clean disconnect/reconnect revalidation and re-arm without a repeated mutation loop.

PR #230 remains OPEN + DRAFT + UNMERGED. Do not mark ProductionEligible or merge until the physical bootstrap + all-signal normal-runtime + reconnect evidence is reviewed.

@masarray masarray changed the title G2.6/G2.7 Smart Dynamic RCB: general field capability + native per-IED bootstrap G2.6/G2.7 Smart Dynamic RCB: field-stable per-IED bootstrap + full eligible residual coverage Sep 3, 2026
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