3yearplan/current-state/equipment-protocol-survey.md

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 → 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 → OtOpcUa → Year 1.

Why this inventory exists (and why it's not the legacy-integrations inventory)

Different question, different denominator:

• 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 → 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 → 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.