design: Adapter-based integration for AAS and upper-system standards (master-in / telemetry-out)

[e7217]

Context

EDG positions itself as a lightweight L2.5 edge gateway (ISA-95). The question came up whether to adopt AAS (Asset Administration Shell) as a first-class concept inside the core. After review, the conclusion is no — keep AAS (and other upper-system standards) out of the core, expose them as adapters.

This issue captures the design rationale and the concrete work needed to make EDG adapter-friendly without committing to any specific standard today.

Layer Mapping

ISA-95 Level	Role	EDG	AAS
L0–L2	Sensors, PLCs, SCADA	source	—
L2.5 (Edge)	Gateway, normalization, buffering	EDG core	partial (asset surface)
L3 (MOM/MES)	Asset twin, ops management	data producer	AAS native habitat
L4 (ERP)	Business systems	—	integration target

EDG operates on the data plane (high-frequency observations). AAS lives on the information plane (asset identity, capability, lifecycle). They overlap only thinly at "asset metadata".

Proposed Architecture: Canonical Model + Ports & Adapters

                    ┌─────────────────────────────────┐
                    │      EDG Canonical Model        │
                    │  (Asset, Relation, Observation) │
                    └─────────────────────────────────┘
                          ▲                    │
              ┌───────────┘                    └───────────┐
              │ (cold, low freq)                (hot, high freq)
              │                                            │
   [Master Data IN]                              [Telemetry OUT]
   - AAS Importer                                - NATS/JSON (existing)
   - OPC-UA Browse                               - Telegraf -> VictoriaMetrics
   - ECLASS / IRDI                               - MQTT Sparkplug B
   - ERP/MES API                                 - AAS Submodel push (if needed)

Why two distinct axes

Axis	Trigger	SLA	Adapter responsibility
Master data (cold)	Asset register/change	minutes–hours	Standard -> internal model, identifier reconciliation
Telemetry (hot)	Every measurement	sub-ms	Internal model -> standard serialization, must never block

Performance / Lightweight Alignment

The "lightweight" promise applies to the hot path only.

• Hot path stays NATS/JSON, no AAS serialization.
• Cold path adapters (per-asset, on change) add near-zero runtime cost.
• Heavy dependencies (e.g. JVM-based BaSyx) live in sidecar processes, decoupled via NATS — never linked into the Go core.

No conflict with the project's performance philosophy as long as this separation is preserved.

Best-Practice References

• Eclipse BaSyx / FA³ST: AAS server runs alongside the gateway, syncs from asset events.
• Siemens Industrial Edge: telemetry via OPC-UA, AAS handled by a separate Asset Hub.
• Catena-X: AAS is used at the organizational boundary, not as the internal domain model.

Common pattern: AAS is a boundary serialization format, not a domain model.

Concrete Work Items

• Identifier slots in asset model: add optional fields for IRDI / ECLASS / IEC CDD / AAS Identifier so external standards can map mechanically without schema changes later.
• Master Data Port (inbound API): stable interface for adapters to push asset / relation upserts (POST /assets, PUT /assets/{id}, POST /relations).
• Metadata change events: publish platform.meta.asset.changed on NATS so external exporters (AAS, OPC-UA, etc.) can sync without polling or coupling.
• Source provenance & reconciliation policy: tag each metadata record with its source and define precedence rules for conflicts (ERP vs AAS vs manual).
• Versioned mappers: document the expectation that adapters carry versioned mapping functions, isolating the core from upstream schema evolution.
• Sidecar pattern documentation: ADR describing how heavyweight standard adapters (BaSyx, OPC-UA stacks) should be deployed as separate processes.

Non-Goals (for now)

• Implementing an AAS server, AASX packaging, or BaSyx integration inside edg-core.
• Adopting AAS Submodel structures as internal domain types.
• Committing to a single upper-system standard — the design must remain pluggable.

Open Questions

• Which upper-system integration is the first real driver (MES vendor? Catena-X? internal MOM)? This determines which adapter ships first.
• Should the metadata change event stream be a separate NATS subject hierarchy or piggyback on existing asset registration flow?