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.
43 lines
2.2 KiB
Markdown
43 lines
2.2 KiB
Markdown
# Overview
|
|
|
|
The `schemas` repo is the org's single source of truth for OT equipment definitions. Three things live here:
|
|
|
|
1. **UNS hierarchy** — per-site declarations of which Areas and Lines exist (`uns/`).
|
|
2. **Equipment-class templates** — per-class declarations of which raw signals each equipment type exposes (`classes/`).
|
|
3. **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.md` Equipment 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).
|