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

Remove equipment protocol survey — driver list confirmed by v2 team

Browse Source 
The OtOpcUa v2 implementation team committed all 8 core drivers from
internal knowledge of the estate, making the formal protocol survey
unnecessary for driver scoping. Removed current-state/equipment-protocol-
survey.md and cleaned up all references across 7 files.

The UNS hierarchy snapshot (per-site equipment-instance walk for site/area/
line/equipment assignments + UUIDs) is now a standalone Year 1 deliverable,
decoupled from protocol discovery. Tracked in status.md and goal-state.md
UNS naming hierarchy section.

Eliminates ~52 TBDs (all placeholder data in the pre-seeded survey rows).
This commit is contained in:
Joseph Doherty
2026-04-17 11:54:37 -04:00
parent f53a775968
commit bed8c8e12b
8 changed files with 13 additions and 282 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -1,268 +0,0 @@
# Equipment Protocol Survey
The authoritative inventory of **equipment protocols in use across the estate**. Feeds scope decisions for the **OtOpcUa core driver library** (see [`../goal-state.md`](../goal-state.md) → OtOpcUa → Driver strategy).
> This file is the **input** to the Year 1 OtOpcUa decision: which protocols get a driver built **proactively** (core library) vs. which get built **on-demand** (long-tail) as each site onboards. Without this survey, the core driver library cannot be scoped — the whole Year 1 OtOpcUa workstream sits on top of it. See [`../roadmap.md`](../roadmap.md) → OtOpcUa → Year 1.
## Why this inventory exists (and why it's not the legacy-integrations inventory)
Different question, different denominator:
- [`legacy-integrations.md`](legacy-integrations.md) tracks **bespoke IT↔OT integrations that cross the ScadaBridge-central boundary outside ScadaBridge**. Denominator for pillar 3 retirement.
- **This file** tracks **equipment protocols on the OT side** — the native protocols that PLCs, controllers, and instruments actually speak on the shopfloor, which OtOpcUa has to translate into OPC UA. Denominator for the OtOpcUa core driver library scope.
They are unrelated lists. Equipment that already speaks OPC UA natively is **in scope for this survey** (because OtOpcUa still needs to connect to it), even though "OPC UA → OtOpcUa" is not a driver build.
## Companion deliverable: initial UNS hierarchy snapshot
**The discovery walk for this survey is the same walk that produces the initial UNS naming-hierarchy snapshot.** See [`../goal-state.md`](../goal-state.md) → **Target IT/OT Integration → Unified Namespace (UNS) posture → UNS naming hierarchy standard**.
The UNS hierarchy (Enterprise → Site → Area → Line → Equipment, with stable equipment UUIDs) and this protocol survey both require someone to walk System Platform IO config, Ignition OPC UA connections, and ScadaBridge templates across the estate. Running those walks once and producing two artifacts is dramatically cheaper than running them twice.
**Different granularity, same source:**
- **This file** captures data at **equipment-class granularity** — "approximately 40 three-axis CNC mills, Vendor X, Modbus TCP, across Warsaw West and Warsaw North" — because the core driver library scope is a per-protocol decision and individual instance detail would be noise at that level.
- **The UNS hierarchy snapshot** captures data at **equipment-instance granularity** — one entry per physical machine, with site / area / line / equipment-name / stable UUID — because the hierarchy is a per-instance addressing surface.
**Guidance for the walker:** at every step of the Discovery approach below, capture both levels of data in the same pass. Each equipment instance found becomes both (a) an increment to this file's equipment-class count for its protocol, and (b) a row in the initial UNS hierarchy snapshot for the `schemas` repo. Do not split into two discovery efforts.
The initial hierarchy snapshot is not stored in this file (it belongs in the `schemas` repo as part of the UNS canonical definition), but capturing it is a **required output** of the same discovery walk. If the walker produces only protocol-survey data and no hierarchy data, the work has to be redone for the UNS snapshot — unacceptable duplication.
## How to use this file
- **One row per (site, equipment class, protocol) combination.** An equipment class is a grouping of functionally equivalent machines — "3-axis CNC milling machines, Vendor X, 2015–2020 generation" is one class, regardless of how many individual machines fit that description. If the same equipment class appears at multiple sites speaking the same protocol, list all sites in the `Sites` field of a single row. If the same class speaks different protocols at different sites (e.g., older fleet on Modbus, newer fleet on OPC UA), split into separate rows.
- **Rows are discovery-grade.** Exact model numbers, exact counts, and exact firmware revisions are **not** required. The survey only has to be precise enough to scope driver work — "approximately 40 units across 3 sites, Modbus TCP" is enough; a CMDB dump is not.
- **Missing values are fine during discovery** — mark them `_TBD_` rather than leaving blank.
- **Rows are not removed once the driver ships.** A row represents "this protocol exists in the estate," which stays true even after OtOpcUa can speak it. Rows are removed only when the underlying equipment is decommissioned.
## Field schema
| Field | Description |
|---|---|
| `ID` | Short stable identifier (e.g., `EQP-001`). Never reused. |
| `Equipment Class` | Human-readable grouping — machine type + vendor + generation. Precise enough to mean something to a shopfloor engineer, not precise enough to require a part number. |
| `Vendor(s)` | Equipment manufacturer(s) covered by this class. |
| `Native Protocol` | The protocol the equipment actually speaks on the wire. One of: `OPC UA`, `Modbus TCP`, `Modbus RTU`, `EtherNet/IP` (CIP), `Siemens S7` (ISO-on-TCP), `Profinet`, `Profibus`, `DeviceNet`, `MTConnect`, `Fanuc FOCAS`, `Heidenhain DNC`, `Siemens SINUMERIK OPC UA`, `ASCII serial`, `proprietary`, other (name it). |
| `Protocol Variant / Notes` | Sub-variant if relevant (e.g., `Modbus TCP with custom register map`, `EtherNet/IP explicit messaging only`, `S7-300 vs S7-1500`). |
| `Sites` | Sites where equipment in this class is present. `All integrated sites` is acceptable shorthand. |
| `Approx. Instance Count` | Rough order-of-magnitude across all listed sites (e.g., `~40`, `~10–20`, `>100`, `unknown`). A magnitude is enough. |
| `Current Access Path` | How equipment in this class is accessed **today** — direct OPC UA from Aveva System Platform / Ignition / ScadaBridge, via a site-level gateway, via a vendor-specific driver in System Platform, not connected at all, etc. |
| `OtOpcUa Driver Needed?` | One of: `No — already OPC UA` (OtOpcUa connects as an OPC UA client, no driver build), `Yes — core candidate` (protocol is broad enough to warrant a proactive driver), `Yes — long-tail` (protocol is narrow; driver built on-demand when the first site that needs it onboards), `Unknown` (survey incomplete). |
| `Driver Complexity (Estimate)` | `Low` / `Medium` / `High` / `Unknown`. Proxy for how much the driver will cost to build and maintain; influences core-vs-long-tail decision. |
| `Priority Site(s)` | If this driver is on the critical path for onboarding a specific site or cluster, name it. Drives sequencing. |
| `Notes` | Vendor docs availability, known quirks, existing LMX or ScadaBridge work that could be reused, anything else. |
## Classification: core vs long-tail
A protocol becomes a **core library driver** if it meets **any one** of these criteria:
1. **Breadth** — present at **three or more sites**, regardless of instance count.
2. **Volume** — present at **any number of sites** with a combined instance count **above ~25** across the estate.
3. **Blocker** — needed to onboard a site that is on the roadmap for Year 1 or Year 2, regardless of how narrowly the protocol is used elsewhere.
4. **Strategic vendor** — the protocol belongs to a vendor whose equipment is expected to grow in the estate (e.g., the vendor is winning new purchases), even if today's footprint is small. This is a **judgment call**, not a hard rule — use sparingly.
A protocol is **long-tail** by default if none of the above apply. Long-tail drivers are built **on-demand** when the first site that needs the protocol reaches onboarding.
**Protocols already OPC UA** are **neither core nor long-tail** — OtOpcUa speaks OPC UA natively and the work is a connection configuration, not a driver build.
**Tiebreakers:**
- When a protocol narrowly misses a threshold, **err toward long-tail.** Core drivers are a commitment to maintain; long-tail drivers are one-off builds. The cost of building a long-tail driver later is bounded; the cost of committing to maintain a core driver forever is not.
- When a protocol narrowly makes a threshold but is **known to be retiring** from the estate (old generation equipment scheduled for replacement), **err toward long-tail** and make a note about the retirement horizon.
## Current inventory
> **Discovery not started.** Populate as the protocol survey is conducted. The rows below are pre-seeded with **expected categories** based on typical discrete-manufacturing estates — they are **placeholders** to make the shape of the table obvious, not confirmed observations. Remove or merge them as real discovery data arrives. **Nothing in this section is authoritative until it has a non-TBD `Approx. Instance Count` and at least one confirmed `Sites` entry.**
### EQP-001 — OPC UA-native equipment
| Field | Value |
|---|---|
| **ID** | EQP-001 |
| **Equipment Class** | Equipment speaking OPC UA natively (mixed vendors and generations) |
| **Vendor(s)** | _TBD — almost certainly a mix, name the top 3–5 vendors once known_ |
| **Native Protocol** | OPC UA |
| **Protocol Variant / Notes** | _TBD — security modes actually in use (`None` / `Sign` / `SignAndEncrypt`), profiles (`Basic256Sha256`, `Aes256_Sha256_RsaPss`, etc.), auth tokens (anonymous vs UserName vs certificate)_ |
| **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?** | **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 **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)
| Field | Value |
|---|---|
| **ID** | EQP-002 |
| **Equipment Class** | Siemens S7 PLCs (S7-300 / S7-400 / S7-1200 / S7-1500) |
| **Vendor(s)** | Siemens |
| **Native Protocol** | Siemens S7 (ISO-on-TCP); newer S7-1500 also speaks OPC UA natively |
| **Protocol Variant / Notes** | _TBD — mix of S7 generations determines whether the S7 driver is actually needed or whether OPC UA covers most units_ |
| **Sites** | _TBD_ |
| **Approx. Instance Count** | _TBD_ |
| **Current Access Path** | _TBD — likely a mix of System Platform S7 IO drivers and direct OPC UA on newer units_ |
| **OtOpcUa Driver Needed?** | **Unknown.** Depends on whether the S7-1500 OPC UA footprint has displaced older S7 generations. If S7-300/400 still dominate → **core candidate**. If fleet is mostly S7-1500 → `No — already OPC UA` for most units, long-tail for the residual older generations. |
| **Driver Complexity (Estimate)** | Medium — S7 protocol is well-documented; multiple open-source implementations exist; the work is in matching existing System Platform semantics. |
| **Priority Site(s)** | _TBD_ |
| **Notes** | Strong core candidate on first-principles grounds — Siemens is a common PLC vendor in discrete manufacturing. Confirm or refute with a specific count during discovery. |
### EQP-003 — Allen-Bradley / Rockwell PLC family (EtherNet/IP)
| Field | Value |
|---|---|
| **ID** | EQP-003 |
| **Equipment Class** | Allen-Bradley / Rockwell ControlLogix, CompactLogix, MicroLogix, SLC families |
| **Vendor(s)** | Rockwell Automation |
| **Native Protocol** | EtherNet/IP (CIP) |
| **Protocol Variant / Notes** | _TBD — implicit vs explicit messaging, tag-based vs legacy data table access_ |
| **Sites** | _TBD_ |
| **Approx. Instance Count** | _TBD_ |
| **Current Access Path** | _TBD — likely System Platform EtherNet/IP IO driver_ |
| **OtOpcUa Driver Needed?** | **Unknown — likely core candidate.** Rockwell equipment does not generally speak OPC UA natively at the controller level, so if Rockwell has any meaningful footprint in the estate, an EtherNet/IP driver is a core candidate. |
| **Driver Complexity (Estimate)** | Medium-to-high — CIP is a large protocol family; scope depends on which message classes are actually needed. |
| **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 |
|---|---|
| **ID** | EQP-004 |
| **Equipment Class** | Modbus TCP and Modbus RTU devices across instruments, sensors, power meters, older PLCs, variable-frequency drives |
| **Vendor(s)** | Mixed — Modbus is multi-vendor |
| **Native Protocol** | Modbus TCP, Modbus RTU (often bridged to TCP via a gateway) |
| **Protocol Variant / Notes** | _TBD — per-device register map is the real work, not the protocol itself_ |
| **Sites** | _TBD_ |
| **Approx. Instance Count** | _TBD_ |
| **Current Access Path** | _TBD — likely a mix of System Platform Modbus driver and site-level gateways_ |
| **OtOpcUa Driver Needed?** | **Likely core candidate.** Modbus is the most common low-cost protocol in the estate on first-principles grounds. The driver itself is simple; the long-tail is **per-device register maps**. |
| **Driver Complexity (Estimate)** | Low for the protocol; Medium-to-High for the register-map configuration surface (needs to be editable per-device without code changes). |
| **Priority Site(s)** | _TBD_ |
| **Notes** | **Register map configuration is the real work.** The core driver should ship a configuration mechanism (UI or templates) for register-map definition so new Modbus devices don't require code changes. Strong candidate for core library. |
### EQP-005 — Fanuc CNC controllers (FOCAS)
| Field | Value |
|---|---|
| **ID** | EQP-005 |
| **Equipment Class** | Fanuc CNC machine controls |
| **Vendor(s)** | Fanuc |
| **Native Protocol** | Fanuc FOCAS (proprietary library, not a wire protocol) |
| **Protocol Variant / Notes** | FOCAS1 / FOCAS2 library versions |
| **Sites** | _TBD_ |
| **Approx. Instance Count** | _TBD_ |
| **Current Access Path** | _TBD — likely direct or via a vendor-specific driver_ |
| **OtOpcUa Driver Needed?** | **Core candidate if any significant CNC footprint exists.** FOCAS is the de-facto API for Fanuc CNCs and does not come "for free" with OPC UA. |
| **Driver Complexity (Estimate)** | High — FOCAS is a C library with platform-specific bindings and licensing considerations; wrapping it into a .NET driver carries non-trivial ops/licensing work. |
| **Priority Site(s)** | _TBD — Warsaw campuses or TMT likely candidates if they have CNC machining centers_ |
| **Notes** | **Decouple from core library decision until the CNC count is known.** If CNC is a meaningful fraction of the estate, FOCAS is unavoidable. If CNC is a handful of machines, build on-demand as long-tail. A separate alternative — MTConnect — is worth asking about (some modern CNCs expose MTConnect, which is a simpler target). |
### EQP-006 — Other long-tail equipment
| Field | Value |
|---|---|
| **ID** | EQP-006 |
| **Equipment Class** | Everything else — instruments, ovens, vision systems, stand-alone controllers, legacy proprietary devices |
| **Vendor(s)** | Mixed |
| **Native Protocol** | Various — ASCII serial, proprietary, vendor-specific |
| **Protocol Variant / Notes** | _TBD — catalog as encountered_ |
| **Sites** | _TBD_ |
| **Approx. Instance Count** | _TBD_ |
| **Current Access Path** | _TBD — often bespoke per-device integration work in System Platform today_ |
| **OtOpcUa Driver Needed?** | **Long-tail — build on-demand.** This is the category the "on-demand long-tail" driver strategy exists to serve. |
| **Driver Complexity (Estimate)** | Low-to-High per device — varies wildly. |
| **Priority Site(s)** | Wherever the first blocker appears. |
| **Notes** | Track individual long-tail cases as separate rows (EQP-007, EQP-008, …) as discovery identifies them. The placeholder above exists only to anchor the category. |
### _Further rows TBD — add as discovery progresses_
## Rollup views
These views are **derived** from the row-level data above. Regenerate as rows are updated.
### By protocol — drives core library scope
| Native Protocol | Row IDs | Total Approx. Instances | Sites | Core / Long-tail / Already OPC UA |
|---|---|---|---|---|
| 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.
### By site — drives onboarding sequencing
| Site | Row IDs present | Protocols present | Blockers for tier-1 cutover |
|---|---|---|---|
| South Bend DC (primary cluster) | _TBD_ | _TBD_ | _TBD_ |
| Warsaw West | _TBD_ | _TBD_ | _TBD_ |
| Warsaw North | _TBD_ | _TBD_ | _TBD_ |
| Shannon | _TBD_ | _TBD_ | _TBD_ |
| Galway | _TBD_ | _TBD_ | _TBD_ |
| TMT | _TBD_ | _TBD_ | _TBD_ |
| Ponce | _TBD_ | _TBD_ | _TBD_ |
**Decision output of this table:** **tier-1 ScadaBridge cutover sequencing.** The roadmap commits tier 1 at large sites first; this view identifies which sites can cut over with which drivers available, so that sequencing is driven by driver availability, not just site size.
## Discovery approach
Recommended path — not prescriptive. **Each step produces both protocol-survey rows (equipment-class granularity) and UNS hierarchy snapshot rows (equipment-instance granularity) in the same pass** — see "Companion deliverable" above.
1. **Walk the Aveva System Platform IO configuration** at the primary cluster and each site cluster. System Platform's IO server layer is the most complete existing inventory of "what protocols are we talking to what equipment with." Every configured IO object is a row candidate — and its parent galaxy / area / cluster assignment maps directly onto UNS Site and Area levels.
2. **Walk the Ignition OPC UA connections** at the central Ignition footprint in South Bend. These are the equipment Ignition talks to directly today. Every distinct endpoint is a row candidate; Ignition's tag browse tree typically groups endpoints by site and production area, which feeds the UNS hierarchy walk directly.
3. **Walk ScadaBridge template configuration** for equipment-facing templates. Less complete than System Platform IO, but captures anything already templated on ScadaBridge. Template groupings also surface line-level organization where it exists.
4. **Walk any existing site asset registers or CMDBs** if present. Lower priority — often stale, rarely matches reality — but may surface equipment not yet integrated with any SCADA layer, and may be the best source for a stable enterprise equipment ID that can seed the UNS UUID.
5. **Interview site controls/automation engineers** at each large site. They are the ground truth for "what's actually out there" — especially for long-tail equipment that never made it into a central inventory. Interviews are also the best source for **Line-level structure**, which is frequently implicit in operator knowledge and absent from System Platform or Ignition configuration.
6. **Cross-check against Camstar's equipment master data** (if Camstar tracks equipment at that granularity) as a sanity check against what manufacturing operations believes is on the floor — and as a tiebreak when different configuration sources name the same machine differently.
**Order matters.** Steps 1–3 are cheap and produce most of the signal for both outputs. Steps 4–6 are interview-driven and time-consuming; reserve them for gap-filling after the System Platform / Ignition / ScadaBridge walks are done.
**Dual output at each step:** the walker should carry two notebooks (or two sheets of a spreadsheet) and capture entries in both as they go — one equipment instance observed produces one row in each notebook. Reconciliation between the two outputs happens at the end of the walk, not during it. If reconciliation reveals mismatches (a machine shows up in the protocol survey but not the hierarchy, or vice versa), that's a walker error to chase down, not a data difference to split the difference on.
## Open questions for the survey itself
- **Who owns the survey?** The OtOpcUa workstream lead, a dedicated discovery resource, or a rotating responsibility across site automation engineers? _TBD._
- **Deadline.** Year 1 OtOpcUa work cannot scope the core driver library without this survey — it's a **Year 1 prerequisite**. Aim to complete at least steps 1–3 (System Platform / Ignition / ScadaBridge walks) within the first quarter of Year 1 so core driver library build can start by quarter 2. Interview-driven gap-filling can extend through the rest of Year 1 in parallel with core driver build.
- **How often is this file reviewed after Year 1?** Recommended: quarterly during Year 1 (active discovery), annually thereafter (to catch drift from new equipment purchases). Add a row when a new equipment class shows up in the estate; do **not** remove rows when drivers ship.
- **Relationship to Site Onboarding workstream.** When a smaller site (Berlin, Winterthur, Jacksonville, …) is onboarded in Year 2, its equipment should be added to this file as part of the onboarding checklist — that way the core-vs-long-tail decision is re-evaluated as the estate grows.
- **MTConnect.** Modern CNCs often expose MTConnect as an alternative to FOCAS. If MTConnect coverage is broad enough, it may replace FOCAS as the CNC driver choice. Worth an explicit "is MTConnect in play here?" question during discovery.