Joseph Doherty cd85159951 Add _base equipment-class template for universal cross-machine metadata that every machine in the OtOpcUa estate exposes regardless of vendor, protocol, or machine type. References OPC UA Companion Spec OPC 40010 (Machinery) for the Identification component (Manufacturer, Model, ProductInstanceUri, SerialNumber, HardwareRevision, SoftwareRevision, YearOfConstruction, ManufacturerUri, DeviceManual, AssetLocation) plus the MachineryOperationMode enum (Auto, Manual, Maintenance, Service, Setup, Other), OPC UA Part 9 for the alarm summary fields (HasActiveAlarms, ActiveAlarmCount, HighestActiveAlarmSeverity), ISO 22400 for the lifetime counter fields (TotalRunSeconds, TotalCycles) that feed Availability + Performance KPIs at Layer 3, and the 3-year-plan handoff §"Canonical Model Integration" for the canonical state vocabulary (Running / Idle / Faulted / Starved / Blocked) declared in _base.stateModel. Includes the OtOpcUa five-identifier set (EquipmentUuid, MachineCode, ZTag, SAPID, plus DeviceClass = EquipmentClassRef) so every machine surfaces the join keys downstream consumers need; ConnectionState + LastDataTimestamp + DriverType for driver-side observability that does not require any particular equipment-protocol feature; optional production context (CurrentWorkOrder, CurrentPartNumber, CurrentRecipe, CurrentOperator, CurrentShift) marked isRequired: false since not every machine type surfaces these. Plus two universal alarm definitions (communication-loss, data-stale) that apply to every equipment regardless of class.
Equipment-class.schema.json gains an `extends` field for class inheritance — child classes inherit signals, alarms, and stateModel from the parent and can add new ones or override individual entries by name. Convention: `_` prefix on classId marks an abstract base class (e.g. `_base`) intended only to be extended, not assigned directly to equipment via Equipment.EquipmentClassRef.

FANUC CNC class updated to extends: "_base"; redundant identity signals (Version, ActiveAlarmCount) removed since they're now in the base; remaining FANUC-specific signals updated with cross-references showing how they feed into the base signals at Layer 3 (RunState → canonical Running/Idle/Faulted derivation; AlarmActive → HasActiveAlarms / HighestActiveAlarmSeverity; PartsCount → TotalCycles; MainProgramNumber → CurrentRecipe).

Format-decisions.md adds D9 (rationale for `_base` + `extends` inheritance, with references to OPC 40010 / Part 9 / ISO 22400 / handoff) and D10 (signal `category` drives OPC UA folder placement, per OPC 40010 Identification + Status pattern, with a category-to-folder mapping table).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-17 12:54:17 -04:00
Add _base equipment-class template for universal cross-machine metadata that every machine in the OtOpcUa estate exposes regardless of vendor, protocol, or machine type. References OPC UA Companion Spec OPC 40010 (Machinery) for the Identification component (Manufacturer, Model, ProductInstanceUri, SerialNumber, HardwareRevision, SoftwareRevision, YearOfConstruction, ManufacturerUri, DeviceManual, AssetLocation) plus the MachineryOperationMode enum (Auto, Manual, Maintenance, Service, Setup, Other), OPC UA Part 9 for the alarm summary fields (HasActiveAlarms, ActiveAlarmCount, HighestActiveAlarmSeverity), ISO 22400 for the lifetime counter fields (TotalRunSeconds, TotalCycles) that feed Availability + Performance KPIs at Layer 3, and the 3-year-plan handoff §"Canonical Model Integration" for the canonical state vocabulary (Running / Idle / Faulted / Starved / Blocked) declared in _base.stateModel. Includes the OtOpcUa five-identifier set (EquipmentUuid, MachineCode, ZTag, SAPID, plus DeviceClass = EquipmentClassRef) so every machine surfaces the join keys downstream consumers need; ConnectionState + LastDataTimestamp + DriverType for driver-side observability that does not require any particular equipment-protocol feature; optional production context (CurrentWorkOrder, CurrentPartNumber, CurrentRecipe, CurrentOperator, CurrentShift) marked isRequired: false since not every machine type surfaces these. Plus two universal alarm definitions (communication-loss, data-stale) that apply to every equipment regardless of class.
2026-04-17 12:54:17 -04:00

3-Year Plan: Shopfloor IT/OT Transformation

A 3-year plan for transforming and enhancing shopfloor IT/OT interfaces and data collection — bridging IT and OT layers, improving operator interfaces, and upgrading data collection pipelines.

Vision

A stable, single point of integration between shopfloor OT and enterprise IT.

Three Pillars (binary at end of plan)

  1. Unification — 100% of sites on the standardized stack (OtOpcUa + ScadaBridge + Redpanda + SnowBridge + Snowflake/dbt).
  2. Analytics / AI Enablement — machine data in Snowflake with a ≤15-minute analytics SLO; at least one "not possible before" use case in production.
  3. Legacy Retirement — zero remaining bespoke IT/OT integration paths outside ScadaBridge.

Key Architecture

Layer 1  Equipment (PLCs, controllers, instruments)
Layer 2  OtOpcUa (unified site-level OPC UA — single session per equipment, two namespaces)
Layer 3  SCADA (Aveva System Platform + Ignition)
Layer 4  ScadaBridge (sole IT/OT crossing point)
         ─── IT/OT Boundary ───
         Enterprise IT (Camstar, Delmia, Snowflake, Power BI, SnowBridge)

The plan also declares a Unified Namespace (UNS) composed of OtOpcUa + Redpanda + canonical model in schemas repo + dbt curated layer, with a 5-level naming hierarchy standard (Enterprise → Site → Area → Line → Equipment).

Plan Documents

File Purpose
current-state.md Snapshot of today's systems, integrations, and pain points
goal-state.md Target end-state: architecture, components, success criteria, UNS, canonical model
roadmap.md 7 workstreams x 3 years migration grid
STATUS.md Working-session bookmark — where we left off, pending items

Component Detail Files

File Purpose
current-state/legacy-integrations.md Pillar 3 denominator: 3 legacy IT/OT integrations to retire
current-state/equipment-protocol-survey.md Removed — protocol survey no longer needed; OtOpcUa v2 team committed driver list directly
goal-state/digital-twin-management-brief.md Digital twin management conversation brief (completed)
schemas/ Canonical OT equipment definitions (DRAFT seed contributed by OtOpcUa team — UNS hierarchy + equipment-class templates + format JSON Schemas + worked FANUC CNC pilot). Temporary location until a dedicated schemas repo is created and an owner team is named — see schemas/README.md

Output Generation

File Purpose
outputs/README.md How to regenerate PPTX + PDF from plan source
outputs/presentation-spec.md 18-slide mixed-stakeholder deck structure
outputs/longform-spec.md Faithful-typeset PDF structure

Trigger: regenerate outputs, regenerate presentation, or regenerate longform in a Claude Code session.

Conventions

  • Everything in markdown — no proprietary formats.
  • _TBD_ marks gaps that still need filling.
  • Decisions are captured inline with rationale; don't re-open without new information.

Working with Claude Code

This repo includes a CLAUDE.md file that orients Claude Code sessions to the plan's structure and conventions. Resume work with:

claude --resume <session-id>

or start a new session in this directory — CLAUDE.md and STATUS.md provide enough context to pick up where the last session left off.

Description
No description provided
Readme 2.1 MiB
Languages
Mermaid 100%