98bf2d0da4
SnowBridge now owns machine-data ingest, in-process .NET transformation, and direct writes to curated tables in Snowflake. Collapses the previous ingest/transform split into a single service; no dbt, no external orchestrator, no Snowflake landing tier. Keeps the in-house .NET pattern consistent with ScadaBridge and OtOpcUa. The "Snowflake dbt Transform Layer" roadmap workstream merges into SnowBridge (7 → 6 workstreams); Year 2 canonical-state-based OEE moves with it. Canonical model still has three surfaces — the third is renamed from "dbt curated layer" to "SnowBridge curated layer in Snowflake"; mechanics unchanged.
2.2 KiB
2.2 KiB
Overview
The schemas repo is the org's single source of truth for OT equipment definitions. Three things live here:
- UNS hierarchy — per-site declarations of which Areas and Lines exist (
uns/). - Equipment-class templates — per-class declarations of which raw signals each equipment type exposes (
classes/). - Format definitions — JSON Schemas defining what UNS and class files must look like (
format/).
Why a central repo
Three OT/IT systems consume the same canonical model:
- OtOpcUa equipment namespace — exposes raw signals over OPC UA
- Redpanda + Protobuf event topics — canonical event shape on the wire
- SnowBridge curated layer in Snowflake — analytics model (SnowBridge writes curated rows directly; no separate dbt layer)
Without a central source, they would drift. With one repo, every consumer pulls a versioned snapshot and validates against it. Drift becomes a CI failure, not a production incident.
Lifecycle
[author edits JSON in this repo]
│
▼
[CI validates against format/*.schema.json]
│
▼
[PR review by maintainer + consumer reps]
│
▼
[merge to main → tag a semver release]
│
▼
[each consumer pulls the tag and integrates per docs/consumer-integration.md]
What's NOT in this repo
- Per-equipment configuration — which specific CNC at Warsaw West runs which program. That's per-instance config in OtOpcUa's central config DB (
lmxopcua/docs/v2/config-db-schema.mdEquipment table), not template-level material. - State derivation rules — how raw signals derive into
Running/Idle/Faulted/Starved/Blocked. That's Layer 3 logic in Aveva System Platform / Ignition. Equipment-class templates can declare which states the class supports (stateModel.states) but not the derivation itself. - Wire-format Protobuf schemas — those are code-generated from this repo into a separate output artifact for Redpanda. The authoring source is here; the binary wire format is derived.
- Authoritative LDAP groups, ACL grants, OPC UA security policies — those live in the consuming systems (OtOpcUa central config DB, identity provider).