Communication method, device and equipment for initiating plate from machine and storage medium

Abstract

The application provides a communication method, device and equipment of a detonator slave machine and a storage medium. The method comprises the following steps: obtaining a synchronization code sent by a detonator master machine, and entering a communication synchronization state according to the synchronization code; after entering the communication synchronization state, entering a preset heartbeat detection period cyclically, determining a communication quality score according to a heartbeat data packet sent by the detonator master machine and obtained in the heartbeat detection period; when the communication quality score is lower than a preset quality threshold, entering a safety locking state, generating a communication state report according to the communication quality score, sending the communication state report to the detonator master machine, and resuming the communication synchronization state with the detonator master machine.

Description

Technical Field

[0001] This application relates to the field of detonator communication technology, and in particular to a communication method, apparatus, device and storage medium for a detonator slave device. Background Technology

[0002] Currently, in existing detonator systems, the detonator slave devices typically communicate with the detonator master device using a simple point-to-point communication mode. When multiple detonator slave devices coexist, efficient and reliable communication management becomes difficult. Specifically, in a master-slave network environment, the following problems exist: multiple detonator slave devices compete for the communication bus, easily leading to data conflicts; a single detonator slave device failure can affect the overall system communication stability; there is a lack of link health status monitoring and dynamic management mechanisms; and the system recovery speed after communication anomalies is slow, resulting in poor reliability. Summary of the Invention

[0003] This application provides a communication method, apparatus, device, and storage medium for a detonator slave device, which improves communication quality and recovery efficiency after a fault in a detonator network with one master and multiple slave devices.

[0004] In a first aspect, embodiments of this application provide a communication method for a detonator slave device, the method comprising:

[0005] Obtain the synchronization code sent by the detonator host, and enter the communication synchronization state according to the synchronization code;

[0006] After entering the communication synchronization state, the system cycles through a preset heartbeat detection period and determines the communication quality score based on the heartbeat data packets sent by the detonator host obtained within the heartbeat detection period.

[0007] When the communication quality score is lower than a preset quality threshold, a safety lock state is entered. A communication status report is generated based on the communication quality score and sent to the detonator host to restore the communication synchronization state with the detonator host.

[0008] In some embodiments, obtaining the synchronization code sent by the detonating plate host and entering the communication synchronization state according to the synchronization code includes:

[0009] After power-on, it enters listening mode to obtain the synchronization code sent by the detonator host;

[0010] Calculate the baud rate and frame format based on the synchronization code, set the communication interface based on the baud rate, and enter a silent standby state;

[0011] Obtain the name call instruction broadcast by the detonator host, parse the name call instruction based on the frame format, and obtain the first flag;

[0012] When the first flag and the preset second flag are the same, a response request is sent to the detonator host, where the preset second flag is the identification flag of the detonator slave.

[0013] After receiving the response from the detonator host, it enters the communication synchronization state and caches the baud rate and frame format to a preset database.

[0014] In some embodiments, determining a communication quality score based on heartbeat data packets sent by the detonator host within the heartbeat detection period includes:

[0015] Error rate is obtained by performing error checking on the heartbeat data packets.

[0016] In response to the data feedback instruction sent by the detonator host, the heartbeat data packet is fed back to the detonator host, and the number of feedback failures per unit time is recorded;

[0017] If the heartbeat data packet is not received within a heartbeat detection cycle, the preset heartbeat loss count is incremented by one to obtain the latest heartbeat loss count. The latest heartbeat loss count is reset to the preset heartbeat loss count after the heartbeat data packet is received.

[0018] A communication quality score is determined based on the bit error rate, the number of failed transmissions, or the latest number of lost heartbeats.

[0019] In some embodiments, generating a communication status report based on the communication quality score includes:

[0020] After each first preset number of heartbeat detection cycles, a communication status report is generated based on the bit error rate, the number of backhaul failures, the latest number of lost heartbeats, and the communication quality score.

[0021] In some embodiments, determining the communication quality score based on the bit error rate, the number of backhaul failures, or the latest heartbeat loss count includes:

[0022] If the bit error rate is greater than a preset bit error threshold, the communication quality score is set to unqualified; or,

[0023] If the number of failed data transmissions exceeds a preset first threshold, the communication quality score will be set to unqualified; or,

[0024] If the latest number of lost heartbeats exceeds the preset second threshold, the communication quality score will be set as unqualified.

[0025] In other cases, the communication quality score is set to qualified.

[0026] In some embodiments, restoring the communication synchronization state with the detonator host includes:

[0027] Within the second preset number of heartbeat detection cycles, the communication synchronization state is restored with the detonator host according to the baud rate and the frame format.

[0028] After a second preset number of heartbeat detection cycles, an adaptive recovery process is initiated, through which the communication synchronization state with the detonator host is restored.

[0029] In some embodiments, restoring the communication synchronization state with the detonator host through the adaptive recovery process includes:

[0030] Reset the communication interface, re-enter the listening mode, and wait for the synchronization code to be resent by the detonator host;

[0031] Based on the synchronization code resent by the detonator host, the updated baud rate and updated frame format are obtained;

[0032] The communication interface is reset according to the updated baud rate, and bidirectional communication authentication is completed with the detonator host based on the updated frame format to restore the communication synchronization state.

[0033] Secondly, embodiments of this application provide a communication device for a detonator slave device, the device comprising:

[0034] The communication connection module is used to obtain the synchronization code sent by the detonator host and enter the communication synchronization state according to the synchronization code;

[0035] The communication scoring module is used to cycle through a preset heartbeat detection cycle after entering the communication synchronization state, and determine the communication quality score based on the heartbeat data packets sent by the detonator host obtained within the heartbeat detection cycle.

[0036] The communication recovery module is used to enter a safety lock state when the communication quality score is lower than a preset quality threshold, generate a communication status report based on the communication quality score, and send the communication status report to the detonator host to restore the communication synchronization state with the detonator host.

[0037] Thirdly, embodiments of this application provide an electronic device, which includes a memory and a processor;

[0038] The memory is used to store computer programs;

[0039] The processor is configured to execute the computer program and, in executing the computer program, implement the communication method of the detonator slave device as described in any of the embodiments of this application.

[0040] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to implement the communication method of the detonator slave device as described in any of the embodiments of this application.

[0041] This application provides a communication method for a detonator slave device. The method includes: acquiring a synchronization code sent by the detonator master device; entering a communication synchronization state based on the synchronization code; after entering the communication synchronization state, cyclically entering a preset heartbeat detection cycle; determining a communication quality score based on the heartbeat data packets sent by the detonator master device within the heartbeat detection cycle; when the communication quality score is lower than a preset quality threshold, entering a safety lock state; generating a communication status report based on the communication quality score; sending the communication status report to the detonator master device; and restoring the communication synchronization state with the detonator master device. In the above method, the synchronization code ensures high reliability of the initial connection between the slave and master devices; through periodic heartbeat data packet analysis, the communication link quality score is quantified in real time, and combined with the preset quality threshold, accurate judgment of abnormal states is achieved, avoiding unnecessary interruptions caused by misjudgments. At the fault recovery level, a tiered recovery strategy is adopted: when the communication quality score is lower than the threshold, a safety lock state is first triggered, prohibiting detonation operations and generating a status report containing indicators such as bit error rate and retransmission count, which is then fed back to the master device. Subsequently, the communication synchronization state with the detonator master device is restored, ensuring a high success rate of connection reconstruction in extreme scenarios. Attached Figure Description

[0042] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0043] Figure 1 A schematic flowchart illustrating a communication method for a detonator slave device provided in an embodiment of this application;

[0044] Figure 2 This is a schematic block diagram of a communication device for a detonator slave device provided in an embodiment of this application. Detailed Implementation

[0045] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0046] The flowchart shown in the attached diagram is for illustrative purposes only and does not necessarily include all content and operations / steps, nor does it necessarily have to be performed in the order described. For example, some operations / steps can be broken down, combined, or partially merged, so the actual execution order may change depending on the actual situation.

[0047] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of the application. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0048] It should also be further understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0049] Please see Figure 1 , Figure 1 This is a schematic flowchart illustrating a communication method for a detonator slave device provided in an embodiment of this application. Figure 1 As shown, the specific steps of the communication method of the detonator slave device include: S101-S10X.

[0050] S101. Obtain the synchronization code sent by the detonator host and enter the communication synchronization state according to the synchronization code.

[0051] For example, after the detonator slave device starts up, it automatically enters listening mode, continuously monitoring the communication channel to capture the synchronization code sent by the detonator master device. The synchronization code is a specific coded signal sent by the detonator master device, used to identify the initial parameters and connection request of the communication link. The detonator slave device parses the structure and content of the synchronization code to identify the communication rules of the detonator master device, including key parameters such as timing and data format, thereby completing the initial negotiation with the detonator master device. This process enables the detonator slave device and the detonator master device to reach agreement on dimensions such as data transmission rate and frame structure, establishing a stable communication synchronization state. Confirmation of the communication synchronization state depends on the complete reception and verification of the synchronization code, ensuring the reliability of subsequent data exchange. In this state, the detonator slave device enters standby mode, suspending active data transmission and retaining only the ability to respond to commands from the detonator master device. The establishment of the communication synchronization state provides a basic link guarantee for subsequent periodic quality checks and command interactions, avoiding communication failures caused by parameter mismatches.

[0052] S102. After entering the communication synchronization state, the system cycles through the preset heartbeat detection period and determines the communication quality score based on the heartbeat data packets sent by the detonator host within the heartbeat detection period.

[0053] For example, after communication synchronization is established, the detonator slave device initiates a heartbeat detection cycle at preset time intervals. Within each cycle, the detonator master device sends a heartbeat data packet to the slave device. This heartbeat data packet includes a sequence number, timestamp, and verification information. The slave device evaluates the real-time performance of the communication link by observing the time interval and integrity of the received heartbeat data packets. Specifically, the slave device calculates the success rate of heartbeat data packet reception, the number of consecutive data packet losses, and the bit error rate (BER) based on the verification results (such as CRC errors) within the data packets. Simultaneously, the slave device records the number of retransmission requests from the detonator master device triggered by transmission failures per unit time. These metrics are weighted to generate a comprehensive communication quality score, with the score range mapped to a preset quality level (e.g., 0-100 points). The communication quality score reflects the stability and reliability of the link; a higher score indicates better performance in metrics such as BER, retransmission frequency, and heartbeat loss rate. The periodically updated score provides a quantitative basis for subsequent anomaly detection and recovery decisions, ensuring dynamic monitoring of the link status.

[0054] S103. When the communication quality score is lower than the preset quality threshold, the system enters a safety lock state, generates a communication status report based on the communication quality score, and sends the communication status report to the detonator host to restore communication synchronization with the detonator host.

[0055] For example, when the communication quality score consistently falls below a preset quality threshold, the detonator slave device triggers a safety lockout state. In this state, the slave device immediately suspends the execution of high-risk operation commands (such as detonation or charging) and freezes unnecessary data interactions, retaining only minimal status feedback functionality. Simultaneously, the slave device integrates raw data such as bit error rate, retransmission count, and heartbeat loss count from multiple heartbeat detection cycles to generate a structured communication status report. This report is encapsulated in a specific encoding format and sent to the detonator master device via a reserved secure channel, providing data support for the master device to optimize its scheduling strategy. Subsequently, the slave device initiates a communication synchronization recovery process: attempting to quickly rebuild the communication synchronization state by reusing parameters from previously successful connections, or rescanning the channel to capture the synchronization code sent by the master device. If reusing parameters fails to restore communication, the scanning range is gradually expanded until a stable communication synchronization state is re-established. This coordinated design of the safety lockout state and recovery mechanism avoids the risk of misoperation under abnormal link conditions and improves the self-healing efficiency of the communication link through closed-loop feedback.

[0056] This application provides a communication method for a detonator slave device. The method includes: acquiring a synchronization code sent by the detonator master device; entering a communication synchronization state based on the synchronization code; after entering the communication synchronization state, cyclically entering a preset heartbeat detection cycle; determining a communication quality score based on the heartbeat data packets sent by the detonator master device within the heartbeat detection cycle; when the communication quality score is lower than a preset quality threshold, entering a safety lock state; generating a communication status report based on the communication quality score; sending the communication status report to the detonator master device; and restoring the communication synchronization state with the detonator master device. In the above method, the synchronization code ensures high reliability of the initial connection between the slave and master devices; through periodic heartbeat data packet analysis, the communication link quality score is quantified in real time, and combined with the preset quality threshold, accurate judgment of abnormal states is achieved, avoiding unnecessary interruptions caused by misjudgments. At the fault recovery level, a tiered recovery strategy is adopted: when the communication quality score is lower than the threshold, a safety lock state is first triggered, prohibiting detonation operations and generating a status report containing indicators such as bit error rate and retransmission count, which is then fed back to the master device. Subsequently, the communication synchronization state with the detonator master device is restored, ensuring a high success rate of connection reconstruction in extreme scenarios.

[0057] To more clearly illustrate the technical solution of this application, the technical solution of this application will be described below through specific embodiments. It should be noted that the specific embodiments are used to expand the description of the technical solution of this application, and are not intended to limit this application.

[0058] In some embodiments, the synchronization code sent by the detonator host is obtained, and the communication synchronization state is entered according to the synchronization code, including: S1011-S1015.

[0059] S1011. After power-on, enter the listening mode and obtain the synchronization code sent by the detonation board host.

[0060] For example, after the detonator slave unit is powered on, it immediately activates the communication interface and enters listening mode. In this mode, the slave unit continuously scans the communication channel, detecting synchronization code signals periodically or triggered by the detonator master unit. The synchronization code is a specific encoded sequence used by the detonator master unit to identify itself and establish initial parameters for the communication link, containing key information such as baud rate, frame length, and parity check method. The slave unit identifies and extracts the synchronization code through a signal acquisition module, ensuring the accuracy of subsequent parameter calculations. The listening mode design avoids channel interference caused by the slave unit actively sending data in an unsynchronized state, while providing raw input for subsequent baud rate and frame format calculations. The process of acquiring the synchronization code must meet preset signal strength and encoding integrity conditions. If the synchronization code is missing or distorted, the slave unit will extend the listening time until a valid signal is successfully acquired.

[0061] S1012. Calculate the baud rate and frame format based on the synchronization code, set the communication interface according to the baud rate, and enter the silent standby state.

[0062] For example, after parsing the synchronization code, the detonator slave device calculates the baud rate and frame format parameters of the detonator master device using timing analysis and encoding structure parsing algorithms. The baud rate is determined by measuring the duration of the high and low levels in the synchronization code, while the frame format is parsed based on the identification fields (such as start bit, stop bit, and parity bit configuration) carried at the end of the synchronization code. After calculation, the detonator slave device writes the baud rate parameter into the register of the communication interface and configures the transmit and receive timing to match the data transmission rate of the detonator master device. The frame format parameters are used to define the parsing rules for subsequent data packets, including data length, parity method, etc. After the parameters are set, the detonator slave device enters a silent standby state, disables the active transmission function, and retains only the receiving and parsing capabilities. The silent standby state ensures that the bus is controlled only by the detonator master device, avoiding conflicts caused by multiple detonator slave devices competing for the channel, and preparing for the reception and response to subsequent call-out commands.

[0063] S1013. Obtain the name call command broadcast by the detonator host, parse the name call command based on the frame format, and obtain the first flag.

[0064] For example, in silent standby mode, the detonator slave continuously listens to the channel, capturing the name-calling instructions broadcast by the detonator master. The name-calling instruction is a command frame generated by the detonator master according to a preset polling table, and its data structure conforms to the synchronized frame format requirements. The detonator slave decodes the name-calling instruction based on the parsed frame format parameters (such as start bit, data field length, and check bit position), extracting the target device identification field (i.e., the first flag) from the instruction. The first flag is typically the detonator slave's unique identification code or address information, used to identify the detonator slave object that the detonator master is currently requesting to interact with. During the parsing process, the detonator slave synchronously performs a CRC check to verify the integrity of the name-calling instruction. If the check fails, the detonator slave discards the current instruction and continues to wait for the next broadcast. Successfully parsed first flags are compared with locally stored preset parameters to determine whether to initiate a response process.

[0065] S1014. When the first flag and the preset second flag are the same, send a response request to the detonator host. The preset second flag is the identification flag of the detonator slave.

[0066] For example, the detonator slave compares the parsed first flag with a preset second flag stored locally. The preset second flag is an identification identifier pre-written into the detonator slave, used to uniquely distinguish different detonator slaves in the communication link. When the two match perfectly, the detonator slave determines itself as the current polling target, immediately activates the sending function of the communication interface, and generates a response request data packet containing its own identity confirmation information. The frame format and baud rate parameters of the response request use the calculation results from the synchronization phase to ensure compatibility with the detonator master. After sending, the detonator slave re-enters a silent standby state, waiting for further instructions from the detonator master. If the first flag and the second flag do not match, the detonator slave remains silent to avoid increasing bus load by responding to non-local instructions. This mechanism achieves precise instruction addressing and conflict avoidance, ensuring orderly communication in scenarios with multiple detonator slaves.

[0067] S1015. After receiving the response from the detonator host, enter the communication synchronization state and cache the baud rate and frame format to the preset database.

[0068] For example, after the detonator slave sends a response request, it continuously monitors the channel to capture the response reply from the detonator master. The response reply is a valid confirmation signal from the detonator master to the detonator slave's identity, containing a communication link ready instruction or error code information. Upon receiving a valid response reply (e.g., verification passed and the content is a confirmation instruction), the detonator slave formally enters the communication synchronization state. In this state, bidirectional data transmission can occur between the detonator slave and the detonator master, and operational tasks such as detonation control and status reporting can be performed. Simultaneously, the detonator slave writes the currently used baud rate and frame format parameters into a preset database (such as non-volatile memory or a cache register) as priority connection parameters for subsequent anomaly recovery. The database caching mechanism ensures that after communication interruption, the detonator slave can quickly recall historical valid parameters to attempt resynchronization, reducing the time consumed by full parameter scanning. Maintaining the communication synchronization state relies on periodic heartbeat detection and instruction interaction, laying the operational foundation for subsequent communication quality monitoring and anomaly handling.

[0069] In some embodiments, a communication quality score is determined based on the heartbeat data packets sent by the detonator host during the heartbeat detection period, including: S1021-S1024.

[0070] S1021. Perform error checking based on the heartbeat data packets to obtain the bit error rate.

[0071] For example, after receiving a heartbeat data packet from the detonator master during the heartbeat detection cycle, the detonator slave device initiates an error checking process. Error checking is achieved by verifying the integrity and accuracy of the data packet: the detonator slave device extracts the verification field (such as the CRC checksum) from the heartbeat data packet and compares it with the verification result recalculated from the data packet content. If the two are inconsistent, the heartbeat data packet is determined to have a transmission error and recorded as an erroneous packet. The bit error rate is calculated based on the ratio of the number of erroneous packets within the statistical window to the total number of received heartbeat data packets. For example, if 100 data packets are received cumulatively within a 10-second period, and 2 of them fail verification, the bit error rate is 2%. The bit error rate reflects the signal quality and anti-interference capability of the communication link; a higher value indicates more severe distortion or noise interference during data transmission. The detonator slave device uses the real-time updated bit error rate as one of the core indicators for communication quality scoring, providing a data basis for subsequent anomaly detection. The continuous execution of error checking ensures dynamic monitoring of the link status and avoids misjudgments due to occasional errors.

[0072] S1022. In response to the data feedback instruction sent by the detonator host, send the heartbeat data packet back to the detonator host and record the number of feedback failures per unit time.

[0073] For example, when the detonator master sends a data return command, the detonator slave immediately encapsulates the currently stored heartbeat data packet according to a preset format and returns it to the detonator master via the communication interface. The data return command is a control signal used by the detonator master to verify the integrity and responsiveness of the detonator slave's data reception, requiring the detonator slave to complete the return operation within a specified time. During the return process, the detonator slave monitors the operation results: if it does not receive a reception confirmation signal from the detonator master within the timeout threshold, or if the returned data fails to reach the detonator master due to collisions, signal attenuation, or other reasons, it is considered a return failure. The detonator slave counts the number of return failures per unit time (e.g., 1 minute), and this indicator directly reflects the bidirectional transmission stability of the communication link. An increase in the number of return failures may be caused by channel congestion, hardware failure, or environmental interference, and its value is negatively correlated with the communication quality score. This mechanism, through proactive interactive testing, supplements the limitations of one-way bit error rate detection and enhances the comprehensive assessment of link availability.

[0074] S1023. If no heartbeat data packet is received within a heartbeat detection cycle, the preset heartbeat loss count is incremented by one to obtain the latest heartbeat loss count. The latest heartbeat loss count is reset to the preset heartbeat loss count after a heartbeat data packet is received.

[0075] For example, at the end of the heartbeat detection cycle, the detonator slave device checks whether it has successfully received the heartbeat data packet sent by the detonator master device. If no valid heartbeat data packet is detected within the cycle, the detonator slave device increments a preset heartbeat loss counter to generate the latest heartbeat loss count. For example, the preset initial value is 0, and the counter accumulates to 3 after three consecutive cycles without receiving a heartbeat data packet. The accumulation mechanism of the heartbeat loss count is used to identify the persistence of communication interruption: short-term loss may be caused by transient interference, while long-term loss indicates a serious link failure. When the detonator slave device receives a valid heartbeat data packet again in a subsequent cycle, the counter is immediately reset to the initial value, eliminating interference from historical loss records. This design distinguishes between occasional packet loss and persistent interruption, avoiding excessive recovery operations triggered by brief anomalies. The dynamic update of the heartbeat loss count provides time-series status information for communication quality scoring, enhancing the predictive ability of link deterioration trends.

[0076] S1024. Determine the communication quality score based on the bit error rate, the number of failed transmissions, or the latest number of lost heartbeats.

[0077] For example, the communication quality score is a comprehensive evaluation result based on multiple dimensions, including bit error rate, number of backhaul failures, and number of lost heartbeats. The detonator slave assigns weight coefficients to each indicator, such as bit error rate (50%), backhaul failures (30%), and lost heartbeats (20%), and calculates the total score (e.g., 0-100) through weighted averages. Bit error rate directly affects data reliability; a high bit error rate leads to a significant drop in score. Backhaul failures reflect the reliability of bidirectional interaction; frequent failures indicate asymmetric defects in the link. Lost heartbeats quantify the risk of link interruption; consecutive losses trigger a precipitous drop in score. The score results are mapped to preset quality levels (e.g., excellent, good, warning, fault), with different processing strategies for each level: excellent level maintains the current link, warning level initiates diagnostic logging, and fault level triggers a security lockout. The periodic generation and reporting of the communication quality score allows the detonator master to monitor the link status in real time, optimize resource scheduling and fault intervention strategies, thereby improving the overall robustness and response efficiency of the communication system.

[0078] In some embodiments, generating a communication status report based on a communication quality score includes: after every first preset number of heartbeat detection cycles, generating a communication status report based on the bit error rate, the number of backhaul failures, the latest number of lost heartbeats, and the communication quality score.

[0079] For example, the first preset quantity includes 3-30. Setting the first preset quantity helps the detonator host and detonator slave to re-establish the connection. Therefore, it is necessary to prevent long-term communication interruptions on the link and to avoid frequent communication reconnection caused by occasional communication anomalies.

[0080] In some embodiments, the detonator host is equipped with a trained BiLSTM network. The detonator host receives a communication status report and inputs the communication status report into a bidirectional LSTM model for failure mode analysis. The specific steps include: S301-S305.

[0081] S301. Obtain time-series data of bit error rate, number of transmission failures, number of heartbeat loss and communication quality score of the detonation board slave device, and construct a four-dimensional feature matrix containing mean, variance and number of consecutive anomalies through a sliding window.

[0082] For example, a communication quality time-series dataset of the detonator slave device is obtained. The dataset includes bit error rate, number of backhaul failures, number of heartbeat loss, and communication quality score. Continuous communication events are captured through a preset time window, with the window length covering at least three complete heartbeat cycles. The raw data is cleaned, and the sliding window difference method is used to eliminate baseline drift. The gradient of bit error rate change between adjacent windows is calculated. A four-dimensional feature matrix (time window × communication parameters × statistical indicators × device number) is constructed, where the statistical indicators include mean, variance, extreme values, and number of consecutive anomalies. Failure status labels are simultaneously labeled, and the labels are automatically generated based on the cumulative value of heartbeat loss exceeding a set threshold or the communication quality score falling below a critical value.

[0083] S302. Input the four-dimensional feature matrix into the BiLSTM network, extract the features of the period of sudden increase in bit error rate through the time attention mechanism, and generate a deep feature vector with anomaly label by combining event-driven pooling.

[0084] For example, a four-dimensional feature matrix is ​​input into a pre-defined communication quality analysis network, which includes a time-series modeling submodule, an event detection submodule, an attention-weighting submodule, and a feature fusion submodule. The time-series modeling submodule performs bidirectional LSTM processing on the four-dimensional feature matrix, where the forward LSTM extracts communication state degradation time-series features, and the inverse LSTM extracts fault tracing time-series features, outputting an original time-series feature vector that fuses the forward and inverse features. The event detection submodule scans the original time-series feature vector in real time. When the number of backhaul failures exceeds a preset threshold or the number of lost heartbeats shows a monotonically increasing trend within three consecutive time windows, an event trigger flag is generated at the corresponding time step. Based on the event trigger flag, the attention-weighting submodule performs feature enhancement on periods of sudden increases in bit error rate (BER change rate > 10% / ms), using a scaled dot product attention mechanism to calculate the weight coefficients for each time step, thus doubling the feature weights for periods of sudden increases in BER. The feature fusion submodule performs gated fusion of the feature vector with event trigger flags and the attention-weighted feature vector, dynamically adjusting the contribution ratio of normal communication features and abnormal features to generate a fused enhanced feature vector. Event-driven pooling is then performed on the enhanced feature vector, extracting local maximum eigenvalues ​​within the windows before and after the time step corresponding to the event trigger flag, ultimately outputting a compressed depth feature vector with anomaly markers.

[0085] S303. Based on deep feature vectors and real-time communication quality scores, a dynamic failure risk value is constructed by fusing the output of a dual-branch network, and an adaptive decision threshold that varies with the bit error rate gradient is designed.

[0086] For example, a dual-branch network constructed based on deep feature vectors and real-time communication quality scores extracts an abstract representation of bit error rate (BER) change patterns, backhaul failure correlations, and heartbeat loss timing features through a fully connected transformation of the deep feature vectors in the main branch, outputting a basic failure probability prediction value. The auxiliary branch receives the real-time communication quality score sequence, calculates the score decay rate using a sliding window, and generates a dynamic compensation factor through an S-shaped transformation to reflect the immediate degree of degradation of the current communication link. The outputs of the two branches are weighted and superimposed in the fusion layer, with the weight coefficients determined according to the principle of maximizing the area under the ROC curve of the validation set, ensuring that the sensitivity of real-time score changes is prioritized in scenarios with fluctuating BER. The dynamic failure risk value integrates historical feature evolution patterns and current state change information to form a comprehensive evaluation index that takes into account both short-term and long-term communication quality changes. The adaptive decision threshold adjustment mechanism is strongly correlated with the BER gradient. When the BER change gradient ΔBER is detected to exceed a preset critical value, the dynamic threshold decay mode is activated, causing the decision threshold to decrease linearly with the rate of BER degradation, thereby improving the early warning sensitivity in high-risk scenarios. This mechanism effectively overcomes the lag problem of traditional fixed thresholds in sudden interference scenarios by introducing a bit error rate gradient feedback loop. At the same time, it uses Focal Loss as the training objective function to enhance the learning ability of low-frequency high-risk samples and ensure the optimal distribution of the classification boundary in the feature space.

[0087] S304. Perform four-quadrant analysis using failure risk value and decision threshold to obtain failure analysis results. Then, perform feature inversion and localization on the failure analysis results to obtain key parameter combinations.

[0088] For example, the combination of failure risk value and adaptive decision threshold drives the operation of the four-quadrant analysis model. A two-dimensional decision plane is constructed using the mean bit error rate (BER) as the x-axis and the heartbeat loss rate (WDR) as the y-axis, dividing the model into four regions: normal, observation, warning, and failure. When a data point falls into the warning region, a feature inversion localization process is triggered. The gradient ascent method is used to generate the minimum feature perturbation set that causes the failure risk value to cross the decision threshold, identifying the key parameter combinations leading to state transition. The inversion process focuses on BER surge event windows, dense backhaul failure intervals, and periods of continuous heartbeat loss. By comparing the differences between the original features and the perturbation features, the contribution intensity of each communication parameter to state deterioration is quantified. The extraction of key parameter combinations follows the principle of maximum correlation and minimum redundancy, prioritizing the three-dimensional feature intersection that simultaneously satisfies high BER gradient, high backhaul failure frequency, and continuously increasing WDR. This combination not only includes explicit anomaly indicators but also captures implicit coupling relationships between parameters, such as the nonlinear decay phenomenon of communication quality score caused by high-frequency WDR. The localization results are visualized and mapped to each layer of the device's communication protocol stack, providing directional input for subsequent root cause analysis.

[0089] S305. Apply the hierarchical correlation propagation method to the combination of key parameters, calculate the contribution ranking of communication parameters, and determine the cause of failure. The causes of failure include: link layer failure dominated by backhaul failure or protocol layer out-of-sync dominated by heartbeat loss.

[0090] For example, the key parameter combination input hierarchical correlation propagation algorithm traces back from the fully connected classification layer to the original input feature space, decomposing the contribution weights of each communication parameter in the neural network decision path layer by layer. The algorithm uses gradient rules to assign feature importance in the BiLSTM layer and calculates the time step influence based on the weight matrix in the attention layer, ultimately generating a contribution ranking covering bit error rate fluctuation patterns, backhaul failure time sequence distribution, and heartbeat loss event density. Parameters corresponding to peak contribution values ​​are identified as dominant failure factors: when the contribution of backhaul failures exceeds 40% of the threshold, combined with the correlation between its occurrence time and retransmission mechanism response delay, it is determined to be protocol data unit loss caused by physical layer link instability; when the contribution of heartbeat loss exceeds 30% and exhibits periodic burst characteristics, it is determined to be an abnormal handshake process caused by protocol layer clock synchronization inaccuracy. The judgment process integrates the communication protocol state machine model to verify the logical consistency between data-driven conclusions and physical layer / protocol layer failure modes, ensuring that the root cause diagnosis results simultaneously meet statistical significance and engineering interpretability. The contribution heatmap provides a precise fault reproduction path for on-site maintenance by identifying high-weight time windows and parameter combinations.

[0091] In some embodiments, a communication quality score is determined based on the bit error rate, the number of return failures, or the latest number of lost heartbeats, including: S241-S244.

[0092] S241. If the bit error rate is greater than the preset bit error threshold, the communication quality score is set to unqualified.

[0093] For example, a preset bit error rate threshold (e.g., 1%) is a tolerance limit set based on historical data and safety requirements, used to distinguish between acceptable random errors and systemic failures. When the bit error rate exceeds this threshold, it indicates that there is continuous interference in the channel or a hardware anomaly, resulting in a significant decrease in the proportion of valid data. At this time, the detonator slave device marks the communication quality score as "unqualified," triggering a link quality degradation response. The bit error rate exceeding the limit may be caused by electromagnetic interference, signal attenuation, or transceiver failure. After the score degradation, the detonator slave device prioritizes error logging and alarm reporting to prevent erroneous data from affecting the security of control command execution.

[0094] S242. If the number of failed transmissions exceeds the preset first threshold, the communication quality score will be set to unqualified.

[0095] For example, a threshold number (e.g., more than 5 times per unit time) is set based on business tolerance to identify abnormal states of frequent interaction failures. When the number of return transmission failures exceeds this threshold, it indicates an asymmetric fault in the link (e.g., uplink channel blockage or malfunction of the detonator slave's transmitting module), resulting in severely impaired command response capabilities. At this time, the communication quality score is set to "unqualified," and the detonator slave suspends non-critical data interaction to concentrate resources on troubleshooting the source of the fault. The statistics of the number of return transmission failures, combined with a timeout retry mechanism, distinguish between temporary congestion and hardware failure. After the threshold is triggered, the detonator slave can initiate redundant channel switching or a reduced-speed reconnection strategy to restore basic communication functions.

[0096] S243. If the latest number of lost heartbeats is greater than the preset second threshold, the communication quality score is set to unqualified.

[0097] For example, the latest heartbeat loss count records the number of consecutive cycles in which the detonator slave device fails to receive heartbeat data packets, used to quantify the duration of the communication interruption. A second threshold (e.g., 3 consecutive losses) is set based on the system's fault-tolerant design to avoid misjudging occasional packet loss as a serious fault. When the heartbeat loss count exceeds this threshold, it indicates a complete link interruption or a host malfunction, and the detonator slave device cannot maintain basic communication heartbeat synchronization. At this time, the communication quality score is marked as "unqualified," triggering a safety lockout state and initiating a self-recovery process (e.g., interface reset, parameter resynchronization). The threshold setting needs to balance fault sensitivity and anti-interference capability; for example, in a strong interference environment, the threshold can be appropriately increased to reduce frequent recovery operations caused by false triggers. The dynamic reset mechanism for the heartbeat loss count (resetting to zero upon receiving a new data packet) ensures that only degraded responses are made to persistent interruptions.

[0098] S244. In other cases, set the communication quality score to qualified.

[0099] For example, when the bit error rate, the number of failed transmissions, and the latest heartbeat loss count all do not exceed their respective preset thresholds, the communication quality score is determined to be "qualified," indicating that the link is in a stable and available state. Under a qualified score, the detonator slave maintains normal communication mode, performs core services such as detonation control and status reporting, and continuously monitors real-time indicators. The confirmation of a qualified state relies on the joint judgment of multiple thresholds; fluctuations in a single indicator (such as a brief increase in the bit error rate) will not affect the overall score if they do not exceed the limit. When the score is qualified, the detonator slave periodically sends a link health report (including raw data such as bit error rate and number of failed transmissions) to the host for the host to optimize scheduling strategies. Maintaining a qualified state requires periodic indicator updates and threshold comparisons to ensure that the score always reflects the true state of the link, providing low-latency and highly reliable communication guarantees for high-priority operations.

[0100] In some embodiments, restoring communication synchronization with the detonator host includes: S1031-S1032.

[0101] S1031. Within the second preset number of heartbeat detection cycles, retry to restore communication synchronization with the detonator host according to the baud rate and frame format.

[0102] For example, when the communication quality score falls below a threshold, triggering the recovery process, the detonator slave device prioritizes calling the cached baud rate and frame format parameters, and attempts to rebuild the communication synchronization state with the detonator master device within a second preset number of heartbeat detection cycles (e.g., 5 cycles). The second preset number represents the number of fast recovery attempts allowed by the detonator slave device, and its value is set based on the historical average recovery time and service fault tolerance requirements. During the retry process, the detonator slave device uses the baud rate parameters stored in the database to configure the communication interface, ensuring that the transmission and reception timing is consistent with the detonator master device; at the same time, it parses the response signal of the detonator master device based on the locked frame format to verify the effectiveness of the link reconstruction. If the heartbeat data packet of the detonator master device is successfully received and parsed within the preset period, the communication synchronization state is determined to be restored, the detonator slave device exits the recovery process and returns to normal communication mode. This stage reduces the time cost of full parameter scanning by reusing historical parameters, and is suitable for scenarios with short-term interference or temporary link interruption.

[0103] S1032. After the second preset number of heartbeat detection cycles, the adaptive recovery process is entered, and the communication synchronization state with the detonator host is restored through the adaptive recovery process.

[0104] For example, if communication synchronization fails to be restored within the second preset number of heartbeat detection cycles, the detonator slave determines that the currently buffered baud rate or frame format parameters are invalid and initiates an adaptive recovery process. This process is a deep recovery mechanism; the detonator slave no longer relies on historical parameters but instead rebuilds the link by rescanning the channel, capturing the detonator host signal, and dynamically parsing the new parameters. The adaptive recovery process includes interface reset, synchronization code monitoring, and parameter adaptation, covering a comprehensive recovery action from the hardware layer to the protocol layer. The triggering of this process indicates that there is a structural anomaly in the link (such as baud rate drift, frame format change, or hardware failure), requiring a more thorough configuration reset to eliminate potential errors. During adaptive recovery, the detonator slave suspends the execution of service commands and concentrates resources to complete the reconstruction of basic communication parameters, ensuring the priority and reliability of the recovery operation.

[0105] In some embodiments, the communication synchronization state with the detonator host is restored through an adaptive recovery process, including: S321-S323.

[0106] S321. Reset the communication interface, re-enter the listening mode, and wait for the detonator host to resend the synchronization code.

[0107] For example, after the adaptive recovery process is initiated, the detonator slave device performs a hardware and software reset operation on the communication interface: disabling the current interface driver (such as the RS485 interface driver / USART port driver), clearing the transmit and receive buffers, and reinitializing the register configuration. The reset operation eliminates potential deadlocks, buffer overflows, or timing errors in the interface, providing a clean hardware environment for parameter reconstruction. After the interface reset is complete, the detonator slave device re-enters the listening mode, activates the signal receiving circuit, and scans the communication channel, waiting for the synchronization code signal to be retransmitted by the detonator master device. In listening mode, the detonator slave device does not actively send data; it only captures the synchronization code broadcast by the detonator master device through a high-sensitivity receiving module, avoiding interference from its own signal that could affect synchronization code recognition. The goal of this stage is to reacquire a valid synchronization code from the detonator master device, providing a reference signal for subsequent baud rate and frame format updates.

[0108] S322. Based on the synchronization code resent by the detonator host, obtain the updated baud rate and the updated frame format.

[0109] For example, after successfully capturing the synchronization code retransmitted by the detonator master, the detonator slave initiates the parameter parsing algorithm. The updated baud rate is calculated by measuring the duration of key bits (such as the start and stop bits) in the synchronization code, ensuring a strict match with the current clock reference of the detonator master. The updated frame format is determined by the configuration fields (such as data bit length, checksum type, and terminator identifier) ​​embedded in the decoded synchronization code, ensuring the consistency of subsequent data packet parsing rules. During parameter parsing, the detonator slave performs multiple checks (such as level stability detection and encoding compliance verification) to eliminate erroneous results caused by noise interference. The updated baud rate and frame format will overwrite historical cached parameters, serving as the core basis for current link reconstruction. This stage achieves dynamic adaptation of communication parameters, resolving parameter mismatch issues caused by changes in the detonator master configuration or environmental factors.

[0110] S323. Reset the communication interface according to the updated baud rate and complete bidirectional communication authentication with the detonator host based on the updated frame format to restore the communication synchronization state.

[0111] For example, after the parameters are updated, the detonator slave writes the updated baud rate into the clock generator of the communication interface and adjusts the data transmission rate to synchronize with the detonator master. Simultaneously, it configures the data packet parser according to the updated frame format to ensure structural compatibility of transmitted and received data. After the communication interface is reconfigured, the detonator slave actively sends an authentication request to the detonator master. This request includes a pre-set second identifier (identity identifier) ​​and is encapsulated using the new frame format. Upon receiving the request, the detonator master verifies the identifier's validity and returns a response data packet containing a confirmation instruction. After successfully parsing the response packet and verifying its validity, the detonator slave determines that the two-way communication authentication is successful and officially restores the communication synchronization state. The authentication mechanism prevents unauthorized devices from accessing the network, ensuring the legitimacy and security of the link reconstruction. After restoration, the detonator slave stores the updated parameters in the database for subsequent use and reactivates the heartbeat detection and service instruction response functions.

[0112] Please see Figure 2 , Figure 2 This is a schematic block diagram of a communication device for a detonator slave device provided in an embodiment of this application. The communication device 200 of the detonator slave device is used to execute the aforementioned communication method of the detonator slave device. The communication device 200 of the detonator slave device can be configured in a server.

[0113] The server can be a standalone server, a server cluster, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0114] like Figure 2 As shown, the communication device 200 of the detonator slave includes: a communication connection module 201, a communication scoring module 202, and a communication recovery module 203.

[0115] The communication connection module 201 is used to obtain the synchronization code sent by the detonator host and enter the communication synchronization state according to the synchronization code.

[0116] The communication scoring module 202 is used to cycle through a preset heartbeat detection cycle after entering the communication synchronization state, and determine the communication quality score based on the heartbeat data packets sent by the detonator host obtained within the heartbeat detection cycle.

[0117] The communication recovery module 203 is used to enter a safety lock state when the communication quality score is lower than a preset quality threshold, generate a communication status report based on the communication quality score, and send the communication status report to the detonator host to restore the communication synchronization state with the detonator host.

[0118] This application provides an electronic device, which includes a memory and a processor; the memory is used to store a computer program; the processor is used to execute the computer program and, when executing the computer program, implement the communication method of the detonator slave device as described in any of the embodiments of this application.

[0119] This application provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it enables the processor to implement a communication method for a detonator slave device as described in any of the embodiments of this application.

[0120] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A communication method of a primer board slave machine, characterized by, The method comprises: acquiring a synchronization code sent by a detonator host, entering a communication synchronization state according to the synchronization code, and caching a baud rate and a frame format calculated according to the synchronization code to a preset database; after entering the communication synchronization state, entering a preset heartbeat detection period cyclically, determining a communication quality score according to a heartbeat data packet sent by the detonator host in the heartbeat detection period; when the communication quality score is lower than a preset quality threshold, entering a safety locking state, generating a communication state report according to the communication quality score, and sending the communication state report to the detonator host, retrying to recover the communication synchronization state with the detonator host according to the baud rate and the frame format in a second preset number of the heartbeat detection periods, and entering an adaptive recovery process after the second preset number of the heartbeat detection periods, resetting a communication interface, re-entering a listening mode, waiting for a synchronization code re-sent by the detonator host, obtaining an updated baud rate and an updated frame format according to the synchronization code re-sent by the detonator host, resetting the communication interface according to the updated baud rate, and completing bidirectional communication authentication with the detonator host based on the updated frame format to recover the communication synchronization state.

2. The method of claim 1, wherein the initiator slave is a blasting cap. The acquiring a synchronization code sent by a detonator host, entering a communication synchronization state according to the synchronization code comprises: entering a listening mode after power-on, and acquiring a synchronization code sent by the detonator host; calculating a baud rate and a frame format according to the synchronization code, setting a communication interface according to the baud rate, and entering a silent standby state; acquiring a roll call instruction broadcasted by the detonator host, analyzing the roll call instruction based on the frame format to obtain a first flag; when the first flag is the same as a preset second flag, sending a response request to the detonator host, the preset second flag being an identity flag of the detonator slave; after receiving a response reply sent by the detonator host, entering the communication synchronization state.

3. The method of claim 1, wherein the initiator slave communicates by, The determining a communication quality score according to a heartbeat data packet sent by the detonator host in the heartbeat detection period comprises: performing error code checking according to the heartbeat data packet to obtain an error code rate; in response to a data back transmission instruction sent by the detonator host, back transmitting the heartbeat data packet to the detonator host, and recording a back transmission failure number per unit time; if the heartbeat data packet is not received in one heartbeat detection period, adding one to a preset heartbeat loss number to obtain a latest heartbeat loss number, the latest heartbeat loss number being reset to the preset heartbeat loss number after the heartbeat data packet is received; determining a communication quality score according to the error code rate, the back transmission failure number, or the latest heartbeat loss number.

4. The method of claim 3, wherein the initiator slave is a blasting cap. The generating a communication state report according to the communication quality score comprises: generating a communication state report according to the error code rate, the back transmission failure number, the latest heartbeat loss number, and the communication quality score every interval of a first preset number of the heartbeat detection periods.

5. The method of claim 3, wherein the initiator slave communicates by transmitting a signal to the master. The communication quality score is determined according to the error rate, the number of backhaul failures, or the number of latest heartbeat loss times. If the error rate is greater than a preset error threshold, the communication quality score is set as unqualified; or, If the number of backhaul failures is greater than a preset first number threshold, the communication quality score is set as unqualified; or, If the number of latest heartbeat loss times is greater than a preset second number threshold, the communication quality score is set as unqualified. In other cases, the communication quality score is set as qualified.

6. A communication device for a primer boat, characterized by The communication device of the detonator slave is configured to perform the communication method of the detonator slave as claimed in any one of claims 1-5, and the communication device of the detonator slave comprises: a communication connection module configured to obtain a synchronization code sent by a detonator master, enter a communication synchronization state according to the synchronization code, and cache a baud rate and a frame format calculated according to the synchronization code to a preset database; a communication score module configured to, after entering the communication synchronization state, enter a preset heartbeat detection period cyclically, and determine a communication quality score according to heartbeat data packets sent by the detonator master obtained in the heartbeat detection period; a communication recovery module configured to, when the communication quality score is lower than a preset quality threshold, enter a safe locking state, generate a communication state report according to the communication quality score, and send the communication state report to the detonator master, retry to recover the communication synchronization state with the detonator master according to the baud rate and the frame format in a second preset number of the heartbeat detection periods, and enter an adaptive recovery process after the second preset number of the heartbeat detection periods, reset the communication interface, re-enter a listening mode, wait for a synchronization code re-sent by the detonator master, obtain an updated baud rate and an updated frame format according to the synchronization code re-sent by the detonator master, re-set the communication interface according to the updated baud rate, and complete bidirectional communication authentication with the detonator master based on the updated frame format to recover the communication synchronization state.

7. An electronic device, comprising: The electronic device comprises a memory and a processor; The memory is configured to store a computer program; The processor is configured to execute the computer program and implement the communication method of the detonator slave as claimed in any one of claims 1-5 when the computer program is executed.

8. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program, and the computer program causes the processor to implement the communication method of the detonator slave as claimed in any one of claims 1-5 when the computer program is executed by the processor.

Images