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 recent 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 [2603.24703]. 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 [2603.24703], [1804.04531], [2410.02529], [2410.15813], [2405.11836], [2201.07185].
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 [2603.24703]. 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 [2603.24703].
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 [1804.04531]. 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 [2410.02529]. The 2024 Modbus/TCP connector work on oktoflow extends this line of thought to protocol integration without manual programming per device [2410.15813]. 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 [2603.24703].
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 [2603.24703]. At the bottom are either a “Mock Simulator” for offline testing or “Real PLC / RTU” targets for plant deployment [2603.24703].
A central feature of the system is the common response envelope
[
{success, data, error, meta}
]
which normalizes the outer contract for all benchmarked adapters [2603.24703]. 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 [2603.24703]. 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 [2603.24703]. The repository contains ten protocol modules, but only three are benchmarked: Modbus, MQTT/Sparkplug B, and OPC UA [2603.24703].
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 [2410.15813]. The flexible industrial networking architecture centers on an Aggregation Point as an orchestration point for heterogeneous industrial access technologies [1804.04531]. 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 [2410.02529]. 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 [2603.24703]. 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 [2603.24703]. A specific safety mechanism is adapter-level uint16 validation, with the valid range given as
[
0 \text{--} 65535.
]
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 [2603.24703]. 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 [2410.15813].
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 [2603.24703]. 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 [2603.24703]. 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 [2603.24703]. Method invocation exists in the prototype but is excluded from benchmarking because the mock method path is not stable enough for repeatable evaluation [2603.24703]. A protocol-specific liveness probe checks the ServerStatus node and forces reconnection when needed through _ensure_connected() [2603.24703].
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 [1804.04531]. 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 [2305.10151]. 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 [2410.15813]. 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 [2603.24703]. 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 [2603.24703].
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 [2603.24703]. 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 [2603.24703]. 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 [2603.24703].
The evaluation targets adapter behavior rather than end-to-end LLM planning and is explicitly deterministic [2603.24703]. 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 [2603.24703]. 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 [2603.24703].
The normal suite achieved complete success. All 480 task executions succeeded, and all 2820 tool calls matched expected outcomes [2603.24703]. 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 [2603.24703]. 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 [2603.24703].
The fault suite confirmed structured error handling with 100.0% error-handling rate across all 7 fault scenarios and 210 runs [2603.24703]. 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 [2603.24703].
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 [2603.24703]. By contrast, Modbus recovers through pymodbus auto-reconnect, and OPC UA recovers through _ensure_connected() [2603.24703]. The recovery suite then demonstrates same-session recovery after endpoint restart for all three protocols under a 3-second post-restart window [2603.24703].
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 [2410.15813]. The production-infrastructure work emphasizes deployable information security, scalable stream processing, and semantically rich long-term storage across shop floor, edge, and cloud [2305.10151]. 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 [2405.11836]. 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 [2603.24703]. Its explicit safety mechanisms include write guards, bounded input validation, protocol-aware error classification, and protocol-specific recovery handling [2603.24703]. The most concrete example is the Modbus uint16 range rule
[
0 \text{--} 65535,
]
enforced at the adapter layer before forwarding a write [2603.24703].
Current write safety is controlled through environment-driven guards such as MODBUS_WRITES_ENABLED, which can force deterministic write denial [2603.24703]. Fault isolation is handled inside the adapter wrappers, so failures are normalized into structured envelopes rather than crashing the MCP-facing layer [2603.24703]. 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 [2603.24703].
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 [2603.24703].
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 [1804.09442]. 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 [2410.02529]. The production-infrastructure work emphasizes policy-aware data sharing, trusted sensors, blockchain-based trust anchors, and privacy-preserving industrial collaboration [2305.10151]. 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 [2603.24703], [1804.09442], [2410.02529].
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 [1804.04531]. The edge-computing industrial gateway similarly mediates among PLCs, REST interfaces, local storage, and policy enforcement, with ARM TrustZone protecting critical checks [2410.02529]. INDUSTRICONNECT resembles these systems in miniature: its adapters are not mere syntax translators, but protocol-aware boundary components with validation and error semantics [2603.24703].
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 [2410.15813]. 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 [2305.10151]. INDUSTRICONNECT extends this connector logic into the MCP domain: the northbound contract becomes schema-discoverable AI tools instead of conventional application APIs [2603.24703].
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 [1907.01875]. 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 [2405.11836]. The cloud-based situation-aware reconfiguration platform integrates NiFi, Kafka, predictive analytics, optimization, and operator-facing scheduling in a loop from monitoring to reconfiguration [1910.05357]. 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 [2603.24703].
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 [2201.07185]. VirtuWind does something similar for critical infrastructure, using VTNs, path computation, admission control, service function chaining, and inter-domain QoS negotiation [1902.02539]. The production-infrastructure work’s World Wide Lab makes secure inter-site collaboration a first-class requirement [2305.10151]. 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 [2603.24703].
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 [1806.03023]. Industrial DevOps formalizes roles such as Flow Manager, Brick Developer, IT Operator, Domain Expert, and Business Unit Manager [1907.01875]. PLASMA likewise coordinates operators, on-site technicians, and remote experts [2405.11836]. 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 [2603.24703].
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 [2603.24703]. Its latency figures are mock-only and localhost-only, so they cannot be generalized to plant networks [2603.24703]. Only Modbus, MQTT/Sparkplug B, and OPC UA are benchmarked; the remaining protocol modules are scaffold or roadmap context rather than validated claims [2603.24703]. 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 [2603.24703]. The stress suite identifies certain concurrency and recovery boundaries, but does not map the full overload surface [2603.24703].
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 [2603.24703]. The second is deployment realism: validation on real PLCs, brokers, and OPC UA servers remains future work [2603.24703]. The third is AI-facing evaluation: the current benchmark deliberately evaluates adapters rather than model quality across multiple LLM families [2603.24703]. The fourth is operator integration: there is no user study or operator-in-the-loop assessment yet [2603.24703].
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 [2305.10151]. PLASMA remains a concept and project-positioning paper without quantitative field results [2405.11836]. The edge-computing gateway prototype is implemented in OP-TEE-enabled QEMU rather than plant hardware and still awaits active-attack evaluation [2410.02529]. The 5G slicing framework is a blueprint that leaves standardization and deterministic industrial support as open questions [2201.07185]. 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 [2603.24703], [2410.02529], [2410.15813], [1907.01875], [2405.11836].
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 [2603.24703]. 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.