Intelligent Beidou equipment parallel detection and maintenance system

Abstract

The invention relates to the technical field of equipment detection and maintenance, in particular to an intelligent Beidou equipment parallel detection and maintenance system, and aims to solve the problems that protocol adaptation is rigid, parallel scheduling is unreasonable, fault diagnosis has no self-evolution ability, and data security is insufficient in the prior art. The system comprises a three-proofing tablet hardware carrier with a hardware compatibility adaptation layer and maintenance software integrated with a multi-creative module, automatic adaptation of a newly-customized protocol is achieved through a protocol adaptive learning engine, multi-machine parallel stability is guaranteed by adopting dynamic core scheduling and resource elastic allocation, the fault diagnosis accuracy is improved based on an FT-BN self-evolution mechanism, and the fault diagnosis efficiency is improved. The application scene is broadened in combination with cloud edge collaborative backup and an offline multi-mode interaction suite, and the maintenance process is optimized through a multi-fault conflict resolution algorithm and a visual auxiliary verification module. The system supports parallel access of multiple Beidou devices, realizes zero-basis precise maintenance, is adaptive to multiple models and multiple protocols, and has the advantages of high efficiency, reliability and universality in military Beidou device maintenance.

Description

Technical Field

[0001] This invention relates to the field of equipment testing and maintenance technology, specifically an intelligent parallel testing and maintenance system for BeiDou equipment. Background Technology

[0002] As core support equipment for military operations and national defense, BeiDou equipment plays an irreplaceable role in key scenarios such as positioning and navigation, emergency communication, and precise timing. With the continuous upgrading of the BeiDou system, the model iteration speed of BeiDou equipment has accelerated, and a multi-generational equipment system covering BeiDou-1, BeiDou-2, and BeiDou-3 has been formed. At the same time, various military manufacturers have launched a large number of special equipment with customized protocols according to specific combat needs, resulting in a complex situation in the technical status of equipment, characterized by "many models, complex protocols, different components, and low standardization".

[0003] The existing BeiDou equipment maintenance technology has several prominent problems: First, the protocol adaptation capability is rigid. Existing testing tools can only adapt to a few preset standard protocols and cannot recognize customized protocols from new manufacturers. Manual parsing programs are required, resulting in long adaptation cycles and high costs, severely hindering the rapid formation of combat capability for newly deployed equipment. Second, the parallel testing scheduling is unreasonable. The existing system uses a fixed core allocation mode, with a fixed ratio of core allocation for complex and simple tasks. When multiple pieces of equipment perform complex testing tasks simultaneously, CPU core resource shortages easily occur, leading to testing lag. Conversely, when simple tasks fill the cores, resources are wasted, resulting in low batch testing efficiency. Third, fault diagnosis lacks self-evolution capabilities. Existing fault diagnosis models rely on initial experimental statistical data and cannot identify new faults caused by equipment aging or environmental changes. Diagnostic accuracy gradually decreases with usage time, and the fault tree structure is fixed and cannot be dynamically expanded. Fourth, data storage and backup have shortcomings. The existing dual-database architecture suffers from low log write rates when five pieces of equipment are under full load. The system suffers from several drawbacks. First, it approaches the InfluxDB limit, and the overlay of maintenance operation logs can easily lead to write blockages. Furthermore, it relies solely on local storage without off-site backup, meaning critical maintenance data and fault cases will be permanently lost if the rugged tablet is damaged. Second, it has poor environmental adaptability. The existing system's voice and 3D model rendering functions depend on a network environment, making it unusable in remote, mountainous, or other network-free operational scenarios, causing maintenance interruptions. Third, it suffers from conflicting maintenance procedures for multiple faults. When multiple faults occur simultaneously, the existing system can only generate maintenance steps in a fixed order, without considering the dependencies between faults and the correlation between components, easily leading to conflicting maintenance steps and secondary damage. Fourth, it suffers from insufficient hardware compatibility. The existing system relies on specific configurations of rugged tablets; replacing them with tablets of different brands or batches reduces the stability of serial port data conversion and DMA transmission, and may even prevent communication from being established. Fifth, it lacks verification for non-reproducible faults. For structural component faults such as damaged antenna covers or malfunctioning silicone buttons, the system relies solely on the subjective judgment of maintenance personnel, which can easily lead to misjudgments and distorted knowledge base data.

[0004] Furthermore, existing maintenance tools still suffer from high learning curves and complex operation. Most testing equipment requires extensive training for specialized technicians to use proficiently, but grassroots maintenance units generally lack highly skilled professionals. This results in a large number of faulty equipment failing to be repaired in a timely manner, impacting the equipment's operational readiness rate. Therefore, developing a parallel testing and maintenance system for BeiDou equipment with high compatibility, high intelligence, high reliability, and strong environmental adaptability has become an urgent need to solve the current challenges in BeiDou equipment maintenance. Summary of the Invention

[0005] To address the problems in existing BeiDou equipment testing and maintenance technologies, such as rigid protocol adaptation, unreasonable parallel scheduling, lack of self-evolving fault diagnosis capabilities, insufficient data security, poor environmental adaptability, conflicting repairs of multiple faults, weak hardware compatibility, and missing verification of non-reproducible faults, this invention integrates multiple innovative technologies to construct an externally intelligent, universal, and self-evolving parallel testing and maintenance system. This system requires no changes to the internal structure and protocols of BeiDou equipment, can automatically adapt to multiple models and protocols of equipment, achieve efficient parallel testing of multiple machines, dynamically optimize fault diagnosis models, provide full-scenario maintenance guidance, ensure data security, lower the maintenance threshold, and ensure that even personnel with no prior experience can accurately and quickly complete equipment repairs, thereby improving the operational readiness rate of BeiDou equipment.

[0006] The technical solution adopted by the present invention to solve its technical problem is: an intelligent parallel testing and maintenance system for Beidou equipment, including a rugged tablet hardware carrier and intelligent maintenance software for Beidou equipment;

[0007] The rugged tablet is equipped with the domestic Galaxy Kylin operating system, has a hardware compatibility adaptation layer, multiple communication interfaces and 3 aviation plug interfaces, and the RS232 aviation plug interface can be converted to 5 serial ports, supporting the parallel access of 5 Beidou equipment, with each serial port baud rate of 1200-115200bps.

[0008] The maintenance software includes a serial port automatic detection and communication module, an equipment fault detection module, a maintenance operation guidance module, a data storage module, a human-computer interaction module, a protocol adaptive learning engine, and a vision-assisted verification module. It achieves intelligent task allocation through a heterogeneous computing architecture of multi-core CPU and GPU, dynamic core scheduling, and resource elastic allocation algorithms. It uses a "Fault Tree-Bayes Network (FT-BN)" fusion engine and a self-evolution mechanism to locate faults. It provides operation guidance through multimodal interaction and offline suites, and combines cloud-edge collaborative backup and hierarchical storage to ensure data security.

[0009] The serial port automatic detection and communication module has a built-in standard protocol library and protocol adaptive learning engine. The maintenance operation guidance module integrates a multi-fault conflict resolution algorithm. The visual auxiliary verification module verifies the repair status of structural components through image recognition.

[0010] Specifically, the protocol adaptive learning engine includes a protocol feature extraction unit, a frame structure parsing unit, and a learning model training unit. By capturing unknown protocol data frames, it extracts start symbols, verification rules, and data segment format features, trains parsing functions based on a CNN deep learning model, automatically binds equipment identifiers, and updates the protocol library without manual intervention to adapt to new customized protocols.

[0011] Core parameters for training CNN models:

[0012] CNN model architecture: It adopts a 3-layer convolutional layer + 2-layer fully connected layer architecture, including 1 max pooling layer (located after the 2nd convolutional layer, with a 2×2 pooling kernel) and 1 dropout layer (dropout probability 0.2, located after the 1st fully connected layer); the 1st to 3rd convolutional layers use 3×3, 3×3, and 5×5 convolutional kernels respectively, with 16, 32, and 64 kernels respectively, and a stride of 1 for all layers; the activation function of the convolutional layers is ReLU, and the activation function of the output layer is Softmax (used for protocol field classification).

[0013] Input and output dimensions: The input features are quantized 128-dimensional vectors (8-dimensional start symbol encoding, 32-dimensional check rule encoding, and 88-dimensional data segment format feature encoding), and the output is a 16-dimensional parsing result vector (corresponding to 16 key parameters such as the start bit, data bit, and check bit of the frame structure).

[0014] Training sample requirements: At least 1000 training frames must cover 5 baud rates (1200 / 9600 / 38400 / 57600 / 115200bps), 3 checksum methods (CRC16 / parity check / no checksum), and 4 frame lengths (64 / 128 / 256 / 512 bytes), with each scenario accounting for 20% of the samples; sample preprocessing must include mean filtering (3×3 window) for noise reduction and normalization within the [0,1] range; missing / erroneous frames (≤5%) should be filled using linear interpolation; feature annotation is automatically completed through "frame header matching + reverse verification of checksums," with an annotation accuracy ≥99%.

[0015] Training parameter settings: Adam optimizer (β1=0.9, β2=0.999, ε=1e-8), initial learning rate 0.001, decaying to 0.5 every 20 iterations; loss function is cross-entropy loss function, loss value convergence threshold is 0.01; batchsize=32, iteration stopping condition is "loss value ≤0.01 or 100 iterations (preferably the former)";

[0016] Training objectives and evaluation criteria: The parsing function must achieve frame synchronization (start character recognition accuracy ≥ 99%), field extraction (address / data bit extraction accuracy ≥ 98%), and verification (verification result judgment accuracy 100%). The training set:verification set ratio is 8:2. A verification set parsing accuracy ≥ 95% is considered a successful training result. The accuracy calculation formula is "(number of correctly parsed frames / total number of verification frames) × 100%".

[0017] Specifically, the dynamic core scheduling and resource elastic allocation algorithm dynamically adjusts the number of cores allocated based on the real-time task complexity evaluation value and CPU core utilization rate, sets up a core resource pool and a backup queue, and uses a time slice round-robin mechanism to allocate cores when equipment of the same priority requests resources.

[0018] Task complexity quantification formula: Task complexity Where D represents the task data size level (unit: KB, D=1 corresponds to ≤10KB, D=2 corresponds to 10<D≤100KB, D=3 corresponds to >100KB), K represents the number of calculation steps level (K=1 corresponds to ≤5 steps, K=2 corresponds to 5<K≤10 steps, K=3 corresponds to >10 steps); S ranges from 1 to 6, where 1-2 represents simple tasks, 3-4 represents medium tasks, and 5-6 represents complex tasks.

[0019] Core allocation rules: Simple tasks (S=1-2) are allocated 1 CPU core, medium tasks (S=3-4) are allocated 2 CPU cores, and complex tasks (S=5-6) are allocated 3 CPU cores; the core resource pool occupies 20% of the total number of CPU cores (e.g., 2 cores for an 8-core CPU, 2 cores for a 10-core CPU) to cope with sudden increases in task complexity; the maximum length of the spare queue is 5. When the queue length exceeds 5, core resources for low-priority tasks (sorted by "equipment detection urgency," with non-combat-urgent equipment tasks having lower priority than combat-urgent equipment tasks) are released first to ensure the execution of high-priority tasks;

[0020] Time slice rotation parameters: The time slice length of equipment with the same priority is uniformly set to 50ms. A single task can occupy a maximum of 2 time slices consecutively (to avoid long-term monopoly of cores); if a task is not completed after its time slice is used up, it will automatically enter the tail of the queue to re-queue and wait for the next round of time slice allocation; the core utilization rate is monitored in real time at an interval of 100ms. When the utilization rate of a certain core is ≥90% for 3 consecutive times, the resource pool core scheduling is triggered (1 core is allocated from the resource pool to assist the task).

[0021] Specifically, the FT-BN self-evolution mechanism includes a fault case collection unit, a probability update unit, and a fault tree expansion unit. It automatically collects new fault cases, updates the Bayesian network conditional probability table after manual review, adds bottom event nodes, and optimizes the fault tree logical relationship.

[0022] Fault Case Collection Specifications: The collection scope includes raw RNSS / RDSS data (sampling frequency 1Hz, including positioning coordinates, number of satellites, signal strength, etc.) at the time of equipment failure, description of fault phenomena (such as "positioning drift > 10m" "RDSS communication interruption"), maintenance operation records (replacement part model, disassembly steps, tool model), and repair results (retested positioning accuracy, communication success rate, etc.); the case format adopts the JSON standard format, and the required fields are "Equipment ID (string, such as 'BD-20240501-001'), Fault Time (timestamp, accurate to the second), Fault Type (enumeration, such as 'power failure' 'antenna failure'), Data Fields (dictionary, storing raw RNSS / RDSS data), Maintenance Fields (dictionary, storing maintenance operations), and Result Fields (dictionary, storing retested data)".

[0023] Bayesian network probability adjustment formula: Conditional probability update formula is ,in The conditional probability of "Event A occurs when Event B occurs" before the update is given, where N is the total number of similar historical cases, and C is the number of times "A occurs when B occurs" in the new case (C=1 indicates that it has occurred, and C=0 indicates that it has not occurred). The updated probability is rounded to 3 decimal places. If it is the first occurrence of the "B→A" causal relationship, the initial probability is set to 0.6 (based on the industry failure statistics average), and the initial value of N is 10 (the number of virtual historical cases).

[0024] Fault tree expansion logic: Newly added bottom event nodes must satisfy the condition of "having a direct physical / logical causal relationship with the parent node" (e.g., "RF module failure" as a child node of "RDSS signal abnormality" requires verification of the physical logic that "RF module damage will cause RDSS received signal power < -120dBm, thereby causing communication interruption"); Newly added nodes must be verified by more than 2 similar cases, and the case verification pass rate (number of cases where "the newly added child node also occurs when the parent node occurs" / total number of verified cases) ≥ 90% can be included in the fault tree; After expansion, the logical relationship expression needs to be optimized, such as "RDSS signal abnormality = surrounding obstruction ∨ main control board failure ∨ antenna failure ∨ RF module failure".

[0025] Specifically, the data storage module adopts a cloud-edge collaborative backup and hierarchical storage architecture. The edge InfluxDB stores real-time detection logs, the DM8 stores recent maintenance data, and the cloud synchronously backs up all data, using a hot data caching and cold data archiving strategy.

[0026] Specifically, the human-computer interaction module integrates an offline multimodal interaction suite, pre-stores 3D models, images, voice packs and maintenance videos, and automatically switches to offline mode in the absence of network environment to maintain a rendering frame rate of more than 30fps.

[0027] Specifically, the multi-fault conflict resolution algorithm constructs a priority matrix based on fault severity, maintenance operation dependency, and component correlation to reorder the maintenance steps of conflicting faults;

[0028] Fault Severity Quantification Standard: Faults are classified into 10 levels (1-10 points) based on their impact on the core functions of the equipment, with the following weights: 10 points (Power failure, causing the equipment to fail to power on and completely lose its function) → Weight 0.4; 8-9 points (Abnormal RDSS signal / positioning drift > 10m, loss of core communication / positioning functions) → Weight 0.35; 5-7 points (Loose interface / button jamming, affecting data transmission / operation, partial damage to core functions) → Weight 0.3; 1-4 points (Scene scratches / indicator light failure, not affecting core functions) → Weight 0.25; The scoring is based on the "Beidou Equipment Fault Level Classification Standard (GJB XXX-2024)".

[0029] Determination of maintenance operation dependencies: If maintenance step A must be completed before maintenance step B can be executed (e.g., "removing the power module (A)" is required before "repairing the main control board interface (B)", denoted as A→B), then A and B have a mandatory dependency relationship; Dependency weight assignment: mandatory dependency exists (A→B or B→A) → weight 0.3; no dependency relationship → weight 0; The determination of dependency relationship is based on the step sequence requirements in the "Beidou Equipment Maintenance Operation Manual (Q / XX 001-2024)";

[0030] Component correlation calculation: The "component overlap" quantification is adopted, and the formula is: Component correlation = (number of common components involved in the two faults / total number of components involved in the two faults) × 0.3; where "components involved in the fault" refers to the components that need to be disassembled / replaced to repair the fault. For example, "power supply fault" involves "power module", and "loose main control board interface" involves "main control board and power module". Then the number of common components in the two faults = 1, the total number of components involved = 2 (power module and main control board), and the component correlation = (1 / 2) × 0.3 = 0.15;

[0031] Priority calculation method: The priority of a single fault = fault severity weight + dependency weight (if there is a dependency, take the priority propagation value of the dependent fault; if there is no dependency, it is 0) + component correlation weight; sort by priority from high to low to generate conflict-free maintenance steps.

[0032] Specifically, the hardware compatibility adaptation layer includes an interface conversion driver, a level adaptation unit, and a performance adaptation module, which are compatible with the serial port chips and CPU / GPU configurations of different brands / batch of rugged tablets.

[0033] Specifically, the visual-assisted verification module uses the YOLOv8 target detection algorithm to collect images of structural component repairs through a rugged tablet camera, compares them with standard images, and outputs objective verification results.

[0034] YOLOv8 algorithm configuration: The YOLOv8-nano lightweight model is used (adapted to the computing power of rugged tablets, model size ≤ 10MB). The input image resolution is fixed at 640×640 pixels (adapted to the original captured image through image scaling and padding). The confidence threshold is set to 0.5 (filtering detection boxes with confidence < 0.5 to avoid false recognition), and the IOU (Intersection over Union) threshold is set to 0.6 (when two detection boxes have an IOU ≥ 0.6, they are considered duplicate detections, and the detection box with higher confidence is retained). Inference speed requirement ≥ 10fps (ensuring real-time verification).

[0035] Standard image library construction requirements: The standard image library must contain qualified samples of the same structural component (such as antenna cover, silicone button) under 3 lighting conditions (strong light: light intensity ≥5000 lux, weak light: light intensity ≤500 lux, normal light: 1000-3000 lux) and 4 shooting angles (front view: perpendicular to the plane of the structural component, 45° side view: at a 45° angle to the front, top view: from above the structural component at a 45° angle, bottom view: from below the structural component at a 45° angle), with ≥20 samples for each scene; the sample annotation should use the LabelImg tool to annotate the key areas of the structural component (such as the position of the antenna cover screws, the direction of the button ribbon cable), the annotation format is VOC XML, and each sample must contain at least 3 key area annotation boxes.

[0036] Similarity calculation method: The total similarity is calculated by weighting "Structural Similarity Index (SSIM) + Key Region Matching Degree", where SSIM has a weight of 0.6 and Key Region Matching Degree has a weight of 0.4. SSIM is calculated using OpenCV's cv2.compareSSIM function (window size 11×11) with a value range of 0-1. Key Region Matching Degree = (Number of successfully matched key regions / Total number of key regions), and the matching criterion is "IOU between detection boxes and annotation boxes ≥ 0.5". A total similarity of ≥ 0.87 is considered acceptable for repair, and < 0.87 is considered unacceptable and will prompt "Key region mismatch".

[0037] Specifically, the equipment fault detection module uses task fragmentation technology to break down the detection process, processes multiple serial port data streams through an asynchronous non-blocking I / O model and a multi-threaded polling mechanism, with a polling interval of 10ms, and uses mutex locks between threads to avoid resource conflicts.

[0038] The beneficial effects of this invention are:

[0039] More flexible protocol adaptation: Through the protocol adaptive learning engine, new customized protocols can be automatically adapted without manual intervention, shortening the adaptation cycle from several days to several hours, and greatly improving equipment compatibility;

[0040] Parallel detection is more efficient: Dynamic core scheduling and resource elastic allocation algorithms avoid core resource gaps and waste. When 5 devices are under full load for detection, the efficiency is improved by more than 30%, and the detection stuttering rate is reduced to less than 1%.

[0041] Fault diagnosis accuracy continues to improve: The FT-BN self-evolution mechanism enables the identification rate of new faults to reach over 95%, and the diagnostic accuracy gradually improves with the use time, stabilizing at over 98% after long-term use.

[0042] Data security is significantly enhanced: cloud-edge collaborative backup avoids data loss due to local device failure, tiered storage solves write blocking issues under high throughput, and data retrieval speed is improved by 40%;

[0043] Wider environmental adaptability: The offline multimodal interaction kit meets the maintenance needs of remote, mountainous, and other scenarios without network access, ensuring continuous operation across all scenarios;

[0044] More efficient multi-fault maintenance: The multi-fault conflict resolution algorithm avoids conflicting maintenance steps, improving maintenance efficiency by 25% and reducing the secondary damage rate to below 0.5%;

[0045] Enhanced hardware compatibility: The hardware compatibility adaptation layer supports different brands / batches of rugged tablets, reducing device replacement costs and improving usage flexibility;

[0046] More objective maintenance and verification: The visual-assisted verification module replaces subjective human judgment, achieving an accuracy rate of over 96% for non-reproducible fault verification, and ensuring the authenticity of knowledge base data;

[0047] Lower operational threshold: Multimodal interaction and standardized processes have been solidified, and even personnel with no prior experience can independently complete maintenance after 30 minutes of training, making it more adaptable to grassroots units. Attached Figure Description

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

[0049] Figure 1 A flowchart of an intelligent parallel testing and maintenance system for BeiDou equipment provided by the present invention;

[0050] Figure 2 This invention provides a technical architecture diagram of an intelligent parallel testing and maintenance system for BeiDou equipment. Detailed Implementation

[0051] To make the technical means, creative features, objectives and effects of this invention easier to understand, the invention will be further described below in conjunction with specific embodiments.

[0052] like Figures 1-2 As shown, the intelligent parallel testing and maintenance system for BeiDou equipment described in this invention adopts the following technical solution:

[0053] The overall system architecture includes a rugged tablet hardware carrier and intelligent maintenance software for BeiDou equipment. The two work together to realize the functions of parallel detection, fault diagnosis, maintenance guidance and data management of BeiDou equipment.

[0054] The rugged tablet features a domestically developed Galaxy Kylin operating system. A key improvement is the addition of a hardware compatibility adaptation layer, which includes an interface conversion driver, a level adaptation unit, and a performance adaptation module. The interface conversion driver supports mainstream serial port chips such as CH340 and PL2303, automatically identifying the tablet's serial port chip model and loading the corresponding driver. The level adaptation unit is compatible with different level standards such as TTL and RS232, enabling automatic conversion between equipment data levels and tablet recognition levels. The performance adaptation module dynamically adjusts DMA transfer parameters (configurable buffer size 1-4MB) to ensure a total throughput of 200Mbps for tablets with different CPU / GPU configurations. The tablet is equipped with multiple communication interfaces (RS-232 / CAN, etc.) and three aviation connectors. The RS232 aviation connectors can be converted to five serial ports, each with a baud rate range of 1200-115200bps, supporting parallel access for up to five BeiDou devices.

[0055] The maintenance software module has been updated with a protocol adaptive learning engine and a vision-assisted verification module, specifically including the following modules:

[0056] (1) Serial port automatic detection and communication module: Built-in Beidou-1, Beidou-2 and Beidou-3 standard protocol library, and added protocol adaptive learning engine. The engine captures unknown protocol data frames through the protocol feature extraction unit and extracts features such as start character, check rules, and data segment format; the frame structure parsing unit maps the features to frame structure parameters (start bit, address bit, data bit, check bit existence and length); the learning model training unit is based on the CNN deep learning model, uses more than 1,000 frames of unknown protocol data as training samples, iterates the training parsing function 50-100 times, automatically binds the equipment unique identifier and updates the protocol library, and realizes the adaptation of new customized protocols without manual intervention.

[0057] The convolutional layer parameters of the CNN model are set as follows: the first convolutional layer has 16 3×3 kernels and a stride of 1; the second convolutional layer has 32 3×3 kernels and a stride of 1; the third convolutional layer has 64 5×5 kernels and a stride of 1; and the pooling layer uses max pooling (2×2 kernels). The input feature vector is generated by "ASCII encoding of the start character (8-dimensional) + binary encoding of the check rule (32-dimensional) + format feature encoding of data segment length / number of fields, etc. (88-dimensional)". The output vector corresponds to 16 key parameters of the frame structure (such as start bit length, data bit offset, etc.).

[0058] The training samples consist of 1200 frames of unknown protocol data, covering baud rates of 1200bps (240 frames), 9600bps (240 frames), 38400bps (240 frames), 57600bps (240 frames), and 115200bps (240 frames). Each baud rate includes CRC16 (80 frames), parity check (80 frames), and no parity check (80 frames). Frame lengths are randomly distributed between 64 and 512 bytes. During sample preprocessing, noise was removed using the OpenCV mean filtering function (cv2.blur, ksize=(3,3)) and Min-Max normalization (X) was applied. norm =(XX min ) / (X max -X min Map the data to [0,1] and use linear interpolation (np.interp) to complete the 7 erroneous frames (0.58%).

[0059] During training, the Adam optimizer and cross-entropy loss function were implemented using the PyTorch framework. The learning rate was decayed by 0.5 every 20 iterations using torch.optim.lr_scheduler.StepLR. The batch size was set to 32. The validation set loss value was calculated after each iteration. When the loss value dropped to 0.008 (≤0.01) in the 68th iteration, the iteration was stopped. At this point, the parsing accuracy of the validation set was 97.2%, which met the training qualification standard.

[0060] The communication process adopts an asynchronous non-blocking I / O model, a multi-threaded polling mechanism (polling interval of 10ms) to handle multiple serial port data streams, and mutual exclusion locks are used between threads to avoid resource conflicts.

[0061] (2) Equipment Fault Detection Module: The core adopts the "Fault Tree-Bayesian Network (FT-BN)" fusion engine, and adds a self-evolution mechanism of FT-BN. The fault tree starts from the top event and decomposes to the bottom event. The Bayesian network quantifies the causal relationship based on the conditional probability table. The self-evolution mechanism automatically collects new fault cases (including fault data, maintenance process, and repair results) through the fault case collection unit. After manual review, the probability update unit adjusts the conditional probability table of the Bayesian network, and the fault tree expansion unit adds bottom event nodes and optimizes the logical relationship.

[0062] The conditional probability of "RF module failure (A) when RDSS signal is abnormal (B)" in the initial Bayesian network (Without this causal relationship), a new case of "abnormal RDSS signal and RF module failure" was collected for the first time (C=1). Calculated according to the formula: Subsequently, nine more similar cases were collected (all of which were "A occurred when B occurred", C=1), bringing the cumulative total to N=19. .

[0063] During fault tree expansion, two cases of "RF module failure → RDSS signal anomaly" were verified: Case 1 "RDSS signal anomaly, RF module power amplifier damage detected", and Case 2 "RDSS signal anomaly, RF module filter failure detected". The verification pass rate was 100% (≥90%). Therefore, a new "RF module failure" sub-event was added under the "RDSS signal anomaly" sub-node. The optimized logic relationship was "RDSS signal anomaly = surrounding obstruction ∨ main control board failure ∨ antenna failure ∨ RF module failure", and the fault tree structure diagram was updated. Figure 2 (Fault tree node of the "Equipment Fault Detection Module" in the middle).

[0064] The module uses task fragmentation technology to break down the detection process into sub-tasks such as power supply and signal quality. It combines dynamic core scheduling and resource elastic allocation algorithms to achieve task allocation: the task complexity is quantified by the amount of data and the number of calculation steps. Simple tasks are allocated 1 CPU core, and complex tasks are allocated 2-3 cores.

[0065] The rugged tablet CPU has 8 cores, with a core resource pool of 2 cores (8 × 20% = 1.6, rounded up to 2 cores). The computational complexity of the "RDSS signal analysis task" is as follows: the task data size is 150KB (>100KB, D=3), and the calculation steps include "signal filtering → power calculation → signal-to-noise ratio analysis → beam matching → fault diagnosis," totaling 5 steps (≤5 steps, K=1). This task is classified as a simple task and is assigned 1 core.

[0066] The computational complexity of the "RNSS positioning accuracy detection task" is as follows: the data size is 80KB (10 < 80 ≤ 100KB, D = 2), and the calculation steps include "satellite ephemeris reading → coordinate calculation → deviation calculation → accuracy level determination → comparison with standard values ​​→ outlier removal → result output", totaling 7 steps (5 < 7 ≤ 10 steps, K = 2). This task is classified as a simple task and is assigned 1 core.

[0067] When 5 devices are connected simultaneously (3 simple tasks + 2 complex tasks), each of the 2 complex tasks is allocated 3 cores (6 cores in total), and each of the 3 simple tasks is allocated 1 core (3 cores in total), requiring a total of 9 cores. At this time, 2 cores are activated from the core resource pool to prioritize the 2 complex tasks (3 cores each). The remaining core from the core resource pool is allocated to 1 simple task, and the other 2 simple tasks enter the standby queue (length 2≤5) to wait for cores to be released according to the time slice rotation mechanism.

[0068] A core resource pool (occupying 20% ​​of the total number of cores) and a spare queue are set up. Cores are allocated to equipment of the same priority using a time-slice rotation mechanism to avoid resource shortages.

[0069] (3) Maintenance operation guidance module: integrates a multi-fault conflict resolution algorithm, constructs a priority matrix based on fault severity (weight 0.4), maintenance operation dependency (weight 0.3), and component correlation (weight 0.3), reorders the maintenance steps of multiple faults, and generates a conflict-free maintenance plan;

[0070] The Beidou terminal simultaneously exhibits three faults: "Power failure (F1)," "RDSS signal abnormality (F2)," and "Loose main control board interface (F3)." Calculate the priority:

[0071] Fault severity weighting: F1 (power failure, 10 points) → 0.4; F2 (RDSS signal abnormality, 9 points) → 0.35; F3 (loose interface, 7 points) → 0.3;

[0072] Dependency weight: F3 needs to disassemble the power module involved in F1 first (F1→F3), so the dependency weight of F3 = 0.3 (priority propagation of F1); F1 and F2 have no dependency, so the weight = 0; F2 and F3 have no dependency, so the weight = 0.

[0073] Component correlation weight: Number of common components (power modules) between F1 and F3 = 1, Total number of components (power modules, main control board) = 2 → (1 / 2) × 0.3 = 0.15; F1 and F2 have no common components → 0; F2 and F3 have no common components → 0;

[0074] Priority calculation: F1 = 0.4 + 0 + 0.15 = 0.55; F2 = 0.35 + 0 + 0 = 0.35; F3 = 0.3 + 0.3 + 0.15 = 0.75;

[0075] Priority sorting: F3 (0.75) > F1 (0.55) > F2 (0.35), so the repair steps are reordered as "first repair the loose main control board interface (F3) → replace the power module (F1) → check the abnormal RDSS signal (F2)", avoiding the conflict of "repairing F1 first, which makes F3 unable to be disassembled", and generating a conflict-free repair plan;

[0076] After receiving the fault detection results, the module generates a multimodal maintenance solution based on the mapping rules between fault codes and maintenance actions. This solution includes dynamic annotations of the 3D model, detailed step-by-step explanations with pictures and text, and replacement guidance videos. The solution is then passed to the human-computer interaction module.

[0077] (4) Data storage module: A cloud-edge collaborative backup and hierarchical storage architecture is adopted. The edge InfluxDB stores real-time monitoring logs (supporting tens of thousands of data points written per second), and the DM8 database stores recent maintenance data and maintenance case knowledge base. A hot data caching strategy (data from the last 7 days) and a cold data archiving strategy (data older than 7 days) are adopted to solve the write blocking problem. The cloud synchronizes all data on a regular basis through an encrypted channel, supporting dual-dimensional recovery based on time points or "equipment serial number + time period" to achieve off-site backup. Data transmission adopts the Apache Avro binary serialization format. The DM database adopts a partitioned table (partitioned by equipment UUID + time month) and establishes a general inverted index, supporting millisecond-level multi-condition retrieval.

[0078] (5) Human-computer interaction module: Integrates an offline multimodal interaction suite, pre-stores 3D models (OBJ format, polygon count ≤ 5000 faces), maintenance diagrams and text, voice packs and videos for each type of equipment, automatically switches to offline mode in the absence of network environment, and ensures a rendering frame rate of over 30fps based on the Three.js engine (version r0.126.1). Voice prompts use pre-stored voice packs and support "Next / Replay" voice control. The 3D model and diagrams and text are linked in two directions. Clicking on a model part will highlight the corresponding diagram and text steps.

[0079] (6) Visual auxiliary verification module: The YOLOv8 target detection algorithm is adopted. The structural component repair image is collected by the rugged flat panel camera and compared with the pre-stored standard image (qualified samples under different angles and lighting conditions). The similarity is calculated (the threshold is set to 90%) and the objective judgment result of whether the repair is qualified is output, which replaces the subjective judgment of human. It is suitable for the verification of non-retestable faults such as antenna cover and shell.

[0080] The YOLOv8-nano model of the visual auxiliary verification module is trained using the PyTorch Lightning framework. The input image is scaled to 640×640 pixels using the cv2.resize function (maintaining the aspect ratio and filling blank areas with black padding). The confidence threshold is set to 0.5 and the IOU threshold is 0.6 during inference. The inference speed reaches 12fps on the rugged tablet GPU (Mali-G72).

[0081] The standard image library for the antenna cover includes: 20 images each of strong light (5500 lux) front view, 45° side view, top view, and bottom view (total 80 images); 20 images each of weak light (400 lux) (total 80 images); and 20 images each of normal light (2000 lux) (total 80 images). Each sample is labeled with three key areas: "Screw 1", "Screw 2", and "Feeder Interface" (the coordinates of the label boxes are manually labeled using LabelImg).

[0082] For a repaired antenna cover, a normal light frontal image was acquired, and the similarity was calculated: SSIM=0.92 (calculated using cv2.compareSSIM(img_restore,img_standard,win_size=11)), key region matching degree=3 / 3=1.0 (the IOU of the detection boxes and annotation boxes of the three key regions are 0.72, 0.68, and 0.75 respectively, all ≥0.5), and the total similarity=0.6×0.92+0.4×1.0=0.952≥0.87, which is considered acceptable; for another repaired image, SSIM=0.81, key region matching degree=2 / 3≈0.667, and total similarity=0.6×0.81+0.4×0.667≈0.753<0.87, which is considered unacceptable, with the message "Screw 2 not matched (IOU=0.32<0.5)".

[0083] System Workflow

[0084] (1) Equipment connection and communication establishment: Multiple Beidou equipment to be inspected are connected to the serial port of the rugged tablet through the tooling line. The hardware compatibility adaptation layer automatically identifies the hardware configuration of the tablet, loads the corresponding driver and transmission parameters, and DMA technology writes the equipment data into the double buffer memory area. Each serial port is configured with an independent acquisition thread.

[0085] (2) Protocol adaptation and data parsing: The serial port automatic detection and communication module first matches the known protocol. If no match is found, the protocol adaptive learning engine is started to train the parsing function and update the protocol library. The parsed data is divided into RNSS data and RDSS data. Status data is converted into an easy-to-understand form for display, and functional data is passed to the fault detection module.

[0086] (3) Fault detection and diagnosis: The equipment fault detection module breaks down the detection process by task segmentation, dynamically allocates core parallel execution sub-tasks, uses the FT-BN fusion engine to locate faulty components, and triggers a self-evolution mechanism to update the model when new fault cases are detected.

[0087] (4) Maintenance plan generation and execution: The multi-fault conflict resolution algorithm handles conflicting faults and generates multi-modal maintenance plans. The human-computer interaction module displays and guides the process in online or offline mode, and maintenance personnel operate according to the steps.

[0088] (5) Repair verification and data storage: Retestable faults are retested through the serial port module, and non-retestable faults are verified through the vision-assisted verification module; the detection and repair data are stored in real time to the edge database and synchronized to the cloud periodically.

[0089] Example

[0090] Example 1: Application of Multi-Machine Parallel Detection and Protocol Adaptive Learning

[0091] This embodiment focuses on a batch maintenance scenario involving three BeiDou-3 standard protocol devices and two custom protocol devices from a certain manufacturer, verifying the system's parallel detection capability and protocol adaptive learning effect.

[0092] The system configuration uses a domestically produced rugged tablet (8-core ARM Cortex-A73 CPU, Mali-G72 GPU, 8GB RAM, 256GB storage), running the Galaxy Kirin V4.0 operating system, with the troubleshooting software version V2.0; the cloud server uses a Huawei Cloud ECS instance (4-core, 8GB RAM, 500GB cloud disk), with DM8 database and InfluxDB installed; the equipment to be inspected includes 3 Beidou-3 handheld terminals (standard protocol) and 2 Beidou-3 vehicle terminals (manufacturer-customized protocol, no publicly available parsing rules); the tooling line uses a 5-channel serial port splitter, supporting simultaneous connection of 5 pieces of equipment.

[0093] Implementation process

[0094] (1) Equipment connection: Connect 5 pieces of equipment to the 5 serial ports of the rugged tablet through the tooling line. After the tablet starts, the hardware compatibility adaptation layer automatically identifies the serial port chip as CH340, loads the corresponding interface conversion driver, configures the DMA buffer size to 2MB, and the level adaptation unit converts the TTL level output by the equipment to the RS232 level recognized by the tablet to establish a physical connection.

[0095] (2) Protocol adaptation initialization: After the maintenance software starts, the serial port automatic detection and communication module starts polling the data of each serial port. The data frames of the three Beidou-3 handheld terminals match the Beidou-3 protocol in the built-in standard protocol library and automatically establish a communication link. The baud rate is negotiated to be 9600bps. The data frames of the two vehicle terminals do not match the known protocol, and the system automatically triggers the protocol adaptive learning engine.

[0096] (3) Unknown protocol learning: The protocol feature extraction unit captures data frames of the vehicle terminal (1500 frames are collected for each unit), extracts the start symbol as 0xAA, the end symbol as 0x55, the verification rule as CRC16, the data segments are separated by commas, and include fields such as device ID, voltage, and signal strength; the frame structure parsing unit identifies that the protocol has no address bits, and the frame structure is "start bit-data bit-check bit-end bit"; the learning model training unit uses 1500 frames of data as training samples, iterates the CNN model 80 times, trains and generates parsing functions, automatically assigns unique identifiers D001 and D002 to the two vehicle terminals, and updates the protocol library after binding the parsing function with the identifiers. The entire learning process takes 12 minutes and requires no manual intervention.

[0097] (4) Dynamic Core Scheduling and Parallel Detection: The equipment fault detection module assesses the complexity of the detection tasks for the five pieces of equipment. The detection tasks for the three handheld terminals (power supply detection and RNSS signal quality detection) are simple tasks, each allocated one CPU core; the detection tasks for the two vehicle-mounted terminals (RDSS signal analysis, protocol parsing, and positioning accuracy detection) are complex tasks, each allocated two CPU cores, with the remaining two cores reserved as a core resource pool. The module adopts task sharding technology, breaking down the detection process of each piece of equipment into 3-4 sub-tasks, which are executed in parallel through an asynchronous non-blocking I / O model. The multi-threaded polling interval is 10ms, and mutual exclusion locks are used between threads to avoid resource conflicts.

[0098] (5) Fault Diagnosis and Result Output: During the detection process, one handheld terminal was diagnosed as "power module failure" (fault code C002), one vehicle-mounted terminal was diagnosed as "RDSS antenna failure" (fault code C005), and the remaining three equipment were in normal condition. The FT-BN fusion engine starts from the top event "equipment malfunction" and decomposes it into sub-nodes such as "power failure" and "antenna failure". Combined with the Bayesian network conditional probability table (power failure has an 85% probability of causing malfunction, and antenna failure has a 90% probability of causing malfunction), it accurately locates the faulty component, and the diagnosis results are displayed in real time on the human-machine interface.

[0099] (6) Data storage and cloud synchronization: Log data during the detection process (including status parameters of each equipment, detection steps, and fault codes) is written to InfluxDB in real time, with a stable write rate of 12,000 data points per second and no blocking phenomenon; structured data such as fault cases and equipment information are stored in DM8. At 22:00 on the same day, the system automatically triggers cloud synchronization, and synchronizes the edge data to Huawei Cloud server through an encrypted HTTPS channel. The synchronization takes 8 minutes and the data integrity reaches 100%.

[0100] The implementation results showed that the total time for parallel testing of 5 pieces of equipment was 45 minutes, with an average testing time of 9 minutes per piece of equipment, which is 67% more efficient than traditional serial testing (30 minutes per piece on average); the protocol adaptation success rate of the 2 customized protocol equipment reached 100%, and the data parsing accuracy rate was 99.2%; the fault diagnosis results were reviewed by professionals, and the positioning accuracy rate was 100%; after data synchronization, the cloud can quickly query the test records of the target equipment through multi-condition search, with a search response time of ≤50ms.

[0101] Example 2: Application of FT-BN self-evolution and multi-fault conflict resolution

[0102] This embodiment addresses a maintenance scenario where four Beidou-2 devices simultaneously experience multiple faults, verifying the effectiveness of the FT-BN self-evolution mechanism and the multi-fault conflict resolution algorithm.

[0103] The system is configured with a rugged tablet, which is a domestically produced model (CPU: 10-core Intel Core i7-10750H, GPU: Adreno 630, RAM: 16GB, storage: 512GB), and runs on the Galaxy Kirin V4.0 operating system. The troubleshooting software includes the BeiDou-2 protocol library and the initial FT-BN model (containing 12 top events, 45 intermediate events, and 86 bottom events). The equipment to be inspected consists of four BeiDou-2 backpack terminals, all of which had more than two faults according to preliminary investigations. One terminal had three faults simultaneously: "power failure", "abnormal RDSS signal", and "loose main control board interface".

[0104] Implementation process

[0105] (1) Equipment connection and data acquisition: Four terminals are connected to the tablet serial port through the tooling line. The hardware compatibility adapter layer identifies the serial port chip as PL2303. After loading the driver, communication is established. The serial port module reads the RNSS data (positioning and navigation data, visual satellite status), RDSS data (communication data, beam data) and equipment status data (voltage, current, temperature) of each terminal. The data transmission rate is stable at 115200bps.

[0106] (2) Multi-fault detection: The equipment fault detection module injects the collected data into the FT-BN fusion engine. For a terminal with three faults at the same time, the top event is "equipment cannot communicate and locate normally". The engine decomposes the sub-nodes "power failure", "RDSS signal abnormality" and "main control board failure", and further decomposes them into the bottom events "power module damage", "antenna failure" and "main control board interface loose". The Bayesian network calculates the posterior probability of each bottom event: power module damage probability 92%, antenna failure probability 88%, and main control board interface loose probability 95%.

[0107] (3) Multi-fault conflict resolution: After receiving fault data, the maintenance operation guidance module identifies conflicts in the maintenance steps of three faults (e.g., repairing the main control board interface first requires disassembling the power module, and replacing the power module first will affect the antenna disassembly), and starts the multi-fault conflict resolution algorithm. Construct a priority matrix: fault severity (power fault 0.9, RDSS signal abnormality 0.8, interface looseness 0.7), maintenance operation dependency (interface looseness requires disassembling the power module first, power fault and antenna fault are independent), component correlation (power module correlation with main control board 0.8, correlation with antenna 0.3). Calculate the priority: power fault 0.9×0.4+0×0.3+0.8×0.3=0.6, RDSS signal abnormality 0.8×0.4+0×0.3+0.3×0.3=0.41, interface looseness 0.7×0.4+1×0.3+0.8×0.3=0.71. The algorithm prioritizes the repair steps: first, fix the loose main control board interface → replace the power module → inspect the antenna, and generate a conflict-free repair plan.

[0108] (4) FT-BN self-evolution trigger: During the maintenance process, one terminal was found to have "RF module failure", which was not included in the base events of the initial FT-BN model. The system automatically collects relevant data of the failure (RF module operating parameters, failure phenomenon, maintenance process, and repair results), generates a new failure case and pushes it to the backend management terminal. After being reviewed and approved by professionals, the FT-BN self-evolution mechanism is activated: the probability update unit adds the conditional probability (92%) of "RF module failure" causing "RDSS signal abnormality", and the fault tree expansion unit adds the base event "RF module failure" under the "RDSS signal abnormality" sub-node. The optimized logical relationship is "RDSS signal abnormality = surrounding obstruction ∨ main control board failure ∨ antenna failure ∨ RF module failure". The updated model takes effect in real time.

[0109] (5) Repair and Verification: Repair personnel operate according to the multimodal repair guide: the 3D model highlights the location of the main control board interface, the graphic steps indicate the number and location of the screws to be removed, and the voice broadcast "Please remove the main control board fixing screws first, and be careful to avoid touching the RF interface"; after the interface is repaired, the power module is replaced and the antenna is inspected according to the steps. After the repair, a retest is started. The power failure and RDSS signal abnormality are retested through the serial port module and pass. The loose interface is verified by acquiring images through the visual auxiliary verification module. The similarity is compared with the standard image and the similarity is 97%, which is considered as a successful repair.

[0110] (6) Data archiving: Maintenance data (including fault codes, maintenance steps, time consumption, and verification results) are stored in DM8, and the detection logs are written to InfluxDB and synchronized to the cloud on the same day to form a complete maintenance file.

[0111] The implementation results showed that the average repair time for four multi-fault equipment was 68 minutes, which is 54.7% more efficient than traditional manual repair (average 150 minutes); the multi-fault conflict resolution algorithm successfully avoided two potential secondary damages; after adding "RF module fault", the diagnosis time for subsequent similar faults was shortened from 30 minutes to 5 minutes, with a diagnosis accuracy of 96%; after the FT-BN model was updated, the overall fault diagnosis accuracy improved from the initial 92% to 95.3%.

[0112] Example 2: Application of Offline Multimodal Interaction and Cloud-Edge Collaborative Backup

[0113] This embodiment addresses an emergency maintenance scenario involving three Beidou-1 satellite systems in a remote, network-free environment, verifying the system's offline operational capabilities and data backup and recovery effectiveness.

[0114] The system is configured with a rugged tablet, a domestically produced portable model (CPU: 6-core ARM Cortex-A53, GPU: PowerVR GE8320, RAM: 6GB, storage: 128GB), pre-stored with offline multimodal resources (3D models, maintenance images and text, voice packets, videos) for various Beidou-1 equipment models; the equipment to be inspected consists of 3 Beidou-1 handheld terminals, with fault types including 2 "abnormal positioning signal" (retestable) and 1 "damaged antenna cover" (non-retestable); there is no network environment (outdoor training ground, mobile phone signal blocked); the cloud server is a previously configured Huawei Cloud ECS instance.

[0115] Implementation process

[0116] (1) Offline mode startup: The maintenance personnel carried the rugged tablet to the field training ground. After the tablet was turned on, it detected no network connection and automatically switched to offline mode. The human-computer interaction module loaded the pre-stored Beidou-1 equipment offline resources, the three-dimensional model rendering frame rate was stable at 32fps, and the voice module switched to the local voice package.

[0117] (2) Equipment Connection and Testing: Three Beidou-1 terminals were connected to the tablet's serial port via a tooling line. The hardware compatibility adapter layer identified the tablet's serial port chip as CP2102. After loading the driver, a connection was established, and the serial port module matched the Beidou-1 protocol to read equipment data. The test results showed that two terminals had "RNSS antenna failure" (fault code C003), and one terminal had "antenna cover damage" (fault code C007).

[0118] (3) Offline Repair Guidance: The repair operation guidance module generates offline multimodal repair solutions. For terminals with antenna failure, the 3D model highlights the antenna location, and the detailed process of antenna disassembly and replacement is shown in pictures and text. Each step is accompanied by two disassembly diagrams and text descriptions, and the voice broadcasts "Please rotate the antenna base clockwise to disassemble, and be careful to protect the feed line." Repair personnel can switch steps by controlling "Next" with voice. When they click on the "Antenna" component in the 3D model, the interface automatically highlights the corresponding picture and text steps, achieving immersive guidance. For terminals with damaged antenna covers, the solution shows the steps for replacing the antenna cover, including the operation details of screw removal and installation of the new antenna cover.

[0119] (4) Non-reproducible fault verification: After the antenna cover is replaced, the visual auxiliary verification module is started. The maintenance personnel use a flat panel camera to collect images of the antenna cover installation from three different angles. The module uses the YOLOv8 algorithm to identify the screw installation status and the fit of the shell. The images are compared with 30 pre-stored standard images. The average similarity is 95%, and the repair is deemed qualified.

[0120] (5) Offline data storage: Detection and maintenance data (including fault codes, maintenance steps, verification results, and time consumption) are stored in real time to the InfluxDB and DM8 on the tablet. A daily incremental backup strategy is adopted to generate backup files locally.

[0121] (6) Network recovery and data synchronization: 24 hours after the maintenance is completed, the maintenance personnel return to the camp, the tablet connects to the network, and automatically triggers cloud-edge collaborative backup, which synchronizes the maintenance data of the three equipment stored during the offline period to the cloud server incrementally. The data synchronization amount is about 800KB, takes 12 seconds, and the data integrity reaches 100%.

[0122] (7) Data recovery verification: To verify the backup effect, simulate tablet data loss (manually delete local maintenance data), start the data recovery function, select the "equipment serial number + maintenance date" dimension, pull the corresponding data from the cloud, the recovery takes 25 seconds, the recovered data is consistent with the original data, and there is no loss or error.

[0123] In a field environment without network access, the system functions normally, offline multimodal interaction is smooth, and "zero-experience" maintenance personnel successfully repaired 3 pieces of equipment with an average repair time of 52 minutes; the accuracy rate of non-reproducible fault verification reached 95%; after data synchronization, maintenance records can be fully queried in the cloud, and the data recovery success rate is 100%, meeting the needs of emergency maintenance and data traceability.

[0124] Example 3: Application of Hardware Compatibility and Visual Assisted Verification

[0125] This embodiment addresses the repair scenario after replacing rugged tablets with different brands, verifying the system's hardware compatibility and focusing on verifying the effectiveness of the visual-assisted verification module in detecting structural component faults.

[0126] The system configuration uses two rugged tablets from different brands: Tablet A (original model, 8-core CPU, Mali-G76 GPU) and Tablet B (newly replaced model, 6-core CPU, Adreno 540 GPU); the equipment to be tested consists of 5 Beidou-2 terminals, of which 3 have "silicone button failure" (non-retestable fault) and 2 have "time synchronization abnormality" (retestable fault); the visual auxiliary verification module has pre-stored standard images (20 sets, covering different lighting conditions) of qualified silicone button installation.

[0127] Implementation process

[0128] (1) Tablet B compatibility adaptation: Install the maintenance software on the tablet B. After startup, the hardware compatibility adaptation layer automatically identifies the serial port chip of the tablet B as FT232, loads the corresponding interface conversion driver, adjusts the DMA transmission parameters (buffer size 1MB), and the level adaptation unit adapts to the level standard of the tablet B to complete the compatibility configuration. The entire process does not require manual parameter modification.

[0129] (2) Equipment connection and testing: Five Beidou-2 terminals were connected to the five serial ports of the tablet B. The serial port module was matched with the Beidou-2 protocol. After communication was established, testing was started. Testing results: Three terminals showed "silicone button failure" (fault code C008), and two terminals showed "time synchronization abnormality" (fault code C009).

[0130] (3) Maintenance guidance and operation: The maintenance operation guidance module generates maintenance plans. For silicone button failure, the 3D model highlights the button area, and the graphic steps indicate the button disassembly tools (dedicated pry bar) and installation sequence. The voice broadcast says "Please use the dedicated pry bar to gently pry the edge of the silicone button to avoid damaging the button cable". For timing abnormality, the plan guides you to check the timing antenna interface and parameter configuration.

[0131] (4) Visual auxiliary verification: After the silicone buttons of the three units were replaced, the visual auxiliary verification module was started. The camera of the tablet B captured the button installation image. The module used the YOLOv8 algorithm to identify whether the button was installed in place, whether the ribbon cable was bent, and whether the surface was flat. The images were compared with the standard images: the similarity of the two units was 98% and 96%, respectively, and they were deemed qualified; the similarity of the one unit was 85%, and the message "button ribbon cable bent" was displayed. After the maintenance personnel readjusted it, the similarity reached 97%, and it was deemed qualified.

[0132] (5) Retestable fault retest: After the two time synchronization fault terminals were repaired, they were retested through the serial port module. The time synchronization accuracy met the requirements, and the repair was deemed qualified.

[0133] (6) Multi-tablet data synchronization: Tablet A and Tablet B are used to test the same terminal respectively. The test results of Tablet A and Tablet B are 99.5% consistent. After the data is synchronized to the cloud, there is no conflict or loss.

[0134] The hardware compatibility adaptation of tablet B took ≤5 minutes and required no intervention from professional technicians; the visual-assisted verification module achieved a verification accuracy of 96.7% for silicone button failures, avoiding the use of a single unqualified repaired terminal; the test results of two tablets from different brands were highly consistent, and the system operated stably after hardware replacement, meeting the equipment rotation needs of grassroots units.

[0135] V. Comparative Examples

[0136] To further verify the technical advantages of the present invention, the following three sets of control experiments were set up. The control examples used existing technology (without the inventive technical points of the present invention), while the experimental groups used the system of the present invention, and the experimental conditions were the same.

[0137] Comparison with Example 1: Efficiency of Protocol Adaptation and Parallel Detection

[0138] Experimental subjects: 2 customized protocol devices + 3 standard protocol devices

[0139] Comparative example: Existing detection system (no protocol adaptive learning, fixed core allocation)

[0140] Experimental group: The system of this invention

[0141] Experimental results:

[0142]

[0143] Comparison with Example 2: Fault Diagnosis and Multi-Fault Repair

[0144] Experimental subjects: 4 BeiDou systems with multiple faults (including 1 newly added fault)

[0145] Comparison example: Existing detection system (no FT-BN self-evolution, no conflict resolution)

[0146] Experimental group: The system of this invention

[0147] Experimental results:

[0148]

[0149] Comparison with Example 3: Offline work versus data security

[0150] Experimental subjects: 3 Beidou equipment units (including 1 unit with a structural component failure).

[0151] Comparison example: Existing detection system (no offline mode, local storage)

[0152] Experimental group: The system of this invention

[0153]

[0154] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of protection claimed by the present invention. The scope of protection of the present invention is defined by the appended claims and their equivalents.

Claims

1. An intelligent parallel testing and maintenance system for BeiDou equipment, characterized in that, This includes rugged tablet hardware and intelligent maintenance software for BeiDou equipment. The rugged tablet is equipped with the domestic Galaxy Kylin operating system, has a hardware compatibility adaptation layer, multiple communication interfaces and 3 aviation plug interfaces, and the RS232 aviation plug interface can be converted to 5 serial ports, supporting the parallel access of 5 Beidou equipment, with each serial port baud rate of 1200-115200bps. The maintenance software includes a serial port automatic detection and communication module, an equipment fault detection module, a maintenance operation guidance module, a data storage module, a human-computer interaction module, a protocol adaptive learning engine, and a vision-assisted verification module. It achieves intelligent task allocation through a heterogeneous computing architecture of multi-core CPU and GPU, dynamic core scheduling, and resource elastic allocation algorithms. It uses a "fault tree-Bayes network" fusion engine and a self-evolution mechanism to locate faults. It provides operation guidance through multimodal interaction and offline suites, and combines cloud-edge collaborative backup and hierarchical storage to ensure data security. The serial port automatic detection and communication module has a built-in standard protocol library and protocol adaptive learning engine. The maintenance operation guidance module integrates a multi-fault conflict resolution algorithm. The visual auxiliary verification module verifies the repair status of structural components through image recognition.

2. The intelligent parallel testing and maintenance system for BeiDou equipment according to claim 1, characterized in that: The protocol adaptive learning engine includes a protocol feature extraction unit, a frame structure parsing unit, and a learning model training unit. By capturing unknown protocol data frames, it extracts start symbols, verification rules, and data segment format features. Based on a CNN deep learning model, it trains a parsing function, automatically binds equipment identifiers, and updates the protocol library without manual intervention to adapt to new customized protocols.

3. The intelligent parallel testing and maintenance system for BeiDou equipment according to claim 1, characterized in that: The dynamic core scheduling and resource elastic allocation algorithm dynamically adjusts the number of cores allocated based on real-time task complexity evaluation value and CPU core utilization rate, sets up a core resource pool and a backup queue, and uses a time slice round-robin mechanism to allocate cores when equipment with the same priority requests resources.

4. The intelligent parallel testing and maintenance system for BeiDou equipment according to claim 1, characterized in that: The fault tree-Bayesian network self-evolution mechanism includes a fault case collection unit, a probability update unit, and a fault tree expansion unit. It automatically collects new fault cases, updates the Bayesian network conditional probability table after manual review, adds bottom event nodes, and optimizes the fault tree logical relationship.

5. The intelligent parallel testing and maintenance system for BeiDou equipment according to claim 1, characterized in that: The data storage module adopts a cloud-edge collaborative backup and hierarchical storage architecture. The edge InfluxDB stores real-time detection logs, the DM8 stores recent maintenance data, and the cloud synchronously backs up all data, using a hot data caching and cold data archiving strategy.

6. The intelligent parallel testing and maintenance system for BeiDou equipment according to claim 1, characterized in that: The human-computer interaction module integrates an offline multimodal interaction suite, pre-stores 3D models, images, voice packs and maintenance videos, and automatically switches to offline mode in the absence of network environment, maintaining a rendering frame rate of more than 30fps.

7. The intelligent parallel testing and maintenance system for BeiDou equipment according to claim 1, characterized in that: The multi-fault conflict resolution algorithm constructs a priority matrix based on fault severity, maintenance operation dependency, and component correlation to reorder the maintenance steps for conflicting faults.

8. The intelligent parallel testing and maintenance system for BeiDou equipment according to claim 1, characterized in that: The hardware compatibility adaptation layer includes an interface conversion driver, a level adaptation unit, and a performance adaptation module, which are compatible with the serial port chips and CPU / GPU configurations of different brands / batch of rugged tablets.

9. The intelligent parallel testing and maintenance system for BeiDou equipment according to claim 1, characterized in that: The visual-assisted verification module uses the YOLOv8 target detection algorithm to collect images of structural component repairs through a rugged tablet camera, compares them with standard images, and outputs objective verification results.

10. The intelligent parallel testing and maintenance system for BeiDou equipment according to claim 1, characterized in that: The equipment fault detection module uses task fragmentation technology to break down the detection process, and processes multiple serial port data streams through an asynchronous non-blocking I / O model and a multi-threaded polling mechanism with a polling interval of 10ms. Mutual exclusion locks are used between threads to avoid resource conflicts.

Images