Skip to content

P3-A: vendor-neutral SCL-driven SV interoperability profile foundation #33

Open

Description

@masarray

Goal

Make the SV injector configuration-driven and interoperable across merging-unit implementations without hard-coded device identities or vendor-specific branches.

North-star rule

A real SCL/CID stream is engineering intent. ARStack must parse it, preserve its wire-relevant semantics, compile it into a deterministic publisher profile, and reject ambiguous bindings rather than guessing.

Public repository content remains vendor-neutral. Commercial names, product names, screenshots, captures, and proprietary configuration files are not committed. Real lab evidence may be distilled into anonymous regression fixtures that preserve only standards-relevant structure.

P3-A0 — parser/profile foundation

  • preserve SmvOpts semantics in the SCL model;
  • expand FCDA entries that select a structured data object without daName into ordered leaf attributes using DataTypeTemplates and FC filtering;
  • compile SclSampledValuesStream into a normalized SvPublisherProfile;
  • preserve destination MAC, APPID, VLAN ID/PCP, svID, confRev, sample rate/mode, nofASDU, dataset order/types and synchronization policy inputs;
  • derive sample-counter modulus for SmpPerSec without hard-coding 4000;
  • provide a rational tick scheduler so rates such as 4800 samples/s do not accumulate timing drift;
  • add a vendor-neutral 4800 samples/s 4I+4V structured-FCDA regression fixture;
  • add a CLI inspector for SCL/CID -> normalized SV profile.

P3-A1 — compiled device profile

  • define versioned binary profile schema with length/checksum;
  • host-side serialize/validate;
  • embedded validate and activate atomically;
  • prebuild fixed packet templates outside the hot path;
  • remove stream identity/rate/layout hard-coding from the ESP32-P4 publisher.

P3-A2 — interoperability matrix

Test anonymous profile families, not brands:

  • 4000 SmpPerSec / 50 Hz protection-style 4I+4V;
  • 4800 SmpPerSec / 60 Hz or second-aligned 4I+4V;
  • explicit leaf FCDA and structured FCDA without daName;
  • optional SmvOpts combinations;
  • different APPID/MAC/VLAN/confRev/svID values;
  • multiple streams and nofASDU variants;
  • datasets beyond fixed 4I+4V where the SCL type system fully resolves the wire layout.

Acceptance

  • no vendor/product-specific code path;
  • no XML parsing, allocation, string work or type resolution in the realtime TX hot path;
  • 4000 and 4800 schedules are long-term drift-free in the scheduler model;
  • unresolved or unsupported wire layout is reported explicitly;
  • canonical stream remains SCL/profile-driven;
  • synchronization claims remain evidence-driven and smpSynch is not promoted without measured lock state.

This issue is independent of the hardware-TX timestamp acceptance track; the two converge when the compiled profile drives the deterministic hardware publisher.

Activity

  1. masarray commented on Aug 10, 2026

    @masarray
    OwnerAuthor

    P3-A0 is now active in draft PR #34. The implementation is intentionally profile-family driven rather than brand-preset driven: SCL/CID/SCD/IID intent is parsed into a normalized SvPublisherProfile, structured FCDA entries can expand through DataTypeTemplates, SmvOpts is preserved, and non-integer-microsecond publisher rates use a rational tick schedule. An anonymous 4800 samples/s structured 4I+4V regression fixture and read-only profile inspector are included.

    One important hardening decision was made during implementation: SmpPerSec does not by itself become authoritative sample-counter-wrap evidence. A sample-rate-sized modulus may be exposed only as an unvalidated candidate for inspection; P3-A1 device deployment must receive a validated profile rule or independently observed-evidence modulus. This preserves the configured-vs-observed separation required for broad interoperability.

    PR #26 remains the independent hardware timing track. P3-A1 will converge the two by deploying a validated binary profile to the deterministic ESP32-P4 publisher and measuring the resulting canonical stream with EMAC hardware TX timestamps.

  2. masarray commented on Oct 6, 2026

    @masarray
    OwnerAuthor

    2026-10-06 continuation from #139

    The P3-A foundation has advanced materially without creating a parallel profile model:

    The next interoperability-profile node after #142 is accepted should complete the profileFamily slot already described in NORTH_STAR.md.

    Rules for that node:

    • distinguish Generic IEC 61850-9-2, Legacy 9-2LE compatibility and IEC 61869-9;
    • family selection/claim must be explicit or backed by a specific rule/evidence source — never inferred merely from APPID, MAC, DataSet naming or payload shape;
    • generic wire/SCL validity remains separate from profile-family validity;
    • ESP32-P4 device capability remains a separate final gate;
    • do not claim IEC 61869-9 conformance merely because the timing model can represent a family-shaped stream;
    • keep vendor identities out of protocol branches.

    Recovery source remains #139; continue from current accepted PR lineage rather than reopening P3-A0.

  3. masarray commented on Oct 7, 2026

    @masarray
    OwnerAuthor

    2026-10-07 closure audit after P1.2 review

    This issue is not ready to close yet, but the remaining gap is now narrow and already has a canonical owner.

    P3-A0 — effectively complete

    Covered by the merged #140/#141/#142/#143 lineage plus active #145:

    • SmvOpts preservation and explicit profile-family semantics;
    • structured/explicit FCDA -> ordered canonical leaves;
    • normalized SvPublisherProfile compiler;
    • MAC/APPID/VLAN/svID/confRev/timing/nofASDU/DataSet preservation;
    • rational 4000/4800 timing model;
    • explicit counter-policy boundary;
    • anonymous 4800 fixture + CLI inspector;
    • IEC 61869-9 dataset/variant/scaling authority in P3-H P1.2: IEC 61869-9 variant, dataset and scaling authority #145.

    P3-A1 — remaining closure blocker

    The ESP runtime already has:

    • atomic STOPPED profile staging/commit;
    • bounded RuntimePublisherProfile validation;
    • prebuilt packet templates + encoder-owned WirePlan;
    • stream identity/rate pulled from active runtime profile;
    • no XML/type traversal in the realtime TX path.

    But the issue explicitly requires a versioned binary host->device profile with total length + integrity/checksum validation. The current bridge is still a staged textual PROFILE command protocol populating an in-memory schema-v1 RuntimePublisherProfile. That is not equivalent to the requested binary integrity contract.

    Canonical owner: #36. Do not create a second device-profile authority here.

    P3-A2

    Host-side breadth is now substantially covered (multi-stream identity/family state, nofASDU timing semantics, IEC 61869-9 non-4I4V semantic profiles), but physical interoperability/timing evidence remains separate and should stay tied to #21/#36.

    Closure rule

    Close #33 only after #36 lands the bounded binary profile/integrity contract (or #33 is explicitly rescaled by maintainers). Do not close it merely because the host compiler is mature.

  4. masarray commented on Oct 7, 2026

    @masarray
    OwnerAuthor

    2026-10-07 incremental acceptance audit (post-#145)

    Decision: keep #33 OPEN. Verified current main@0a08767df0352b0311fdcf5d31a9782ccba1a13b includes merged standards foundation #140/#141/#142/#143/#145; P1.2 IEC 61869-9 host authority is accepted. #147/#148 remain the narrow fail-closed nofASDU follow-up and must pass exact-head CI before merging.

    Closure gate: #146 binary contract accepted plus the relevant #36 device decode/transport activation and physical evidence, or an explicit scoped redefinition of #33. Continue #139 recovery orchestration; do not close #33 based on host-only tests.

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