dohertj2/3yearplan
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Integrate OtOpcUa v2 implementation corrections into plan

Browse Source 
19 corrections from handoffs/otopcua-corrections-2026-04-17.md:

Inaccuracies fixed:
- A1: OPC UA-native equipment requires OpcUaClient gateway driver (~hours
  config), not "no driver build"
- A2: "single endpoint" is per-node (non-transparent redundancy), not
  per-cluster; no VIP planned

Missing constraints added:
- B1: ACL surface (EquipmentAcl table, Admin UI, NodeManager enforcement)
  as Year 1 deliverable before Tier 1 cutover
- B2: schemas-repo creation on OtOpcUa critical path with FANUC CNC pilot
- B3: Certificate-distribution as pre-cutover step (per-node ApplicationUri
  trust-pinning)

Architectural decisions incorporated:
- C1: 8 committed core drivers (added TwinCAT/Beckhoff, split AB Legacy)
- C2: Three-tier driver stability model (A/B/C with out-of-process for
  Galaxy and FOCAS)
- C3: Polly v8+ resilience with default-no-retry on writes
- C4: Multi-identifier equipment model (5 IDs: UUID, EquipmentId,
  MachineCode, ZTag, SAPID)
- C5: Consumer cutover plan needs an owner (flagged)
- C6: Per-building cluster implications at Warsaw clarified

TBDs resolved:
- D1: Pilot equipment class = FANUC CNC
- D2: Schemas repo format = JSON Schema (.json), Protobuf derived
- D3: ACL definitions in central config DB alongside driver/topology
- D4: Enterprise shortname still unresolved (flagged as pre-cutover blocker)

New TBDs added:
- E1: UUID generation authority (OtOpcUa vs external system)
- E2: Aveva System Platform IO pattern validation (Year 1/2 research)
- E3: Site-wide vs per-cluster consumer addressing at Warsaw
- E4: Cluster endpoint wording (resolved via A2)
This commit is contained in:
Joseph Doherty
2026-04-17 10:05:07 -04:00
parent 9b2acfe699
commit 68dbc014da
3 changed files with 90 additions and 30 deletions
Download Patch File Download Diff File Expand all files Collapse all files

52
current-state/equipment-protocol-survey.md
View File

@@ -85,10 +85,10 @@ A protocol is **long-tail** by default if none of the above apply. Long-tail dri
| **Sites** | _TBD_ |
| **Approx. Instance Count** | _TBD_ |
| **Current Access Path** | Mixed — direct OPC UA sessions from Aveva System Platform, Ignition, and/or ScadaBridge depending on the equipment. See [`../current-state.md`](../current-state.md) → Equipment OPC UA. |
| **OtOpcUa Driver Needed?** | **No — already OPC UA.** OtOpcUa acts as an OPC UA client to these devices; no driver build, but connection configuration and auth setup still required. |
| **Driver Complexity (Estimate)** | N/A — connection work only. |
| **OtOpcUa Driver Needed?** | **Uses the `OpcUaClient` gateway driver** from the core library — no new protocol-specific driver project required, but per-equipment configuration (endpoint URL, browse strategy, namespace remapping to UNS, certificate trust, security policy) is still real work. **Onboarding effort per OPC UA-native equipment is ~hours of config, not zero.** |
| **Driver Complexity (Estimate)** | Low — config work, not protocol work. But non-trivial in aggregate if the OPC UA-native fleet is large. |
| **Priority Site(s)** | N/A |
| **Notes** | Will be the **easiest** equipment class to bring onto OtOpcUa once OtOpcUa ships — no driver work, just redirect the client-side connection. Expected to be a meaningful fraction of the estate given the "OPC UA-first" posture of most equipment vendors over the last decade. Survey should **still** capture this category because the count informs how much of the tier-1 ScadaBridge cutover is "redirect an existing OPC UA client" vs "bridge through a new driver." |
| **Notes** | Will be the **lowest per-unit effort** equipment class to bring onto OtOpcUa — the `OpcUaClient` gateway driver handles them, but each equipment still needs endpoint config, browse strategy, namespace remapping, and certificate trust. Expected to be a meaningful fraction of the estate given the "OPC UA-first" posture of most equipment vendors over the last decade. Survey should **still** capture this category because the count informs (a) how much of the tier-1 ScadaBridge cutover is "configure an existing driver" vs "build a new one" and (b) aggregate config effort. |
### EQP-002 — Siemens PLC family (S7)
@@ -124,6 +124,40 @@ A protocol is **long-tail** by default if none of the above apply. Long-tail dri
| **Priority Site(s)** | _TBD_ |
| **Notes** | Paired with EQP-002 (Siemens) as the two most likely dominant PLC protocol families. Confirm scope during discovery. |
### EQP-003a — Allen-Bradley Legacy (SLC 500 / MicroLogix — PCCC protocol)
| Field | Value |
|---|---|
| **ID** | EQP-003a |
| **Equipment Class** | Allen-Bradley / Rockwell SLC 500, MicroLogix families (legacy — separate from ControlLogix/CompactLogix CIP) |
| **Vendor(s)** | Rockwell Automation |
| **Native Protocol** | PCCC (Programmable Controller Communication Commands) — different protocol stack from EtherNet/IP CIP, despite same vendor |
| **Protocol Variant / Notes** | Data table addressing (integer, float, binary, timer, counter files), not tag-based like CIP. Shared library (libplctag) with EQP-003, but separate driver project due to different protocol semantics. |
| **Sites** | _TBD_ |
| **Approx. Instance Count** | _TBD_ |
| **Current Access Path** | _TBD — likely System Platform PCCC/DH+ IO driver_ |
| **OtOpcUa Driver Needed?** | **Core candidate (pre-committed in v2 design).** The v2 OtOpcUa design commits AB Legacy as a separate driver from AB CIP. Marginal cost is low (shared libplctag library) but it has its own stability tier (B), test coverage, and Admin UI surface. |
| **Driver Complexity (Estimate)** | Low-to-Medium — shares libplctag with EQP-003; the added work is the data-table addressing model and validation against legacy hardware. |
| **Priority Site(s)** | _TBD_ |
| **Notes** | Split from EQP-003 based on v2 OtOpcUa implementation findings — CIP and PCCC are different enough to warrant separate driver instances. Confirm via survey whether SLC/MicroLogix equipment still exists in meaningful numbers or has been replaced by ControlLogix. |
### EQP-003b — Beckhoff TwinCAT (ADS protocol)
| Field | Value |
|---|---|
| **ID** | EQP-003b |
| **Equipment Class** | Beckhoff TwinCAT PLCs and motion controllers |
| **Vendor(s)** | Beckhoff Automation |
| **Native Protocol** | TwinCAT ADS (Automation Device Specification) — proprietary Beckhoff protocol with native subscription support |
| **Protocol Variant / Notes** | ADS supports native subscriptions (no polling needed), which makes it more efficient than poll-based protocols for high-frequency data. ADS runs over TCP. |
| **Sites** | _TBD — known Beckhoff installations at specific sites per OtOpcUa team's internal knowledge_ |
| **Approx. Instance Count** | _TBD_ |
| **Current Access Path** | _TBD — likely direct ADS or via a Beckhoff OPC UA server_ |
| **OtOpcUa Driver Needed?** | **Core candidate (pre-committed in v2 design).** Not in the original plan's expected categories — added based on known Beckhoff installations at specific sites, confirmed by the OtOpcUa team ahead of the formal protocol survey. |
| **Driver Complexity (Estimate)** | Medium — ADS protocol is well-documented by Beckhoff; native subscriptions simplify the subscription model. Tier B stability (wrapped native, mature). |
| **Priority Site(s)** | _TBD — the sites with known Beckhoff installations should be confirmed during the protocol survey_ |
| **Notes** | **Pre-survey addition.** This category was not in the original expected list (EQP-001 through EQP-006). Added based on v2 OtOpcUa implementation design findings confirming known Beckhoff installations. The formal protocol survey should validate whether the committed core driver is justified by the install base. |
### EQP-004 — Generic Modbus devices
| Field | Value |
@@ -185,11 +219,13 @@ These views are **derived** from the row-level data above. Regenerate as rows ar
| Native Protocol | Row IDs | Total Approx. Instances | Sites | Core / Long-tail / Already OPC UA |
|---|---|---|---|---|
| OPC UA | EQP-001 | _TBD_ | _TBD_ | Already OPC UA — no driver needed |
| Siemens S7 | EQP-002 | _TBD_ | _TBD_ | _TBD — depends on S7-1500 fraction_ |
| EtherNet/IP | EQP-003 | _TBD_ | _TBD_ | _TBD — likely core_ |
| Modbus TCP/RTU | EQP-004 | _TBD_ | _TBD_ | _TBD — likely core_ |
| Fanuc FOCAS | EQP-005 | _TBD_ | _TBD_ | _TBD — depends on CNC count_ |
| OPC UA | EQP-001 | _TBD_ | _TBD_ | Uses `OpcUaClient` gateway driver (core library) — config work per equipment, not protocol work |
| Siemens S7 | EQP-002 | _TBD_ | _TBD_ | **Pre-committed core** (v2 design) — validate with survey |
| EtherNet/IP (CIP) | EQP-003 | _TBD_ | _TBD_ | **Pre-committed core** (v2 design) |
| PCCC (AB Legacy) | EQP-003a | _TBD_ | _TBD_ | **Pre-committed core** (v2 design) — validate SLC/MicroLogix fleet still exists |
| TwinCAT ADS (Beckhoff) | EQP-003b | _TBD_ | _TBD_ | **Pre-committed core** (v2 design) — based on known installations, validate with survey |
| Modbus TCP/RTU | EQP-004 | _TBD_ | _TBD_ | **Pre-committed core** (v2 design) |
| Fanuc FOCAS | EQP-005 | _TBD_ | _TBD_ | **Pre-committed core** (v2 design) — **pilot equipment class for canonical model** |
| Long-tail mix | EQP-006+ | _TBD_ | _TBD_ | Long-tail — on-demand |
**Decision output of this table:** the **core driver library scope** for Year 1 OtOpcUa. A protocol row tagged `Core` becomes a Year 1 build commitment; `Long-tail` becomes a Year 2+ on-demand build budget; `Already OPC UA` becomes connection configuration work only.