HRC-Architecture: Vendor-Neutral Embedded Control Architecture for Safety-Critical Human--Robot Collaboration (v2.1.0)

Abstract

Validation datasets, figures and analysis code for a vendor-neutral embedded control architecture for safety-critical human–robot collaboration.This deposit accompanies the article Vendor-Neutral Embedded Control Architecture for Safety-Critical Human–Robot Collaboration: Hardware Abstraction, Bounded-Latency Execution and Industrial Protocol Integration Evaluated Against Simulated Vendor Interfaces (Electronics, manuscript electronics-4587969). It contains the datasets behind every figure and table in that article, the configurations and random seeds that produce them, the analysis scripts, and a checker that re-derives the published numbers and fails if any of them has drifted.Data provenance. Seven of the data files (cycles_36M, stage_timings, ablation_cycles, protocol_samples, segments_30, tuning_grid, cbf_dataset_66d), and the timing columns of an eighth (detection_ms, recovery_s and intervention_min of faults_450), are reference reconstruction datasets: synthetic, deterministic (fixed-seed) datasets generated by tools/reconstruct_data.py and tools/reconstruct_faults.py from the summary statistics reported in the article, released so that every published figure, table and test can be regenerated and independently checked. The commissioning, effort, inter-failure, conformance and code-metric files, and the event list (category, time, flags) of the fault file, are recordings from the study.Scope of the evidence — read this firstEvery quantity in this deposit was produced by the deployable software stack executing against simulated robot, sensor and programmable logic controller interfaces: URSim 5.17.0, KUKA Sunrise.OS 1.17 in FRI monitoring mode, ABB RobotStudio 2024.1 virtual controller, Siemens PLCSIM Advanced V5.0, Rockwell Logix Emulate V33 and Mitsubishi GX Simulator3, with cell kinematics from CoppeliaSim 4.6.0 rev18. No physical manipulator, no safety-rated hardware, no industrial network and no human participant was involved at any stage. Timing figures characterise the software on the stated compute hardware and exclude physical actuation, true sensor acquisition and electromagnetic interference on industrial buses. Reliability figures describe the behaviour of the software under an injected fault model and are not extrapolated beyond the 200-hour observation window. No conformity with IEC 61508, ISO 13849, ISO 10218 or ISO/TS 15066 is claimed, and no Safety Integrity Level or Performance Level is implied.Contentscycles_36M.parquet — control-cycle telemetry, 3.6×107 cycles over 200 h at 50 Hz: per-cycle time, per-stage breakdown, sensor-data age, deadline flag, scenario.ablation_cycles.parquet — the architectural ablation: seven arrangements (A0 monolithic, A1 socket IPC, A2a no real-time priority, A2b shared core, A2c no watchdog, A2 all three removed, A3 proposed), each over 30 condition cells (5 human-trajectory seeds × 3 scenarios × 2 background loads), with execution time and release interval recorded separately for every cycle.protocol_samples.parquet — REST, OPC-UA, Modbus TCP and EtherCAT transaction latencies.segments_30.parquet — segment means for seven methods across 30 paired 20-minute segments, the unit of analysis for the statistical comparison, for both the tuned and the untuned baseline parameter sets.tuning_grid.parquet — the baseline tuning sweep: one principal parameter per baseline over five values, evaluated on a 10-segment split held out from the 30 comparison segments.stage_timings.parquet — per-stage timings with the device each stage ran on, from which the 6.2 ms critical path is itemized.conformance_log.csv and code/tests/conformance/ — the clause-by-clause interface checklists derived from the cited vendor documents, the 47 behavioural-equivalence tests that implement them, and their pass/fail logs.cbf_dataset_66d.npz — barrier-network training set, 66-dimensional input, with the unlabelled 100–150 mm gray-zone evaluation split held separately.faults_450.csv (event list logged, timing columns re-derived), interfailure.csv, plc_runs.csv, effort_log.csv, cloc_lizard.json — fault campaign, inter-failure intervals, per-run commissioning times, task-level porting hours, code metrics.figures/ — the thirteen published figures at 600 dpi (PNG) and as vector PDF, with p2_figures.py, which regenerates all of them.code/ — snapshot of the GitHub repository at release 2.1.0, including config/seeds.json, the per-experiment configurations, the analysis pipeline and analysis/check_against_paper.py.schemas/ — JSON Schema for every tabular file. MANIFEST.md lists sizes and checksums.Reproducing the published numberspip install -r code/requirements.txtcp *.parquet cbf_dataset_66d.npz code/data/ # Windows: copy ... code\data\cd code && make all && make checkThe small tabular files are already in code/data/; the copy step adds the large files, which are kept once, at the top level of this deposit. Alternatively, clone the GitHub repository and run make fetch-data.make check recomputes 287 values — among them the itemized 6.2 ms critical path, the block-level deadline-miss bound, the 3.67 h mean PLC commissioning time, the three fault-population counts, 98.50 % availability with its cross-check and its sensitivity, all three MTBF estimates with their exact Poisson intervals, the censored Weibull fit, the 1.070 m protective separation distance, and the ablation's dispersion and jitter columns — and exits non-zero if any disagrees with the article. Four of those checks are negative: they assert that a withdrawn claim stays withdrawn. A checker that only confirms favourable numbers is not a check.What has been withdrawn, and whenThis item has had four versions during the review of the article, and the withdrawals are recorded against the version in which each took effect. The superseded versions remain retrievable under their own version DOIs, so the chronology is auditable rather than silently rewritten.At v1.0.0. The extrapolated MTBF of 847 h is withdrawn: it is not derivable from a 200-hour observation of a population whose observed MTBF is of the order of one hour. The within-window analysis is deposited instead. The claim of “100 % ISO/TS 15066 compliance” is withdrawn and replaced by a clause-level statement of what was assessed in simulation and what was not assessed at all. The item description registered with v1.0.0 and v1.1.0 nevertheless continued to quote the 847 h figure; that description is corrected here.At v2.0.0. Three further claims are withdrawn. The per-cycle deadline-miss bound of 8.3×10-8 is withdrawn, because it treated 3.6×107 dependent cycles as independent trials; the bound is now stated only at the block grain (no miss in 120 cold-started 100-minute blocks, so 3/120 = 2.5×10-2). The claim that the layering improves the latency tail is withdrawn: the monolithic baseline holds the lowest observed maximum of the seven configurations. The cycle-time advantage over distributed MPC and over a single-objective barrier controller is withdrawn: it does not survive giving those baselines a matched tuning budget. See code/CHANGELOG.md.At v2.1.0. A consistency release. One provenance statement is corrected: the 40–45 h bespoke-integration figure was attributed to three integrator quotations, of which no record is available; it is now stated to be the author’s own estimate, for which no documentary record exists, drawn as a single range in Figures 5 and 12 and the graphical abstract, and no conclusion rests on it. No other claim is withdrawn. The reliability design is stated as 120 blocks of 100 minutes (200 h in total), the timing columns of the fault file agree with the per-mode statistics in the article, the empirical Lipschitz lower bound (6.1) and the bootstrap intervals of the tuned-baseline comparison are corrected in the article, and Figures 6, 7 and 10 are redrawn directly from the deposited files by figures/p2_figures.py. See code/CHANGELOG.md.Licence and citationData and figures: CC BY 4.0. Code: MIT. Cite both this deposit and the article; see code/CITATION.cff.What is not includedVendor software development kits and the vendor simulators are not redistributable and must be obtained from the manufacturers under their own licence terms.