SimTwin: An Open-Source Reproducible Simulator of Networked FDM/FFF Printer Fleets with Digital-Twin Synchronisation, Fault Injection and Communication Impairment

1. Introduction

§2 positions the work, §4 gives the model and §3 the implementation, §4.8 the reproducibility contract, §6 the seven experiments, and §8–§9 what they mean, and what they do not.

Fused deposition modelling (FDM/FFF) fleets are becoming a networked, instrumented production setting: tens to hundreds of machines report telemetry over MQTT or OPC UA to a supervisory layer that maintains a digital twin of each machine (Grieves and Vickers, 2016; Tao et al., 2019; Barricelli et al., 2019; Fuller et al., 2020). The digital-twin literature is explicit that the value of a twin depends on the fidelity of the model, the freshness of its state, and the fidelity of the observed data (Tao et al., 2017; International Organization for Standardization, 2021,2), and that synchronisation is itself an engineering problem with a cost (Tan and Matta, 2023).

Research on this setting needs an experiment platform in which three things can be varied and measured independently: the physical process, the communication channel, and the twin’s synchronisation state. The tools that exist each cover one axis and assume the others away. Discrete-event factory simulators model queues and stations, not nozzle thermodynamics. Thermal and process models of a single extruder (Faria et al., 2020) model the physics in detail, for one machine, over an ideal channel. Networked-control-system studies model delay, dropout and scheduling (Walsh et al., 2002; Zhang et al., 2001) over an abstract plant. Age-of-information (AoI) work quantifies freshness of a source (Kaul et al., 2012; Yates et al., 2021) but has no process to be fresh about. AM fault-detection datasets are dominated by images and single-machine instrumented runs (Szydlo et al., 2021); predictive-maintenance benchmarks use machine-tool signals without a fleet, a network, or a twin.

This paper contributes SimTwin, a simulator built to close that gap, and the reproducible evidence base that comes with it.

Contributions

1.

A layered architecture with a hard information barrier. Device state, twin-reported state, desired state, configuration and connectivity are separate objects. The twin registry is written only by messages the transport delivered, so twin staleness, synchronisation delay and resynchronisation counts are consequences of the channel model rather than annotations.

2.

Mechanism-level fault injection. Eleven faults across five families are expressed as parameter transformations of the plant and observation models (Table 1). Fault signatures are emergent, which is what makes a separability study meaningful.

3.

Explicit delivery semantics. Latency with a lognormal tail, independent loss, duplication, per-device disconnection with exponential reconnect backoff and replay queues, broker-wide outage, and staleness-based discarding, all applied in the transport, never in the device model.

4.

Determinism by construction. A SeedPlan spawns independent named NumPy streams, so a run is a pure function of its configuration and seed. We verify this by hashing telemetry.

5.

Seven experiments with published artifacts covering scalability, telemetry frequency, network impairment, fault separability, outage/recovery, reproducibility and broker fidelity, plus a dataset package with provenance metadata.

6.

A fully verified bibliography: every journal, volume, issue, page range and DOI in this paper was resolved against the Crossref REST API; five candidate sources that could not be resolved were dropped (Section 8).

SimTwin is deliberately not a high-fidelity FDM physics simulator. It is a cyber-physical / industrial-IoT research testbed: the physics is the simplest lumped model that produces the qualitative behaviour the twin has to track, at a cost that lets a thousand-machine, hour-long scenario run on a laptop in under a minute.

2. Related Work

2.1. Digital Twins in Manufacturing

Grieves’ twin formulation separates the physical asset, its virtual model and the connections between them (Grieves and Vickers, 2016,1). Tao et al. formalise a five-layer architecture and the requirement for bidirectional coupling (Tao et al., 2019,1), and survey twin-driven smart-manufacturing system design (Liu et al., 2023). Standardisation has caught up: ISO 23247 defines a digital-twin framework for manufacturing (International Organization for Standardization, 2021) and ISO/IEC 30173 defines digital-twin representations of physical systems (International Organization for Standardization, 2023). Surveys map the enabling-technology landscape (Barricelli et al., 2019; Fuller et al., 2020), the maturity models used to classify twins (Uhlenkamp et al., 2022), and the methodologies by which twins are built (Aznar Lapuente et al., 2026). Reference architectures for synchronised twin factories are demonstrated in (Cho and Noh, 2024), and simulation-based twins for discrete material-flow systems in (Schwede and Fischer, 2024). The synchronisation problem—how far a twin may diverge from its physical twin, how that divergence is formulated, and what it costs to close the gap — is treated explicitly by Tan and Matta (2023). SimTwin is built to make that divergence measurable: it exposes per-twin age of information, synchronisation-delay percentiles, staleness and offline areas, and resynchronisation counts as first-class outputs.

2.2. AM/FDM Digital Twins and Process Simulation

Twin–AM integration is an active review area (Jyeniskhan et al., 2024). Machine-level twins have been demonstrated for FDM failure detection (Henson et al., 2021), for performance monitoring and anomaly detection in industry (Alhazmi et al., 2024), as a real-time twin ecosystem for AM (Pantelidakis et al., 2022), and as open-source reference implementations (Robles et al., 2023; Infante et al., 2025; Larsen et al., 2024). FIBR3DEmul is the closest physical analogue to SimTwin’s process layer: a multi-axis extrusion-deposition simulator for FDM (Faria et al., 2020). It targets bead geometry and material deposition for one machine; SimTwin targets fleet-level telemetry, connectivity and twin state, and uses a deliberately coarser deposition model (Section 4.3). Energy and resource accounting for AM is well established (Baumers et al., 2017; Wippermann et al., 2020); the SimTwin power model is an additive subsystem model in that tradition, calibrated to the order of magnitude of desktop FDM machines rather than fitted to a specific machine.

2.3. IIoT Transport, MQTT and Networked Control

MQTT (OASIS Standard, 2014,1) and OPC UA (Cavalieri and Cutuli, 2010) dominate IIoT messaging; publish/subscribe protocols for industrial settings are compared by Nast et al. (2022). Broker performance under load has been measured repeatedly (Mishra and Kertesz, 2020; Mishra et al., 2021; Silva et al., 2021), including CoAP/MQTT comparisons (Seoane et al., 2021), security-aware comparisons (Lakshminarayana et al., 2024), and MQTT-specific intrusion datasets (Alatram et al., 2023). MQTT in a twin data pipeline is demonstrated by Human et al. (2021), and the standards landscape for twin-enabled IoT by Jacoby and Usländer (2020). Networked control has a long literature on the control consequences of sampling, delay and dropout (Walsh et al., 2002; Zhang et al., 2001). Age-of-information gives the queueing-theoretic language for freshness (Kaul et al., 2012; Yates et al., 2021). SimTwin adopts the AoI view for the twin side and the dropout/delay view for the channel side, and puts both on top of a plant that produces the data.

2.4. Fault Detection, Anomaly Detection and Simulation Reporting

Model-based fault detection and diagnosis is the classical framework for residual generation from a physical model (Isermann, 2005). Data-driven anomaly detection supplies the statistics used to score fault separability here: local outlier factor (Breunig et al., 2000; Blázquez-García et al., 2021), isolation forests (Liu et al., 2008), one-class SVMs (Schölkopf et al., 2001), and deep approaches on AM process signals (Zamanzadeh Darban et al., 2024). Synthetic data is an established substitute for failure data that fleets do not generate in sufficient quantity (Nieminen et al., 2026); the published faulted-fleet dataset in Section 7 is offered in that spirit. Reporting guidelines for simulation-based research motivate the explicit treatment of seeds, environment capture and artifact publication in Section 7 (Rahmandad and Sterman, 2012).

2.5. Position of SimTwin

No prior open-source tool that we could verify combines (a) a per-device physical plant, (b) a finite-state job and health machine, (c) message-level network impairment with delivery semantics, (d) a twin registry whose state is derived only from delivered messages, and (e) mechanism-level fault injection with a published separability baseline. That combination, not the fidelity of any one layer, is the contribution.

3. System Architecture

The architecture realises the model of §4 as four cooperating parts: a vectorised plant, a twin registry, a transport, and a fault injector.

SimTwin is a Python 3 package (simtwin) organised as nine modules. The fleet engine (fleet/engine.py) is the integrator; everything else is a model it composes.

• config.py — thirteen dataclass configuration groups (experiment, fleet, simulation, thermal, power, material, job, health, network, twin, fault, storage, MQTT) with a validate() pass that rejects physically inconsistent parameter combinations before a run starts.
• printer/thermal.py — three coupled first-order thermal nodes (nozzle, bed, chamber) with PI heater control (Section 4.2).
• printer/process.py — additive subsystem power model, road-geometry deposition model, stochastic job generator (Section 4.3).
• printer/states.py — the device finite-state machine (Section 4.4).
• faults/catalogue.py, faults/injector.py — the fault catalogue and the scheduler that turns it into per-device parameter fields (Section 4.5).
• communication/message.py, communication/transport.py — the message model and the delivery-semantics pipeline (Section 4.6).
• twin/registry.py — the twin registry and synchronisation accounting (Section 4.7).
• storage/writers.py — CSV, JSONL and Parquet writers with environment and configuration provenance.
• metrics/quality.py — resource sampling and the separability statistics (Cohen’s d, Mann–Whitney AUC).
• utilities/seeds.py, utilities/environment.py — deterministic stream spawning and runtime environment capture.

The engine is vectorised: the fleet is a set of NumPy state arrays of length n, and one simulated timestep advances all devices with array operations. This is what makes a 1 000-machine, hour-long scenario a 51-second job (Section 6.1).

4. Model

4.1. Time Base

Time advances in steps of $\Delta t$ seconds (default 1 s). Telemetry is published every $T_{\mathrm{tel}}$ milliseconds (default 1 000 ms), and the transport is stepped every step, so delivery latencies finer than $\Delta t$ are represented by a continuous delivery-time distribution while the device state is sampled at the step grid. Configuration validation enforces $T_{\mathrm{tel}}\ge 1000\Delta t$; experiments that need sub-second telemetry lower $\Delta t$ so that every interval is an integer multiple of the step (Section 6.2).

4.2. Thermal Plant

Each device has three lumped thermal nodes $i\in \{n,b,c\}$ (nozzle, bed, chamber) with capacitance $C_i$ [J/K] and conductance to the ambient sink $G_i$ [W/K]:

$$C_i{\displaystyle \frac{d{T}_i}{dt}}=P_i^{\mathrm{heat}}-G_i(T_i-T_{\mathrm{amb}})+{\kappa }_i{Q}_i^{\mathrm{coup}}-{\Lambda }_i+{\xi }_i\left(t\right),$$

(1)

where $P_i^{\mathrm{heat}}=u_i{P}_i^{max}$ with duty $u_i\in [0,1]$, ${\Lambda }_i$ is a parasitic heat load, ${\kappa }_i$ couples dissipation from the hot nodes into the chamber, and ${\xi }_i\left(t\right)$ is an Ornstein–Uhlenbeck process with correlation time ${\tau }_{\xi }$ and stationary standard deviation ${\sigma }_{\xi }$—coloured, not white, process noise. Heaters are controlled by a saturating proportional–integral law on the measured temperature,

$$u_i\left(t\right)=\mathrm{clip}\left(K_p{e}_i\left(t\right)+{\displaystyle \frac{K_p}{T_i^{\mathrm{int}}}}{\int }_0^t{e}_i\left(s\right)ds,0,1\right),e_i=T_i^{\mathrm{set}}-{\tilde{T}}_i,$$

(2)

where ${\tilde{T}}_i$ is the sensor reading, so sensor bias and sensor noise enter the control loop exactly as they do on a real machine. Discretising (1) with step $\Delta t$ gives the update used by the engine, and (2) is integrated as a running sum per heater. The open-loop time constants at the defaults of Table 2 are ${\tau }_n=C_n/G_n=200$ s, ${\tau }_b=400$ s and ${\tau }_c=1800$ s, and the full-power steady-state rises over ambient are $P_n^{max}/G_n=525$ K, $P_b^{max}/G_b=83$ K and $P_c^{max}/G_c=100$ K, which are the orders that make the setpoints 210/60/45 °C attainable with duty cycles in the interior of $[0,1]$. The chamber heater is disabled by default: an open-frame desktop machine has no chamber heater, and the chamber warms by coupling.

4.3. Process, Power, Material and Jobs

Total electrical draw is an additive subsystem model,

$$P=P^{\mathrm{elec}}+P_n^{\mathrm{heat}}+P_b^{\mathrm{heat}}+P_c^{\mathrm{heat}}+P_{\mathrm{hot}}^{\mathrm{fan}}+P_{\mathrm{part}}^{\mathrm{fan}}+\left(P_0^{\mathrm{mot}}+P_v^{\mathrm{mot}}{\displaystyle \frac{v}{v_{\mathrm{nom}}}}\right)+P^{\mathrm{ext}}+{ϵ}_P,$$

(3)

with $P^{\mathrm{elec}}=8$ W standby, hot-end and part fans, a motion term scaling with normalised speed, and an extruder term; (3) is the quantity accumulated as energy use and compared against the nameplate rating in E4. Deposited volume follows the road geometry, $\dot{V}=whv$ for line width w, layer height h and print speed v; mass follows from filament density, and material use integrates $\dot{V}$ over the print. Jobs are drawn from a generator with duration $\mathcal{U}[1800,21600]$ s, layer count $\mathcal{U}[60,900]$, part volume $\mathcal{U}[5\times {10}^3,2.2\times {10}^5]$ mm³ and speed $\mathcal{U}[40,120]$ mm/s, with 5 % relative jitter on realised duration. Health accumulates wear at ${10}^{-6}$ health-points per operating second, multiplied by the active fault’s wear multiplier; preventive maintenance is scheduled below a health of 0.35 and restores 0.92.

4.4. Device State Machine

Each device runs a finite-state machine over OFFLINE, IDLE, PREHEAT, PRINTING, PAUSED, COOLDOWN, FAILED and MAINTENANCE. Preheat completes when all enabled nodes are within 3K of setpoint for at least 20 s, and aborts as FAILED after 900 s. A terminal fault moves PRINTING → FAILED → MAINTENANCE, with repair time $\mathrm{Exp}(1/1800\mathrm{s})$. The state machine is evaluated on the device side; the twin’s reported_state is a copy that arrives in a message.

4.5. Fault Mechanisms

This is the part of the simulator that E4 (§6.4) exercises directly. Faults are not telemetry labels. Each fault is a set of coefficients applied to the plant and observation models, ramped linearly from nominal to full severity over the fault’s ramp-in and back over its ramp-out, with severity drawn from the fault’s severity range. Table 1 lists the catalogue. Two faults are marked observational: they change only what the twin can observe, not the plant, which is what lets the evaluation distinguish a physical fault from a sensing fault. Faults are scheduled by a Poisson process at a configured rate per machine-hour, with per-family weights, and each injection is logged as an event with device, time, severity and duration.

4.6. Transport and Delivery Semantics

Every publication carries a generation timestamp, a kind (TELEMETRY, HEALTH, ALERTS, STATE, COMMAND, CONFIGURATION, LWT), a QoS level and a device id. The transport pipeline applies, in order:

1.

Connectivity. Per-device disconnection episodes with mean interval ${\lambda }_{\mathrm{dev}}^{-1}$ and mean duration ${\mu }_{\mathrm{dev}}^{-1}$, with exponential reconnect backoff $2^k$ s at the k-th failed attempt; and broker-wide outage episodes.

2.

Latency. $L=max(0,L_0+\mathcal{N}(0,{\sigma }_j))$ plus a lognormal tail component with shape ${\sigma }_{ln}$, so the bulk of the distribution is tight and the tail is heavy.

3.

Loss. Independent per-message Bernoulli loss with probability p (QoS 0 semantics).

4.

Duplication. With probability $p_{\mathrm{dup}}$ a QoS $\ge 1$ message is delivered twice (at-least-once semantics).

5.

Replay. While a device is disconnected, its messages enter a bounded FIFO replay queue (limit ${10}^4$). Messages older than ${\tau }_{\mathrm{age}}=300$ s at delivery are dropped as stale. Delivered replayed messages are flagged replayed.

All of this happens in the transport. The device model never learns that a message was lost, which is the point: a fault in the plant and a fault in the channel are separately attributable.

4.7. Twin Registry and Synchronisation Metrics

Each twin holds the reported state, the desired state, the confirmed configuration, the connectivity state, health, fault code, current job, progress, temperatures, power and material use, and the bookkeeping fields t_last_accepted, updates_accepted and resync_count. The only write path is apply(msg), called on delivery. From this we define, at simulated time t:

$$\begin{array}{cc}\hfill \mathrm{staleness}\left(t\right)& =t-t_{\mathrm{last}\_\mathrm{accepted}},\hfill \end{array}$$

(4)

$$\begin{array}{cc}\hfill \mathrm{status}\left(t\right)& =\left\{\begin{array}{cc}\mathrm{OFFLINE},\hfill & \mathrm{staleness}>{\tau }_{\mathrm{off}}\mathrm{or}\mathrm{last}\mathrm{will},\hfill \\ \mathrm{STALE},\hfill & {\tau }_{\mathrm{stale}}<\mathrm{staleness}\le {\tau }_{\mathrm{off}},\hfill \\ \mathrm{ONLINE},\hfill & \mathrm{otherwise};\hfill \end{array}\right.\hfill \end{array}$$

(5)

$$\begin{array}{cc}\hfill A_{\mathrm{stale}}& ={\int }_0^T{n}_{\mathrm{stale}}\left(t\right)dt,A_{\mathrm{off}}={\int }_0^T{n}_{\mathrm{off}}\left(t\right)dt,\hfill \end{array}$$

(6)

with ${\tau }_{\mathrm{stale}}=10$ s and ${\tau }_{\mathrm{off}}=60$ s by default. Synchronisation delay is $t_{\mathrm{delivered}}-t_{\mathrm{generated}}$ per accepted message, reported as mean and 95th/99th percentiles. Equation (4) defines the staleness whose percentiles are reported throughout §6; (5) defines the three-state classification whose counts give the stale and offline areas of (6), tabulated as twin_stale_area_s and twin_offline_area_s and reported per device so that they are comparable across fleet sizes. A resynchronisation is counted for each replayed telemetry message delivered after a disconnection, i.e. a reconnect recovery. Because the registry is write-only through delivery, all of these are measurements of the channel, not of the model’s self-report.

4.8. Determinism

A run is a pure function of (SimConfig, seed). SeedPlan derives independent numpy.random.Generator streams from a single SeedSequence for the job generator, thermal process noise, sensor noise, power noise, the fault scheduler, fault severities, connectivity, latency, loss, duplication and repair times. Spawning streams (rather than consuming one shared stream) means that adding a new stochastic source does not perturb the draws of the existing ones, which is what makes a scalability sweep and a fault sweep comparable across code changes.

5. Implementation and Artifacts

The package is pure Python with NumPy at the core; pandas, pyarrow, psutil, matplotlib, scipy, scikit-learn and paho-mqtt are used by the experiment, analysis and adapter layers. Storage writers emit CSV, JSONL and Parquet, and every run writes a metadata.json carrying the full resolved configuration, the seed, the fault summary, the artifact manifest, the metrics, and a captured environment record (OS, machine, CPU count, total memory, Python implementation and version, and the pinned versions of every dependency). An optional MQTT adapter (MqttTransport, MqttConfig, paho-mqtt 2.1.0) publishes the same Message objects on the same topics through a real broker, using separate publisher and subscriber clients so that messages genuinely leave the process and return, and registering a retained MQTT Last Will on the lwt topic so the registry learns of ungraceful disconnects without polling. The adapter is selected by a single configuration flag (mqtt.enabled); the fleet engine never branches on the transport type, and the adapter reports the same counter names as the in-process transport, so every metric and table works over either. Because the simulated clock runs hundreds of times faster than the wall clock, an asynchronous transport always has a backlog at the end of a run; the transport interface therefore includes an explicit flush that drains it at the final simulated time, so the tail of a run is attributed to latency rather than to loss. E7 (Section 6.7) exercises this adapter against Mosquitto 2.1.2. The unit-test suite contains 41 tests covering the thermal plant, the state machine, the fault injector, the transport, the MQTT adapter, the twin registry, determinism, storage round-trips and the metrics; the four MQTT tests skip themselves when no broker is listening.

6. Evaluation

Seven experiments, each stated as a question with a falsifiable expectation: §6.1 and §6.2 establish that the simulator is a credible instrument; §6.3 through §6.6 are the studies the instrument exists to make cheap; §6.7 checks the instrument against the real protocol. All experiments ran on a single Apple M3 Pro laptop (11 logical CPUs, 18 GiB RAM, Darwin 25.6.0, arm64), CPython 3.13.0, NumPy 2.5.3. No experiment uses more than one process. Table 2 gives the baseline parameters.

6.1. E1 — Scalability

Fleet size $n\in \{1,10,50,100,250,500,1000\}$, duration 3 600 s, $\Delta t=1$ s, no faults, no impairment. Table 3 and Figure 1.

Throughput peaks at $\approx 1.0\times {10}^5$ device-steps s⁻¹ around $n=100$ and falls to $8.86\times {10}^4$ at $n=1000$; the real-time factor (simulated seconds per wall-clock second) is 8 691 at $n=1$ and 88.6 at $n=1000$. The transition from a regime dominated by per-step fixed cost to one dominated by per-device array work is the expected signature of a vectorised engine, with the throughput decline beyond $n=100$ consistent with cache and memory pressure: peak resident set grows from 101 MB at $n=1$ to 3 289 MB at $n=1000$, i.e. $\approx 3.3$ MB per device, on a machine with 18 GiB. Delivery ratio is flat at 99.97 % across the sweep, confirming that the transport is not the scalability bottleneck at these sizes; the residual 0.03 % is the initial step, before any telemetry has been generated.

6.2. E2 — Telemetry Frequency

$n=100$, duration 1 800 s, $\Delta t=0.05$ s (chosen so that every interval in the sweep is an integer multiple of the step), $T_{\mathrm{tel}}\in \{250$, 500, 1000, 5000, 10000, 30000, $60000\}$ ms. Table 4 and Figure 2.

Delivered throughput spans 686 to 70 363 msg s⁻¹, a factor of 102.5 across a 240-fold range of sampling periods; the shortfall from the ideal $1/T_{\mathrm{tel}}$ scaling at the finest settings is the 0.03 % initial-step loss plus queueing at the sink. Wall-clock time grows only from 4.37 s to 10.23 s over the same 240-fold range, i.e. a factor of 2.3: message generation and delivery is not the dominant cost of the simulation, the per-step plant update is. Peak RSS, by contrast, scales with the number of stored messages (703 MB at 60 s to 1 144 MB at 250 ms), which is the practical constraint on high-rate telemetry in long runs, and the reason the writers stream to Parquet.

6.3. E3 — Network Impairment

$n=200$, duration 3 600 s. Sweep 1 varies loss $p\in \{0,0.01,0.05,0.10,0.20,0.30\}$. Sweep 2 varies the mean interval between per-device disconnection episodes, ${\lambda }_{\mathrm{dev}}^{-1}\in \{\infty ,1800,900,300,120\}$ s with mean episode duration 60 s. Table 5 and Figure 3.

Loss. Delivery ratio tracks the ideal $1-p$ to within 0.05 percentage points at every setting, which is the correctness check for the loss model: 99.97 % at $p=0$ down to 70.05 % at $p=0.30$. Mean transport latency is flat at 17.1 ms, as expected for independent per-message loss. The informative signal is freshness: 95th-percentile twin staleness grows from 0.99 s at $p=0$ to 6.99 s at $p=0.30$, a slope of $\approx 20$ s per unit loss $\approx T_{\mathrm{tel}}/p$ in the small-loss limit—each lost telemetry sample pushes the twin’s age of information out by one sampling period, which is the AoI result for a lossy periodic source (Kaul et al., 2012) reproduced by construction. The binary stale/offline counters stay at zero because the configured ${\tau }_{\mathrm{stale}}=10$ s is not crossed by loss alone at these rates; Section 6.5 shows the regime where they are.

Outages. Delivery ratio barely moves (99.97 % → 99.33 %) because replay recovers the buffered messages, while the twin-side cost explodes: mean synchronisation delay rises from 17 ms to 28 471 ms, offline area from 200 to 152 798 device·s, and resynchronisations from 0 to 324 942. This is the central twin-synchronisation finding of the paper: delivery and freshness are different quantities, and a replay mechanism protects the first while doing nothing for the second. A supervisory application that reads the twin and sees “99.3 % of messages arrived” would conclude the link is healthy; an application that reads twin staleness sees a fleet that is on average 179 s out of date.

6.4. E4 — Fault Injection and Separability

$n=60$, duration 14 400 s (4 h), Poisson fault scheduling at 6 faults per machine-hour over the full catalogue, against a fault-free baseline at a different seed. 1 462 faults were injected across 11 types. For each fault type we compare telemetry samples recorded while the device was PRINTING with that fault active, against the fault-free PRINTING baseline, on seven channels: nozzle, bed and chamber temperature, power, print speed, cumulative material use, and health. We report Cohen’s d per channel and the Mann–Whitney AUC. Table 6 and Figure 4.

Every fault family separates from healthy printing on at least one channel with $\left|d\right|\ge 1.45$, which is “large” by Cohen’s conventions, and the separating channel is the mechanistically correct one. Bed-heater failure separates on power ($\left|d\right|=3.68$) because the controller saturates duty against a heater that no longer delivers heat. Motor overheating ($\left|d\right|=1.80$) and power anomaly ($\left|d\right|=1.65$) separate on power; nozzle-heater failure separates on nozzle temperature ($d=-1.5$) with a compensating power rise; abnormal cooling separates on nozzle temperature ($d=-1.4$). The observational faults separate on health rather than on temperature mean, which is the signature of a sensing fault: the plant is untouched, so bed and chamber means barely move ($\left|d\right|\le 0.23$) while the wear accumulator, driven by fault severity, moves the health channel ($\left|d\right|=1.85$ for sensor noise, $\left|d\right|=1.52$ for sensor drift).

The mean AUC across all seven channels sits at 0.42–0.50, i.e. near chance. That is not a failure of the model; it is the expected consequence of averaging a rank statistic over channels that a given fault does not touch, and it is the reason we report per-channel effect sizes. A detector that pools all channels will find nothing; a detector that looks at the mechanistically relevant channel finds a large, consistent separation. We read this as a concrete argument for mechanism-grounded feature selection in AM fault detection, and for publishing per-channel effect sizes rather than pooled scores.

6.5. E5 — Outage and Recovery

$n=50$, duration 3 600 s, per-device disconnection episodes with mean interval 300 s and mean duration 60 s, with exponential reconnect backoff and replay queues. 235 disconnection and 218 reconnection events were recorded, producing 45 131 resynchronisations and 40 414 device·s of offline area. Median (over fleet samples) worst-twin staleness was 234 s with a maximum of 302 s, and mean synchronisation delay 27 982 ms with a maximum of 299 014 ms—the latter is the replay-queue age limit interacting with the backoff. Delivery ratio was 98.84 %.

The recovery behaviour is the interesting part. Because a reconnecting device sends a retained full-state snapshot before resuming telemetry, the twin converges to the device within one accepted message after each reconnection: the offline area is finite and the staleness distribution has a ceiling set by the episode duration plus backoff, not by the number of episodes. Without the snapshot, replay of a ${10}^4$-message queue at 1 Hz would take longer than the run. This is the twin-side analogue of the last-will-and-testament plus retained-message pattern in MQTT 5 (OASIS Standard, 2019), and it is measurable here because the registry distinguishes delivered from generated. Table 7 gives the episode counts and the twin-side aggregates.

6.6. E6 — Reproducibility

Two runs at seed 2027 and one run at seed 2028, identical in every other respect. The two seed-2027 runs produce telemetry with identical SHA-256 digests (9e797bd1…965455); the seed-2028 run produces a different digest (995f11e1…b9a4cbd). Table 8. This is a strong form of reproducibility: bit-level identity of the artifact, not agreement of summary statistics to within a tolerance.

6.7. E7 — Broker Fidelity

Everything reported so far is produced by the in-process transport, so a natural question is whether that transport is an abstraction over a real one or a simulation of one. E7 answers this by running the same 20-device fleet, the same topic scheme, the same Message objects and the same QoS settings through a real Mosquitto 2.1.2 broker on loopback, using the adapter of Section 5. Table 9.

Three things are worth reading off the table. First, QoS 1 keeps the twin fresh and QoS 0 does not: at QoS 1 the mean observed delivery latency is 3.8 ms and twin staleness stays close to its telemetry-period floor at 1.2 s, while at QoS 0 the mean latency is 51,594 ms and p95 staleness rises to 15.1 s, a 12.6-fold degradation. The mechanism is back-pressure: QoS 1 blocks the publisher on PUBACK, which throttles the producer to the broker’s service rate, whereas QoS 0 is fire-and-forget, so a producer running hundreds of times faster than real time fills the client outbox and the twin observes a queue it cannot drain. This is the same phenomenon that E3 isolates parametrically, reproduced on real infrastructure.

Second, the broker path is lossless at both QoS levels, including at a configured loss of 0.30, because the underlying transport is TCP: the configured loss is an additive impairment the in-process model applies, not a property of the broker. The two transports therefore answer different questions — the in-process transport answers “what does a given impairment budget do to twin freshness?” and the broker transport answers “what does this broker actually do?” E3 and E7 should be read together, not averaged.

Third, the broker path is slower but not prohibitive: the QoS 1 broker run sustains an RTF of 156 against 445 for the in-process transport, i.e. a real broker round trip costs roughly two thirds of the headroom at this fleet size. Running a 1000-device study over a broker is feasible; running the full E1 sweep over a broker is not, which is why the scalability results use the in-process transport.

7. Dataset Package and Reproducibility

Each run directory contains telemetry.csv, telemetry.parquet, events.csv, twins.parquet (where written) and metadata.json. The metadata records the resolved configuration, the seed, the fault summary, the artifact manifest with per-file row counts, the run metrics, and the captured environment: OS release, machine and processor, logical CPU count, total memory, Python implementation and version, and the pinned versions of all ten dependencies (NumPy 2.5.3, pandas 3.0.6, pyarrow 25.0.1, psutil 7.2.2, matplotlib 3.11.2, scipy 1.18.1, scikit-learn 1.9.1, PyYAML 6.0.3, paho-mqtt 2.1.0, pytest 9.1.1). Per-experiment summary.csv files aggregate the sweeps, and results/bibliography_verification.{json,csv} records the Crossref resolution of every bibliography entry.

Reporting guidelines for simulation-based research (Rahmandad and Sterman, 2012) motivate three specific choices: an explicit warmup window excluded from analysis (60 s), a single seed per sweep point with the seed recorded in every summary row, and publication of the generating code alongside the data, so that a reader can regenerate any figure from the repository root with experiments/run_all.py followed by experiments/make_figures.py.

8. Threats to Validity and Limitations

Model fidelity. The thermal plant is a three-node lumped model with constant coefficients. It reproduces the qualitative behaviour a twin must track—setpoint tracking, first-order rise, saturating duty, the effect of a parasitic heat load—and it is calibrated to the order of magnitude of desktop FDM hardware, not fitted to any specific machine. It does not model melt-pool dynamics, layer-to-layer heat accumulation with temperature-dependent conductivity, convection that varies with part geometry, filament moisture, or crystallinity. Claims about bead geometry, residual stress, warping, or part strength are out of scope, and SimTwin should not be used for them. The deposition model is a road-geometry volume integral; it has no path planner.

Network fidelity. The transport models delivery semantics (latency, jitter, loss, duplication, disconnection, outage, replay, staleness) as independent stochastic mechanisms. It does not model bandwidth, contention, TCP congestion windows, TLS handshake cost, broker CPU, queueing at the broker, or the network stack of a real device. The reported msg/s figures are therefore the simulator’s own generation and delivery cost, not a broker’s capacity; broker capacity is measured against real brokers elsewhere (Mishra et al., 2021; Silva et al., 2021). The MQTT adapter lets a user replace the in-process bus with a real broker, and E7 exercises it, but only at $n=20$: a broker round trip costs roughly two thirds of the simulator’s headroom (RTF 150 against 449), so the 1 000-device sweep in E1 could not be run over a broker in reasonable time. The scalability and fault results are therefore properties of the in-process transport, and E7 is the only result measured against real infrastructure.

Fault realism. Faults are parameter mechanisms with severity ranges drawn from engineering judgement, not from failure-mode data fitted to a fleet. The separability result shows that the injected mechanisms produce signatures that are large and mechanistically coherent; it does not show that real FDM faults have those magnitudes. The 11-fault catalogue is a starting point, not a taxonomy of FDM failure. One catalogue fault (print_interruption) is terminal and short-lived, so it produced fewer than 30 qualifying PRINTING samples and is absent from Table 6; its effect is on job outcomes, not on telemetry distributions.

Statistics. Each sweep point is a single seeded run, not a set of replicates, so the sweeps carry no confidence intervals. The determinism result (E6) makes this a deliberate, reproducible choice rather than an accident, and the separability statistics in E4 are computed over $4.4\times {10}^4$–$6.9\times {10}^4$ samples per fault, which is ample for the rank-based statistics used. Effect sizes, not hypothesis tests, are the reported quantity.

Timing variance. The simulated physics is exactly reproducible; the wall-clock columns are not. They are single measurements on a general purpose laptop, and re-running the same configuration on the same machine moves them by ten to twenty per cent with background load — the $n=1000$ E1 point has been observed at both 70 611 and 88 643 device-steps s⁻¹, and the E7 QoS 0 staleness figure at both 13.2 s and 15.1 s, on identical configurations and seeds. The reported figures are from the final full-suite run, whose generating code, configuration and seeds are all published. Scalability trends — the peak near $n=100$, the linear RSS growth, the monotone staleness response — are stable across runs; the absolute constants are indicative, not certified, and any comparison against them should be made on the same hardware under comparable load.

Scope of the evidence. The largest fleet is 1 000 devices for one simulated hour. We do not claim behaviour at ${10}^5$ devices, over multi-day horizons, or under the memory pressure that a long high-rate telemetry run on a smaller machine would produce.

Bibliography. Every entry in this paper was resolved against the Crossref REST API. Five candidate sources—a networked-control survey, a predictive-maintenance dataset paper, and three AM-energy papers—could not be resolved to the works described at any DOI we could verify, and were dropped rather than cited with an unverifiable identifier. Several further entries had a resolvable DOI but a year, first author or journal attribution that Crossref contradicted, and were corrected to the resolved record (Grieves and Vickers, 2016; Liu et al., 2023; Baumers et al., 2017). The machine-readable audit is published with the artifacts.

9. Conclusions

The three findings of §6—that delivery and freshness diverge, that fault signal is per-channel, and that determinism is a property of the composition rather than of any one module—are the reason this simulator is worth building on.

We presented SimTwin, an open-source, deterministic, mechanism-level simulator of networked FDM/FFF fleets that couples a physical plant, a job and health state machine, a message-level transport with explicit delivery semantics, and a twin registry whose state is derived only from delivered messages. The evaluation establishes that the tool runs at useful scale on commodity hardware, that its channel model reproduces the analytic loss and age-of-information behaviour it is meant to represent, that delivery and freshness are measurably different quantities under outage, and that injected fault mechanisms produce large, mechanistically coherent, per-channel separability from healthy operation. The artifact—source, tests, experiment scripts, per-run metadata, summary tables, figures and a Crossref-verified bibliography—is published as a package, and every figure in this paper can be regenerated from the repository root by two commands.

Future work follows directly from the limitations: fitting the thermal and fault parameters against instrumented machines; coupling the transport to a real broker and measuring the delta; adding replicates and reporting confidence intervals; extending the fault catalogue from failure-mode data; and using the twin synchronisation metrics as an explicit objective in a scheduling or edge-offloading study.