INDUSTRICONNECT: AI-Enabled Industrial Connectivity
- INDUSTRICONNECT is a prototype suite that bridges AI tools with industrial operational technologies via protocol-aware MCP adapters.
- It integrates diverse protocols like Modbus, MQTT/Sparkplug B, and OPC UA, ensuring precise schema discoverability and protocol-specific safety controls.
- The platform supports mock-first workflows and deterministic evaluations to validate structured error handling and recovery across industrial systems.
Searching arXiv for papers on IndustriConnect and closely related industrial connectivity architectures. INDUSTRICONNECT is a prototype suite of Model Context Protocol (MCP) adapters for AI-assisted industrial operations that exposes industrial actions as schema-discoverable tools while preserving protocol-specific connectivity and safety controls (Xavier et al., 25 Mar 2026). In the available literature, the term is also useful as a broader label for industrial interconnection architectures that bridge heterogeneous operational technology and information technology domains through gateways, orchestrators, security layers, and model-driven connectors. Within that broader landscape, INDUSTRICONNECT is most precisely grounded by the MCP-adapter system described in 2026, but it is illuminated by adjacent work on flexible industrial networking, secure edge gateways, protocol adapters, cloud-based service platforms, and multi-domain orchestration (Xavier et al., 25 Mar 2026, Karrenbauer et al., 2018, Gupta, 2024, Nikolajew et al., 2024, Stumpp et al., 2024, Taleb et al., 2022).
1. Definition and architectural position
In its most specific usage, INDUSTRICONNECT denotes a bounded systems prototype that connects AI assistants to industrial operational-technology environments through protocol-aware MCP adapters (Xavier et al., 25 Mar 2026). The motivating problem is that AI assistants can decompose multi-step workflows, but they do not natively speak industrial protocols such as Modbus, MQTT/Sparkplug B, or OPC UA. Industrial systems, by contrast, expose low-level, protocol-specific interaction models such as register maps, broker topics, hierarchical address spaces, vendor SDK calls, and binary frames. INDUSTRICONNECT addresses that interface mismatch by placing an adapter layer between the assistant and plant systems so that industrial actions become discoverable MCP tools while protocol-native connectivity, validation, and safety semantics remain inside the adapters (Xavier et al., 25 Mar 2026).
This places INDUSTRICONNECT within a broader family of industrial connectivity architectures that do not attempt to replace all shop-floor technologies with a single network, but instead introduce a mediating layer between heterogeneous devices, higher-level applications, and external stakeholders. The 2018 “flexible architecture for industrial networking” similarly treats industrial connectivity as a converged architecture combining 5G, non-cellular wireless systems, public and private mobile connectivity, cloud and edge functions, and established wired fieldbus technologies (Karrenbauer et al., 2018). The 2024 edge-computing industrial gateway for interfacing IT and OT pursues the same mediation principle through a secure gateway at the automation-pyramid boundary (Gupta, 2024). The 2024 Modbus/TCP connector work on oktoflow extends this line of thought to protocol integration without manual programming per device (Nikolajew et al., 2024). Taken together, these works suggest that INDUSTRICONNECT is best understood not merely as a tool suite, but as a specific instance of a more general industrial mediation pattern.
A plausible implication is that the distinctive contribution of INDUSTRICONNECT lies in recasting industrial connectivity for AI-tool invocation rather than only for human-operated SCADA, cloud analytics, or conventional middleware. That implication is supported by the MCP-specific framing in the 2026 prototype, but the broader architectural pattern is visible across the adjacent literature (Xavier et al., 25 Mar 2026).
2. Core architecture and protocol adapter model
The core INDUSTRICONNECT architecture is layered. An MCP-compatible assistant or client communicates with an “IndustriConnect Protocol MCP Server” over stdio using JSON-RPC 2.0. Beneath that interface sits an adapter layer built with “FastMCP,” “asyncio,” and “write guards.” Below the adapter layer are protocol modules, including benchmarked adapters for Modbus, MQTT/Sparkplug B, and OPC UA, as well as additional scaffolded protocol modules such as BACnet/IP, DNP3, EtherCAT, EtherNet/IP, PROFIBUS DP/PA, PROFINET, and Siemens S7comm (Xavier et al., 25 Mar 2026). At the bottom are either a “Mock Simulator” for offline testing or “Real PLC / RTU” targets for plant deployment (Xavier et al., 25 Mar 2026).
A central feature of the system is the common response envelope
which normalizes the outer contract for all benchmarked adapters (Xavier et al., 25 Mar 2026). In this structure, success records whether the requested action reached the expected outcome, data contains the protocol-specific payload, error contains a machine-readable failure reason, and meta contains timing, endpoint details, retry counts, and protocol-specific trace context (Xavier et al., 25 Mar 2026). This envelope does not remove protocol specificity; rather, it standardizes how protocol-specific semantics are surfaced to an assistant or benchmark harness.
The prototype uses a common skeleton for each protocol module. An MCP server registers discoverable tools with bounded JSON input schemas; a protocol client wrapper translates tool calls into native protocol operations and encapsulates transport-specific state; the adapter normalizes timings and failures into the shared response envelope; and a mock endpoint exists for each flagship protocol so workflows can be developed and exercised offline (Xavier et al., 25 Mar 2026). The repository contains ten protocol modules, but only three are benchmarked: Modbus, MQTT/Sparkplug B, and OPC UA (Xavier et al., 25 Mar 2026).
This architecture has close analogues in adjacent research. The oktoflow Modbus/TCP work distinguishes between a generic connector type and application-specific connector instances, reusing a protocol implementation while generating application-specific converter logic from models (Nikolajew et al., 2024). The flexible industrial networking architecture centers on an Aggregation Point as an orchestration point for heterogeneous industrial access technologies (Karrenbauer et al., 2018). The edge-computing industrial gateway likewise introduces a secure gateway between controllers and higher-level systems, partitioning functionality between a Rich Execution Environment and a Trusted Execution Environment (Gupta, 2024). These parallels suggest that INDUSTRICONNECT’s protocol adapters are part of a recognizable industrial design vocabulary: stable northbound interfaces, protocol-specific southbound translation, explicit validation, and controlled exposure of plant functions.
3. Supported protocols, tools, and data semantics
Among the benchmarked adapters, INDUSTRICONNECT covers three distinct industrial communication models. Modbus represents flat register-style interaction; MQTT/Sparkplug B represents broker-mediated messaging; OPC UA represents hierarchical information-model access (Xavier et al., 25 Mar 2026). This triad gives the system coverage across device-register communication, publish/subscribe telemetry, and semantically richer industrial object models.
The Modbus adapter contains 20 tools and includes register and coil reads, bulk writes, typed holding-register access, masked register writes, device-information queries, and alias-based access paths (Xavier et al., 25 Mar 2026). A specific safety mechanism is adapter-level uint16 validation, with the valid range given as
If a caller attempts to write 70000, the adapter rejects the write locally with success=false and error class range_overflow rather than forwarding ambiguous or silently truncated data to the protocol stack (Xavier et al., 25 Mar 2026). This emphasis on bounded value validation parallels the Modbus/TCP connector literature, which stresses that legacy protocols remain operationally important but require explicit handling of register offsets, data types, and byte order (Nikolajew et al., 2024).
The MQTT/Sparkplug B adapter contains 15 tools and spans both generic broker operations and Sparkplug-specific flows, including birth, death, data, and command operations (Xavier et al., 25 Mar 2026). The mock broker is implemented with aedes, and Sparkplug payloads use protobuf encoding; the edge-node simulator publishes NBIRTH, DBIRTH, and periodic DDATA messages for two devices with sinusoidally varying metrics (Xavier et al., 25 Mar 2026). This gives the adapter coverage not only of generic topic traffic but of structured industrial telemetry semantics.
The OPC UA adapter contains 7 tools and supports browsing nodes, reading nodes, writing nodes, multi-node access, and connection recovery (Xavier et al., 25 Mar 2026). Method invocation exists in the prototype but is excluded from benchmarking because the mock method path is not stable enough for repeatable evaluation (Xavier et al., 25 Mar 2026). A protocol-specific liveness probe checks the ServerStatus node and forces reconnection when needed through _ensure_connected() (Xavier et al., 25 Mar 2026).
The broader industrial connectivity literature shows why these protocol families matter. The flexible industrial networking architecture explicitly integrates fieldbus systems such as PROFINET, CAN, Modbus, analog I/O, Bluetooth Low Energy, and Ethernet with 5G-oriented aggregation (Karrenbauer et al., 2018). The production-infrastructure work stresses interoperability across REST, HTTP, MQTT, OPC UA, JSON, XML, JSON-LD, RDF, and Turtle, while advocating FAIR sensor services and model-driven interface generation via SOIL (Pennekamp et al., 2023). The oktoflow connector work shows that even a long-lived protocol such as Modbus/TCP can be embedded into a uniform connector abstraction, reducing the need for application-specific programming (Nikolajew et al., 2024). Within this broader landscape, INDUSTRICONNECT’s choice of Modbus, MQTT/Sparkplug B, and OPC UA positions it at an important intersection of brownfield device access, event-driven telemetry, and semantically rich industrial data services.
4. Mock-first workflow and deterministic evaluation
One of the defining characteristics of INDUSTRICONNECT is its mock-first workflow (Xavier et al., 25 Mar 2026). The system is designed so that the same MCP-facing contract is exercised first against local mock endpoints and only later against plant equipment. This permits local development and deterministic regression testing without immediate access to production assets (Xavier et al., 25 Mar 2026).
The mock fidelity is described in detail. The Modbus mock provisions 100 holding registers, 100 input registers, 100 coils, and 100 discrete inputs, and runs a 1 Hz simulation loop in which variables influence one another; heater power affects temperature, and pump state affects pressure and flow (Xavier et al., 25 Mar 2026). The MQTT/Sparkplug B mock consists of an aedes broker and a Sparkplug B edge-node simulator, with NBIRTH, DBIRTH, and periodic DDATA publications for two devices (Xavier et al., 25 Mar 2026). The OPC UA mock exposes a namespace containing 8 read-only sensor variables, 6 read-write actuator variables, system-status variables, and 5 callable methods, updated every second (Xavier et al., 25 Mar 2026).
The evaluation targets adapter behavior rather than end-to-end LLM planning and is explicitly deterministic (Xavier et al., 25 Mar 2026). The benchmark comprises exactly 870 runs, divided into 480 normal runs, 210 fault-injected runs, 120 stress runs, and 60 recovery trials, with 2820 total tool calls across 7 fault scenarios and 12 stress scenarios (Xavier et al., 25 Mar 2026). The normal suite contains 16 tasks repeated 30 times each; the fault suite contains 7 tasks repeated 30 times; the stress suite contains 12 tasks repeated 10 times; and the recovery suite injects one transient outage per flagship protocol stack, repeated 20 times each (Xavier et al., 25 Mar 2026).
The normal suite achieved complete success. All 480 task executions succeeded, and all 2820 tool calls matched expected outcomes (Xavier et al., 25 Mar 2026). Family-level latency statistics show medians and p95 values of 1.4 ms and 3.1 ms for Modbus, 1.7 ms and 2.5 ms for MQTT, 7.3 ms and 105.2 ms for OPC UA, and 6.7 ms and 8.7 ms for cross-protocol tasks (Xavier et al., 25 Mar 2026). The per-task breakdown shows, for example, 1.1 ms median for Modbus ping, 1.7 ms median for standard MQTT control publish, 3.0 ms median for an OPC UA temperature read, and 103.9 ms median for full OPC UA variable enumeration (Xavier et al., 25 Mar 2026).
The fault suite confirmed structured error handling with 100.0% error-handling rate across all 7 fault scenarios and 210 runs (Xavier et al., 25 Mar 2026). Reported fault classes include protocol error, range overflow, invalid input, and illegal address, covering Modbus invalid register access, uint16 overflow writes, empty-topic MQTT publishes, invalid-QoS subscriptions, non-existent OPC UA nodes, wrong-type OPC UA writes, and a cross-protocol sequence with one deliberate bad input (Xavier et al., 25 Mar 2026).
The stress suite identified concurrency boundaries. The most explicit boundary is MQTT mid-operation restart under a 1-second post-restart window, where the scenario reports 0% success because paho’s reconnect delay begins at 1 second and often does not fire in time (Xavier et al., 25 Mar 2026). By contrast, Modbus recovers through pymodbus auto-reconnect, and OPC UA recovers through _ensure_connected() (Xavier et al., 25 Mar 2026). The recovery suite then demonstrates same-session recovery after endpoint restart for all three protocols under a 3-second post-restart window (Xavier et al., 25 Mar 2026).
This deterministic mock-first methodology resonates with several other industrial-connectivity strands. The Modbus/TCP connector study likewise highlights the importance of comparing software-server behavior and real-device behavior, and explicitly warns that a software-based Modbus/TCP server should not be treated as an easy digital twin without extensive experiments (Nikolajew et al., 2024). The production-infrastructure work emphasizes deployable information security, scalable stream processing, and semantically rich long-term storage across shop floor, edge, and cloud (Pennekamp et al., 2023). The PLASMA remote-maintenance concept similarly argues that real industrial service platforms need end-to-end process support and security from the outset, even if implementation remains at concept stage (Stumpp et al., 2024). INDUSTRICONNECT’s contribution is that it operationalizes this caution in a reproducible adapter benchmark.
5. Security, safety controls, and trust boundaries
INDUSTRICONNECT preserves protocol-specific connectivity and safety controls rather than presenting raw industrial endpoints directly to an assistant (Xavier et al., 25 Mar 2026). Its explicit safety mechanisms include write guards, bounded input validation, protocol-aware error classification, and protocol-specific recovery handling (Xavier et al., 25 Mar 2026). The most concrete example is the Modbus uint16 range rule
enforced at the adapter layer before forwarding a write (Xavier et al., 25 Mar 2026).
Current write safety is controlled through environment-driven guards such as MODBUS_WRITES_ENABLED, which can force deterministic write denial (Xavier et al., 25 Mar 2026). Fault isolation is handled inside the adapter wrappers, so failures are normalized into structured envelopes rather than crashing the MCP-facing layer (Xavier et al., 25 Mar 2026). Recovery logic is not delegated to the AI model; it is implemented per protocol, as seen in OPC UA’s _ensure_connected() and the same-session recovery experiments (Xavier et al., 25 Mar 2026).
The paper is explicit, however, that its current security model is limited. Write guards are configuration booleans, not role-based authorization; there is no per-user RBAC, no tamper-evident audit logging, and no production-ready mTLS or equivalent secure transport. For production use, the authors recommend RBAC with per-tool authorization, audit logging for all writes, mTLS or equivalent secure transport, and human-in-the-loop approval for safety-critical writes (Xavier et al., 25 Mar 2026).
This security posture aligns with a wider industrial literature that treats interconnection as inseparable from trust establishment and data sovereignty. The Trusted Connector in the Industrial Data Space provides X.509 identities, TLS, OAuth 2.0 assertion flow with JWT attributes, TPM-backed attestation, Linux-container isolation, LUCON policy enforcement, and sticky policies for data usage control (Schütte et al., 2018). The edge-computing industrial gateway uses ARM TrustZone, an explicit Security Manager in the TEE, role-scoped command validation, encrypted local storage, and threat-profile generation for IT/OT integration (Gupta, 2024). The production-infrastructure work emphasizes policy-aware data sharing, trusted sensors, blockchain-based trust anchors, and privacy-preserving industrial collaboration (Pennekamp et al., 2023). These works indicate that INDUSTRICONNECT currently occupies a narrower point on the security spectrum: it already provides bounded validation and structured safety semantics, but not yet the full identity, authorization, attestation, and sovereignty machinery that cross-company deployment would require.
A plausible implication is that INDUSTRICONNECT could evolve by combining its adapter-centric MCP contract with the kind of edge trust anchor embodied by the Trusted Connector or TrustZone-based gateway. That implication is not claimed in the source description, but it follows naturally from the architectural complementarity between protocol-aware AI adapters and industrial security gateways (Xavier et al., 25 Mar 2026, Schütte et al., 2018, Gupta, 2024).
6. Relation to the wider industrial connectivity landscape
INDUSTRICONNECT belongs to a broader research landscape concerned with how industrial assets, services, users, and applications become interconnected without collapsing under heterogeneity, latency constraints, security risk, or organizational fragmentation. Several major patterns recur across this literature.
One pattern is the edge aggregation and gateway model. The flexible industrial networking architecture centers on an Aggregation Point containing wired and wireless interfaces, an SDN-capable switch, an SDN controller, and radio management; it bridges heterogeneous local networks into a 5G-oriented connectivity fabric (Karrenbauer et al., 2018). The edge-computing industrial gateway similarly mediates among PLCs, REST interfaces, local storage, and policy enforcement, with ARM TrustZone protecting critical checks (Gupta, 2024). INDUSTRICONNECT resembles these systems in miniature: its adapters are not mere syntax translators, but protocol-aware boundary components with validation and error semantics (Xavier et al., 25 Mar 2026).
A second pattern is the model-driven connector pattern. The oktoflow Modbus/TCP work distinguishes reusable protocol connector types from model-derived connector instances, reducing repetitive integration coding while retaining explicit control over offsets, byte order, and field types (Nikolajew et al., 2024). The production-infrastructure paper generalizes this through FAIR sensor services and the SensOr Interfacing Language, which separates functional interface models from transport/encoding details and generates concrete RESTful HTTP or MQTT interfaces automatically (Pennekamp et al., 2023). INDUSTRICONNECT extends this connector logic into the MCP domain: the northbound contract becomes schema-discoverable AI tools instead of conventional application APIs (Xavier et al., 25 Mar 2026).
A third pattern is the workflow-orchestration and continuous-adaptation pattern. Industrial DevOps proposes a continuous process of operation, observation, and development, using the Titan platform’s bricks and flows to integrate machines, sensors, software systems, and data sources incrementally (Hasselbring et al., 2019). PLASMA frames remote maintenance as an end-to-end service orchestration problem involving automated event reporting, ticketing, remote support, documentation, spare-parts ordering, and ERP/CRM integration (Stumpp et al., 2024). The cloud-based situation-aware reconfiguration platform integrates NiFi, Kafka, predictive analytics, optimization, and operator-facing scheduling in a loop from monitoring to reconfiguration (Scholze et al., 2019). INDUSTRICONNECT’s current benchmark is narrower than these full workflow platforms, but its motivating use case—“check a temperature excursion in OPC UA, confirm a related Modbus register block, and publish a Sparkplug B status update”—already points toward multi-step orchestration (Xavier et al., 25 Mar 2026).
A fourth pattern is the federated, multi-domain interconnection model. The 5G slicing framework extends connectivity across multiple factories, public and private domains, and the extreme edge through federated slices, VNFs, VAFs, and orchestration (Taleb et al., 2022). VirtuWind does something similar for critical infrastructure, using VTNs, path computation, admission control, service function chaining, and inter-domain QoS negotiation (Sakic et al., 2019). The production-infrastructure work’s World Wide Lab makes secure inter-site collaboration a first-class requirement (Pennekamp et al., 2023). In contrast, INDUSTRICONNECT’s current evaluation is mock-only and localhost-only, but its architecture does not preclude federated deployment; it simply has not been validated there yet (Xavier et al., 25 Mar 2026).
A fifth pattern is the human and organizational integration layer. The industrial social network treats operators as a knowledge network, routing troubleshooting requests to colleagues with the right expertise, duties, and availability (Villani et al., 2018). Industrial DevOps formalizes roles such as Flow Manager, Brick Developer, IT Operator, Domain Expert, and Business Unit Manager (Hasselbring et al., 2019). PLASMA likewise coordinates operators, on-site technicians, and remote experts (Stumpp et al., 2024). INDUSTRICONNECT does not yet address human role structures directly, but its recommendation for human-in-the-loop approval of safety-critical writes implies that AI-assisted industrial operations remain embedded in human governance (Xavier et al., 25 Mar 2026).
7. Limitations and prospective development
INDUSTRICONNECT is a prototype suite of MCP adapters, not a production industrial middleware platform, a new LLM reasoning method, or a real-hardware deployment study (Xavier et al., 25 Mar 2026). Its latency figures are mock-only and localhost-only, so they cannot be generalized to plant networks (Xavier et al., 25 Mar 2026). Only Modbus, MQTT/Sparkplug B, and OPC UA are benchmarked; the remaining protocol modules are scaffold or roadmap context rather than validated claims (Xavier et al., 25 Mar 2026). OPC UA method invocation exists in the prototype but is excluded from benchmarking because the mock method path is not stable enough for repeatable evaluation (Xavier et al., 25 Mar 2026). The stress suite identifies certain concurrency and recovery boundaries, but does not map the full overload surface (Xavier et al., 25 Mar 2026).
The principal open issues fall into four groups. The first is security maturation: the system lacks RBAC, tamper-evident audit logging, production transport security, and industrial identity management (Xavier et al., 25 Mar 2026). The second is deployment realism: validation on real PLCs, brokers, and OPC UA servers remains future work (Xavier et al., 25 Mar 2026). The third is AI-facing evaluation: the current benchmark deliberately evaluates adapters rather than model quality across multiple LLM families (Xavier et al., 25 Mar 2026). The fourth is operator integration: there is no user study or operator-in-the-loop assessment yet (Xavier et al., 25 Mar 2026).
These limitations mirror broader industrial-connectivity research trajectories. The production-infrastructure work identifies missing generalized in-network computing frameworks, incomplete automation of metadata generation, and the need for stronger technical enforcement of data usage policies (Pennekamp et al., 2023). PLASMA remains a concept and project-positioning paper without quantitative field results (Stumpp et al., 2024). The edge-computing gateway prototype is implemented in OP-TEE-enabled QEMU rather than plant hardware and still awaits active-attack evaluation (Gupta, 2024). The 5G slicing framework is a blueprint that leaves standardization and deterministic industrial support as open questions (Taleb et al., 2022). INDUSTRICONNECT’s limitations are therefore typical of a research-stage industrial connectivity platform, but they also indicate the next engineering thresholds: identity-aware control, real plant integration, and workflow-level evaluation.
A plausible implication is that the most promising development path for INDUSTRICONNECT would be a layered combination of: AI-facing MCP adapters for tool discoverability and structured invocation; trusted edge gateways for IT/OT mediation and policy enforcement; model-driven connectors for legacy protocol coverage; and orchestration layers for multi-step industrial workflows. The available sources do not describe such a unified system directly, but they collectively outline its constituent parts (Xavier et al., 25 Mar 2026, Gupta, 2024, Nikolajew et al., 2024, Hasselbring et al., 2019, Stumpp et al., 2024).
In summary, INDUSTRICONNECT is most precisely defined as an MCP-adapter prototype for AI-assisted industrial operations, exposing industrial actions as schema-discoverable tools over a common response envelope while preserving protocol-specific connectivity and safety controls (Xavier et al., 25 Mar 2026). At the same time, it can be situated within a broader industrial-connectivity lineage that includes flexible edge aggregation, model-driven protocol adapters, secure IT/OT gateways, workflow-centric remote-maintenance platforms, and federated industrial orchestration. Its current evidence base is strongest on deterministic adapter correctness, structured error handling, and same-session recovery in mock environments; its future significance depends on whether those adapter semantics can be combined with stronger trust, authorization, and real-plant deployment mechanisms.
