A 2020 World Economic Forum survey found that 72% of the world's manufacturers consider improved data sharing with suppliers necessary to lift operational performance [S5], a figure that frames the engineering challenge rather than the answer to it.
Capacity data exchange between plants in a collaborative network typically runs on three layered mechanisms: an IoT layer that pulls machine-level status, a multi-agent translation layer that turns that status into a shared resource pool, and a collaboration-hub layer that normalizes the data across heterogeneous enterprise IT systems [S1][S3][S5]. Each layer has a different latency, a different data model, and a different security boundary, which is why most pilots stall at layer two.
Layer 1: IoT data collection from shop-floor assets
The C2NET project, an EU H2020 Factory of the Future effort (H2020-FoF-2014, grant 636909) that ran from 2015-01 to 2017-12, defined a Data Collection Framework for continuous IoT-based data capture from supply network resources [S3]. The framework's job is narrow: poll machine controllers, PLCs, and MES endpoints at cycle-time intervals, then push the readings into a cloud data module without semantic translation.
In heavy-equipment plants, the same component may be purchased in Brazil and manufactured in-house in the United States, which means the capacity signal for a single part number has to reconcile two different data origins before it is comparable across the network [S2]. Engineers handling this in practice rely on data loggers at the cell level to timestamp machine availability, OEE, and queue depth, then forward those time-stamped payloads to a shared buffer.
Layer 2: Multi-agent translation of machine status into shared resources
Multiagent systems (MAS) sit above the IoT layer and solve a different problem: how do you let a planner in Plant A search for available capacity in Plant B without exposing raw machine telemetry? The MAS literature treats each plant as an agent that advertises resources (machine hours, labor shifts, tooling slots) and responds to negotiation calls from peer agents [S1].
A 2022 system-dynamics study by Zhu, using Baosteel as a micro case and the wider manufacturing industry as the macro case, modeled this exchange and concluded that resource sharing directly improves network collaborative manufacturing efficiency, producing a virtuous cycle that strengthens inter-firm trust over time [S1]. In practice, MAS-based exchanges usually expose only abstracted capacity (e.g. "8 hours of 5-axis CNC on 2026-10-04") rather than the underlying G-code or job list, which keeps IP exposure bounded [S1][S5].
Layer 3: The collaboration hub and data normalization
The third layer is a collaboration hub, a vendor-neutral data repository that integrates internal systems of different departments (production, purchasing, engineering, quality/compliance) plus the systems of external partners into a single coherent view [S5]. Eurostep's 2021 commentary describes the hub as the layer that removes format incompatibility, removes the need for costly reciprocal software licenses, and limits IP exposure because only data flagged for sharing is copied into the hub repository [S5].
The C2NET collaboration tools, layered on top of the C2NET Cloud Platform, deliver this normalized view to plant managers, planners, carriers, and shop floor workers on PCs, tablets, and smartphones, with the explicit goal of real-time visibility across the full supply chain [S3]. For plants using flow meters and other process instrumentation, the hub is also where non-MES signals (utilities, consumables) get stitched into the same capacity model that the MAS layer advertises.
What the data model has to carry
Capacity data in a collaborative network is not a single number. CIMdata's commentary on heavy-equipment manufacturers lists the minimum fields a shared capacity record has to carry: product mix, plant of origin, build-process variant, dependency flags between options (e.g. "size-X bucket requires different attach points and hydraulics"), and as-built status for downstream service [S2].
A practical comparison of the three layers against decision criteria:
Layer 1 (IoT): low latency (sub-second to seconds), raw data fidelity, but no semantic meaning; best for cycle-time optimization inside one plant; weak for cross-plant negotiation.
Layer 2 (MAS): medium latency (minutes), abstracted capacity offers, machine-readable negotiation protocols; best for cross-plant capacity swap; weak for humans reading the data directly.
Layer 3 (Hub): higher latency (minutes to hours), normalized, role-specific views, IP-filtered payloads; best for planner-to-planner collaboration and audit trails; weak for real-time control loops.
Plants typically need all three running in parallel; the failure mode that recurs in pilots is treating any one of them as sufficient [S1][S3][S5].
Failure modes that block the data flow
Isolated systems inside each partner company are the single most-cited blocker: production, purchasing, engineering, and quality/compliance often store and work on the same information in different systems, so cross-supply-chain collaboration becomes ineffective and prone to costly errors and IP leaks [S5]. Legacy ERP and strict internal IT regulations compound the problem by making external API exposure slow and expensive [S5].
CIMdata also flags a second failure mode specific to complex product families: planning cannot start after design freeze. Efficient global manufacturing requires planning and scheduling to begin during engineering, not after the design is transferred to manufacturing, because each plant's build-process variant changes the capacity demand for the same SKU [S2]. When that early hand-off does not happen, the shared capacity record in the hub is built on a bill of materials that is already wrong.
What this looks like under standards and sourcing
Capacity data exchange in collaborative networks is not governed by a single standard, but the plumbing underneath it is. ISO/IEC data-exchange formats (STEP AP242 for product data, OPC UA for shop-floor communication) carry the raw payloads that the hub normalizes, while multi-agent capacity negotiation typically rides on service-oriented architectures (SOAP or REST) with role-based access control enforcing the IP boundary [S3][S5].
For manufacturing engineers specifying instrumentation on the plant side, the practical signal is that collaborative robots, pressure transmitters, and additive-manufacturing material tracking systems are increasingly required to expose their status registers through OPC UA so the IoT layer can ingest them without custom drivers [S3]. Where a plant uses legacy industrial valves with only 4-20 mA position feedback, the plant will need a gateway that converts the analog signal into a digital event the hub can subscribe to, otherwise that asset will be invisible to the network layer.
For sourcing decisions, the comparison matters: plants that instrumented to OPC UA from the start, like the C2NET pilot partners, were able to feed capacity data into the cloud optimizer and run collaborative production plans across borders; plants that started from a 4-20 mA base had to fund a parallel integration project on top [S3]. Related capacity-planning decision points for buyers are detailed in AI server ODM assembly capacity 2026: geography, bottlenecks, and sourcing reality, which covers a comparable cross-plant capacity-sharing problem in a different industry.
Two trackable signals for the next planning cycle: (1) the C2NET project deliverables (Data Collection Framework, Optimizer, Collaboration Tools, Cloud Platform) are public on the CORDIS record under DOI 10.3030/636909 and can be benchmarked against current MES-to-cloud stacks, and (2) the World Economic Forum's 72% data-sharing figure from 2020 has not been re-issued in the supplied research material, so any new survey citing a higher or lower number would be a meaningful indicator of whether the gap between intent and execution is closing [S3][S5].