AI assistants can decompose multi-step workflows, but they do not natively speak industrial protocols such as Modbus, MQTT/Sparkplug B, or OPC UA, so this paper presents INDUSTRICONNECT, a prototype suite of Model Context Protocol (MCP) adapters that expose industrial operations as schema-discoverable AI tools while preserving protocol-specific connectivity and safety controls; the system uses a common response envelope and a mock-first workflow so adapter behavior can be exercised locally before connecting to plant equipment, and a deterministic benchmark covering normal, fault-injected, stress, and recovery scenarios evaluates the flagship adapters, comprising 870 runs (480 normal, 210 fault-injected, 120 stress, 60 recovery trials) and 2820 tool calls across 7 fault scenarios and 12 stress scenarios, where the normal suite achieved full success, the fault suite confirmed structured error handling with adapter-level uint16 range validation, the stress suite identified concurrency boundaries, and same-session recovery after endpoint restart is demonstrated for all three protocols, with results providing evidence spanning adapter correctness, concurrency behavior, and structured error handling for AI-assisted industrial operations.
Figures & tables
Fig. 1: IndustriConnect adapter architecture. An AI assistant issues MCP tool calls through a common JSON-RPC interface. The adapter layer handles protocol translation and safety guards, returning a shared response envelope. Each protocol adapter targets either a local mock (dashed) or real plant equipment.
Field
Role in the adapter contract
success
Reports whether the requested protocol action reached the expected outcome.
data
Carries the protocol-specific payload such as registers, node values, or publish metadata.
error
Preserves a machine-readable failure reason, including guarded denials and transient endpoint failures.
meta
Records wall-clock latency, endpoint details, attempts, and protocol-specific trace context.
TABLE I: Shared response-envelope fields used across the benchmarked adapters.
Protocol
Tools
Mock
Status
Rep. operation
Modbus
17
TCP device
flagship
register/coil I/O
MQTT + SB
15
broker sim.
flagship
pub/sub + DDATA
OPC UA
7
UA server
flagship
browse + node R/W
BACnet/IP
7
BA device
scaffold
object properties
DNP3
8
outstation
scaffold
point poll/control
EtherCAT
14
slave
scaffold
PDO/SDO access
TABLE II: Repository protocol inventory. Tool counts come from registered handlers in the benchmark pass. 2 2 2 Protocols below the mid-rule are not evaluated in this paper.
Fig. 2: Repository protocol landscape with the three evaluated flagship adapters highlighted. This figure is supporting context, not evaluation evidence.
Fig. 3: MCP Manager UI used to register adapters and issue operator-style prompts. This figure is supporting context, not benchmark evidence.
Publish to empty topic (FQ1); subscribe with invalid QoS (FQ2)
TABLE III: Benchmark matrix for the deterministic evaluation.
Family
Mock endpoint
Recovery semantics
Modbus
TCP mock at 127.0.0.1:1502
Same-session via pymodbus auto-reconnect, then fresh session
MQTT/SB
Local broker at 127.0.0.1:1883
Same-session via paho reconnect_delay_set , then fresh session
OPC UA
Local OPC UA endpoint
Same-session via _ensure_connected() liveness probe, then fresh session
TABLE IV: Benchmark runtime configuration used in the paper.
Family
Tasks
Task
Tool
Med.
p95
Rec.
(%)
(%)
(ms)
(ms)
(%)
Modbus
4
100.0
100.0
1.4
3.1
100.0
MQTT
4
100.0
100.0
1.7
2.5
100.0
OPC UA
4
100.0
100.0
7.3
105.2
100.0
Cross-protocol
4
100.0
100.0
6.7
8.7
—
TABLE V: Family-level results from the normal benchmark suite (30 repetitions). Cross-protocol rows aggregate the four multi-adapter tasks.
ID
Family
Operation
Median (ms)
p95 (ms)
M1
Modbus
Ping the adapter and confirm the TCP mock is reachable.
1.1
1.4
M2
Modbus
Read a four-register sensor block from the Modbus mock.
1.5
1.7
M3
Modbus
Write a holding register and read it back for verification.
2.7
3.3
M4
Modbus
Attempt a write with writes disabled and expect a guarded rejection.
1.3
1.6
Q1
MQTT
Inspect broker connectivity through the MCP adapter.
1.8
2.1
Q2
MQTT
Subscribe to the mock sensor topic namespace.
1.7
2.7
TABLE VI: Per-task latency breakdown from the normal benchmark suite (30 repetitions).
Fig. 4: Per-task latency distributions across 30 repetitions. Box plots show median, interquartile range, and outliers.
ID
Family
Fault scenario
EH%
Med. (ms)
Error class
FM1
Modbus
Read invalid register address (9999) and expect a structured protocol error.
100.0
1.3
protocol error
FM2
Modbus
Write overflow value (70000 ¿ uint16 max) and expect adapter rejection.
100.0
1.0
range overflow
FQ1
MQTT
Publish to empty topic string and expect a structured invalid-input error.
100.0
1.6
invalid input
FQ2
MQTT
Subscribe with invalid QoS (5) and expect a structured invalid-input error.
100.0
1.6
invalid input
FO1
OPC UA
Read non-existent node (ns=2;i=99999) and expect a structured read-failed error.
100.0
2.7
illegal address
FO2
OPC UA
Write wrong type (string to float node) and expect a structured write-failed error.
100.0
2.5
protocol error
TABLE VII: Fault-injection task results (30 repetitions). Error-handling rate measures how often the adapter returned a well-formed structured error.
Fig. 5: Error class distribution across the seven fault-injected tasks (30 runs each). Each color represents a distinct error category returned by the adapter.
Fig. 6: Recovery success rates over 60 restart trials per flagship adapter, comparing same-session recovery (adapter reconnects transparently) versus fresh-session recovery (new MCP session).
Fig. 7: Recovery-phase breakdown per flagship adapter.