Virtual beam line software platform for advanced synchrotron radiation light source

Abstract

The invention discloses a virtual beam line software platform for an advanced synchrotron radiation light source, and belongs to the field of synchrotron radiation experiment simulation, control technology and data processing. The platform adopts a three-layer architecture of a user interaction layer, a virtual equipment layer and a data management layer, and supports a full simulation experiment based on a physical model and a data reproduction dual-working mode based on a historical data set. The core of the method is that physical equipment is abstracted into a virtual instance conforming to an EPICS standard through a virtual equipment layer, and seamless compatibility with a real control code is achieved; the user interaction layer carries out experimental process arrangement based on a Bluesky framework; and the data management layer optimizes the access efficiency of mass scientific data by adopting a block reading and memory mapping technology. According to the method, the problem of experimental process fault caused by existing tool chain splitting is solved, full-process high-fidelity virtualization from experimental design, equipment control to data acquisition and analysis is realized, and a unified software environment is provided for construction debugging and operation optimization of a synchrotron radiation light source.

Description

Technical Field

[0001] This invention belongs to the field of synchrotron radiation experiment simulation, control technology and data processing, and specifically relates to a virtual beamline software platform for advanced synchrotron radiation sources. Background Technology

[0002] As a crucial platform for cutting-edge scientific research, synchrotron radiation sources rely heavily on three types of software tools for the design, commissioning, and operation of beamlines: computer simulation, equipment control, and data management. However, existing solutions suffer from severe problems of "tool fragmentation and process discontinuity," lacking a complete, high-fidelity virtualization environment to support pre-verification and testing throughout the entire experimental process.

[0003] In the field of optical simulation, tools such as SHADOW and its graphical integrated platform OASYS can simulate the propagation of X-rays in optical devices based on the principle of ray tracing. However, these tools focus on front-end optical design and lack the ability to virtualize core equipment of the experimental station (such as detectors and sample stages). They cannot simulate the complete data flow of "equipment control-data acquisition" and are disconnected from subsequent experimental control links.

[0004] In terms of equipment control, EPICS (Experimental Physics and Industrial Control Systems) is a widely adopted standard control framework in the field of synchrotron radiation. However, its built-in IOC (Input / Output Controller) simulator has limited functionality, only able to simulate the process variable response of a single device. It is difficult to reproduce the complex collaborative timing logic between multiple devices (such as the triggering of detector acquisition after motor movement), and it cannot support the specialized functional linkage simulation of synchrotron radiation equipment (such as dual-crystal monochromators). The efficiency and reliability of virtual debugging are limited.

[0005] In terms of experimental procedures and data management, frameworks such as Bluesky focus on the orchestration and definition of experimental procedures, but they lack the ability to virtualize devices and efficiently reproduce historical data. Users need to manually configure real device parameters to generate scan plans and cannot directly drive virtual devices; at the same time, there is a significant delay (usually more than 100 milliseconds) when loading historical experimental data (such as GB / TB-level HDF5 / NeXus files), which prevents "experiment orchestration" from forming an effective closed loop with "virtual control" and "data generation / reproduction".

[0006] In summary, the existing "optical simulation-equipment control-experiment management" toolchain is independent, resulting in a disconnect in the entire "equipment-control-data" workflow. This technical bottleneck restricts the construction and operation efficiency of next-generation light sources such as the High Energy Photon Source (HEPS). During the construction phase, there is a lack of a platform for low-cost pre-verification of the complete experimental process, and during the operation phase, there is a lack of effective tools for user training and software testing. Therefore, developing a unified software platform that can deeply integrate the above functions and achieve closed-loop virtualization of the entire process has become a critical technical problem that urgently needs to be solved. Summary of the Invention

[0007] To address the aforementioned technical challenges, this invention provides a virtual beamline software platform for advanced synchrotron radiation sources. By designing a bidirectional mapping and bridging mechanism of "protocol-data-timing," a deep coupling and dynamic interaction relationship is established between equipment control, experiment orchestration, and data management. This enables high-precision virtualization of key equipment at synchrotron radiation beamline stations, providing a high-fidelity, end-to-end virtual environment for the development, testing, and optimization of beamline software, as well as experimental pre-debugging.

[0008] To achieve the above objectives, the present invention adopts the following technical solution:

[0009] A virtual beamline software platform for advanced synchrotron radiation sources comprises a three-layer architecture: a user interaction layer, a virtual device layer, and a data management layer. It supports dual working modes: full simulation experiments based on physical models and data reproduction based on historical experimental datasets.

[0010] The user interaction layer, implemented based on the Bluesky experimental control framework, is used for orchestrating experimental processes and sending control commands to the virtual device layer.

[0011] The virtual device layer includes a virtual experimental station engine, a device virtualization module, a data simulation module, and a data reproduction module. The device virtualization module abstracts physical devices into input / output controller instances conforming to the EPICS standard. Each instance receives control commands and returns data through process variables. The data simulation module has a built-in high-fidelity physical model for generating simulation data in a full-simulation experimental mode. The data reproduction module loads and replays historical experimental datasets in data reproduction mode. The virtual experimental station engine schedules the device virtualization module according to the selected working mode, enabling it to obtain data from the data simulation module or the data reproduction module and respond to the upper layer through a unified process variable interface.

[0012] The data management layer employs block reading and memory mapping technology for efficient storage and access of historical datasets.

[0013] Furthermore, the experimental orchestration in the user interaction layer is specifically implemented by object-oriented encapsulation of the process variables PV of the virtual device through the Ophyd library; the encapsulation encapsulates the virtual detector as the VirtualAreaDetector class and includes a built-in dark current noise injection method, and encapsulates the virtual motor as the VirtualEpicsMotor class and supports homing difference parameter configuration; the encapsulated class establishes a two-way binding with the underlying PV through the EPICS Channel Access protocol, enabling Bluesky experimental orchestration commands to directly drive the virtual device.

[0014] Furthermore, the user interaction layer provides both graphical and programmatic interfaces for defining experimental parameters and procedures; in data reproduction mode, it can automatically parse the experimental time series metadata embedded in the historical dataset and generate the corresponding experimental instruction sequence.

[0015] Furthermore, the physical devices abstracted by the device virtualization module include virtual detectors, virtual motors, and virtual optical devices; wherein, the virtual detectors include zero-dimensional detectors, one-dimensional detectors, and two-dimensional detectors, the virtual motors include linear translation motors and angular rotation motors, and the virtual optical devices include at least a virtual dual-crystal monochromator, a virtual electric four-blade slit, and a virtual beam position probe.

[0016] Furthermore, the physical models embedded in the data simulation module include a two-dimensional elliptic Gaussian function model for simulating light intensity distribution and a three-dimensional projection integral model based on the Shepp-Logan model for simulating CT projection data. It can also inject Poisson noise into the generated simulation data to simulate the dark current of the detector.

[0017] Furthermore, when loading and replaying historical experimental datasets, the data reproduction module specifically performs the following operations: calls down to the high-speed data processing module of the data management layer to obtain the data stream optimized by block reading and memory mapping technology; automatically parses the experimental metadata and acquisition logic embedded in the historical experimental dataset file, and generates the corresponding data acquisition script to be uploaded to the user interaction layer; and drives the virtual device to execute the data reproduction process according to the original experimental sequence.

[0018] Furthermore, the data management layer includes an efficient data management module and a high-speed data processing module; the efficient data management module is used to parse the metadata structure and device configuration information of the historical dataset, and the high-speed data processing module is used to perform high-performance data reading operations based on block indexing and memory mapping.

[0019] Furthermore, the data management layer's block reading and memory mapping technology specifically includes: pre-building a physical address mapping table for data blocks of HDF5 / NeXus files, implementing zero-copy data reading through the operating system's memory mapping function, and employing a double-buffered pipeline mechanism to pre-read subsequent data blocks to ensure access continuity.

[0020] Furthermore, the experimental method in the physical model-based full simulation experimental mode includes:

[0021] Prepare the runtime environment, deploy the basic software environment, and initialize the user interaction layer;

[0022] The virtual device service starts, launching a virtual device instance and configuring parameters according to the experiment mode and type.

[0023] Data acquisition task configuration, defining control parameters, acquisition scripts and data saving settings;

[0024] The virtual experiment process is executed by driving virtual devices to perform data acquisition operations according to the orchestration scheme, generating and storing simulation data in real time.

[0025] Furthermore, the experimental method for data reproduction in dual working modes based on historical experimental datasets includes:

[0026] Prepare the reproduction environment, deploy the basic software environment, and initialize the user interaction layer;

[0027] Import historical data, loading historical datasets in HDF5 / NeXus format aligned by timestamps;

[0028] Virtual device instance creation: Automatically create and initialize virtual devices of the corresponding type based on historical data characteristics;

[0029] The data reproduction process is executed by automatically generating a collection script based on historical data, which drives the virtual device to reproduce the experimental process in the original time sequence.

[0030] The beneficial effects of this invention are as follows:

[0031] It achieves full-process closed-loop virtualization: breaking through the limitations of existing tools that only focus on a single link, it deeply integrates experiment orchestration, equipment control and data management within a unified platform, realizing a full-link closed loop from experiment design and pre-verification to data analysis, which greatly improves the efficiency of experiment preparation and software testing.

[0032] An innovative dual-mode driven architecture has been developed, supporting both "physical model simulation" and "historical data reproduction" working modes. It can flexibly design new experimental schemes based on high-fidelity models, and accurately and efficiently replay real historical experiments, covering the entire life cycle of device construction, commissioning, operation and optimization.

[0033] Deep protocol compatibility and seamless migration have been achieved: Through the full simulation of the EPICS control protocol at the virtual device layer, it is ensured that the control code, user interface and data analysis program developed for real physical devices can run directly in this virtual environment without any modification, realizing seamless migration from the real environment to the virtual environment and ensuring the reusability of development results.

[0034] It provides an efficient data management solution: For massive scientific data from synchrotron radiation, the data management layer adopts optimization techniques such as block reading and memory mapping, which significantly improves the loading and playback speed of TB-level historical experimental data, effectively solves the latency bottleneck of data reproduction, and realizes smooth data backtracking and analysis.

[0035] It ensures the high fidelity of the virtual environment: the virtual device embeds physical and error models (such as detector noise and motor hysteresis), making the generated simulation data closer to the real experimental results, which greatly improves the reliability and robustness of the data acquisition and control software developed based on this platform in actual deployment.

[0036] Significantly reduced experimental costs and risks: By replacing some physical equipment debugging steps with a high-fidelity virtual environment, the risk of damage to high-value optical components is reduced. At the same time, it provides researchers with a safe and flexible environment for operation training and scheme simulation, effectively reducing learning costs and operational risks. Attached Figure Description

[0037] Figure 1 This is a structural diagram of the virtual beamline software platform for advanced synchrotron radiation sources according to the present invention.

[0038] Figure 2 Create control flowcharts for user interaction layer experiments;

[0039] Figure 3 This is a diagram illustrating virtual device types.

[0040] Figure 4 This is a workflow diagram for data acquisition in full analog mode.

[0041] Figure 5 This is a workflow diagram for data acquisition under the historical data reproduction mode. Detailed Implementation

[0042] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0043] This invention relates to a virtualization software platform for synchrotron radiation source experimental stations. Through an innovative "three-layer architecture + dual-drive mode" design, it establishes a dual-mode driven architecture: a "physical model-based full simulation experimental mode" and a "historical dataset-based experimental data reproduction mode." Furthermore, through deep coupling of the EPICS device control protocol and the Bluesky experimental orchestration framework (such as the object-oriented encapsulation of virtual device PVs in the Ophyd library), it achieves a closed-loop virtualization of the entire process from experimental design and virtual device control to virtual data acquisition and analysis, perfectly matching the experimental workflow and equipment characteristics of beamline stations (such as imaging and XRD (X-ray diffraction) mapping). Its core lies in the dual-mode data-driven architecture. The platform can flexibly switch between or combine the two modes according to task requirements, providing a complete virtualization environment for both innovative design and historical backtracking throughout the entire experimental process. In the physical model-based full simulation experimental mode, the platform generates simulation data through a built-in high-fidelity physical model. For example, virtual detectors can output Gaussian-function-based spot images or CT projection data generated from 3D Shepp-Logan models, and can simulate real noise (such as dark current); virtual motors can move according to user-preset trajectories and simulate mechanical errors (such as backlash). In the data reproduction mode based on historical datasets, the platform supports importing historical experimental datasets in formats such as HDF5 / NeXus. Through efficient data loading technologies such as block reading and memory mapping, real data is aligned by timestamps and loaded into the corresponding virtual device modules, completely reproducing the data acquisition process and environmental conditions of the original experiment.

[0044] like Figure 1 As shown, the software platform of this invention adopts a three-layer software architecture consisting of a user interaction layer, a virtual device layer, and a data management layer. Each layer exchanges data and calls functions through clearly defined interface protocols, forming a collaborative working mechanism: the user interaction layer is responsible for the orchestration of experimental procedures and the issuance of instructions; the virtual device layer undertakes the core functions of device virtualization and data generation; and the data management layer provides efficient data access support. This architectural design ensures that the platform maintains the independence of each module while achieving a high degree of synergy in overall functionality.

[0045] The user interaction layer serves as the unified interface for users to interact with the software platform, with its core being the user experiment orchestration module. This module, implemented based on the Bluesky experiment control framework, provides both graphical and programmatic interaction methods, allowing users to select virtual experimental equipment, define experimental parameters (such as scan range, step size, and exposure time), and formulate complex experimental procedures (such as CT scans and XRD mapping). In data reproduction mode based on historical datasets, the system can automatically parse the original experimental logic and generate experimental instruction sequences.

[0046] like Figure 2As shown, the core innovation of the user experiment orchestration module lies in its bidirectional command conversion capability. It allows users to customize the operating logic and data acquisition sequence of virtual devices based on pre-designed data acquisition templates. All virtual devices implement standardized interfaces through the EPICS Channel Access protocol, supporting device control and data reading via PV. In data reproduction mode based on historical datasets, it can receive and automatically execute acquisition scripts generated by the data reproduction module based on parsed original historical data, achieving intelligent reverse reconstruction of the experimental process without manual intervention. Specifically:

[0047] Programming Interface Design: Provides a dual interface of "programmatic + graphical" – the programmatic interface supports defining experimental procedures through BlueskyScan Plan syntax (standard Python) (such as CT continuous rotational scanning: scan([virtual_2d_det],virtual_rot_motor,0,180,180)); the graphical interface has preset experimental templates for imaging, diffraction, and spectroscopy, and users only need to input key parameters (such as exposure time and scan step size) to generate a programming plan.

[0048] Device Interface Encapsulation: Since all virtual devices expose standardized PV interfaces through the EPICS Channel Access protocol, the Ophyd library is used for object-oriented encapsulation, forming a "virtual device-specific class library." Virtual detectors are encapsulated as the VirtualAreaDetector class (inheriting from AreaDetector), with a built-in dark current noise injection method (set_dark_current()); virtual motors are encapsulated as the VirtualEpicsMotor class (inheriting from EpisMotor), supporting backlash difference parameter configuration (set_backlash()). These encapsulated classes establish a two-way binding with the underlying EPICS PV through the Channel Access protocol, ensuring that orchestration commands can directly drive the virtual devices.

[0049] Reproduction mode adaptation: In historical experimental data reproduction mode, the system parses the experimental timing (such as motor position-time curve, detector acquisition trigger signal) in the HDF5 / NeXus file through the virtual device layer data reproduction module, and automatically converts it into Bluesky standard Plan instruction sequence (no manual writing required), realizing reverse reconstruction of the experimental process.

[0050] The virtual device layer serves as the core of the platform and consists of a virtual experimental station engine, a device virtualization module, a data simulation module, and a data reproduction module.

[0051] The virtual experimental station engine acts as a scheduling center, scheduling and coordinating the work of other modules and allocating computing resources according to the user-selected working mode (full simulation / reproduction); specifically:

[0052] Equipment instance scheduling: Based on the experiment type selected by the user (such as CT experiment), the equipment virtualization module is automatically called to generate a cluster of "virtual optical equipment + virtual motion equipment + virtual detection equipment" - for example, the CT experiment needs to generate "virtual dual crystal monochromator + virtual rotary motor + virtual 2D detector", and the corresponding equipment parameter template (such as monochromator Si(111) crystal parameters, detector resolution 1024×1024 size) is loaded through preset script.

[0053] Working mode scheduling: Triggers the corresponding data module according to the mode selected by the user. In full simulation mode, a "physical model call command" is sent to the data simulation module (e.g., calling the 3D Shepp-Logan model for CT experiments), and error parameters (e.g., detector dark current 15 counts / s) are injected synchronously; in historical reproduction mode, a "historical data loading request" is sent to the data reproduction module, specifying the HDF5 / NeXus file path and data blocks to ensure that the data is time-aligned with the virtual device.

[0054] like Figure 3 As shown, the device virtualization module is the core of the entire layer. Its innovation lies in unifying the abstraction of different types of physical devices (such as 1D / 2D detectors, motors, and monochromators) into IOC (Input / Output Controller) instances conforming to the EPICS standard. Each virtual device instance exposes a set of process variables (PVs) through the EPICS Channel Access protocol, thereby receiving control commands and returning data. Its key function is to support dual-mode data response: in simulation mode, it obtains data calculated based on the physical model from the data simulation module; in reproduction mode, it obtains historical data aligned to timestamps from the data reproduction module.

[0055] Virtual detectors consist of zero-dimensional detectors, one-dimensional detectors, and two-dimensional detectors.

[0056] A zero-dimensional detector refers to a detector with a significant size in only one dimension of three-dimensional space. It typically exhibits a point-like or spherical structure. Its core simulation principle is based on a "baseline + random noise" model. The baseline value is configurable (e.g., 100 counts), and the noise is simulated using a random number generator with a settable range (e.g., fluctuations of ±5 counts). Configurable parameters include engineering units (EGU), sampling period, readings (RBV), and noise intensity. It can be used to simulate the responses of photodiodes, ionization chambers (e.g., Keithley 6485 / 6487), and counters.

[0057] One-dimensional detectors are typically used to acquire linear spatial distribution information, such as linear CCDs or linearly scanning radars, which only provide intensity distribution in a linear direction. Their simulation principle is based on an "ideal intensity distribution + Gaussian noise" model. The ideal distribution can be a linear gradient or peak distribution, and the noise intensity is positively correlated with the exposure time. Their core simulation function parameters (corresponding to PV in EPICS) are as follows: ImageMode (single / multiple / continuous); Acquire (start acquisition / stop acquisition); ArrayData (one-dimensional array simulating fluctuations); AcquireTime (exposure time, in seconds); NumImage (number of acquisitions per exposure); TriggerMode (currently only soft triggering is supported).

[0058] Two-dimensional detectors are typically used to record the two-dimensional spatial distribution information of X-rays and are widely used in various fields such as X-ray imaging, X-ray diffraction, and X-ray scattering. Their simulation principle involves calling a physical model (Gaussian spot, 3D Shepp-Logan CT projection) in full simulation mode and injecting Poisson noise (simulating dark current); in reproduction mode, they load ArrayData from historical HDF5 / NeXus data. The core simulation parameters are as follows: ImageMode (single / multiple / continuous); Size_X (horizontal dimension); Size_Y (vertical dimension); AcquireTime (exposure time); Acquire (start acquisition / stop acquisition); ArrayData (used to interface with two-dimensional data provided by the data reproduction and data simulation modules); NumImage (number of acquisitions per exposure); TriggerMode (soft trigger only), etc.

[0059] For virtual motors, which are designed to meet the needs of adjusting the sample stage and equipment in synchrotron radiation source experiments, they are divided into linear translation motors and angular rotation motors. High-precision virtualization is achieved through "motion model + error injection + EPICS PV control".

[0060] The virtual linear translation motor is adapted for linear motion control scenarios in synchrotron radiation source beamlines, simulating X / Y / Z axis positioning of the sample stage and driving of the motorized four-blade slit blades. Its motion is based on a "trapezoidal velocity curve": starting from an initial velocity, accelerating to maximum velocity, and stopping with equal deceleration near the target position, matching the dynamic characteristics of a real motor. Core EPICS PV parameters include configurable items such as initial velocity, acceleration, maximum velocity, and soft limit (±100mm), as well as read-only items such as motion status and actual position feedback (RBV); it supports backlash error injection (e.g., ±0.001mm), compensating for errors before updating the position during reverse motion to restore mechanical characteristics. In typical applications, when driving the virtual four-blade slit, the target position of the four-blade motor can be updated synchronously using a "one-click opening and closing" algorithm to ensure the beam center remains unchanged.

[0061] The virtual angle rotary motor focuses on the synchrotron radiation source sample stage for attitude adjustment and CT experiments, simulating Pitch / Roll / Yaw three-degree-of-freedom control and CT rotation axis motion. The motion model is similar to a linear translation motor (trapezoidal velocity curve), but the engineering unit is "degrees (°)," supporting 360° continuous rotation. Core EPICS PV parameters include initial velocity, acceleration, maximum velocity, soft limit (±185°), target angle, and actual angle feedback (RBV); it supports angle drift error injection (e.g., ±0.01° / min) to simulate real motor temperature drift. In CT experiments, the target angle can be updated according to the Bluesky scan plan (e.g., 0-180°, 1° step). The detector is exposed after reaching the target angle, and RBV ensures positioning accuracy.

[0062] The virtual optical equipment is used to simulate synchrotron radiation. It mainly includes a dual-crystal monochromator, a motorized four-blade slit, and a beam position probe. The virtual dual-crystal monochromator is implemented based on the core architecture of an angle-rotating motor in the virtual motor class; the virtual motorized four-blade slit is implemented based on a linear translation motor in the virtual motor class; and the virtual beam position probe is implemented based on an extension of the virtual detector class.

[0063] The virtual dual-crystal monochromator is an extension of the core architecture of the virtual angle rotary motor. It is a dual-crystal monochromator specifically designed to simulate a beamline station for X-ray energy selection. In addition to inheriting the Bragg angle control (SIM:DCM:Bragg), the following core functional parameters are added: target energy value (SIM:DCM:Energy.VAL), actual energy feedback value (SIM:DCM:Energy.RBV), crystal switching parameters (SIM:DCM:Sel), and crystal temperature (SIM:DCM:Temp).

[0064] The target energy value is used to set the target energy of the monochromator, and the actual energy feedback value is used to obtain the energy feedback value of the virtual dual-crystal monochromator. These two parameters are linked to the target position and actual position feedback value of the motor.

[0065] The relationship between the angle and energy of the virtual dual-crystal monochromator is automatically calculated using Bragg's law, and its core formula is:

[0066] ,

[0067] in, : Diffraction order (usually taken as 1); X-ray wavelength (Å); : Interplanar spacing (Å); Bragg angle (degrees). Its conversion into energy ( Relationship with angle:

[0068] .

[0069] The crystal switching parameters are used to implement the crystal switching function in the monochromator. The corresponding data for the two optional crystal parameters are shown in Table 1 below.

[0070] Table 1

[0071]

[0072] The core of the virtual electric four-blade slit consists of four virtual linear displacement motor instances (Top, Bottom, Left, and Right) and a one-button opening / closing control function. The one-button opening / closing control function is implemented through an intelligent intermittent control algorithm, the formula of which is as follows. By automatically calculating the blade displacement, the movement of the four blades is controlled; that is, the blades in the horizontal x (Left and Right) and vertical y (Top and Bottom) directions perform mirror movements respectively, ensuring that the beam center position remains unchanged.

[0073] ,

[0074] In this case, it is assumed that all four blades are initially located at the zero position (center origin), and the unit is mm; The target horizontal gap; For the target vertical clearance, , , , These represent the blade displacement in the corresponding directions; by setting... The value will automatically adjust the upper and lower cuts synchronously, such as For a distance of 1mm, the virtual motor for the upper cutter moves upward (positive direction) by 0.5mm, and the virtual motor for the lower cutter moves downward (negative direction) by 0.5mm. This is achieved through settings. The value will automatically adjust the left and right blades synchronously, such as For a distance of 1mm, the left blade virtual motor moves 0.5mm to the left (negative direction), and the right blade moves 0.5mm to the right (positive direction).

[0075] The virtual beam position probe is an extension of the zero-dimensional detector based on the virtual detector class. It consists of a four-quadrant electrode array composed of four virtual zero-dimensional detector instances, simulating the electrode signal acquisition and processing process of a real BPM in real time through the EPICS signal channel. This system innovatively employs dynamic signal reconstruction technology to transform the physical electrode response of a traditional hardware BPM into a programmable virtual signal source. It not only fully retains key algorithmic characteristics such as (A+B+C+D) signal monitoring and (A+DBC) / Σ normalized position calculation, but also achieves real-time calculation and feedback of beam position parameters through the Derived Signal mechanism. This allows the virtual device to provide beam trajectory monitoring functions even when completely independent of physical hardware, while also supporting multi-device linkage simulation and global debugging scenarios.

[0076] The data simulation module is applied to a full-simulation experimental mode and has a built-in high-fidelity physical model to respond to PV read / write requests from virtual devices and generate corresponding simulation data. For example, it can dynamically generate Gaussian spot images based on a two-dimensional elliptic Gaussian function model, or generate CT projection data based on a 3D Shepp-Logan model and Radon transform, and can inject preset noise and error models into the data.

[0077] The data reproduction module is applied to historical experimental data reproduction mode. Its core function is to connect downwards to the data management layer, load historical datasets in HDF5 / NeXus format aligned by timestamps, and achieve efficient data stream playback through block reading-memory mapping technology. Furthermore, this module can automatically parse the experimental metadata and acquisition logic embedded in the original data files and generate corresponding data acquisition scripts to upload to the user interaction layer. Specifically:

[0078] For the simulation of Gaussian light spots, a two-dimensional elliptic Gaussian function model is used to simulate the intensity distribution of the synchrotron radiation beam for generating light spot data for a virtual 2D detector. Its core design expression is as follows:

[0079] ,

[0080] in: It is a point The light intensity at point A; A is the amplitude (peak intensity of the light spot). These are the coordinates of the light spot center, which are located at the detector center by default and can be adjusted. The values ​​are offset, with an offset precision of 0.01 pixels; It is the standard deviation in the horizontal direction; It is the standard deviation in the vertical direction. It supports asymmetric spot simulation. It can accurately simulate elliptic beams and dynamically respond to parameter changes with a parameter update delay of less than 10ms. In terms of data output, it outputs 16-bit integer data (matching the data format of a two-dimensional detector), which can be directly input into the ArrayData PV of the virtual 2D detector and supports linkage with the virtual beam position probe (calculating the beam center position through the beam intensity distribution).

[0081] For the simulation of CT projection data, a 3D Shepp-Logan model is used as the basis, and accurate simulation of CT projection data is achieved based on the three-dimensional projection integral formula (a generalization of Radon transform). The core design expression for projection calculation is as follows:

[0082] ,

[0083] in: Indicates the angle The two-dimensional projection data below, For the projection plane coordinates, Represents three-dimensional projection data; The projection angle has a range of values. Uniform distribution sampling is used: (Total number of angles); Let be the Dirac function, representing the angle along the projection direction. The line integral process of ).

[0084] In terms of the generation process, based on the angle sequence of the virtual CT rotary motor (e.g., 0-180°, step size 1°), the projection data corresponding to each angle is calculated according to the above formula → Poisson noise is injected (simulating the dark current of the detector, the noise intensity is positively correlated with AcquireTime) → output to the ArrayData PV of the virtual 2D detector.

[0085] In terms of adaptability, it supports common projection sizes (such as 1024×1024, 2048×2048), and the grayscale distribution error between the projection data and the real CT experimental data is <5%, which can be used for virtual testing of CT reconstruction algorithms.

[0086] The data reproduction module is the core of the historical experimental data reproduction mode. It is specifically designed to load historical data in standard HDF5 / NeXus format and drive virtual devices to replicate the original experimental process. Its core functions are divided into two parts: "data loading management" and "experimental script parsing," as detailed below: In terms of data loading management, this module connects to the data management layer and controls the high-speed data processing module to automatically align and load historical datasets in HDF5 / NeXus format according to timestamps, ensuring efficient data access and providing reliable source support for data reproduction. Regarding experimental script parsing, this module can automatically parse the corresponding data acquisition scripts, extract key information (such as device type and quantity), and return the parsing results to the user interaction layer, facilitating user viewing and management of experimental configurations. The design of this module balances the efficiency of data loading with the accuracy of script parsing, providing complete technical support for the reproduction and analysis of historical experimental data.

[0087] The data management layer consists of a high-speed data processing module and a high-efficiency data management module. It employs a block-based read-memory mapping technology to specifically optimize the loading and access speed of GB / TB-level historical experimental data, thus resolving the data latency bottleneck in traditional methods. Specifically:

[0088] The high-speed data processing module adopts a core technology solution integrating "HDF5 block storage index + memory-mapped zero-copy + double-buffered pipeline". This reduces the loading latency of GB-level data from >100ms for traditional full reads to <10ms, supporting high-throughput access to EB-level data. Simultaneously, it utilizes HDF5's native LZ4 lossless compression to reduce storage footprint while maintaining data quality (compression ratio approximately 2:1). Its specific technical process is as follows:

[0089] 1. Pre-built block index: Parse the Chunked Storage structure of the HDF5 file (e.g., each block is 128×128 pixels), pre-build the physical address mapping table of the data blocks, and realize precise location on demand (without traversing the entire file);

[0090] 2. Memory-mapped loading: Data blocks are directly mapped to the virtual device cache using the operating system's mmap function, achieving "zero-copy reading" (avoiding repeated copying of data between memory and disk).

[0091] 3. Double-buffered pipeline: It adopts a double-buffering mechanism of "main thread processing the data of the current frame + background thread pre-reading the data of the next 1-2 frames", combined with a circular sliding window buffer (the buffer size is configurable, such as 10 frames) to ensure the order and continuity of data.

[0092] The high-efficiency data management module is designed for the commonly used HDF5 / NeXus scientific data formats of synchrotron radiation sources, possessing standardized parsing and flexible adaptation capabilities. Its core data parsing function extracts key information according to a standardized path: it identifies the detector type (0D / 1D / 2D via dimensions) and the number and parameters of motors (speed, soft limit, etc.) from the directories " / entry / instrument / detector / " and " / entry / instrument / motor / ". It extracts beam energy from " / entry / instrument / monochromator / energy" and, combined with " / entry / measurement / timestamps", obtains the timestamps for each data frame and the motor position-time curve, simultaneously collecting metadata such as experiment name and acquisition time. When supporting the data reproduction process, this module passes the parsed "equipment list" and "scan parameters" to the data reproduction module, providing a basis for generating the Bluesky scan plan script. It also generates a "data-equipment" matching table to ensure precise alignment of detector data blocks with corresponding motor positions during reproduction. In addition, the module supports custom data structures for different beamline stations (such as imaging scene “ / entry / CT / projections”, diffraction scene “ / entry / XRD / patterns”), and can extend the parsing rules through configuration files to adapt to diverse experimental data needs.

[0093] Based on the aforementioned software platform, this invention provides a method for full simulation of virtual beamlines for synchrotron radiation sources, comprising the following steps:

[0094] Step 1: Runtime Environment Preparation: Deploy Python 3 (version greater than 3.6.8) and the EPICS 7.0 basic control framework in the runtime environment, configure the necessary dependency libraries; initialize the user interaction layer and load the virtual device configuration interface;

[0095] Step 2: Start the virtual device service: Based on the experiment mode and device type selected by the user, start the corresponding virtual device instance and configure the device parameters, including the status of optical components, detector parameters and motor parameters;

[0096] Step 3, Data Acquisition Task Configuration: Define the experimental data acquisition task, including virtual device control parameters, data acquisition script configuration, and experimental data save path and file format settings;

[0097] Step 4: Virtual Experiment Process Execution: Based on the experiment arrangement scheme provided by the user interaction layer, start the virtual experimental station engine and drive the virtual device to perform data acquisition operations; generate simulation data in real time and store the experimental data in a preset format.

[0098] Furthermore, in step 1, the operating system supported by the runtime environment is Linux (CentOS 7.9 64-bit) or Windows 10 (64-bit), and at least one graphics processing unit (GPU) that supports parallel computing.

[0099] Furthermore, in step 2, the optical device status includes monochromator crystal parameters, slit geometry parameters, and beam position probe values; the detector parameters include image size, exposure time, exposure period, trigger mode, and image mode; and the motor parameters include speed, acceleration, soft limit range, and engineering units.

[0100] Furthermore, in step 4, the virtual device is driven to run through the EPICS control interface, which is fully compatible with the real device and supports standard process variable read and write operations. The data acquisition process includes: the virtual motor moves along a preset trajectory and injects mechanical errors; the detector generates detection data based on the optical element status and physical model; and the data acquisition system records the device status and output data in real time.

[0101] Furthermore, the present invention also provides a method for reproducing historical data of virtual beamlines for synchrotron radiation sources, comprising the following steps:

[0102] Step 1: Prepare the reproduction environment: Deploy Python 3 (version greater than 3.6.8) and the EPICS 7.0 basic control framework in the runtime environment, configure the necessary dependency libraries; initialize the user interaction layer and load the virtual device configuration interface;

[0103] Step 2, Historical Data Import: Based on the high-speed data processing module of the data management layer, load the historical dataset in HDF5 / NeXus format aligned by timestamp, automatically identify the data organization structure, and quickly load the detector data and motor position data into the platform through block reading-memory mapping technology;

[0104] Step 3: Virtual device instance creation: Based on the characteristics of the imported historical data, automatically create virtual detectors and virtual motor devices of the corresponding type and quantity, and complete the virtual device initialization according to the device configuration parameters contained in the data file;

[0105] Step 4: Data Reproduction Process Execution: Automatically generate a data acquisition script based on historical data, start the virtual experimental station engine, drive the virtual device loaded with historical data to execute the data reproduction process in the original time sequence, and save the output data according to the preset format.

[0106] Furthermore, in step 1, the operating environment supports Linux (CentOS 7.9) or Windows 10 (64-bit) operating systems, requires the configuration of at least one graphics processing unit (GPU) that supports parallel computing, and provides storage space of no less than twice the size of the historical dataset.

[0107] Furthermore, in step 2, the historical experimental data is stored in HDF5 / NeXus scientific data format, including equipment configuration parameters, detector raw data, motor motion data, experimental metadata and corresponding timestamp information.

[0108] Furthermore, in step 3, a smart device matching mechanism is used to automatically create virtual devices: by parsing the dimensional information of the detector data in historical data, a detector instance of the corresponding type (0-dimensional, 1-dimensional, or 2-dimensional) is automatically created; a corresponding virtual motor is generated according to the number of motors recorded in the data; devices with complete configuration parameters are initialized according to the original parameters, and devices with missing parameters are intelligently supplemented according to the standard template.

[0109] Furthermore, in step 4, the platform precisely controls the virtual device to perform operations according to the original experimental sequence based on the timestamp information in the historical data, and all output data is automatically saved in a standard format.

[0110] Example 1: Full simulation CT experimental mode for HEPS imaging experimental station.

[0111] like Figure 4 As shown, this embodiment constructs a full-process simulation environment based on the CT tomography scene of the HEPS imaging experimental station of the synchrotron radiation source, focusing on verifying the dynamic collaborative capability of the synchrotron radiation dedicated virtual equipment cluster and the physical fidelity of the experimental data. The experimental parameters are set as follows: beam energy 10keV (corresponding to wavelength 1.24Å), spot size 1mm×0.5mm (horizontal×vertical), fixed at the origin (0,0,0) of the sample stage coordinate system; continuous rotation scanning mode is adopted, with an angle range of 0°-180°, a step size of 1°, a single frame exposure time of 1s, and the detector outputs a 1024×1024 two-dimensional projection.

[0112] Step 1: Experimental Environment Deployment and Standardized Configuration

[0113] Step 1.1: Building the underlying technology stack.

[0114] To ensure the system operates normally, the underlying technology stack needs to be built before system deployment, as follows:

[0115] (1) Python3 runtime environment: Python3 (version greater than 3.6.8) needs to be installed on the computer or server before system deployment.

[0116] (2) Control framework: Install and deploy the EPICS 7.0 basic environment and AreaDetector module;

[0117] (3) Python libraries: Install via pip, but not limited to Bluesky, Ophyd, Numpy and other key libraries.

[0118] Step 1.2: Initialize the virtual optical system.

[0119] Based on the optical characteristics of synchrotron radiation beamlines, a virtual front-end optical equipment cluster was configured. First, a dual-crystal monochromator was used. Crystal parameters (Si(111), d=3.1356Å) were configured via EPICS PV, and the target energy was set to 10keV. The system automatically calculated the Bragg angle (11.40°) and updated the BraggAngle.RBV feedback value, maintaining energy stability within ±0.01keV. Second, an electrically driven four-slit slit was used. A synchrotron radiation-specific "center-holding" algorithm was employed. Using a combination of PV parameters (Top=0.25mm, Bottom=-0.25mm, Left=-0.5mm, Right=0.5mm), the beam cross-section size was precisely controlled while maintaining the beam center (0,0). Finally, a beam position probe was used to simulate the signal output of a four-quadrant ionization chamber. Beam drift was fed back in real-time via XPos / YPos PV (control accuracy ±5μm), with a data sampling rate of 1kHz, and the data was archived as experimental metadata.

[0120] Step 2: Configure core equipment parameters for the virtual experimental station:

[0121] The core equipment of the virtual experimental station includes a virtual two-dimensional detector, a virtual angle rotation motor, and three virtual linear translation motors. The two-dimensional detector is used to simulate CT projection acquisition, the three linear translation motors simulate the three-dimensional positioning of the sample stage, and the angle rotation motors simulate the rotation axis of CT scanning, so as to realize the simulation of the experimental station equipment.

[0122] Step 2.1: Calibrate the virtual detector system parameters.

[0123] Based on the experimental type and requirements, update the EPICS PV values ​​of the virtual 2D detector: AcquireTime to 1s, TriggerMode to SoftTrigger, ImageMode to Single, Size_X to 1024, Size_Y to 1024, and NumImage to 1. Set the data source of the virtual 2D detector to CT simulation projection data based on the 3D Shepp-Logan model. Generate 180 2D projection images from 0° to 180° (step size 1°) using a projection calculation program, ensuring that the projection data is dynamically generated according to the angle sequence.

[0124] Step 2.2: Configure the parameters of the sample motion system.

[0125] Based on the assumption that the spot position is fixed at the origin (0, 0, 0) of the sample stage coordinate system, the actual position values ​​of the three-axis motors (X, Y, Z axes) of the sample stage are set to 0. The angle rotation motor serves as the CT rotation axis, and its limit range is set to ±185°, which is then set to the actual position of the CT starting point at 0°.

[0126] Step 3: Experiment Execution and Data Flow Control

[0127] Step 3.1: Scanning process arrangement and conversion.

[0128] Submit your Bluesky CT scan plan and set scan parameters through the user interface. This includes a rotation angle range of 0° to 180° and a step interval of 1°. The specific commands are as follows.

[0129] scan([virtual_detector],virtual_rotation_motor,0,180,180);

[0130] The Ophyd device abstraction layer parses it into a sequence of EPICS control commands, generating a motion trajectory containing 180 angle points. Each node is associated with a detector trigger signal to ensure the timing accuracy of "motion-exposure" (±1ms).

[0131] Step 3.2: Dynamic data collection and correlation.

[0132] After data acquisition begins, the Bluesky RunEngine executes the data acquisition task according to the established process. First, Ophyd sends stepping commands to the virtual rotary motor via the EPICS channel, while simultaneously reading the motor feedback values ​​in real time to ensure the accuracy of angle positioning. After each stepping angle stabilizes, the system triggers a soft acquisition command from the virtual detector. The detector simulation module calculates a 3D Shepp-Logan projection based on the current angle, generates simulated image data that meets the requirements, and transmits the data stream through the AreaDetector module. During this process, the system synchronously records device status information, including monochromator energy, slit opening and closing dimensions, and beam position signals, and associates this metadata with each frame of image.

[0133] Step 3.3: Data archiving and standardized storage.

[0134] After data acquisition, the system receives the detector data stream through the Bluesky interface. Each image frame triggers an event containing the original pixel array and related scanning parameters. This data is automatically reassembled and stored according to the HDF5 / NeXus standard structure. The raw data layer stores 180 projected images, forming a 180×1024×1024 three-dimensional dataset; the metadata layer records detailed information such as monochromator energy parameters, sample stage geometric position information, and historical data of slit process variables.

[0135] This embodiment verifies the technical feasibility of the virtual platform in beamline-level experimental simulation by reproducing the core features of optical control, precision motion, and temporal coordination in synchrotron radiation CT experiments. Its data output conforms to the synchrotron radiation experimental data standards and can directly support the subsequent development of reconstruction algorithms and optimization of experimental schemes.

[0136] Example 2: Historical data reproduction mode for XRD Mapping experiments.

[0137] like Figure 5 As shown, this embodiment focuses on the historical data reproduction scenario of the XRD Mapping experiment at a synchrotron radiation source. Based on efficient big data processing technology and a standardized equipment virtualization scheme, it achieves accurate replication of the real experimental process. The key focus is on verifying the technical advantages of the virtual platform in historical data parsing, high-fidelity equipment mapping, and low-latency data loading.

[0138] Step 1: Experimental Environment Deployment and Standardized Configuration

[0139] To ensure the system operates normally, the underlying technology stack needs to be built before system deployment, as follows:

[0140] (1) Python3 runtime environment: Python3 (version greater than 3.6.8) needs to be installed on the computer or server before system deployment.

[0141] (2) Control framework: Install and deploy the EPICS 7.0 basic environment and AreaDetector module;

[0142] (3) Python libraries: Install via pip, but not limited to Bluesky, Ophyd, NumPy, and other essential libraries;

[0143] (4) CUDA acceleration environment: Download the CUDA Toolkit installation package (.deb, .rpm or .exe) for the corresponding operating system from the NVIDIA website and install it on your computer;

[0144] (5) Storage configuration: The storage space is required to be ≥ 2.5 times the size of the historical dataset (including data cache and temporary files). For example, 100GB of historical data requires a 250GB or larger SSD storage to ensure the random access speed of the block data.

[0145] Step 2.1: Data standardization and parsing.

[0146] After importing the HDF5 / NeXus format data file of the XRD Mapping experiment, the efficient data management module of the data management layer performs structured parsing: the device configuration is identified by traversing the file / entry / instrument / directory, and the key parameters of the two linear motors (speed 5mm / s, soft limit ±100mm) are parsed from the X / Y sub-nodes under / entry / instrument / motor / . Based on the dimensions node value (1) in / entry / instrument / detector / , it is determined to be a 1DXRD detector (2048 channels, exposure time 100ms); at the same time, from / entry The experiment identifier (ExpID:XRD_20240510), acquisition time (2024-05-10 09:30:00), and beam energy (8keV) were extracted from the nodes in / entry / experiment / . A timestamp sequence containing 546 time nodes (intervals of 100ms) was obtained from / entry / measurement / timestamps. The two-dimensional scanning parameters (X-axis 0-10mm, step size 0.5mm, 21 points; Y-axis 0-5mm, step size 0.2mm, 26 points) were restored, and the scanning trajectory was determined to be a "serpentine path" (reciprocating on the X-axis and advancing line by line on the Y-axis), providing complete data basis for subsequent virtual device matching and process reproduction.

[0147] Step 2.2: Efficient loading via block-based memory mapping.

[0148] High-performance data loading is performed by the high-speed data processing module of the data management layer. The core technology adopts the "block index pre-building + memory mapping zero copy" solution, and the specific process is as follows:

[0149] Blocking strategy definition: Based on the Chunked Storage structure of HDF5 files (the original data block size is 128×2048, that is, 128 scan points × 2048 channels), a "timestamp-data block physical address" mapping table is pre-built, so that the target data can be located without traversing the entire file;

[0150] Memory mapping construction: The energy spectrum data block ( / entry / measurement / detector_data) in the HDF5 file is directly mapped to the cache address space of the virtual detector through the operating system's mmap function, realizing "zero copy reading" - data does not need to be copied from the disk to the memory buffer, the virtual detector can directly access the mapped address to obtain historical data, and the loading latency is reduced to less than 8ms (traditional full read latency >120ms).

[0151] Double-buffered pipeline scheduling: The "main thread data reproduction + background thread preloading" double-buffering mechanism is enabled. When the main thread processes the data of the current scan point (e.g., X=0mm / Y=0mm), the background thread synchronously preloads the next two data blocks (X=0.5mm / Y=0mm, X=1.0mm / Y=0mm). Combined with the circular sliding window cache (cache capacity of 10 data blocks), the continuity of data reproduction is ensured without any stuttering or interruption.

[0152] Step 3.1: Automatic device creation and parameter mapping.

[0153] First, two virtual linear motors are created to simulate the X-axis and Y-axis movement of the sample stage, respectively. The movement speed is set to 5 mm / s, and a soft limit protection of ±100 mm is configured. Simultaneously, the virtual XRD detector is initialized, the single-frame exposure time is set to 100 ms, and multi-frame acquisition mode is specified. Pre-loaded historical XRD energy dispersive spectroscopy data is bound to the virtual detector as a data source, ensuring that 2048 channels of data for the corresponding scan point can be read from the mapped address each time acquisition is triggered.

[0154] Step 3.2, Device communication verification.

[0155] Verify the PV accessibility of all virtual devices using the EPICS Channel Access protocol to ensure that the virtual device service has been started correctly.

[0156] Step 4.1: Reproduce the experimental procedure.

[0157] During the experimental reproduction phase, the XRD Mapping reproduction command is first submitted through the user interface. The system automatically parses the original scanning parameters stored in the historical data file, including key parameters such as the 2D scanning range (X-axis 0-10mm, Y-axis 0-5mm), step interval (X-axis 0.5mm, Y-axis 0.2mm), and acquisition time per point (100ms). Based on these parameters, the system generates the corresponding Bluesky reproduction plan, which includes a complete coordinate sequence extracted from the historical data.

[0158] The Ophyd device layer is responsible for translating the reproduction plan into specific EPICS process variable control instructions. Virtual X-axis and Y-axis motors progressively update the target position according to historical timelines, while the virtual XRD detector is bound to historical energy spectrum data as its data source. This step ensures that the device can accurately reproduce the motion trajectory and data acquisition process of the original experiment.

[0159] During the experiment, the Bluesky RunEngine operated strictly according to the timing control procedure. The virtual motor moved step by step to each target position via the EPICS channel protocol, and the system read the position feedback value in real time to ensure movement accuracy. After reaching each target position, the system sent a hardware trigger signal to the virtual detector, which then returned pre-stored XRD energy spectrum data. This data was output through the AreaDetector module.

[0160] Step 4.2: Data archiving and standardized storage.

[0161] After data acquisition is complete, the system will store all data in a structured manner according to the HDF5 / NeXus standard. The raw energy spectrum data is stored in the form of an N×2048 array in a specified path, and all relevant metadata, including motor coordinate history, original experimental identifiers, and other information, will be fully recorded.

[0162] This embodiment addresses the issue of loading latency for large scientific data through block-memory mapping technology. Combined with standardized equipment virtualization and timing reproduction logic, it achieves high-fidelity replication of XRD mapping experiments. Its technical solution focuses on the "efficiency, standardization, and scenario-based" requirements of scientific information processing, and can directly support compatibility testing and optimization of synchrotron radiation beamline data acquisition software.

[0163] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A virtual beamline software platform for advanced synchrotron radiation sources, characterized in that: The platform comprises a three-layer architecture: a user interaction layer, a virtual device layer, and a data management layer. It supports dual working modes: full simulation experiments based on physical models and data reproduction based on historical experimental datasets. The user interaction layer, implemented based on the Bluesky experimental control framework, is used for orchestrating experimental processes and sending control commands to the virtual device layer. The virtual device layer includes a virtual experimental station engine, a device virtualization module, a data simulation module, and a data reproduction module. The device virtualization module abstracts physical devices into input / output controller instances conforming to the EPICS standard. Each instance receives control commands and returns data through process variables. The data simulation module has a built-in high-fidelity physical model for generating simulation data in a full-simulation experimental mode. The data reproduction module loads and replays historical experimental datasets in data reproduction mode. The virtual experimental station engine schedules the device virtualization module according to the selected working mode, enabling it to obtain data from the data simulation module or the data reproduction module and respond to the upper layer through a unified process variable interface. The data management layer employs block reading and memory mapping technology for efficient storage and access of historical datasets.

2. The virtual beamline software platform for advanced synchrotron radiation sources according to claim 1, characterized in that, The experimental orchestration in the user interaction layer is specifically implemented by object-oriented encapsulation of the process variables PV of virtual devices through the Ophyd library. The encapsulation encapsulates the virtual detector as the VirtualAreaDetector class and includes a built-in dark current noise injection method, and encapsulates the virtual motor as the VirtualEpicsMotor class and supports homing difference parameter configuration. The encapsulated class establishes a two-way binding with the underlying PV through the EPICS Channel Access protocol, enabling Bluesky experimental orchestration commands to directly drive the virtual devices.

3. The virtual beamline software platform for advanced synchrotron radiation sources according to claim 1, characterized in that, The user interaction layer provides both graphical and programmatic interfaces for defining experimental parameters and procedures. In data reproduction mode, it can automatically parse the experimental time series metadata embedded in the historical dataset and generate the corresponding experimental instruction sequence.

4. The virtual beamline software platform for advanced synchrotron radiation sources according to claim 1, characterized in that, The physical devices abstracted by the device virtualization module include virtual detectors, virtual motors, and virtual optical devices; wherein, the virtual detectors include zero-dimensional detectors, one-dimensional detectors, and two-dimensional detectors, the virtual motors include linear translation motors and angular rotation motors, and the virtual optical devices include at least a virtual dual-crystal monochromator, a virtual electric four-blade slit, and a virtual beam position probe.

5. The virtual beamline software platform for advanced synchrotron radiation sources according to claim 1, characterized in that, The physical models embedded in the data simulation module include a two-dimensional elliptic Gaussian function model for simulating light intensity distribution and a three-dimensional projection integral model based on the Shepp-Logan model for simulating CT projection data. It can also inject Poisson noise into the generated simulation data to simulate the dark current of the detector.

6. The virtual beamline software platform for advanced synchrotron radiation sources according to claim 1, characterized in that, When loading and replaying historical experimental datasets, the data reproduction module performs the following operations: calls down to the high-speed data processing module of the data management layer to obtain the data stream optimized by block reading and memory mapping technology; automatically parses the experimental metadata and acquisition logic embedded in the historical experimental dataset file, and generates the corresponding data acquisition script to be uploaded to the user interaction layer; and drives the virtual device to execute the data reproduction process according to the original experimental time sequence.

7. The virtual beamline software platform for advanced synchrotron radiation sources according to claim 1, characterized in that, The data management layer includes an efficient data management module and a high-speed data processing module; The high-efficiency data management module is used to parse the metadata structure and device configuration information of the historical dataset, and the high-speed data processing module is used to perform high-performance data reading operations based on block indexing and memory mapping.

8. The virtual beamline software platform for advanced synchrotron radiation sources according to claim 1, characterized in that, The block reading and memory mapping technology of the data management layer specifically includes: pre-building a physical address mapping table of data blocks for HDF5 / NeXus files, implementing zero-copy data reading through the memory mapping function of the operating system, and using a double-buffered pipeline mechanism to pre-read subsequent data blocks to ensure the continuity of access.

9. The virtual beamline software platform for advanced synchrotron radiation sources according to claim 1, characterized in that, The experimental methods in the physical model-based full simulation experimental mode include: Prepare the runtime environment, deploy the basic software environment, and initialize the user interaction layer; The virtual device service starts, launching a virtual device instance and configuring parameters according to the experiment mode and type. Configure data acquisition tasks, define control parameters, acquisition scripts, and data saving settings; The virtual experiment process is executed by driving virtual devices to perform data acquisition operations according to the orchestration scheme, generating and storing simulation data in real time.

10. The virtual beamline software platform for advanced synchrotron radiation sources according to claim 1, characterized in that, The experimental method for reproducing dual working modes based on historical experimental datasets includes: Prepare the reproduction environment, deploy the basic software environment, and initialize the user interaction layer; Import historical data, loading historical datasets in HDF5 / NeXus format aligned by timestamps; Virtual device instance creation: Automatically create and initialize virtual devices of the corresponding type based on historical data characteristics; The data reproduction process is executed by automatically generating a collection script based on historical data, which drives the virtual device to reproduce the experimental process in the original time sequence.

Images