CBM-Suite: Integrated Software & Data Ecosystem

• CBM-Suite is an integrated ecosystem comprising simulation, data management, control, and online processing components essential for FAIR's free-streaming CBM experiment.
• It unifies tools like CBMROOT, FairRoot, Rucio, and Docker with distributed architectures to support robust simulation, reconstruction, and detector control.
• The suite facilitates real-time event reconstruction, slow control systems, and electronics QA, as demonstrated in FAIR Phase-0 and mCBM deployments.

CBM-Suite can be understood as the integrated software, data-handling, detector-control, electronics-test, and online-processing ecosystem associated with the Compressed Baryonic Matter experiment at FAIR. The term is not used uniformly as a formal project designation in the literature, but the underlying components recur consistently: CBMROOT with FairRoot and FairSoft for simulation and reconstruction, a free-streaming and self-triggered readout architecture with online reconstruction and selection, EPICS- and IPbus-based control infrastructure, and distributed data-management services built around Rucio, XRootD, GFAL, VOMS, and Dockerized runtime environments (Clerkin et al., 2022, Dong et al., 2020, Teklishyn, 25 Jun 2025).

1. Conceptual scope and internal structure

In the CBM literature, the concept denoted here by CBM-Suite spans several layers that are usually described separately: detector and electronics subsystems, software for simulation and reconstruction, slow-control and safety services, data-distribution mechanisms, and the online computing chain that makes triggerless operation feasible. This suggests that CBM-Suite is best treated as an umbrella term for a coherent end-to-end environment rather than as a single executable package (Clerkin et al., 2022, Senger et al., 2020).

Layer	Representative components	Function
Physics and reconstruction	CBMROOT, FairRoot, FairSoft	simulation, digitisation, reconstruction
Data management	Rucio, XRootD, gfal2, VOMS, ESCAPE datalake	logical namespace, replicas, remote access
Online processing	self-triggered FEE, CRI, FLES, GreenIT Cube	free-streaming readout, time-based reconstruction
Control and QA	EPICS, CSS, PostgreSQL, IPbus, SMX tester	slow control, archiving, electronics verification
Runtime and deployment	Docker images, SLURM, cron jobs	portable execution and simple orchestration

The most explicit software-centered formulation appears in the ESCAPE datalake integration work, where a “CBM software environment” combines CBMROOT, FairRoot, FairSoft, and associated tools and libraries integrated into dockerized environments, including python, gfal, the Rucio client, java, voms-client, and XRootD libraries (Clerkin et al., 2022). A complementary control-oriented branch appears in the CBM-TOF detector control system, which is based on EPICS, CSS, PostgreSQL archiving, and IPbus-linked FPGA slow control (Dong et al., 2020). At the experiment-wide level, the detector and electronics overview places these branches inside a free-streaming architecture whose online backbone is the First-Level Event Selector and whose input stream is generated by self-triggered front-end electronics across all major subsystems (Teklishyn, 25 Jun 2025).

2. Physics program and experimental setting

CBM is a fixed-target heavy-ion experiment at FAIR designed to explore QCD matter at high net-baryon density and moderate temperatures. The literature describes the program both in terms of Au+Au collisions in the kinetic energy range $2$–$11\,A\mathrm{GeV}$ and, for the SIS100 operating regime, in terms of $\sqrt{s_{NN}} = 2.9 - 4.9~\mathrm{GeV}$ (Senger et al., 2020, 2207.14585). The experiment is designed to operate at interaction rates up to $10\,\mathrm{MHz}$, and this rate target is central to the definition of the surrounding software and computing stack (2207.14585, Collaboration, 15 Jun 2026).

The scientific program requires simultaneous support for rare probes that are inaccessible with lower-rate architectures. The 2026 program summary emphasizes multi-strange hadron production and their flow coefficients, high-order net-baryon cumulants, dileptons, and production of double-strange hypernuclei (Collaboration, 15 Jun 2026). Earlier physics reviews frame the same program in terms of the high-density equation of state, possible first-order phase transitions, a critical point, in-medium modification of hadrons, hypernuclei, and charm at the upper end of the energy range (Senger et al., 2020, 2207.14585). This experimental agenda explains why CBM-Suite is inseparable from continuous readout, online event reconstruction, and high-throughput analysis.

The detector layout reinforces that interpretation. The experiment combines the MVD and STS for vertexing and tracking, TOF for charged-hadron identification, RICH and TRD for electrons, MuCh for muons, and the PSD or FSD for event characterization, all within a fixed-target geometry optimized for forward rapidity and high occupancy (Senger et al., 2020, Teklishyn, 25 Jun 2025). In practical terms, CBM-Suite must bridge from detector-specific data formats and calibrations to common reconstructed objects suitable for hyperon, dilepton, flow, fluctuation, and hypernuclear analyses.

3. Core software, data handling, and distributed execution

The software core most directly associated with CBM-Suite is CBMROOT, built on FairSoft and FairRoot. In the datalake integration study, CBMROOT is used for full CBM electron setup transport, digitisation, and mCBM reconstruction macros, while Docker images provide a portable runtime that can run on MacBooks outside the GSI network, on a Gentoo desktop inside GSI, or on any Linux host with Docker (Clerkin et al., 2022). This establishes a reproducible execution layer in which the physics software stack and the data-access stack are bundled together.

The data-management model is centered on the ESCAPE datalake, a federated, Rucio-managed storage infrastructure spanning sites such as FAIR and CERN. In this model, logical data management is handled by Rucio through Data Identifiers, datasets, replica metadata, and replication rules, while physical storage resides on site-local systems such as Lustre at GSI/FAIR (Clerkin et al., 2022). The paper demonstrates that CBM workflows treat the datalake as a global logical store for URQMD input, transport output, geometry, parameters, digitized data, raw mCBM files, and reconstructed products.

Three workflow classes are exercised. First, simulated SIS100-like data are processed through demo1.sh, demo2.sh, and demo3.sh, covering URQMD upload and verification, CBMROOT transport, and CBMROOT digitization with datalake upload of dac21.par.root, dac21.tra.root, dac21.geo.root, and dac21.raw.root (Clerkin et al., 2022). Second, real mCBM data are ingested at SIS18 by replaying raw files from the mFLES cluster to Lustre and then registering those existing Lustre files in Rucio as replicas, explicitly as a zero-copy procedure. Third, demo6.sh implements an mCBM reconstruction loop of “pull data → run CBMROOT macro → upload result” (Clerkin et al., 2022).

The operational metrics are sufficiently detailed to make the architecture concrete. The replay chain used 10 parallel rsync jobs from mFLES to Virgo at 150–200 MB/s per process, for an aggregate of $\sim 2~\mathrm{GB/s}$, chosen to mimic the high mCBM data taking rate. Typical raw files were $4~\mathrm{GB}$, and registering a replica and a corresponding replication rule took 30–60 s per 4-GB file after subtracting the forced delay (Clerkin et al., 2022). In 100 repeated runs of demo6.sh, input retrieval via rucio get succeeded in all cases, whereas 75 output uploads failed because of misconfigured davs:// support in the container rather than a datalake-side fault (Clerkin et al., 2022). The paper identifies client-side Adler32 computation as a major bottleneck and argues for support of faster and stronger hashes and reuse of filesystem-level checksums.

4. Online computing, control systems, and electronics QA

The online branch of CBM-Suite is defined by self-triggered front-end electronics, time-stamped streaming data, and a software event-building chain. One program description gives a minimum-bias Au+Au event size of $\approx 50~\mathrm{kB}$, an interaction rate up to $10\,\mathrm{MHz}$, and a raw data stream of $\approx 500~\mathrm{GB/s}$, while the detector-and-electronics overview reports tests and design studies up to $\sim 1~\mathrm{TB/s}$ total input bandwidth (Collaboration, 15 Jun 2026, Teklishyn, 25 Jun 2025). These figures differ because they refer to different system-level estimates and deployment contexts, but both document the same requirement: CBM-Suite must process time slices rather than pre-triggered events.

The data path is organized around detector-specific self-triggered electronics, Common Readout Interface boards, FLES entry nodes, and the GreenIT Cube. A representative description states that CRI boards terminate detector GBT links, package data into microslices, and DMA them to server RAM; FLES entry nodes build larger time slices; and the compute farm performs full reconstruction and software triggering (Collaboration, 15 Jun 2026). Earlier status reports describe the same principle as a triggerless DAQ in which the full data stream is transported to a computing farm, where collision events are reconstructed and selected in software in real time (Senger, 2020). This is the computational center of gravity of CBM-Suite.

A second operational branch is slow control. The CBM-TOF detector control system is based on EPICS, with IOCs, CSS operator interfaces, the CSS Archive System, PostgreSQL storage, and the EPICS Sequencer for safety and exception handling (Dong et al., 2020). In the mCBM deployment it comprised 2635 PV channels, archived at a sampling period of 1 second, producing approximately 200 MB/day (Dong et al., 2020). The controlled devices include the CAEN SY1527LC high-voltage system, the MeanWell low-voltage system, gas-control components with Bronkhorst mass flow controllers, and front-end electronics and environment sensors accessed through IPbus and GBT-SCA paths (Dong et al., 2020). This branch of CBM-Suite is therefore not limited to reconstruction software; it also includes detector state, safety logic, and conditions provenance.

Electronics QA forms a third branch. The SMX and front-end board tester is based on an Artix-7 GBTxEMU platform, uses IPbus for control, supports full functional testing of connected SMX, front-end board, or full detector module, and can operate as a CROB emulator in GBTX-emulation mode (Zabołotny et al., 2021). The same paper highlights the projected scale of production and qualification—approximately 40,000 ASICs and about 2600 FEBs—and notes that the Python software may easily be integrated with higher-level testing software (Zabołotny et al., 2021). This suggests that electronics production tooling is part of the same ecosystem, because configuration, QA, and deployment are aligned with the final DAQ chain.

5. Operational demonstrations and FAIR Phase-0 validation

The most mature demonstrations of CBM-Suite are the FAIR Phase-0 deployments and mCBM system tests. The TOF Phase-0 program used mTOF at mCBM/SIS18 and eTOF at STAR/RHIC to exercise final-detector technologies in real beam conditions. At STAR, eTOF comprised 36 modules in 12 sectors and 3 radial layers, for 108 counters and 6912 readout channels, and achieved a system time resolution of about 85 ps for pions together with kaon–pion separation up to $11\,A\mathrm{GeV}$0 (Deppner et al., 2020). At mCBM, a 25-counter, 1600-channel mTOF wall enabled high-rate benchmark runs, and MRPC3 prototypes showed about 97% efficiency at $11\,A\mathrm{GeV}$1 and linear behavior up to $11\,A\mathrm{GeV}$2 (Deppner et al., 2020).

The MRPC3b production and QA line adds another layer of operational evidence. Batch tests for STAR-eTOF reported time resolution better than 70 ps and efficiency around 95%, while also identifying and then mitigating elevated edge-strip noise through CSTStudio-based redesign of the high-voltage pad and glass-edge geometry (Wang et al., 2023). The optimized design reduced near-end and far-end strip noise to values comparable to the middle strips and was adopted for the final CBM-TOF wall (Wang et al., 2023). This is a concrete example of how subsystem-specific design tools, production QA, and detector deployment belong to the same broader suite.

The most explicit end-to-end validation is the 2024 mCBM $11\,A\mathrm{GeV}$3-baryon reconstruction benchmark. In Ni+Ni collisions at 1.93 AGeV and an average interaction rate of about 250 kHz, mCBM recorded 7.3 TB of free-streaming data, produced $11\,A\mathrm{GeV}$4 software-triggered events, and reached a peak total data rate of about $11\,A\mathrm{GeV}$5 across the FLES-monitored subsystems (Collaboration et al., 1 Jun 2026). The analysis reconstructed $11\,A\mathrm{GeV}$6 $11\,A\mathrm{GeV}$7 candidates with significance $11\,A\mathrm{GeV}$8, $11\,A\mathrm{GeV}$9, and a measured lifetime $\sqrt{s_{NN}} = 2.9 - 4.9~\mathrm{GeV}$0, consistent with the Particle Data Group value quoted in the paper (Collaboration et al., 1 Jun 2026). Since the chain runs from free-streaming digis through software event definition, STS alignment, TOF/BMON calibration, Cellular Automaton tracking, Kalman fitting, KFParticle topology reconstruction, mixed-event background subtraction, and final physics extraction, it functions as a system-level demonstration of CBM-Suite in operation.

6. Limitations, versioning, and prospective consolidation

The literature also identifies constraints that shape the future evolution of CBM-Suite. On the data-management side, client-side Adler32 computation is a major time cost, Rucio may prefer davs:// over root:// when multiple protocols are available, and misconfigured GFAL/libdavix support can generate large upload failure rates with misleading diagnostics (Clerkin et al., 2022). The same study notes software volatility in the CBMROOT development branch shortly before DAC21, requiring new FairSoft and FairRoot versions, updated Docker images, and reworked reconstruction macros (Clerkin et al., 2022). These observations support the argument, stated explicitly there, for stable, versioned CBM-Suite releases for production datalake workflows.

On the control side, the TOF DCS paper stresses that mCBM is a prototype test stand that needs full functionality like the full experiment, and that scalability requires the system to increase without rewriting everything from scratch (Dong et al., 2020). The full TOF wall implies $\sqrt{s_{NN}} = 2.9 - 4.9~\mathrm{GeV}$1 HV channels, major growth in LV channels, gas lines, front-end boards, and archive volume, even though the mCBM deployment already validated 2635 PVs, CSS-based GUIs, PostgreSQL archiving, and Sequencer-based safety logic (Dong et al., 2020). This suggests that control software in CBM-Suite is already architected as a distributed IOC family rather than as a monolithic supervisory layer.

Subsystem integration imposes further constraints. The MVD integration concept requires $\sqrt{s_{NN}} = 2.9 - 4.9~\mathrm{GeV}$2–$\sqrt{s_{NN}} = 2.9 - 4.9~\mathrm{GeV}$3 per layer, operation of the MIMOSIS sensors in target vacuum, a strong magnetic dipole field, and a radiation environment of $\sqrt{s_{NN}} = 2.9 - 4.9~\mathrm{GeV}$4 and $\sqrt{s_{NN}} = 2.9 - 4.9~\mathrm{GeV}$5 per CBM year, all while remaining inside the free-streaming DAQ chain through FEBs, ROBs, GBTx, GBT-SCA, and CRI interfaces (Matejcek et al., 7 Feb 2025). In the detector-and-electronics overview, many components are already in series production or validated in existing experiments, but the suite as a whole still depends on continued integration of detector services, timing, calibration, and online selection for full-rate operation (Teklishyn, 25 Jun 2025).

Taken together, these studies indicate that CBM-Suite is evolving toward a versioned federation of physics software, online reconstruction services, control frameworks, distributed storage, and production QA tools. The suite is therefore both an operational infrastructure for FAIR and a methodological framework for turning a free-streaming $\sqrt{s_{NN}} = 2.9 - 4.9~\mathrm{GeV}$6-class experiment into calibrated, reproducible, and physics-ready datasets (Clerkin et al., 2022, Teklishyn, 25 Jun 2025).