Block a user
42af4fd976
Mark corrections-doc E2 (Aveva System Platform IO pattern verification) as RESOLVED with GREEN-YELLOW verdict — the OtOpcUa team completed the research, published findings at lmxopcua/docs/v2/aveva-system-platform-io-research.md, and added a Phase 1 acceptance test (Task E.10, decision #142) to catch AppServer-specific quirks well before the Year 3 tier-3 cutover schedule. AVEVA's OI Gateway is the documented path; multiple non-AVEVA upstream-server integrations exist in published partner walkthroughs; no re-architecting of OtOpcUa needed. Two integrator-burden risks the plan team should track: validation/GxP paperwork (no AVEVA Part 11 blueprint for non-AVEVA upstream servers — engage QA/regulatory in Year 1) and unpublished scale benchmarks (in-house benchmark required in Year 2 before tier-3 cutover scheduling).
1189dc87fd
Close corrections-doc E2 (Aveva System Platform IO upstream-OPC-UA pattern verification) with GREEN-YELLOW verdict (decision #141) — AVEVA's OI Gateway communication driver is the documented path for AppServer to consume from arbitrary upstream OPC UA servers; multiple AVEVA partners (Software Toolbox, InSource) have published end-to-end integrations against four different non-AVEVA upstream servers (TOP Server, OPC Router, OmniServer, Cogent DataHub). No re-architecting of OtOpcUa required. Path: OPC UA node → OI Gateway → SuiteLink → $DDESuiteLinkDIObject → AppServer attribute. Recommended AppServer floor: System Platform 2023 R2 Patch 01.
78a58b3a31
Resolve enterprise shortname = zb (closes corrections-doc D4) and propagate through all UNS path examples and schema seeds.
0307a498ed
Resolve enterprise shortname = zb (decision #140, closes corrections-doc D4) — matches the existing ZB.MOM.WW.* namespace prefix used throughout the codebase, short by design since this segment appears in every equipment path (zb/warsaw-west/bldg-3/line-2/cnc-mill-05/RunState), operators already say "ZB" colloquially. Updated plan.md UNS browse-path example, plan.md Namespace schema sketch NamespaceUri example, plan.md ServerCluster schema sketch Enterprise comment, admin-ui.md cluster-create workflow form (Enterprise field default-prefilled zb), config-db-schema.md ServerCluster.Enterprise column comment.
8704f9e455
Integrate Round 3 OtOpcUa corrections into the plan files (goal-state.md, roadmap.md) and append a Round 3 addendum to the corrections doc for audit trail.
d8fa3a0ddd
Add OPC 40010 Machinery identity columns to the Equipment table (Manufacturer, Model, SerialNumber, HardwareRevision, SoftwareRevision, YearOfConstruction, AssetLocation, ManufacturerUri, DeviceManualUri — all nullable so equipment can be added before identity is fully captured) and surface them via a dedicated Identification panel in the Admin UI Equipment editor. These pair with the new _base equipment-class template seeded in 3yearplan/schemas/classes/_base.json that every other class extends — Manufacturer + Model are declared isRequired: true in the base, the rest optional. Drivers that can read these dynamically (FANUC cnc_sysinfo() returning SoftwareRevision, Beckhoff TwinCAT.SystemInfo, etc.) override the static value at runtime; static value is the operator-set fallback. Exposed on the OPC UA equipment node under the OPC 40010-standard Identification sub-folder per the category → folder mapping in schemas/docs/format-decisions.md D10. Decisions #138 (_base class with extends inheritance, references OPC 40010 + Part 9 + ISO 22400 + handoff canonical state vocabulary) and #139 (Equipment table identity columns) capture the rationale.
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.
5953685ffb
Seed the canonical OT schemas content under 3yearplan/schemas/ as a temporary location until a dedicated schemas repo is created (Gitea push-to-create is disabled, the dedicated repo needs a manual UI step). Initial seed contributed by the OtOpcUa team to unblock the EquipmentClassRef integration timeline (lmxopcua decision #112) and to provide the future cross-team owner with a concrete starting point rather than a blank slate. Marked DRAFT throughout with prominent "ownership TBD" framing in README and CONTRIBUTING — the future owner team should treat this seed as a starting point and revise format / structure / naming as the open questions in README "Open Questions" get resolved.
dee56a6846
Mark corrections-doc B1 (data-path ACLs) and C5 (consumer cutover scope) as RESOLVED. B1: OtOpcUa team has designed and committed the OPC UA client data-path authorization model in lmxopcua/docs/v2/acl-design.md (decisions #129–132) covering NodePermissions bitmask flags for Browse/Read/Subscribe/HistoryRead/WriteOperate/WriteTune/WriteConfigure/AlarmRead/AlarmAck/AlarmConfirm/AlarmShelve/MethodCall plus common bundles, 6-level scope hierarchy with default-deny + additive grants, NodeAcl table generation-versioned alongside the rest of the content, cluster-create workflow seeding the v1 LDAP-role-to-permission map for v1 → v2 consumer migration parity, Admin UI ACL tab with bulk grant + permission simulator, denied-only audit logging; the "must work from day one of Tier 1 cutover" timing constraint is satisfied because Phase 1 (Configuration + Admin scaffold) completes before any driver phase. C5: consumer cutover (ScadaBridge / Ignition / System Platform IO) is OUT of v2 scope per lmxopcua decision #136 — OtOpcUa team's scope ends at Phase 5 (all drivers built, all stability protections in place, full Admin UI shipped including ACL editor); cutover sequencing per site, validation methodology, rollback procedures, and Aveva-pattern validation for tier 3 are deliverables of a separate integration / operations team that has yet to be named. Plan should explicitly assign ownership of the cutover plan to that team and link to their forthcoming doc.
4903a19ec9
Add data-path ACL design (acl-design.md, closes corrections B1) + dev-environment inventory and setup plan (dev-environment.md), and remove consumer cutover from OtOpcUa v2 scope.
f53a775968
Mark corrections-doc C1 (driver list pre-survey) as RESOLVED — the OtOpcUa team has confirmed all seven v2 drivers (Modbus TCP including DL205, AB CIP, AB Legacy, S7, TwinCAT, FOCAS, OPC UA Client) plus Galaxy/MXAccess by direct knowledge of the equipment estate; the survey is no longer a v2 prerequisite. TwinCAT and AB Legacy specifically called out as committed by known Beckhoff and SLC/MicroLogix legacy installations. Survey may still inform long-tail driver scoping and per-site capacity planning per the handoff's Long-tail drivers section, but the v2 driver list is fixed. Recommends the handoff's "Core library scope is driven by the survey" wording be updated to reflect that the v2.0 core library is pre-committed by direct equipment-estate knowledge, with the survey informing only long-tail driver scoping. Captured as lmxopcua decision #128 (2026-04-17).
2a6c9828e4
Confirm the v2 driver list as fixed (decision #128) and remove the Equipment Protocol Survey from the v2 prerequisites — the seven committed drivers (Modbus TCP including DL205, AB CIP, AB Legacy, S7, TwinCAT, FOCAS, OPC UA Client) plus Galaxy/MXAccess are confirmed by direct knowledge of the equipment estate (TwinCAT and AB Legacy specifically called out by the OtOpcUa team based on known Beckhoff installations and SLC/MicroLogix legacy equipment); the survey may still inform long-tail driver scoping and per-site capacity planning but adding/removing drivers from the v2 implementation list is now out of scope. Phase-1 implementation doc loses the survey row from its Out-of-Scope table.