Accelerator tube full-process automatic reliability test system and device
By designing an automated reliability testing system for accelerator tubes, the problems of data silos and low automation in existing technologies have been solved, enabling efficient and safe accelerator tube testing and data analysis, and improving the reliability and collaboration of the testing system.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- BEIJING HUAQINGJIA HIGH ENERGY ELECTRONIC TECH CO LTD
- Filing Date
- 2025-11-21
- Publication Date
- 2026-08-04
AI Technical Summary
Existing accelerator tube testing platforms suffer from problems such as data silos, low automation, weak reliability analysis capabilities, difficulty in tracing and reproducing data, and poor collaboration, resulting in low testing efficiency and difficulty in conducting effective data analysis and fault prediction.
Design an automated reliability testing system for the entire accelerator tube process, including a control testing module, a hardware control module, a data acquisition and processing module, a business logic module, and a data persistence module. Test scripts are written in C#, and structured process configuration and syntax and semantic verification are performed to realize hardware control, data acquisition and storage, and provide a graphical user interface for monitoring and data display.
It improves testing efficiency and consistency, reduces human error, supports complex testing scenarios, ensures data consistency and security, enables reliable fault prediction and equipment status traceability, and enhances the automation level and data sharing capabilities of the testing system.
Smart Images
Figure CN121324879B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of high-power microwave device testing technology, specifically to an automated reliability testing system and apparatus for accelerator tubes. Background Technology
[0002] As a core component of medical linear accelerators, industrial non-destructive testing equipment, irradiation devices, and other equipment, the reliability, lifespan, and performance stability of electron linear accelerator tubes are of paramount importance. Traditional accelerator tube testing platforms typically rely on manual operation, local files, or handwritten data recording.
[0003] The existing technology has the following shortcomings:
[0004] (1) Data silos and poor consistency: Test data are scattered in different files with inconsistent formats, making it difficult to conduct effective horizontal comparisons and long-term trend analysis.
[0005] (2) Low level of automation: The testing process relies heavily on manual intervention, resulting in low testing efficiency and easy introduction of human error.
[0006] (3) Weak reliability analysis capability: lacks the ability to deeply mine massive historical test data, and cannot effectively establish fault prediction models and life assessment models.
[0007] (4) Difficulty in tracing and reproducing: When problems occur, it is difficult to quickly and accurately trace all the original data, environmental parameters and equipment status of a specific test, and it is impossible to accurately reproduce the test conditions.
[0008] (5) Poor collaboration: Data is difficult to share and analyze efficiently within the project team or between different departments.
[0009] The information disclosed in the background section is only intended to enhance the understanding of the background of this disclosure, and therefore may include information that does not constitute prior art known to those skilled in the art. Summary of the Invention
[0010] The purpose of this invention is to provide an automated reliability testing system and apparatus for accelerator tubes throughout the entire process, in order to solve the problems mentioned in the background art.
[0011] To achieve the above objectives, the present invention provides the following technical solution: an accelerator tube full-process automated reliability testing system, specifically including the following modules: a control testing module, a hardware control module, an acquisition and processing module, a business logic module, a data persistence module, and a user performance module;
[0012] Control Test Module: Write and execute automated reliability test scripts for accelerator tubes, and control the sequence of steps, conditions, and number of loops in the test scripts;
[0013] Hardware control module: Receives and executes hardware control commands, and uploads the device's raw analog / digital signals;
[0014] Acquisition and processing module: Communicates with the devices in the hardware control module, converts test script instructions into protocols that the devices can recognize, converts raw analog / digital signals into digital signals that can be processed by C# programs, and performs filtering, unit conversion, and validity verification on the digital signals;
[0015] Business logic module: Provides over-limit alarm function, provides a unified data access interface for upper layer applications, and sends structured test data to the data persistence layer;
[0016] Data persistence module: Stores all test-related data using a relational database;
[0017] User experience module: Provides test parameter configuration, real-time monitoring, alarm status, data logging, and dose rate curves based on a graphical user interface.
[0018] As a preferred embodiment of the fully automated reliability testing system for accelerator tubes described in this invention, wherein:
[0019] Write and execute automated reliability test scripts for accelerator tubes using the C# language;
[0020] The test flow of the script is established based on the structured description, including several test step nodes and the control relationships between nodes. The control relationships include sequential flow, parallel flow, conditional branching, loop control and timeout constraints.
[0021] The above test process is saved as structured data to the process configuration unit;
[0022] Read the process definition in the process configuration unit, and perform syntax parsing and semantic verification on process nodes, connection relationships and condition expressions;
[0023] If the syntax parsing and semantic verification find inconsistencies or potential dangers, a parsing error report is generated and the process is prevented from being scheduled and executed until the upper-level logic is corrected.
[0024] The test process is driven by the parsed node sequence and the node lifecycle is managed through event-driven mechanisms.
[0025] Nodes are activated sequentially according to the inter-node flow, and test script instructions for the corresponding device control are sent sequentially; after a node returns a successful response, the next sequential node is allowed to proceed.
[0026] When there are parallel branches in the test process, multiple child nodes are scheduled to execute simultaneously, and the subsequent process continues when all parallel branches meet the merging conditions.
[0027] When there are conditional branches in the test process, calculate the value of the conditional expression and select the corresponding subsequent branch based on the result;
[0028] When loop control exists in the test process, it specifically includes:
[0029] For loops with a set number of iterations, the loop counter is initialized to the preset number of iterations before execution. After each iteration, the counter is decremented. If the counter is not zero, the loop returns to the loop entry point and continues execution. If the counter is zero, the loop exits.
[0030] For conditional loops, the loop condition expression is re-evaluated according to the process at the end of each loop. If the condition is true, the loop continues; otherwise, it exits.
[0031] If any execution node fails to complete within the specified time, it will be entered into the failure handling path according to the node configuration.
[0032] Define multi-level exception strategies: immediate interruption (emergency shutdown), branch rollback (returning to the previous step or a safe node), retry, skipping the step and recording the risk;
[0033] Abnormal triggering conditions include node execution failure, timeout, device alarm signal, or violation of safety constraints; the process abnormality handling strategy is specified in the process definition stage and can be verified by the process parsing unit.
[0034] In the event of an exception that triggers a safety interruption, the engine should first execute a preset safety recovery sub-process to preserve the on-site data and issue an alarm.
[0035] As a preferred embodiment of the fully automated reliability testing system for accelerator tubes described in this invention, wherein:
[0036] Receive and execute hardware control instructions, wherein the instruction message structure includes, but is not limited to, operation type, target hardware identifier, execution timing, priority, and data acquisition instruction;
[0037] The received instructions are parsed and semantically verified. The verification includes instruction integrity, parameter range, target hardware reachability, availability of required resources, and security constraints.
[0038] For batch issuance of multiple instructions, the instructions are queued and sorted according to priority and timing requirements, an execution plan is generated and written to the local execution queue;
[0039] Establish a hardware abstraction layer to map the logical hardware identifiers in the instructions to specific physical interfaces and channels. The abstraction layer records the type, electrical parameters and connection status of each physical interface and channel.
[0040] During the mapping process, verify the current state and mutual exclusion relationship between the physical interface and the channel;
[0041] The parsed instructions are converted into specific driver operation sequences;
[0042] The analog / digital signals of the device under test are sampled according to the physical interface and channel, sampling rate, sampling accuracy and triggering conditions specified in the instructions.
[0043] For analog signals, a high-resolution analog-to-digital converter is used in conjunction with a front-end filter and anti-aliasing circuitry.
[0044] For digital signals, they are captured using a high-speed logic sampler or counter module.
[0045] As a preferred embodiment of the fully automated reliability testing system for accelerator tubes described in this invention, wherein:
[0046] Define a mapping table between hardware control command semantics and underlying device protocols. The mapping table contains the protocol format, field meaning, verification method, timeout and retransmission strategy, and priority information that each type of control command can recognize and the device.
[0047] The system receives hardware control commands and automated test scripts, performs semantic parsing on the commands, and generates command messages for the underlying devices according to the mapping table. The messages include a frame header, command code, parameter fields, timestamp, checksum, and frame trailer.
[0048] The raw analog / digital signals are received through the communication channel with the hardware control module;
[0049] After decoding, the corresponding original code value is written to the local buffer according to the channel identifier and timestamp;
[0050] The digitized analog signal is filtered, and the filtering algorithm can be selected according to the test requirements, such as finite impulse response filter, infinite impulse response filter, median filter, moving average, bandpass filter or adaptive filter, and the filter parameters can be switched or configured at runtime.
[0051] The decoded raw code value is converted according to the channel calibration coefficient. The conversion process includes zero-point correction, gain amplification correction, linear / nonlinear correction and temperature compensation, etc., to obtain the true value of the physical quantity.
[0052] The converted physical quantities are subjected to range verification, continuity verification, abrupt change detection, noise spectrum analysis and consistency verification to determine whether the data is valid;
[0053] The physical relationship between channels is verified. If an inconsistency is detected, it is marked as a suspected anomaly and the original data is recorded for subsequent review.
[0054] For data that is deemed abnormal or invalid, it will be automatically repaired and the records will be directly isolated according to the configuration, and all processing paths must leave unalterable audit traces.
[0055] As a preferred embodiment of the fully automated reliability testing system for accelerator tubes described in this invention, wherein:
[0056] The real-time display unit subscribes to data from a specified channel in the processed data stream and displays it on the interface in various forms, including waveforms, numerical values, statistical curves, alarm signs, and status panels.
[0057] The display should show the original signal, the filtered signal, and the converted physical quantities, and indicate the filtering delay, unit, sampling rate, and calibration version;
[0058] It provides trend predictions and historical comparisons, and highlights abnormal areas and trigger times on the interface.
[0059] As a preferred embodiment of the fully automated reliability testing device for the accelerator tube described in this invention, wherein:
[0060] The water chiller unit cools the acceleration pipe window, pipe body, target, magnetron, pulse transformer and four-terminal circulator;
[0061] The control modulation group specifically includes: a regulating motor, a hardware control module, a pulsed high voltage, and a three-phase power supply; the control modulation group is connected to the pulse transformer in the test group for voltage boosting;
[0062] The test group specifically includes: a pulse transformer, a magnetic filament power supply, a magnetron, a motor, a four-terminal circulator, an SF6 gas chamber, a titanium pump power supply, an electron gun power supply, and an acceleration tube.
[0063] The titanium pump power supply and electron gun power supply are connected to the acceleration tube. The titanium pump power supply is used to monitor the vacuum state, and the electron gun power supply provides the acceleration tube with the voltage, current and gun high voltage of the gun filament.
[0064] The magnetic filament power supply provides the voltage and current of the magnetic filament to the magnetron, which in turn provides microwaves to the accelerating tube, and the frequency of the magnetron is controlled by the motor.
[0065] The SF6 gas chamber uses SF6 as an inert medium in the testing process to reduce the probability of sparking during the output microwave process.
[0066] The test group is controlled by the control modulation group based on the fully automated reliability testing system of the accelerator tube, and the status is fed back to the control modulation group. All data is then transmitted to a relational database for storage.
[0067] On the other hand, the present invention provides a computer device including a memory and a processor, wherein the memory stores a computer program, wherein the computer program, when executed by the processor, implements a module of an accelerator tube fully automated reliability testing system as described above.
[0068] On the other hand, the present invention provides a computer-readable storage medium having a computer program stored thereon, wherein: when the computer program is executed by a processor, it implements a module of an accelerator tube fully automated reliability testing system as described above.
[0069] The technical effects and advantages provided by the present invention in the above technical solution are as follows:
[0070] (1) Integrate test script writing, process analysis, hardware distribution, data acquisition, signal processing, alarm processing, data storage and visualization into the same system to avoid information loss, timing misalignment and human error caused by manual connection of multiple systems, and improve test efficiency and consistency.
[0071] (2) By configuring the structured process and performing syntax and semantic checks before scheduling, inconsistencies or potential dangers can be detected and scheduling can be prevented before execution, reducing equipment damage and safety accidents caused by script errors or dangerous configurations.
[0072] (3) It supports sequential flow, parallel flow, conditional branching, count / conditional loop and timeout constraints, and can express complex test scenarios and test logic to meet various reliability test requirements;
[0073] (4) By mapping the hardware abstraction layer and control instructions to the underlying protocol, the differences between underlying devices are shielded, and mutual exclusion and interface status are checked during the mapping process to avoid hardware conflicts.
[0074] (5) Perform syntax and semantic checks, resource availability and target hardware reachability checks on the issued instructions, and generate execution plans according to priority and timing to ensure orderly and safe execution even in complex batch issuance scenarios;
[0075] (6) The original code value is converted to zero point / gain / nonlinearity / temperature compensation according to the channel calibration coefficient, and then range verification, continuity verification, mutation detection, noise spectrum and channel consistency verification are performed. This can effectively identify abnormal or invalid data and improve the reliability of test conclusions.
[0076] (7) All test process definitions, execution instances, node logs, issued instructions, raw sampling, processed data, alarms and audit records are centrally stored in a relational database. The correctness and consistency of reference between data can be ensured through transactions, foreign key constraints and integrity checks, avoiding data asynchrony or loss caused by scattered storage. Attached Figure Description
[0077] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this invention. For those skilled in the art, other drawings can be obtained based on these drawings.
[0078] Figure 1 This is a flowchart of the method for the fully automated reliability testing system for accelerator tubes according to the present invention.
[0079] Figure 2 This is a schematic diagram of the modules of the fully automated reliability testing system for the accelerator tube of the present invention.
[0080] Figure 3 This is a schematic diagram of the structure of the fully automated reliability testing device for the accelerator tube of the present invention. Detailed Implementation
[0081] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that the description of this disclosure will be more complete and fully convey the concept of the exemplary embodiments to those skilled in the art.
[0082] Example 1, referring to Figure 1 and Figure 2 This is the first embodiment of the present invention, which provides an automated reliability testing system for the entire process of an accelerator tube, specifically including the following modules: a control testing module, a hardware control module, a data acquisition and processing module, a business logic module, a data persistence module, and a user performance module;
[0083] Control Test Module: Write and execute automated reliability test scripts for accelerator tubes, and control the sequence of steps, conditions, and number of loops in the test scripts;
[0084] Write and execute automated reliability test scripts for accelerator tubes using the C# language;
[0085] The test flow of the script is established based on the structured description, including several test step nodes and the control relationships between nodes. The control relationships include sequential flow, parallel flow, conditional branching, loop control and timeout constraints.
[0086] Each test step node description should include at least: step identifier, step type (device control, wait, measurement, verification, recording, delay, sub-process call), input parameters and output parameters, execution timeout threshold, failure retry strategy and step priority;
[0087] It should also be noted that, for conditional branching and loop control, a conditional expression model that can express Boolean conditions and numerical comparisons is provided. The conditional expression can reference real-time sensor data, equipment status, historical test data snapshots, or internal variables of the process.
[0088] The above test process is saved as structured data (based on an intermediate representation of a tree or graph) to the process configuration unit;
[0089] Read the process definition in the process configuration unit, and perform syntax parsing and semantic verification on process nodes, connection relationships and condition expressions;
[0090] It should also be noted that static checks should be performed on the test scripts and processes, including but not limited to: the legality of entry and exit nodes, whether the loop has a termination condition, the coverage of condition branches, the existence of reference parameters, and the rationality of timeout and retry strategy configuration.
[0091] If the syntax parsing and semantic verification find inconsistencies or potential dangers (infinite loops, undefined variables, no exit branches), a parsing error report is generated and the process is prevented from being scheduled and executed until the upper-level logic is corrected.
[0092] The test process is driven by the parsed node sequence and the node lifecycle (preparation, execution, completion, failure, rollback) is managed through event-driven mechanisms.
[0093] Nodes are activated sequentially according to the inter-node flow, and test script instructions for the corresponding device control are sent sequentially; after a node returns a successful response, the next sequential node is allowed to proceed.
[0094] When there are parallel branches in the test process, multiple child nodes are scheduled to execute simultaneously, and the subsequent process continues when all parallel branches meet the merging conditions.
[0095] When there are conditional branches in the test process, calculate the value of the conditional expression and select the corresponding subsequent branch based on the result;
[0096] When loop control exists in the test process, it specifically includes:
[0097] For loops with a set number of iterations, the loop counter is initialized to the preset number of iterations before execution. After each iteration, the counter is decremented. If the counter is not zero, the loop returns to the loop entry point and continues execution. If the counter is zero, the loop exits.
[0098] For conditional loops, the loop condition expression is re-evaluated according to the process at the end of each loop. If the condition is true, the loop continues; otherwise, it exits.
[0099] If any execution node fails to complete within the specified time, it will be entered into the failure handling path according to the node configuration.
[0100] Define multi-level exception strategies: immediate interruption (emergency shutdown), branch rollback (returning to the previous step or a safe node), retry, skipping the step and recording the risk;
[0101] Abnormal triggering conditions include node execution failure, timeout, device alarm signal, or violation of safety constraints; the process abnormality handling strategy is specified in the process definition stage and can be verified by the process parsing unit.
[0102] In the event of an anomaly that triggers a safety interruption, the engine should first execute a preset safety recovery sub-process (such as power failure, trigger failure, high voltage shutdown, etc.), retain on-site data, and issue an alarm.
[0103] Hardware control module: Receives and executes hardware control commands, and uploads the device's raw analog / digital signals;
[0104] Receive and execute hardware control instructions, wherein the instruction message structure includes, but is not limited to, operation type, target hardware identifier, execution timing, priority, and data acquisition instruction;
[0105] The received instructions are parsed and semantically verified. The verification includes instruction integrity, parameter range, target hardware reachability, availability of required resources, and security constraints.
[0106] For batch issuance of multiple instructions, the instructions are queued and sorted according to priority and timing requirements, an execution plan is generated and written to the local execution queue;
[0107] A hardware abstraction layer is established to map the logical hardware identifiers in the instructions to specific physical interfaces and channels. The abstraction layer records the type (analog output, analog input, digital output, digital input, high voltage output, low voltage trigger, relay control, servo drive, etc.), electrical parameters, and connection status of each physical interface and channel.
[0108] During the mapping process, the current state and mutual exclusion relationship of the physical interface and channel are verified to avoid executing instructions that may cause hardware conflicts (such as driving the same voltage output to different values at the same time).
[0109] The parsed instructions are converted into specific drive operation sequences, including setting analog output voltage or current, switching digital signal levels, triggering relays, starting or stopping external power supplies, setting signal generator parameters, and controlling the switch quantity acquisition module.
[0110] The analog / digital signals of the device under test are sampled according to the physical interface and channel, sampling rate, sampling accuracy and triggering conditions specified in the instruction. The sampling methods include periodic sampling, event-triggered sampling and synchronous sampling.
[0111] For analog signals, a high-resolution analog-to-digital converter is used in conjunction with a front-end filter and anti-aliasing circuitry.
[0112] For digital signals, they are captured using a high-speed logic sampler or counter module.
[0113] Acquisition and processing module: Communicates with the devices in the hardware control module, converts test script instructions into protocols that the devices can recognize, converts raw analog / digital signals into digital signals that can be processed by C# programs, and performs filtering, unit conversion, and validity verification on the digital signals;
[0114] Define a mapping table between hardware control command semantics and underlying device protocols. The mapping table contains the protocol format, field meaning, verification method, timeout and retransmission strategy, and priority information that each type of control command can recognize and the device.
[0115] The system receives hardware control commands and automated test scripts, performs semantic parsing on the commands, and generates command messages for the underlying devices according to the mapping table. The messages include a frame header, command code, parameter fields, timestamp, checksum, and frame trailer.
[0116] The raw analog / digital signals are received through the communication channel with the hardware control module;
[0117] After decoding, the corresponding original code value is written to the local buffer according to the channel identifier and timestamp;
[0118] The digitized analog signal is filtered, and the filtering algorithm can be selected according to the test requirements, such as finite impulse response filter, infinite impulse response filter, median filter, moving average, bandpass filter or adaptive filter, and the filter parameters can be switched or configured at runtime.
[0119] The decoded raw code value is converted according to the channel calibration coefficient. The conversion process includes zero-point correction, gain amplification correction, linear / nonlinear correction and temperature compensation, etc., to obtain the true value of physical quantities (voltage, current, pressure, temperature).
[0120] Unit conversion supports the exchange between the International System of Units (SI) and other engineering units, and clearly records the unit type and conversion formula in the data element information to ensure that it can be used directly in the backend analysis.
[0121] For channels requiring high-precision conversion, interpolation or lookup table methods are supported for non-linear conversion, and the lookup table version and interpolation method are recorded for traceability.
[0122] The converted physical quantities are subjected to range verification, continuity verification, abrupt change detection, noise spectrum analysis and consistency verification to determine whether the data is valid;
[0123] Verify the physical relationship between channels (the correspondence between current and voltage). If an inconsistency is detected, mark it as a suspected anomaly and record the original data for subsequent review.
[0124] For data that is deemed abnormal or invalid, it will be automatically repaired and the records will be directly isolated according to the configuration, and all processing paths must leave unalterable audit traces.
[0125] Business logic module: Provides over-limit alarm function, provides a unified data access interface for upper layer applications, and sends structured test data to the data persistence layer;
[0126] Data persistence module: Stores all test-related data using a relational database;
[0127] User experience module: Provides test parameter configuration, real-time monitoring, alarm status, data logging, and dose rate curves based on a graphical user interface;
[0128] The real-time display unit subscribes to data from a specified channel in the processed data stream and displays it on the interface in various forms, including waveforms, numerical values, statistical curves, alarm signs, and status panels.
[0129] The display should show the original signal, the filtered signal, and the converted physical quantities, and indicate the filtering delay, unit, sampling rate, and calibration version to facilitate operators in quickly determining the data source and reliability.
[0130] It provides trend predictions and historical comparisons, and highlights abnormal areas and trigger times on the interface. Example
[0131] The following is another embodiment of the present invention, which provides an automated reliability testing system for the entire process of accelerator tubes. In order to verify the beneficial effects of the present invention, a simulation experiment is conducted for scientific demonstration.
[0132] Define 10 template processes (including sequential, parallel, conditional branch, loop with multiple iterations, conditional loop, and timeout), each process containing 8–30 nodes;
[0133] Prepare 5 types of equipment, each type containing 4 channels (analog channels + digital channels), for a total of 20 analog channels and 20 digital channels;
[0134] The sampling modes are divided into: normal mode (10Hz / channel), high frequency mode (1kHz / channel) and transient capture (10kHz, short time period).
[0135] Each test run lasts 60–600 seconds, and the overall simulation lasts 24 hours to simulate long-term stability.
[0136] Three types of anomalies (mutation noise, equipment response timeout, and equipment alarm arcing events) are injected, with each type of event distributed on average twice per hour during the simulation process.
[0137] Five experimental scenarios are defined, including:
[0138] Normal load scenario (low concurrency): single process concurrency is 1, sampling rate is 10Hz / channel, lasting for 24 hours;
[0139] Concurrent scenario (medium concurrency): 10 processes are executed concurrently, with a sampling rate of 100Hz / channel, for 6 hours;
[0140] Stress scenario (high concurrency + high frequency sampling): 50 processes run concurrently, sampling rate 1kHz / channel, for 2 hours;
[0141] Long-term archiving scenario: Evaluate the performance of archiving and partitioning operations when a large number of data collection events are generated within 24 hours.
[0142] Replay / Reproduce Scenario: Perform historical replay and reproduction verification of the 50 injected abnormal events.
[0143] Compared to A: raw_sample is only written to the file system CSV / binary file, while process / alarm is written to the relational database. Replay requires merging file and database data.
[0144] Comparison B: Write all data to the database using a non-transactional batch insert method, and do not establish an audit hash chain;
[0145] Compare with C: Write raw_sample to a dedicated time-series database, and write process / alarm / audit data to a relational database, and compare the impact of hybrid storage on querying and playback;
[0146] After the testing process was initiated, the data integrity of control group A was 99.80% ± 0.15%, the data integrity of control group B was 98.60% ± 0.5%, the data integrity of control group C was 99.90% ± 0.05%, while the data integrity of the present invention was 99.995% ± 0.002%.
[0147] The consistency error count for control group A was 25, the consistency error count for control group B was 11, the consistency error count for control group C was 3, while the data integrity count for this invention was 1.
[0148] The average single-channel time window query latency of control group A was 850ms ± 120ms, that of control group B was 140ms ± 40ms, that of control group C was 95ms ± 25ms, and that of the present invention was 120ms ± 30ms.
[0149] By integrating test script writing, process parsing, hardware deployment, data acquisition, signal processing, alarm handling, data storage and visualization into the same system, information loss, timing misalignment and human error caused by manual connection of multiple systems can be avoided, thereby improving test efficiency and consistency.
[0150] By configuring structured processes and performing syntax and semantic checks before scheduling, inconsistencies or potential dangers can be detected and scheduling can be prevented before execution, reducing equipment damage and safety incidents caused by script errors or dangerous configurations.
[0151] It supports sequential flow, parallel flow, conditional branching, count / conditional loop and timeout constraints, and can express complex test scenarios and experimental logic to meet various reliability testing needs.
[0152] By using a hardware abstraction layer and a mapping table from control commands to underlying protocols, the differences between underlying devices are shielded, and mutual exclusion and interface status are checked during the mapping process to avoid hardware conflicts.
[0153] The system performs syntax and semantic checks, resource availability and target hardware reachability checks on the issued commands, and generates execution plans according to priority and timing to ensure orderly and safe execution even in complex batch issuance scenarios.
[0154] The original code value is converted to zero point / gain / nonlinearity / temperature compensation according to the channel calibration coefficient. Then, range verification, continuity verification, mutation detection, and noise spectrum and channel consistency verification are performed. This can effectively identify abnormal or invalid data and improve the reliability of test conclusions.
[0155] All test process definitions, execution instances, node logs, issued instructions, raw sampling, processed data, alarms, and audit records are centrally stored in a relational database. Transactions, foreign key constraints, and integrity checks can ensure the correctness and consistency of references between data, avoiding data asynchrony or loss caused by scattered storage.
[0156] The foregoing has only described certain exemplary embodiments of the present invention by way of illustration. Undoubtedly, those skilled in the art can modify the described embodiments in various ways without departing from the spirit and scope of the present invention. Therefore, the foregoing drawings and descriptions are illustrative in nature and should not be construed as limiting the scope of protection of the claims of the present invention.
Claims
1. An automated reliability testing system for accelerator tubes, characterized in that, Specifically, it includes the following modules: control testing module, hardware control module, data acquisition and processing module, business logic module, data persistence module, and user performance module; Control Test Module: Write and execute automated reliability test scripts for accelerator tubes, and control the sequence of steps, conditions, and number of loops in the test scripts; The control test module uses C# language to write and execute automated reliability test scripts for the accelerator tube. Establish the test flow for this script based on the structured description; The above test process is saved as structured data to the process configuration unit; Read the process definition in the process configuration unit, and perform syntax parsing and semantic verification on process nodes, connection relationships and condition expressions; The test process is driven by the parsed node sequence and the node lifecycle is managed through event-driven mechanisms. Activate nodes sequentially according to the inter-node flow, and send the corresponding device control test script instructions sequentially. After a node returns a successful response, proceeding to the next sequential node is allowed; When there are parallel branches in the test process, multiple child nodes are scheduled to execute, and the subsequent test process continues when all parallel branches meet the merging conditions. When there are conditional branches in the test process, calculate the value of the conditional expression and select the corresponding subsequent branch based on the result; When loop control exists in the test process, it specifically includes: For loops with multiple iterations, the loop counter is initialized to a preset number of iterations before execution. After each loop, the counter is decremented. If the counter is not zero, the loop entry is returned to continue execution. If the counter is zero, the loop is exited. For conditional loops, the loop condition expression is re-evaluated according to the process at the end of each loop. If the condition is true, the loop continues; otherwise, it exits. If any execution node fails to complete within the specified time, it will be entered into the failure handling path according to the node configuration. Define multi-level exception strategies: immediate interruption, branch rollback, retry, skipping the step and recording the risk; For any exceptions that trigger a safety interruption, execute the pre-defined safety recovery sub-process, retain the on-site data, and issue an alarm; Hardware control module: Receives and executes hardware control commands, and uploads the device's raw analog / digital signals; The hardware control module receives and executes hardware control commands; Perform syntax parsing and semantic verification on the received instructions; For batch issuance of multiple instructions, the instructions are queued and sorted according to priority and timing requirements, an execution plan is generated and written to the local execution queue; Establish a hardware abstraction layer to map the logical hardware identifiers in the instructions to specific physical interfaces and channels. The abstraction layer records the type, electrical parameters and connection status of each physical interface and channel. During the mapping process, verify the current state and mutual exclusion relationship between the physical interface and the channel; The parsed instructions are converted into specific driver operation sequences; The analog / digital signals of the device under test are sampled according to the physical interface and channel, sampling rate, sampling accuracy and triggering conditions specified in the instructions. Acquisition and processing module: Communicates with the devices in the hardware control module, converts test script instructions into protocols that the devices can recognize, converts raw analog / digital signals into digital signals that can be processed by C# programs, and performs filtering, unit conversion, and validity verification on the digital signals; The acquisition and processing module defines a mapping table between hardware control command semantics and underlying device protocols; It receives hardware control commands and automated test scripts, performs semantic parsing on the commands, and generates command messages for the underlying devices according to the mapping table. The system receives the processed raw analog / digital signals through the communication channel with the hardware control module and performs frame verification, field decoding, and error detection. After decoding, the corresponding original code value is written to the local buffer according to the channel identifier and timestamp; The physical relationship between channels is verified. If an inconsistency is detected, it is marked as a suspected anomaly and the corresponding original analog / digital signal is recorded. The system is automatically repaired according to the configuration and the record is directly isolated. All processing paths are marked with unalterable audit traces. Business logic module: Provides over-limit alarm function, provides a unified data access interface for upper layer applications, and sends structured test data to the data persistence layer; Data persistence module: Stores all test-related data using a relational database; User experience module: Provides test parameter configuration, real-time monitoring, alarm status, data logging, and dose rate curves based on a graphical user interface.
2. The fully automated reliability testing system for accelerator tubes according to claim 1, characterized in that: The user performance module, in real time, subscribes to data from a specified channel in the processed data stream and displays it on the interface in various forms, including waveforms, values, statistical curves, alarm signs, and status panels. The display should show the original signal, the filtered signal, and the converted physical quantities, and indicate the filtering delay, unit, sampling rate, and calibration version; It provides trend predictions and historical comparisons, and highlights abnormal areas and trigger times on the interface.
3. An automated reliability testing device for an accelerator tube, comprising a water turbine unit, a control and modulation unit, and a testing unit, characterized in that: The water chiller unit cools the acceleration pipe window, pipe body, target, magnetron, pulse transformer and four-terminal circulator; The control modulation group specifically includes: a regulating motor, a hardware control module, a pulsed high voltage, and a three-phase power supply; the control modulation group is connected to the pulse transformer in the test group for voltage boosting; The test group specifically includes: a pulse transformer, a magnetic filament power supply, a magnetron, a motor, a four-terminal circulator, an SF6 gas chamber, a titanium pump power supply, an electron gun power supply, and an acceleration tube. The titanium pump power supply and electron gun power supply are connected to the acceleration tube. The titanium pump power supply is used to monitor the vacuum state, and the electron gun power supply provides the acceleration tube with the voltage, current and gun high voltage of the gun filament. The magnetic filament power supply provides the voltage and current of the magnetic filament to the magnetron, which in turn provides microwaves to the accelerating tube, and the frequency of the magnetron is controlled by the motor. The SF6 gas chamber uses SF6 as an inert medium in the testing process to reduce the probability of sparking during the output microwave process. The control modulation group controls the test group according to the module of the fully automated reliability test system for accelerator tubes as described in claim 1, feeds back the status to the control modulation group, and transmits all data to a relational database for storage.
4. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, it implements the module of the fully automated reliability testing system for the accelerator tube as described in any one of claims 1 to 2.
5. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, it implements the module of the fully automated reliability testing system for accelerator tubes as described in any one of claims 1 to 2.