A high-frequency electrotome implicit fault prediction method based on internal bus perturbation

Abstract

The application discloses a high-frequency electrotome implicit fault prediction method based on internal bus micro-perturbation, and particularly relates to the technical field of high-frequency electrotome fault prediction, and is used for solving the problem that the time sequence margin of the internal bus link of the existing high-frequency electrotome gradually shrinks and the implicit abnormality is difficult to be recognized and positioned in advance when no explicit communication fault occurs. By freezing the detection state version when the radio frequency output and power drive are prohibited and the protection transaction is idle, a witness transaction chain is formed by selecting a read-only transaction, and according to the total time of the reference idle time, the minimum idle time of the protocol and the micro-perturbation acceptance boundary, the forward and reverse micro-perturbation transactions are generated, the first mismatch section and the boundary shrinkage trend are determined by combining the anchoring and recovery transactions, so that the implicit time sequence change of the internal bus link is recognized under the condition of not entering the radio frequency output state, and the fault development trend record of the corresponding section is formed.

Description

Technical Field

[0001] This invention relates to the field of high-frequency electrosurgical unit (ESU) fault prediction technology, specifically to a method for predicting latent faults in ESUs based on internal bus perturbation. Background Technology

[0002] A high-frequency electrosurgical unit typically consists of a main controller, a logic controller, an RF sensing unit, a power drive circuit, and a protection controller. The control nodes communicate via an internal bus, exchanging status read requests, control information, and returned data. During operation, the main controller coordinates and controls RF energy output, instrument connections, and fault protection based on the RF output status, power drive status, protection status, and the operating status returned by the sensing unit. Existing equipment generally determines the operating status of the internal communication link and control nodes through power-on self-test, register status reading, communication timeout detection, returned data verification, and protection events such as overcurrent, overvoltage, and temperature.

[0003] Even with aging internal bus connection devices, node response time drift, increased signal recovery time, or slower state latching processes, communication transactions may still be completed within the protocol-specified time. The returned status value, data length, and verification results may also remain normal. Therefore, existing detection methods based on communication failures, returned errors, or protection events struggle to promptly identify implicit changes in link timing margins. Conventional status readings typically only obtain whether a transaction is complete and the final return result, lacking continuous differentiation of time variations across processing intervals during the request's transmission from the main controller to the logic controller, RF sensing unit, and back to the main controller. When response delays occur, it's difficult to determine whether the change originated during request forwarding, sensing unit state formation, return content loading, or the return transmission process.

[0004] Furthermore, the internal communication status of a high-frequency electrosurgical unit is affected by RF output switching, power drive actions, protection transaction insertions, bus configuration changes, and differences in operating status at different detection times. Existing detection records, without consistent correlation between device status, bus configuration, transaction objects, and timing conditions, may directly compare response times obtained under different operating conditions, causing the timing variations of the link itself to become intertwined with device status changes; single response delays are also difficult to confirm as either continuous changes or occasional fluctuations. If detection results cannot be continuously carried over to subsequent detection cycles, the already existing reduction in timing margin is also difficult to establish a comparable historical relationship. Therefore, latent anomalies in the internal bus link are usually only discovered after communication timeouts, abnormal status returns, or device protection actions, and the location and development process of the fault are difficult to determine. Therefore, it is necessary to address the problems of difficulty in early identification of internal bus link timing changes, difficulty in segment location, and difficulty in continuous judgment of changes across detection cycles when the high-frequency electrosurgical unit's normal reading results have not yet shown obvious errors. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a method for predicting latent faults in high-frequency electrosurgical units based on internal bus perturbation, thereby solving the problems mentioned in the background section.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a method for predicting latent faults in high-frequency electrosurgical units based on internal bus perturbation, comprising: 1. Read the RF output status, power drive status, bus configuration and protection transaction status, and freeze the detection status version when RF output and power drive are disabled and protection transactions are idle; 2. Select read-only transactions that do not change the output parameters, protection thresholds and drive status according to the detection status version, and form a witness transaction chain in the order of main controller, logic controller and radio frequency sensing unit, and record the witness time of the node. 3. Determine the perturbation amount based on the baseline idle time, the minimum idle time of the protocol, and the perturbation acceptance boundary of the link health status version, and generate positive perturbation transactions and reverse perturbation transactions with the same total duration after exchanging the previous and subsequent idle times. IV. Within the detection status version, execute the anchoring, forward perturbation, anchoring, reverse perturbation, and recovery transactions in sequence to obtain the node witness time and status summary; V. Based on the node witnessing time, the segment propagation time is formed, and the segment propagation benchmark is established with anchored transactions. The first mismatch segment and the perturbation acceptance boundary are determined based on the positive perturbation, the reverse perturbation and the recovery transaction. 6. Arrange the first mismatched segment and the perturbation acceptance boundary according to the detection status version. Form a fault prediction record based on the boundary contraction of the same segment. Write the prediction record and the upper limit of the perturbation in the pending execution cycle into the link health status version.

[0007] Furthermore, the detection status version includes status read sequence number, device identifier, hardware version, firmware version, confirmation period, RF output status, power drive status, bus configuration, bus configuration version identifier, protection transaction status, and status confirmation parameter version. After all fields of the candidate detection status version are successfully written, the record status and validity flag of the candidate detection status version are rewritten to valid in the same indivisible commit, and the termination time and terminated record status are written to the previous valid detection status version.

[0008] Furthermore, the access direction of a read-only transaction is reading, no write enable signal is generated during execution, the target register is the status register and the original state is maintained after reading; The transaction identifier is written into the fixed transaction identifier field in the read request frame header and remains unchanged along the logic controller, RF sensing unit and return path; The node witness time is recorded in the following order: the main controller requests to send, the logic controller requests to receive, the RF sensing unit requests to receive, the RF sensing unit status is latched, the logic controller returns to load, and the main controller returns to receive.

[0009] Furthermore, the perturbation quantity is the smallest non-negative complete count value among the pre-transaction baseline idle time minus the protocol minimum idle time, the post-transaction baseline idle time minus the protocol minimum idle time, and the perturbation acceptance boundary count value. For forward perturbation transactions, the idle time before the transaction decreases the perturbation amount, while the idle time after the transaction increases the perturbation amount. For reverse perturbation transactions, the idle time before the transaction increases the perturbation amount, while the idle time after the transaction decreases the perturbation amount. The transaction body configuration duration and total duration are the same for both.

[0010] Furthermore, the two anchored transactions use the same read-only transaction content, access direction, target register, return length, node routing, bus clock configuration, and base idle time; Each type of transaction obtains six witness moments and latches a status summary consisting of the return status value, return length, RF output status, power drive status, protection transaction status, and bus configuration version identifier when the main controller fully receives the return content; When the five types of transactions, node witness times, and status summaries are complete, the record status and validity flag of the candidate transaction execution record are rewritten as valid.

[0011] Furthermore, five segments are formed according to the order of the witnessing times of adjacent nodes, and the propagation time of each segment is the count value of the witnessing time of the next node minus the count value of the witnessing time of the previous node. The segment propagation reference is the sum of the segment propagation times corresponding to the two anchor transactions, divided by two and rounded up. The allowable deviation is the larger of the count value obtained by dividing the absolute value of the difference between the segment propagation times corresponding to the two anchor transactions by two and rounding up, and a board-level reference clock count value.

[0012] Furthermore, segments whose absolute value of the difference between the segment propagation time and the segment propagation reference is greater than the allowable deviation are recorded as mismatch segments, and the first mismatch segment is determined according to the first to the fifth segments; When the absolute value of the difference between each segment of the recovery transaction is not greater than the allowable deviation, and the state summaries of the forward perturbation transaction, the reverse perturbation transaction, and the recovery transaction are all consistent with the common state summary of the anchor transaction, the perturbation acceptance boundary is taken as the current perturbation amount when neither of the two perturbation transactions is mismatched, and the current perturbation amount is taken as the current perturbation amount minus one board-level reference clock count value when there is a mismatch, and the current perturbation amount is taken as zero when it is one count value.

[0013] Furthermore, the first mismatch segment and the perturbation acceptance boundary of the detected status version will be recorded as a segment determination record; Records with identical device identifier, hardware version, firmware version, bus configuration version identifier, witness transaction chain identifier, and transaction identifier are arranged by status reading sequence number. Boundary contraction is determined when adjacent records have the same first mismatch segment and the subsequent perturbation acceptance boundary is reduced by at least one board-level reference clock count value. When the boundary of the same segment contracts once, the predicted record writes the contraction evidence but does not reach the trend threshold. When the boundary of the same segment contracts twice in a row, the record writes that there is a hidden fault development trend.

[0014] Furthermore, the perturbation acceptance boundary of the latest valid segment determination record is compared with the perturbation acceptance boundary of the current valid link health status version, and the smaller value is taken as both the perturbation acceptance boundary of the new link health status version and the upper limit of the perturbation in the pending execution cycle. In the same non-split commit, the record status and validity flag of the new link health status version are rewritten to be valid, and the termination time and terminated record status are written to the previous valid link health status version. The next detection cycle will only call the link health status version where the record status and valid flags are both valid and have not been written to the termination time.

[0015] Compared with the prior art, the present invention has the following beneficial effects: 1. By freezing the detection state version when both RF output and power drive are disabled and the protection transaction is idle, a witness transaction chain is formed by selecting read-only transactions that do not change the output parameters, protection threshold, and drive state. Then, based on the reference idle time, the minimum idle time of the protocol, and the perturbation acceptance boundary, positive perturbation transactions and reverse perturbation transactions with the same total duration are generated. The node witness time is obtained in a fixed order of anchoring, positive perturbation, anchoring, reverse perturbation, and recovery. This determines the first mismatch section, the perturbation acceptance boundary, and the continuous boundary contraction of the same section. This allows the high-frequency electrosurgical unit to expose the implicit changes of the internal bus link under time perturbation without entering the RF output state, and forms a fault development trend record corresponding to the specific mismatch section.

[0016] 2. By using two anchor transactions with consistent state summaries to establish the segment propagation benchmark and allowable deviation for each segment, a comparison is made between forward and reverse perturbation transactions with the same total duration and reverse transfer of idle time. The segment propagation time and state summary are then reviewed in conjunction with recovery transactions. This ensures that the first mismatch segment is formed only when the anchoring conditions are consistent, the state of the perturbation transaction remains unchanged, and the transaction chain has been restored. This eliminates the interference of changes in transaction content, differences in timing quantification, and the continued impact of unrestored states on segment determination, allowing perturbation responses to be assigned to the corresponding segment according to a unified judgment boundary.

[0017] 3. By using a globally unique state reading sequence number to arrange the detection status version, the transaction identifier is kept consistent along the main controller, logic controller, and RF sensing unit. A unified record status and indivisible effective rules are set for the detection status version, witness transaction chain record, transaction execution record, segment judgment record, and link health status version. At the same time, the perturbation acceptance boundary and the perturbation limit of the pending execution cycle are kept at the same value and limited to only being maintained or reduced. This prevents the records of different hardware, firmware, bus configurations, and execution batches from being cross-merged, avoids the simultaneous effectiveness of old and new versions or the re-entry of large historical boundaries into subsequent detection cycles, and enables the fault prediction results and their formation basis to be traced along the version relationship. Attached Figure Description

[0018] Figure 1 A schematic diagram of the overall process for predicting latent faults in high-frequency electrosurgical units; Figure 2 A diagram illustrating the status confirmation and detection status version freeze; Figure 3 A schematic diagram illustrating the filtering of read-only transactions and the formation of the witness transaction chain; Figure 4 A schematic diagram illustrating the determination of perturbation quantities and the formation of forward and reverse perturbation transactions; Figure 5 This diagram illustrates the sequential execution of five types of transactions and the acquisition of their status summaries. Figure 6 A schematic diagram showing the node witnessing moments and the propagation time of the five segments; Figure 7 A schematic diagram showing the determination of the first mismatch section and the perturbation acceptance boundary; Figure 8 A schematic diagram is generated to detect the state version arrangement, boundary shrinkage, and fault prediction. Figure 9 This is a schematic diagram of the closed loop for atomic update of the link health status version and write-back in the next cycle. Detailed Implementation

[0019] 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 embodiments of the present invention, and not all embodiments. 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.

[0020] Example: Combined with Appendix Figures 1-9 This embodiment provides a method for predicting latent faults in high-frequency electrosurgical units based on internal bus perturbation, including: 1. Read the RF output status, power drive status, bus configuration, and protection transaction status. Freeze the detection status version when RF output and power drive are disabled and protection transactions are idle. The specific implementation is as follows: During standby or maintenance testing, after the power-on self-test ends and before the RF output is turned on, the high-frequency electrosurgical unit main controller sequentially reads the RF output status, power drive status, bus configuration and protection transaction status, and reads the device identifier and hardware version from the device identity register and the firmware version from the firmware version register.

[0021] Each complete read is generated by the main controller with a globally unique status read sequence number that increments in the order of formation. The status read sequence number is formed by combining the power-on cycle sequence number stored in the non-volatile record area with the incrementing read sequence number within that power-on cycle. After the device is powered on again, the power-on cycle sequence number is incremented first, and then the system continues to generate the status read sequence number from the starting sequence number within the cycle to avoid duplication of status read sequence numbers before and after the power outage.

[0022] The main controller takes the completion time of the first reading of the RF output status as the start time of the confirmation period and the completion time of the protection transaction status reading as the end time of the confirmation period. The duration of the confirmation period shall not exceed the upper limit of the confirmation period specified in the current effective status confirmation parameter version. Records exceeding the upper limit shall not be merged into the same detection status version.

[0023] The RF output status is determined by the RF output enable signal, the output switch feedback signal, and the measured value of the residual voltage on the output side. The RF output enable signal is read from the RF control register of the main controller, the output switch feedback signal is read from the status feedback terminal of the output switch, and the measured value of the residual voltage on the output side is read from the voltage sampling channel connected to the high-frequency output terminal.

[0024] The main controller first checks whether the RF output enable signal is invalid, then checks whether the output switch feedback signal is open. Next, it compares the measured residual voltage value on the output side with the residual voltage threshold recorded in the current effective status confirmation parameter version. If all three conditions are met and remain unchanged during the RF output prohibition period, the RF output status is recorded as prohibited. If any condition is not met, or if there is an inconsistency among the three conditions, the RF output status is recorded as unconfirmed, and the detection status version cannot be frozen in this round. The residual voltage threshold and the RF output prohibition period are written into the status confirmation parameter version before the equipment enters the operating state. Once this version is effective, it cannot be modified during the current confirmation period.

[0025] The power drive status is determined by the drive enable register value and the hardware drive disable feedback signal. After reading the drive enable register, the main controller immediately reads the hardware drive disable feedback signal. If the drive enable register indicates that the drive is disabled, and the hardware drive disable feedback signal indicates that the drive path is blocked, and both remain unchanged during the power drive disable period specified in the status confirmation parameter version, the power drive status is recorded as disabled. If either indicates that the drive path is open, or if the two are inconsistent, the power drive status is recorded as unconfirmed. The status version must not be frozen in this round, and the status read sequence number, register value, feedback signal value, and corresponding read time must be recorded.

[0026] The bus configuration is read from the internal bus control register and configuration storage area. The bus configuration version record includes at least the bus clock cycle, transaction interval, node address configuration, read / write permission configuration, bus configuration version identifier, and configuration activation flag. The main controller checks the bus configuration version identifier, configuration activation flag, and actual values ​​of the control registers in the following order: configuration activation flag indicates that the bus configuration version has been enabled; the bus configuration version identifier in the configuration storage area is the same as the version identifier associated with the control register; and each actual value of the control register matches the value recorded in the bus configuration version. If any field is inconsistent, the current register value is not replaced with a historical bus configuration, missing fields are not automatically filled in, the detection status version is not frozen in this round, and the inconsistent fields and their sources are written to the pending verification record.

[0027] The protection transaction status is obtained from the protection controller's busy / idle flag, current transaction identifier, number of pending transactions, transaction start record, and transaction completion record. The main controller first checks the busy / idle flag, then checks the current transaction identifier and the number of pending transactions, and finally associates the transaction start record and transaction completion record according to the transaction identifier. If the busy / idle flag is idle, the current transaction identifier is empty, the number of pending transactions is 0, and it is confirmed that there is no protection transaction with only a transaction start record but lacking a transaction completion record within the confirmed time period, the protection transaction status is recorded as idle. If any condition is not met, the protection transaction status is recorded as occupied, and the detection status version must not be frozen in this round. The types of protection transactions are limited to overcurrent shutdown, overvoltage shutdown, temperature protection, and device connection protection that have been registered with the high-frequency electrosurgical protection controller. Idle protection transactions are not inferred based on unregistered software messages.

[0028] All status records above use monotonically increasing time values ​​generated by the main controller's free-running timer. Each read time is recorded in the order of RF output status, power drive status, bus configuration, and protection transaction status, and reverse merging is not allowed. The status read interval is limited to the duration from the completion time of the previous type of status read to the start time of the next type of status read within the same complete read, and is locked by the status confirmation parameter version; the interval between two adjacent complete reads is separately recorded as the adjacent complete read interval. For short-term toggling of switch signals, it is recorded as an invalid toggling only if the toggling duration is less than the debounce period specified in the status confirmation parameter version and the states before and after the toggling are the same; if the toggling duration reaches the debounce period, or the state does not recover after the toggling, the actual changed state is recorded and the current freeze is terminated. Field integrity checks are performed after time alignment. Any missing status value, source identifier, read time, status read sequence number, or bus configuration version identifier must not be automatically filled in, but a new complete read must be restarted; if a complete record cannot be formed after reaching the allowed number of reads, the current freeze is stopped and a record awaiting verification is created. For duplicate records generated by reading the sequence number under the same state, the first complete write record shall prevail. Subsequent duplicate records shall only be recorded at the time of arrival of the duplicate, and shall not overwrite the first record.

[0029] When the RF output status is disabled, the power drive status is disabled, the bus configuration has been confirmed, and the protection transaction status is idle, the main controller writes the status read sequence number, device identifier, hardware version, firmware version, start and end times of the confirmation period, RF output status, power drive status, bus configuration, bus configuration version identifier, protection transaction status, and status confirmation parameter version to the candidate detection status version. The writing order is fixed as version identifier, status details, source and time, record status, and validity flag; the initial record status of the candidate detection status version is candidate and the validity flag is invalid. After all the above content is successfully written, in the same indivisible submission, the record status of the candidate detection status version is rewritten to valid, the validity flag is rewritten to valid, and the termination time and terminated record status are written to the previous valid detection status version; if any write fails, the current candidate detection status version remains candidate and the validity flag is invalid, the previous valid detection status version remains valid and has not terminated, and there cannot be two detection status versions that are valid and have not terminated at the same time. Subsequent steps can only read detection status versions with a valid record status, a valid validity flag, and no termination time written, and cannot modify records that are already frozen.

[0030] The main controller uses a unique submission identifier consisting of a device identifier, a status read sequence number, and a bus configuration version identifier. Each unique submission identifier can only correspond to one candidate detection status version. Detection status version records and records to be verified are stored in the non-volatile recording area of ​​the high-frequency electrosurgical unit. After a record is written, the writing result and field integrity result are retained.

[0031] In this implementation, all versions and records are uniformly set to a record status, which is limited to candidate, valid, incomplete, pending verification, and terminated. Only when the record status is valid can the valid flag be valid; valid flags in the candidate, incomplete, pending verification, and terminated states remain invalid. When a record changes from valid to pending verification or terminated, it cannot be restored to valid; a new version can only be formed based on the new source record. During the detection period, if an RF output request, power drive open request, protection transaction initiation, or bus configuration switch occurs, the current reading is immediately stopped. The candidate detection status version remains candidate, and the valid flag is invalidated, without affecting the original execution order of RF output control and protection control. This step only performs status reading and version freezing; no control values ​​are written to the RF output control register, power drive control register, or protection control register.

[0032] During on-site verification, based on the confirmation period in the test status version, retrieve the RF output enable signal, output switch feedback signal, residual voltage measurement value, drive enable register value, hardware driver disable feedback signal, bus control register value, and protection transaction record for the same period from the equipment operation record. Compare each item in the order of the records in the test status version. If any field is inconsistent, in the same status submission, rewrite the record status of that test status version as pending verification and change the valid mark to invalid. Subsequent steps must not use this information. Alternatively, the logic controller can collect each status first, and the main controller can read it uniformly. However, the original source, reading time, reading order, and freezing conditions of each status must still be retained. The summarized status must not replace the original status values.

[0033] Preferably, the upper limit of the confirmation period is set to 200 milliseconds, the state reading interval between adjacent states within the same complete read is set to 10 milliseconds, the de-jittering period is set to 5 milliseconds, the RF output prohibition holding period and the power drive prohibition holding period are both set to 50 milliseconds, the residual voltage threshold is set to 1% of the rated output voltage, the number of complete reads allowed is set to 3, the interval between adjacent complete reads is set to 20 milliseconds, and the time from when the candidate detection state version is written to when the valid flag takes effect does not exceed 100 milliseconds.

[0034] During a standby test, the RF output enable signal remains invalid for 200 milliseconds, the output switch feedback signal remains open, the residual voltage measurement value is below the residual voltage threshold, and both the driver enable register and hardware driver disable feedback signals indicate that the driver is disabled. The current bus configuration is checked item by item for consistency, the protection controller's busy / idle flag is set to idle, the current transaction flag is empty, and the number of pending transactions is 0. Based on this, the main controller generates a valid detection status version. During batch verification, at least 30 detection status versions or 10% of the total in each batch are sampled, and the larger of the two is compared field by field.

[0035] II. Select read-only transactions that do not change the output parameters, protection thresholds, and drive status according to the detection status version, and form a witness transaction chain in the order of main controller, logic controller, and RF sensing unit, recording the witness time of each node. The specific implementation is as follows: The main controller reads the detection status version that is recorded as valid, valid as valid, and has not been written to the termination time. It obtains the device identifier, hardware version, firmware version, bus configuration, bus configuration version identifier, RF output status, power drive status, and protection transaction status. Read-only transaction selection is performed only when the RF output status is disabled, the power drive status is disabled, the protection transaction status is idle, and the bus configuration has not changed.

[0036] The main controller reads the corresponding transaction registration record from the non-volatile record area according to the hardware version, firmware version, and bus configuration version identifier in the detection status version. When the firmware version is released, the transaction registration record is formed by merging the register address record, access direction record, write enable signal connection record, read action record, and node routing record item by item, and binds the hardware version, firmware version, bus configuration version identifier, and record validity mark. If any version is inconsistent or the record validity mark is invalid, the transaction registration record shall not be used.

[0037] The main controller sequentially checks the access direction, write enable signal connection, target register address, and post-read action in the transaction registration record, and selects read-only transactions that do not change the output parameters, protection threshold, and drive state.

[0038] A read-only transaction is defined as a transaction where the access direction is denoted as "read", no write enable signal is generated during the transaction execution, the target register is a status register, and the action after reading is denoted as "maintaining the original state". Transactions that clear after reading, increment the count after reading, pop from the queue after reading, confirm the fault after reading, release the lock after reading, or transition the state after reading are not allowed to be read-only transactions.

[0039] The confirmation that the output parameters are not changed is completed by comparing the target register address with the range of RF power, operating frequency, pulse width, cutting mode and coagulation mode registers in the transaction registration record item by item. The target register must not be within the above range, and the action after reading must not be connected to the latch signal and update signal of the above parameters.

[0040] For confirmation that the protection thresholds are not changed, the target register address is compared with the range of overcurrent threshold, overvoltage threshold, temperature threshold and instrument connection protection threshold registers one by one. After reading, the action must not generate protection confirmation signal, fault clearing signal and protection count reset signal.

[0041] For confirmation that the drive state is not changed, the target register address is compared item by item with the range of power drive enable, power drive latch, gate drive configuration and power drive reset registers. After reading, the action must not generate drive enable signal, drive unlock signal and drive state transition signal.

[0042] If there are missing, overlapping, or conflicting address ranges, signal connections, or actions after reading in the transaction registration record, the transaction shall not enter the read-only transaction selection result, shall not use other versions of content to fill in the gaps, and shall record the detection status version identifier, transaction address, conflict fields, and record source.

[0043] After the screening is completed, the main controller generates a transaction identifier according to the detection status version identifier and the incrementing transaction sequence number. Transaction identifiers within the same detection status version must not be duplicated. Duplicate transactions are judged based on the consistency of the transaction address, target register, return length, and node route. If all are consistent, the first complete record is retained. If any item is inconsistent, each item is retained separately and not merged.

[0044] The main controller routes read-only transactions according to the node routing in the transaction registration record, forming a witness transaction chain in the order of main controller, logic controller, and radio frequency sensing unit.

[0045] The node routing must explicitly record that the main controller sends a read request to the logic controller, the logic controller forwards the corresponding status request to the RF sensing unit, and the RF sensing unit forms a status value and then returns it to the main controller through the logic controller. If the logic controller directly returns a cached value, or if the transaction does not reach the RF sensing unit or there is a branch path that cannot be uniquely determined, a witness transaction chain will not be formed.

[0046] Before sending a read-only transaction, the master controller writes the transaction identifier to the witness control register and simultaneously writes it to the fixed transaction identifier field in the read request frame header. The bit width, byte order, and intra-frame position of this field are locked by the current transaction registration record. After the complete read request passes the frame integrity check, the logic controller latches the transaction identifier field and keeps the field value unchanged in the status request frame header forwarded to the RF sensing unit. When the RF sensing unit receives the status request completely, it latches the same field and carries the transaction identifier in its original value in the returned content. The logic controller must not rewrite the returned content, and the master controller must check it again when it receives the returned content completely. The transaction identifiers latched by the three nodes and the transaction identifiers carried in the returned content must be completely consistent. If any node fails to obtain the transaction identifier, the field width or byte order is inconsistent, or any latched value is inconsistent, the status of this witness transaction chain record is rewritten as incomplete and the valid mark is invalidated.

[0047] After the witness transaction chain is formed, the main controller, logic controller and radio frequency sensing unit record the witness time of the node respectively.

[0048] The main controller records the moment when the read request is fully loaded into the internal bus transmit register and the moment when the complete return content is entered into the receive register; the logic controller records the moment when the complete read request passes the frame integrity check and the moment when the corresponding return content is fully loaded into the return register; the RF sensing unit records the moment when the status request is fully received and the moment when the corresponding status value is latched.

[0049] The above six moments are all node witness moments and cannot be replaced by software task start moments, record write moments, estimation moments, or adjacent transaction moments.

[0050] Each node's timing register is driven by the same board-level reference clock. The timing value is a continuously monotonically non-decreasing count that does not wrap around during a single witness transaction chain. The reference clock period, count bit width, and count start state are associated with the detection status version. Two adjacent witness actions are allowed to obtain the same count value when they are in the same reference clock period.

[0051] The node witnessing time is written according to the transaction identifier, node name, witnessing action name and timing value. The recording order is fixed: master controller requests to send, logic controller requests to receive, radio frequency sensing unit requests to receive, radio frequency sensing unit status latch, logic controller returns to load, and master controller returns to receive.

[0052] If any moment is missing, the subsequent witness moment is shorter than the previous witness moment, the transaction identifier is inconsistent, the record order is incorrect, or the record moment exceeds the validity period of the detection status version, it shall not be automatically supplemented, exchanged, or calculated. Instead, the status of this record shall be rewritten as incomplete and marked as invalid.

[0053] Before re-executing the same read transaction, the main controller re-verifies that the detection status version is still valid and checks that the RF output status, power drive status, protection transaction status, and bus configuration have not changed; if any of these change, re-execution is stopped and the current record status is kept as incomplete.

[0054] Within the same detection state version, only one read-only transaction to be witnessed is allowed to be in execution state at the same time. When protection transactions and radio frequency control transactions arrive, they are executed first, and the current witness transaction chain is terminated. The witnessed nodes that have already been acquired only write records with an incomplete record status and do not enter the scope of subsequent calls.

[0055] After obtaining the complete transaction identifier, node route, and all node witness times, the main controller writes the detection status version identifier, transaction identifier, transaction address, target register, node order, node witness time, base clock cycle, hardware version, firmware version, and bus configuration version identifier into the candidate witness transaction chain record. After all fields are written, the record status and validity flag are simultaneously rewritten to valid. If the write fails, the record status remains candidate and the validity flag is invalid, without overwriting the already effective witness transaction chain record.

[0056] Subsequent steps only call witness transaction chain records that are consistent in status version, consistent in transaction identifier, complete in node order, and valid in record status and marked as valid.

[0057] During on-site verification, the main controller sending register records, logic controller request and return register records, and radio frequency sensing unit request and status latch records are retrieved according to the transaction identifier. The node sequence, witnessing action, and timing value source are checked item by item. If any source cannot be matched, the record status of the witnessing transaction chain record is changed to pending verification and the valid mark is changed to invalid.

[0058] Alternatively, the logic controller can use the same board-level reference clock to centrally capture the signals sent by the main controller, the signals received and returned by the logic controller, and the signals requested to receive and latched by the RF sensing unit, and form the node witnessing time according to the same transaction identifier; this alternative method still needs to maintain the read-only transaction filtering boundary, the actual propagation order of the three nodes, the six witnessing actions, and the unified timing reference unchanged.

[0059] Preferably, the internal bus clock is set to 10 MHz, the board-level reference clock is set to 100 MHz, the node witnessing time is counted in units of 10 nanoseconds, the duration of a single witnessing transaction chain does not exceed 500 microseconds, and two re-executions are allowed when the record is invalid. The interval between adjacent executions is set to 1 millisecond. In one field execution, the main controller filters 18 status read transactions from 128 transaction registration records. After excluding 4 read-clear transactions, 3 transactions that did not reach the RF sensing unit, and 2 transactions involving drive latch confirmation, 9 witnessing transaction chains are formed. Among them, 8 complete 6 node witnessing times and write valid records, and 1 still lacks the RF sensing unit status latching time after 2 re-executions, so it remains an incomplete record.

[0060] III. Based on the baseline idle time, the minimum idle time of the protocol, and the perturbation acceptance boundary of the link health status version, determine the perturbation quantity, and generate positive and negative perturbation transactions with swapped idle times and the same total duration. The specific implementation is as follows: After obtaining a valid detection status version and its corresponding valid witness transaction chain, the main controller reads the baseline idle time, the minimum protocol idle time, and the perturbation acceptance boundary in the link health status version based on the detection status version identifier, the transaction identifier in the witness transaction chain, and the current bus configuration version identifier. The perturbation acceptance boundary in the link health status version uses the same value as the upper limit of the perturbation for the pending execution cycle recorded in that version. The above reading and transaction generation are completed while the RF output state remains disabled, the power drive state remains disabled, the protection transaction state remains idle, and the bus configuration has not changed. Only the idle time configuration of the pending read-only transaction is changed; the transaction message content, access direction, target register, return length, node routing, and bus clock configuration are not changed.

[0061] The baseline idle time consists of the pre-transaction baseline idle time and the post-transaction baseline idle time, both obtained from the transaction timing baseline record bound to the current transaction identifier. The pre-transaction idle time and the post-transaction idle time use independent idle slot definitions: the pre-transaction idle slot is the configurable idle interval exclusive to the current read-only transaction and immediately preceding the transaction body; the post-transaction idle slot is the configurable idle interval exclusive to the current read-only transaction and immediately following the transaction body. These are not counted repeatedly with the idle slots of adjacent transactions. The pre-transaction baseline idle time is calculated from the start time of the pre-transaction idle slot and ends at the start time of the first valid send edge of the current read-only transaction; the post-transaction baseline idle time is calculated from the end time of the last valid return edge of the current read-only transaction and ends at the end time of the post-transaction idle slot. Scheduling intervals set separately between adjacent transactions are not included in the pre-transaction idle time, post-transaction idle time, or total duration of any transaction.

[0062] The transaction timing baseline record is simultaneously bound to the hardware version, firmware version, bus configuration version identifier, transaction identifier, and record validity flag. The main controller only uses records whose version and transaction identifier are consistent with the current witness transaction chain and whose record validity flag is valid. If any baseline idle time before a transaction, baseline idle time after a transaction, or version field is missing, it will not be calculated or supplemented based on adjacent transactions, historical averages, or other transaction records.

[0063] The minimum idle time of the protocol is obtained from the transaction timing limit record corresponding to the current bus configuration version. This time adopts a uniform value, which is the maximum value among all the shortest durations required by the main controller, logic controller, RF sensing unit, and bus isolator actually passed by the current witness transaction chain during the pre-transaction idle phase and post-transaction idle phase. If no bus isolator is set or the current witness transaction chain does not pass through a bus isolator, the bus isolator is not listed as a mandatory node. The transaction timing limit record is formed based on the chip select release time, receive recovery time, status latch release time, and next transaction receive preparation time of each actual mandatory node, and is bound to the applicable hardware version, firmware version, bus configuration version identifier, transaction range, allowed duration of the transaction body determined by the transaction identifier, allowed number of re-executions of the complete execution batch, and record effective flag.

[0064] If any required node lacks a minimum duration record, has an inconsistent applicable version, or has an invalid record validity flag, the missing time will not be recorded as 0, and the perturbation quantity will not be determined further.

[0065] The link health status version is read from the non-volatile record area, and it is bound to the device identifier, hardware version, firmware version, bus configuration version identifier, transaction identifier, effective time, record status, validity flag, perturbation acceptance boundary, and perturbation limit for the pending execution cycle. The perturbation acceptance boundary and the perturbation limit for the pending execution cycle in the same link health status version use the same count value. The perturbation acceptance boundary is limited to the maximum amount of time allowed for the same witness transaction chain to transfer from the idle time before the transaction to the idle time after the transaction, or from the idle time after the transaction to the idle time before the transaction, without changing the transaction content and bus clock configuration.

[0066] The master controller only uses the link health status version where the record status is valid, the valid flag is valid, the termination time has not been written, and all binding fields are consistent with the current witness transaction chain; only one valid and non-terminating link health status version is allowed under the same link conditions.

[0067] The initial link health status version, pre-written by the device before shipment, is used during the initial execution. This initial version must be bound to the same hardware version, firmware version, bus configuration version identifier, and transaction identifier. The perturbation acceptance boundary and the upper limit of the perturbation in the pending execution cycle in the initial link health status version are directly formed according to the transaction timing baseline record and the transaction timing limit record: two idle margins are obtained by subtracting the minimum protocol idle time from the baseline idle time before the transaction and the minimum protocol idle time from the baseline idle time after the transaction, respectively. The smaller of these two margins, which is not less than 0, is written as the initial perturbation acceptance boundary and the initial upper limit of the perturbation in the pending execution cycle. If either idle margin is less than 0, no initial link health status version is generated; if the smaller idle margin is 0, both initial fields are written as 0. The above calculations use records that are consistent with the current hardware version, firmware version, bus configuration version identifier, and transaction identifier and whose record validity is marked as valid, and are completed when the device is configured and solidified at the factory. If no matching initial link health status version exists, the perturbation acceptance boundary is not set automatically, and no forward or reverse perturbation transactions are generated.

[0068] Before comparison, the pre-transaction baseline idle time, post-transaction baseline idle time, protocol minimum idle time, and perturbation acceptance boundary are uniformly converted into board-level baseline clock count values. The baseline idle time is adopted according to the actual count value in the transaction timing baseline record. When the protocol minimum idle time cannot be divided by the board-level baseline clock period, it is rounded up to the complete count value. When the perturbation acceptance boundary cannot be divided by the board-level baseline clock period, it is rounded down to the complete count value. This is to prevent the converted idle time from being less than the protocol requirement or the perturbation amount from being greater than the allowable range of the link health status version.

[0069] The main controller subtracts the minimum idle time of the protocol from the baseline idle time before the transaction to obtain the count value that the idle time before the transaction can be shortened, and subtracts the minimum idle time of the protocol from the baseline idle time after the transaction to obtain the count value that the idle time after the transaction can be shortened. Then, the above two count values ​​are compared with the perturbation acceptance boundary count value one by one, and the smallest complete count value that is not less than 0 is determined as the perturbation quantity.

[0070] When any allowed shortened count value is less than 0, it indicates that the corresponding baseline idle time has fallen below the minimum idle time of the protocol, and this record is transferred to the pending verification state; when the determined perturbation amount is 0, no positive perturbation transaction or reverse perturbation transaction is generated.

[0071] During the period of perturbation quantity determination, if the transaction timing baseline record, transaction timing limit record, link health status version or detection status version is switched, the perturbation transaction record that has not yet taken effect shall be immediately revoked, and the time quantities in different versions shall not be merged and used.

[0072] After determining the perturbation amount, the main controller replicates the transaction identifier, message content, access direction, target register, return length, node routing, bus clock configuration, and transaction body configuration duration in the valid witness transaction chain, and only adjusts the idle time before and after the transaction.

[0073] For a forward perturbation transaction, the pre-transaction idle time is set to the pre-transaction baseline idle time minus the perturbation amount, and the post-transaction idle time is set to the post-transaction baseline idle time plus the perturbation amount; for a reverse perturbation transaction, the pre-transaction idle time is set to the pre-transaction baseline idle time plus the perturbation amount, and the post-transaction idle time is set to the post-transaction baseline idle time minus the perturbation amount.

[0074] The exchange of idle time before and after a transaction is limited to the same perturbation quantity being transferred in opposite directions between the idle time before and after the transaction, rather than directly swapping the values ​​of the two base idle times.

[0075] The total duration of both forward and reverse perturbation transactions is determined by the sum of the counts of the idle time before the transaction, the transaction body configuration duration, and the idle time after the transaction. Since the two transactions use the same transaction body configuration duration and the increase or decrease in idle time before and after the transaction cancels each other out, the counts of their total durations must be exactly the same, and the same judgment method within the error range is not used.

[0076] After generation, each of the two transactions is checked for its transaction identifier, message content, access direction, target register, return length, node route, bus clock configuration, perturbation amount, and total duration. If any item is inconsistent, the entire set of records is revoked, and no single transaction is retained.

[0077] The main controller writes the detection status version identifier, witness transaction chain identifier, transaction timing baseline record version, transaction timing limit record version, link health status version identifier, pre-transaction baseline idle time, post-transaction baseline idle time, protocol minimum idle time, perturbation acceptance boundary, perturbation amount, pre-transaction and post-transaction idle time of forward perturbation transactions, pre-transaction and post-transaction idle time of reverse perturbation transactions, and total duration into the same candidate perturbation transaction group. Only after all fields and two transactions have been written can the record status and validity mark of the candidate perturbation transaction group be changed to valid. If any field fails to be written, the record status remains candidate and the validity mark is invalid, without overwriting existing valid records.

[0078] Only one set of valid records is allowed for the same detection status version, the same witness transaction chain, the same transaction timing baseline record version, the same transaction timing limit record version, and the same link health status version. When the records are generated repeatedly and all fields are consistent, the first valid record will be used. If there are differences, the record status of the later generated record will be changed to pending verification and the valid record will be marked as invalid.

[0079] Subsequent steps only call candidate perturbation transaction groups that have a valid record status, are marked as valid, have the same source version, and have both forward and reverse perturbation transactions existing simultaneously with the same total duration count.

[0080] Alternatively, the idle time before and after a transaction is configured by the timing register in the logic controller, and the main controller writes the determined idle time count value and the corresponding version identifier to the logic controller. This method still requires that the base idle time, the minimum idle time of the protocol, the perturbation acceptance boundary and the source of the perturbation, the rounding rules, the transfer relationship between the idle time before and after the transaction and the pairwise effective conditions remain unchanged.

[0081] Preferably, the board-level reference clock period is set to 10 nanoseconds, the reference idle time before and after the transaction is set to 20 microseconds, the minimum idle time of the protocol is set to 8 microseconds, the perturbation acceptance boundary in the link health status version is set to 6 microseconds, and the idle time before and after the transaction is allowed to be shortened by 12 microseconds respectively. The main controller thus determines the perturbation amount to be 6 microseconds. The idle time before the transaction for a forward perturbation transaction is 14 microseconds and the idle time after the transaction is 26 microseconds. The idle time before the transaction for a reverse perturbation transaction is 26 microseconds and the idle time after the transaction is 14 microseconds. The total idle time of the two transactions is 40 microseconds. The transaction body configuration duration is the same, so the total duration count value is completely consistent.

[0082] IV. Within the detection state version, execute the anchoring, forward perturbation, anchoring, reverse perturbation, and recovery transactions sequentially to obtain the node witness time and state summary. The specific implementation is as follows: The main controller reads the detection status version that is recorded as valid, marked as valid, and not written to the termination time. At the same time, it reads the valid witness transaction chain and valid candidate perturbation transaction group corresponding to the detection status version, and checks the device identifier, hardware version, firmware version, bus configuration version identifier, transaction identifier, target register, and node route item by item. If any field is inconsistent, no transaction execution record is established for this round.

[0083] The main controller uses the detection status version identifier, witness transaction chain identifier, candidate perturbation transaction group identifier, and incremental batch number to form the execution batch identifier. Only one execution batch is allowed to be in the execution state at the same time for the same detection status version and the same witness transaction chain.

[0084] The execution batch starts from the start time of the free slot before the first anchor transaction and ends at the end time of the free slot after the recovery transaction. The entire interval must be within the valid period of the same detection status version. If the detection status version is written to the termination time during the execution period, or if the RF output status is no longer disabled, the power drive status is no longer disabled, the protection transaction status is no longer free, or the bus configuration version identifier changes, the current execution batch will be terminated immediately. The status of the already formed records will be rewritten as incomplete and kept valid with the invalidation mark. Records under different detection status versions must not be merged.

[0085] Both the first and second anchor transactions replicate the read-only transaction content, access direction, target register, return length, node routing, and bus clock configuration in the valid witness transaction chain. The idle time before the transaction is based on the baseline idle time before the transaction, and the idle time after the transaction is based on the baseline idle time after the transaction. The configuration content of the two anchor transactions is exactly the same, and they are only distinguished by the execution sequence number.

[0086] Forward and reverse perturbation transactions directly call the corresponding records that are effective in pairs in the candidate perturbation transaction group, without modifying the perturbation amount, the idle time before the transaction, or the idle time after the transaction in this step.

[0087] Restore the full configuration of the transaction replication anchor transaction, restore its pre-transaction idle time and post-transaction idle time to the base idle time, and limit it to the first same read transaction executed after the reverse perturbation transaction is completed.

[0088] The main controller allocates consecutive execution sequence numbers in the order of the first anchor transaction, the forward perturbation transaction, the second anchor transaction, the reverse perturbation transaction, and the recovery transaction. After the idle slots following the transaction of the previous transaction have been completed, the idle slots preceding the transaction of the next transaction can only begin after a scheduling interval locked in the transaction scheduling record and not included in the total duration of any transaction. The order cannot be swapped, parallel execution cannot be performed, transactions cannot be skipped, a transaction cannot be repeated, or historical execution records cannot be used to replace the current round of transactions.

[0089] Except for protection transactions and radio frequency control transactions, other internal bus transactions must not be inserted between the above five types of transactions; when a protection transaction or radio frequency control transaction arrives, it shall be executed immediately with its original priority, and the batch of this round of execution shall be marked as incomplete and shall not continue from the interrupt position after the protection transaction ends.

[0090] The execution interval for each type of transaction begins with its pre-transaction idle time, passes through the transaction body and the post-transaction idle time in sequence, and ends with the post-transaction idle time. The transaction body begins when the main controller loads the complete read request into the send register and ends when the main controller obtains the complete return content with the length matching the transaction registration record and the transaction identifier.

[0091] If the transaction body exceeds the allowed duration of the transaction body locked according to the current transaction identifier in the transaction sequence limit record, the return length is inconsistent, the transaction identifier is inconsistent, the node route is incomplete, or the free slots after the transaction are not fully maintained, the current batch of execution will be terminated immediately.

[0092] When re-execution is required, the main controller re-verifies that the detection status version, witness transaction chain, and candidate perturbation transaction group are still valid, generates a new execution batch identifier, and restarts from the first anchored transaction. The original execution batch is retained as a record with an incomplete record status and is not allowed to be concatenated with transactions in the new execution batch. The number of re-executions allowed for a complete execution batch is obtained from the transaction sequence limit record. After reaching this number, automatic re-execution stops, and the last incomplete execution record is retained.

[0093] At the start of each transaction, the main controller writes the execution batch identifier, execution sequence number and transaction type into the witness control register. The main controller, logic controller and RF sensing unit record the node witness time based on the same transaction identifier.

[0094] Each type of transaction records the moment when the main controller requests to fully load the transmit register, the moment when the logic controller fully receives the read request, the moment when the RF sensing unit fully receives the status request, the moment when the RF sensing unit completes the status value latching, the moment when the logic controller completes the loading of the return content, and the moment when the main controller fully receives the return content.

[0095] The node witness time uses a monotonically non-decreasing count value generated by the same board-level reference clock, and is associated with the execution batch identifier, execution sequence number, transaction type, node name, and witness action name; adjacent witness actions are allowed to have equal count values ​​when they are in the same reference clock cycle. The duration of a single execution batch must be less than the timer wrap-around period. If a timer wrap-around occurs during execution, the status of the entire batch of records is rewritten as incomplete and the valid mark is invalidated.

[0096] If any witness moment is missing, the subsequent witness moment is less than the previous witness moment, the transaction identifier is inconsistent, or the execution sequence number is not continuous, the moment will not be supplemented, reordered, or calculated, and the record status of the current execution batch will be rewritten as incomplete.

[0097] When multiple count values ​​correspond to the same execution batch identifier, execution sequence number, node name, and witness action name, the count value that is first fully latched by the witness action is taken as the node witness time, and subsequent count values ​​are only retained as duplicate records.

[0098] When the main controller fully receives the return content of each type of transaction, it latches the required fields of the state summary at the same board-level reference clock edge, without rereading the above fields through additional internal bus transactions.

[0099] The status summary consists of the returned status value, return length, RF output status, power drive status, protection transaction status, and bus configuration version identifier arranged in a fixed order. The returned status value and return length are latched from the current transaction receive register, and the bus configuration version identifier is latched from the currently effective configuration register. The RF output status, power drive status, and protection transaction status are entered into the local status mirror through a two-level synchronization register driven by the board-level reference clock. The second-level synchronization register updates the mirror value at each edge of the board-level reference clock and sets the valid mark of the mirror to valid after completing two consecutive levels of sampling. When the source status changes, the maximum lag in the propagation of the change to the local status mirror is two board-level reference clock cycles. When the master controller receives the returned content completely, it latches the mirror value at the same edge of the board-level reference clock only if the valid marks of all three local status mirrors are valid, the detected status version is still valid, and the status change termination condition has not been triggered in the current batch.

[0100] In this embodiment, the state summary is the original state sequence of the above fields, and the fields are not irreversibly compressed; the width, byte order and enumeration value of each field are locked by the state summary field record bound to the current firmware version, and all 5 types of transactions are recorded using the same state summary field.

[0101] The returned status value maintains the original bit order and byte order specified in the transaction registration record. If the field width is insufficient, the field source version is inconsistent, any local status image is invalid, the status version detection is terminated before latching, or the latching time is later than the end time of the free slot after the current transaction, it will not be padded with 0, the previous transaction field will not be used, and the current batch will be terminated immediately.

[0102] All five types of transactions are completed in a fixed order. After each type of transaction obtains six witness times and one complete status summary, the main controller writes the detection status version identifier, witness transaction chain identifier, candidate perturbation transaction group identifier, execution batch identifier, five execution sequence numbers, five transaction categories, 30 witness times, and five status summaries into the candidate transaction execution record. Only after all fields are written can the record status and validity flag of the candidate transaction execution record be rewritten to valid.

[0103] If any transaction, node witness moment, or state summary is missing, the entire batch of records remains in an incomplete state and is marked as invalid. Transactions that are already complete are not submitted to the next stage separately.

[0104] When submitting the same execution batch identifier repeatedly, the first complete write result is used and no effective records are overwritten; the new execution batch formed by re-execution is saved separately.

[0105] Subsequent steps only call the transaction execution records that check the consistency of the status version, the complete sequence of the 5 types of transactions, the complete witness time and status summary of all nodes, and the record status is valid and the valid mark is valid.

[0106] Alternatively, the logic controller can schedule five types of transactions based on the execution batch identifier and execution sequence number issued by the main controller, and centrally capture the node witnessing time of six types of witnessing actions. The main controller latches the status summary each time the returned content is fully received. This method still requires that the same detection status version, fixed execution order, transaction execution interval, inter-transaction insertion prohibition rule, node witnessing action, status summary field definition and batch effective conditions remain unchanged.

[0107] Preferably, the board-level reference clock is set to 100 MHz, the node witness time is counted in 10 nanosecond units, the allowable duration of a single transaction body is set to 500 microseconds, and adjacent transactions maintain a 1-millisecond scheduling interval after the previous transaction finishes its idle slot before entering the next transaction's idle slot. This scheduling interval is not included in the total duration of any transaction, and a complete execution batch is allowed to be re-executed twice. In one field execution, 5 types of transactions are completed sequentially, and each type of transaction obtains 6 node witness times and 1 status summary, forming a total of 30 node witness times and 5 status summaries. All transaction identifiers, execution sequence numbers, bus configuration version identifiers, and status summary field widths are consistent. Based on this, the main controller rewrites the record status and valid flag of the candidate transaction execution record to valid.

[0108] V. Based on the node witnessing time, a segment propagation time is formed. An anchor transaction is used to establish a segment propagation benchmark. The first mismatch segment and the perturbation acceptance boundary are determined based on the positive perturbation, the negative perturbation, and the recovery transaction. The specific implementation is as follows: The main controller reads transaction execution records that are valid and marked as valid. Based on the detection status version identifier, witness transaction chain identifier, candidate perturbation transaction group identifier, and execution batch identifier, it confirms that the first anchor transaction, forward perturbation transaction, second anchor transaction, reverse perturbation transaction, and recovery transaction all belong to the same detection status version. It also confirms that each type of transaction has 6 node witness times recorded in a fixed order and a complete status summary. If any identifier is inconsistent, the transaction order is incomplete, the timing benchmark is different, or the node witness times are missing, no segment propagation time is formed.

[0109] The main controller divides the witnessing transaction chain into 5 segments according to the sequential relationship of adjacent witnessing actions. The first segment extends from the moment the main controller requests to fully load the transmit register to the moment the logic controller fully receives the read request. The second segment extends from the moment the logic controller fully receives the read request to the moment the RF sensing unit fully receives the status request. The third segment extends from the moment the RF sensing unit fully receives the status request to the moment the RF sensing unit completes the status value latch. The fourth segment extends from the moment the RF sensing unit completes the status value latch to the moment the logic controller completes the return content loading. The fifth segment extends from the moment the logic controller completes the return content loading to the moment the main controller fully receives the return content. The aforementioned segments are continuous time intervals between adjacent witnessing actions. The third segment includes the time for the RF sensing unit to form and latch the status value, and the fourth segment includes the time for the status value to be returned to the logic controller and form the complete return content. The segments are not limited to the simple physical line transmission time.

[0110] The segment propagation time of each segment is obtained by subtracting the count value of the previous node's witnessing time from the board-level reference clock count value of the subsequent node's witnessing time. The result represents the number of complete counting cycles experienced between two witnessing actions, without adding or subtracting one count value. When the result is 0, it means that the two actions fall within the same counting cycle and are still considered valid results. When the result is less than 0, the timer wraps around during execution, or the counting units are inconsistent, the current transaction execution record is transferred to the pending verification state, and the count value is not reordered, taken as absolute value, interpolated, or padded.

[0111] The main controller generates associated records based on transaction type, execution sequence number, segment order from segment 1 to segment 5, segment start and end witness actions, and segment propagation time.

[0112] Subsequently, a segment propagation baseline is established using two anchor transactions. The status digests of the two anchor transactions are compared bit by bit according to the field width, field order, byte order, and enumeration value of the locked field records in the status digest field. Only when all bit values ​​are the same will the segment propagation baseline be established. If any bit value is different, it indicates that the two anchor transactions do not have a common baseline condition, and different fields are not ignored, merged, or replaced.

[0113] For each segment, the main controller adds the segment propagation time of the two anchored transactions and divides it by 2. If the sum is not evenly divisible, it rounds up to the nearest whole number to form the segment propagation reference. Then, it divides the absolute count value of the segment propagation time difference between the two anchored transactions by 2. If the sum is not evenly divisible, it rounds up and compares it with the count value of a board-level reference clock. The larger value is taken as the allowable deviation for the segment.

[0114] The resulting allowable deviation just covers the count quantification difference that has already occurred between the two anchored transactions. Instead of using the complete difference as the allowable deviation, we avoid expanding the acceptable range without basis.

[0115] The five segments form the segment propagation benchmark and allowable deviation. The values ​​of each segment are only applicable to the current detection status version, the current witness transaction chain, and the current execution batch, and cannot be called across segments or execution batches.

[0116] The main controller then compares the segment propagation time of the forward perturbation transaction and the reverse perturbation transaction with the corresponding segment propagation reference in a fixed order from segment 1 to segment 5. When the absolute count value of the difference between the segment propagation time and the segment propagation reference is greater than the allowable deviation, the segment is recorded as a mismatch segment. When the difference is equal to or less than the allowable deviation, it is recorded as a non-mismatch segment.

[0117] When multiple mismatched segments occur in the same transaction, the segment that appears first is selected according to the segment order. When both the forward perturbation transaction and the reverse perturbation transaction have mismatched segments, the first mismatched segments of the two transactions are compared, and the segment with the earlier segment order is selected as the first mismatched segment. If the two transactions are in the same segment, the segment is used directly. When only one transaction has a mismatched segment, the first mismatched segment of that transaction is used. When neither transaction has a mismatched segment, the fixed status value "no mismatch" is written to the first mismatched segment field.

[0118] The state summaries of the forward and reverse perturbation transactions are compared bit by bit with the common state summaries of the two anchored transactions. If any bit of the state summary of any perturbation transaction differs, regardless of whether the segment propagation time shows a mismatch, the state difference shall not be forcibly assigned to any of the aforementioned five segments. The current execution batch shall be transferred to the pending verification state and shall not form a valid first mismatch segment or perturbation acceptance boundary.

[0119] The recovery transaction is used to confirm whether the witness transaction chain has returned to the state corresponding to the segment propagation benchmark after the perturbation transaction is completed. The master controller compares the propagation time of the five segments of the recovery transaction with the corresponding segment propagation benchmark item by item, and compares the state summary of the recovery transaction with the state summary of the anchor transaction bit by bit. The recovery transaction only meets the recovery condition when the absolute count of the difference of the five segments is not greater than the corresponding allowable deviation and the state summary is exactly the same.

[0120] When a recovery transaction does not meet the recovery conditions, the segment differences obtained in the current batch may contain the continued effects of the unrecovered state, and therefore no valid first mismatch segment and perturbation acceptance boundary are submitted.

[0121] The perturbation acceptance boundary in this step is defined as the upper limit of the common perturbation time allowed to continue to be used in the next detection cycle based on the positive perturbation, negative perturbation and recovery transaction evidence of the current execution batch. It does not represent the physical limit of the link obtained by trying all the time amounts one by one.

[0122] When a recovery transaction meets the recovery conditions and neither the forward nor the reverse perturbation transaction has a mismatch segment, the current perturbation quantity in the candidate perturbation transaction group is determined as the perturbation acceptance boundary. When a recovery transaction meets the recovery conditions and at least one mismatch segment occurs in either the forward or reverse perturbation transaction, the current perturbation quantity is reduced by one board-level reference clock count value and used as the perturbation acceptance boundary for the next detection cycle. When the current perturbation quantity is only one count value, the perturbation acceptance boundary is determined to be 0.

[0123] This reduction value is the upper limit of the control for the next cycle, and small perturbations that have not been actually implemented in this round are not described as having passed the test.

[0124] The perturbation acceptance boundary must not be greater than the original perturbation acceptance boundary bound to the candidate perturbation transaction group, and it applies to both the forward and reverse directions simultaneously, without retaining the larger boundary for the lenient direction separately.

[0125] After the determination is completed, the main controller will detect the status version identifier, device identifier, hardware version, firmware version, bus configuration version identifier, witness transaction chain identifier, transaction identifier, execution batch identifier, board-level reference clock cycle, segment propagation time of the five segments, segment propagation reference, allowable deviation, mismatch of forward and reverse perturbation transactions, recovery conditions, first mismatched segment, current perturbation amount, and perturbation acceptance boundary and write them into the candidate segment determination record. After all fields are written, the record status and validity mark will be rewritten to valid. If any required field is missing, the record status will remain as candidate and the validity mark will be invalid. Subsequent steps will only call the segment determination record that meets the recovery conditions, the status summary comparison is valid, the record status is valid, and the validity mark is valid.

[0126] Alternatively, the logic controller can form the segment propagation time based on the witnessing time of adjacent nodes and submit it to the main controller. The main controller can then establish the segment propagation benchmark and determine the first mismatch segment and the perturbation acceptance boundary. This method still requires that the meaning of the start and end witnessing actions of the five segments, the count difference formation rule, the anchor transaction comparison rule, the allowable deviation formation rule, the state summary application boundary, the recovery condition, and the upper limit of the control of the perturbation acceptance boundary remain unchanged.

[0127] Preferably, the board-level reference clock period is set to 10 nanoseconds. The propagation times of the five segments of the two anchored transactions are 120, 85, 40, 88, 125 count values ​​and 121, 85, 41, 89, 124 count values, respectively. The resulting segment propagation references are 121, 85, 41, 89, 125 count values, with an allowable deviation of 1 count value for each segment. The forward perturbation transaction corresponds to 121, 86, 44, 91, 126 count values, and the third... The segment is the first to exceed the allowable deviation. The reverse perturbation transactions correspond to counts of 121, 85, 42, 90, and 126, and no mismatch segment appears. The recovery transactions correspond to counts of 121, 85, 41, 89, and 125, and the state summary is exactly the same as the anchoring transaction. Therefore, the third segment is determined as the first mismatch segment. When the current perturbation amount is 600 counts, the perturbation acceptance boundary for the next detection cycle is determined to be 599 counts, or 5.99 microseconds.

[0128] VI. Arrange the first mismatch segment and the perturbation acceptance boundary according to the detection status version. Form a fault prediction record based on the boundary contraction of the same segment. Write the prediction record and the upper limit of the perturbation in the pending cycle into the link health status version. The specific implementation is as follows: The main controller reads the segment determination records that are valid and marked as valid from the non-volatile recording area. It filters the records formed under the same link conditions according to the device identifier, hardware version, firmware version, bus configuration version identifier, witness transaction chain identifier, and transaction identifier, and keeps the detection status version, first mismatch segment, and micro-disturbance acceptance boundary in each record in a one-to-one correspondence. When any of the aforementioned link conditions changes, the records before and after the change are arranged separately, and no comparison is made across link conditions.

[0129] The main controller arranges the globally unique status read sequence numbers bound to the detection status version in ascending order, and does not replace the status read sequence number with the record writing time, execution completion time, or effective time. Only one valid segment judgment record is allowed to correspond to the same status read sequence number. If the detection status version identifier, execution batch identifier, first mismatch segment, and micro-disturbance acceptance boundary of duplicate records are all consistent, the first valid record is retained, and the rest are retained as duplicate records. If any field is inconsistent, the record status of all records corresponding to the status read sequence number is rewritten to pending verification and the valid mark is rewritten to invalid.

[0130] In the arrangement, adjacent detection state versions are limited to those that are adjacent after being arranged according to the state reading sequence number under the same link condition and there is no other detection state version between them; when there is a detection state version in the middle that has not formed a valid segment determination record, the continuous comparison relationship terminates at that position and starts again from the next valid record.

[0131] When a mismatch occurs, the first mismatch segment field will always use one of the segment names from segment 1 to segment 5. Only segments with identical segment names, segment start witness actions, and segment end witness actions are considered to be in the same segment. When no mismatch occurs, a fixed status value of "no mismatch" will be written. This fixed status value does not belong to any segment and does not constitute the same segment as any other segment.

[0132] The perturbation acceptance boundary continues to use the board-level reference clock count value in the segment determination record. The board-level reference clock period in the same permutation sequence must be exactly the same. Different periods indicate that the timing conditions have changed. Even if other link conditions are the same, they are arranged separately without nanosecond conversion, proportional conversion or approximate comparison.

[0133] The main controller compares two adjacent valid records in the order of arrangement. When the first mismatch segment of the two records belongs to the same segment and the subsequent perturbation acceptance boundary is at least one board-level reference clock count value less than the previous perturbation acceptance boundary, it is determined that boundary contraction has occurred. When the subsequent boundary is equal to the previous boundary, it is determined that boundary is maintained. When the subsequent boundary is greater than the previous boundary, it is determined that boundary is restored. Neither of these is considered boundary contraction. No allowable error is set, and the actual size relationship of the count value is not replaced by percentage change.

[0134] If the first mismatch segment of adjacent records is different, any record is "no mismatch", any perturbation acceptance boundary is missing, or any record is in the record status of pending verification, no evidence of boundary contraction between adjacent detection status versions is formed.

[0135] The main controller generates a fault prediction record based on the latest valid segment determination record in the sequence. The threshold for the number of consecutive boundary contractions is fixed at 2, and this value is written to the fault prediction parameter version in the non-volatile recording area. This parameter version is bound to the current hardware version, firmware version, and bus configuration version identifier. When the latest detection state version and its previous adjacent detection state version do not form a boundary contraction in the same segment, the prediction state is written as "No boundary contraction in the same segment has been formed"; when one boundary contraction in the same segment is formed but the number of consecutive contractions has not reached 2, the prediction state is written as "Contraction evidence has not reached the trend threshold"; when two consecutive boundary contractions occur in the same segment, the prediction state is written as "A latent fault development trend exists". The fault prediction record records at least the fault prediction record identifier, the fault prediction parameter version identifier, the current first mismatched segment, the detection state version participating in the comparison, the corresponding perturbation acceptance boundary, the amount of each contraction, the number of consecutive contractions, and the prediction state.

[0136] When multiple adjacent detection state versions experience boundary contraction in the same segment, each contraction is appended to the same consecutive contraction evidence segment according to its state reading sequence number. If boundary maintenance, boundary recovery, first mismatch segment change, "no mismatch" occurs, or recording is interrupted, the consecutive contraction evidence segment ends at the previous detection state version, and subsequent segments are re-established; the number of contractions before and after the interruption is not accumulated. After two consecutive contractions, subsequent records of contractions in the same segment are appended to the evidence sequence of the corresponding fault prediction record. After the consecutive contraction evidence segment terminates, the next fault prediction record is re-accumulated.

[0137] The predicted status "No contraction of the same segment boundary" in the fault prediction record indicates that the current adjacent detection status versions have not achieved a contraction relationship of the same segment boundary; "Contraction evidence has not reached the trend threshold" indicates that one contraction of the same segment boundary has been achieved but not two consecutive times; "There is a latent fault development trend" indicates that the perturbation receiving boundary corresponding to the same segment has continuously decreased in three consecutive detection status versions. None of the above predicted statuses indicate that the high-frequency electrosurgical unit has experienced an RF output fault, nor do they directly modify the RF output status, protection threshold, or power drive status.

[0138] After the fault prediction record is formed, the main controller determines the upper limit of the perturbation for the next execution cycle based on the latest valid segment judgment record. The execution cycle is limited to the next detection cycle started for the same link condition after the latest detection status version is completed. Regardless of whether the predicted status is "no contraction of the same segment boundary has formed", "contraction evidence has not reached the trend threshold", or "there is a hidden fault development trend", as long as the latest segment judgment record is valid, a new link health status version is formed, and the perturbation acceptance boundary determined this time enters the next detection cycle.

[0139] When a current valid link health status version exists under the same link conditions, the perturbation acceptance boundary in the latest valid segment judgment record is compared with the perturbation acceptance boundary in the current valid link health status version, and the smaller one is taken as both the perturbation acceptance boundary of the new link health status version and the upper limit of the perturbation in the pending execution cycle; when no current valid link health status version exists, the latest perturbation acceptance boundary is written as both the perturbation acceptance boundary and the upper limit of the perturbation in the pending execution cycle.

[0140] The perturbation acceptance boundary and the upper limit of the perturbation in the new link health status version always use the same value. This value can only be maintained or reduced relative to the previous effective link health status version, and cannot be increased due to boundary maintenance, boundary recovery or a single large measurement result.

[0141] When the latest perturbation acceptance boundary is 0, the perturbation acceptance boundary and the upper limit of the perturbation in the pending cycle in the new link health status version are both determined to be 0. The next detection cycle shall not generate positive perturbation transactions and reverse perturbation transactions with non-zero perturbation amounts. When the latest valid segment judgment record is missing, no fault prediction record is formed and no new link health status version is created. The original valid link health status version continues to be effective.

[0142] The main controller writes the fault prediction record and the upper limit of the perturbation in the pending execution cycle into the new link health status version. The link health status version records at least the version identifier, device identifier, hardware version, firmware version, bus configuration version identifier, witness transaction chain identifier, transaction identifier, source detection status version, first mismatch segment, prediction status, fault prediction record identifier, perturbation acceptance boundary, upper limit of the perturbation in the pending execution cycle, effective time, record status, valid mark and termination time. The perturbation acceptance boundary and the upper limit of the perturbation in the pending execution cycle must be the same.

[0143] During the writing process, a candidate link health status version is first created with a record status of "candidate" and a valid mark of "invalid". Then, the source relationship, fault prediction record, perturbation acceptance boundary, and upper limit of perturbation for the pending execution period are written sequentially. After all fields are successfully written, the record status and valid mark of the candidate link health status version are rewritten to "valid" in the same indivisible commit. The termination time and terminated record status are also written to the previous valid link health status version. If any write fails, the candidate link health status version remains "candidate" and the valid mark of "invalid", while the previous valid link health status version remains "valid" and has not been terminated.

[0144] The same source detection status version, transaction identifier, and fault prediction record identifier constitute the basis for determining duplicate writes. When all fields are consistent, the first complete write result is used. When the prediction status, perturbation acceptance boundary, or upper limit of perturbation in the pending execution cycle are inconsistent, the record status of the later generated record is rewritten to pending verification and kept valid and marked as invalid.

[0145] The next detection cycle only calls the link health status version that has consistent link conditions, records a valid status, has a valid flag, and has not been written to the termination time, and directly uses the perturbation acceptance boundary and the upper limit of the perturbation in the pending cycle to constrain the perturbation amount.

[0146] Alternatively, the logic controller can complete the sorting of detection status versions and the comparison of boundary contraction, and then submit the sorting results to the main controller to form a fault prediction record and write it into the link health status version. This method still needs to maintain the rules of status reading sequence number sorting, same segment definition, adjacent detection status version definition, boundary contraction conditions, continuous boundary contraction number threshold, perturbation acceptance boundary and the upper limit of perturbation in the period to be executed being the same and only maintained or reduced, and the effective order of link health status versions.

[0147] Preferably, when the board-level reference clock period is 10 nanoseconds and the threshold for the number of consecutive boundary contractions is 2, the status read sequence numbers bound to the three consecutive detection status versions are 101, 102, and 103 respectively, the first mismatch segment is the third segment, the perturbation acceptance boundaries are 600, 580, and 550 count values ​​respectively, the boundary corresponding to status read sequence number 102 contracts by 20 count values ​​relative to status read sequence number 101, the boundary corresponding to status read sequence number 103 contracts by 30 count values ​​relative to status read sequence number 102, and the number of consecutive contractions reaches the threshold, the main controller forms a fault prediction record with the predicted status of "there is a hidden fault development trend"; when the perturbation acceptance boundary and the upper limit of the perturbation in the current effective link health status version are both 580 count values, the new perturbation acceptance boundary and the upper limit of the perturbation in the pending execution cycle are both 550 count values, i.e., 5.5 microseconds, and are written together with the fault prediction record into the new link health status version.

[0148] In the operating scenario shown in this embodiment: after a high-frequency electrosurgical unit completes one coagulation output and enters standby, the main controller detects that the RF output enable signal has become invalid, the output switch feedback signal is open, the residual voltage on the output side is lower than 1% of the rated output voltage for 200 milliseconds, the drive enable register and the hardware drive disable feedback signal both indicate that the power drive path is disabled, the busy / idle flag of the protection controller is idle, the current transaction flag is empty and the number of pending transactions is 0, and at the same time, the actual value of the internal bus control register is consistent with the bus clock cycle, transaction interval, node address and read / write permissions recorded in the current bus configuration version.

[0149] The main controller generates a globally unique status read sequence number 101 using the power-on cycle sequence number and the incremental read sequence number within the cycle. It writes the device identifier, hardware version, firmware version, status read sequence number 101, RF output status, power drive status, protection transaction status, bus configuration version identifier, and the time of each read into the candidate detection status version. In the same indivisible submission, it makes the detection status version effective and terminates the previous detection status version, thereby forming the effective detection status version used in this standby detection.

[0150] The main controller filters the access direction, write-enabled connection, target register address and post-read action of the registered transactions according to the transaction registration record corresponding to the detection status version. It selects a read-only transaction to access the working status register of the radio frequency sensing unit. This transaction does not involve radio frequency power, operating frequency, protection threshold, drive enable and drive latch register. After reading, it does not clear, increment, reset and cause state transition.

[0151] The main controller generates a transaction identifier for the transaction, writes the transaction identifier into the witness control register and the fixed transaction identifier field in the read request frame header. After receiving the data, the logic controller keeps the field unchanged and forwards the status request to the radio frequency sensing unit. The radio frequency sensing unit latches the same transaction identifier and the current status value, and then the logic controller sends the returned content back to the main controller.

[0152] The main controller, logic controller, and RF sensing unit use the same 100 MHz board-level reference clock to sequentially record the witnessing times of six nodes: main controller request to send, logic controller request to receive, RF sensing unit request to receive, RF sensing unit state latching, logic controller return to load, and main controller return to receive, forming a valid witnessing transaction chain.

[0153] The transaction timing baseline record bound to the transaction identifier indicates that the baseline idle time before the transaction and the baseline idle time after the transaction are both 20 microseconds, and the minimum idle time given by the transaction timing limit record is 8 microseconds; the perturbation acceptance boundary and the upper limit of the perturbation in the current link health status version are both 6 microseconds.

[0154] The main controller obtains that the idle time before and after the transaction can be shortened by 12 microseconds. Taking the minimum of these two margins and the 6-microsecond perturbation acceptance boundary, the perturbation amount for this round is determined to be 6 microseconds. Subsequently, a positive perturbation transaction with an idle time of 14 microseconds before the transaction and an idle time of 26 microseconds after the transaction is generated, as well as a negative perturbation transaction with an idle time of 26 microseconds before the transaction and an idle time of 14 microseconds after the transaction is generated. The two transactions maintain the same message content, target register, return length, node routing, bus clock configuration, and transaction body configuration duration. Their total idle time is 40 microseconds, so the total duration is exactly the same.

[0155] During the validity period of detection status version 101, the main controller generates an execution batch identifier and executes five types of transactions in a fixed order: the first anchor transaction, the forward perturbation transaction, the second anchor transaction, the reverse perturbation transaction, and the recovery transaction.

[0156] The first and second anchored transactions both use a 20-microsecond pre-transaction baseline idle time and a 20-microsecond post-transaction baseline idle time. The recovery transaction restores the same baseline configuration after the reverse perturbation transaction. A 1-millisecond scheduling interval is maintained between adjacent transactions, and this scheduling interval is not included in the total transaction duration.

[0157] Each type of transaction fully acquires 6 node witness moments. The main controller latches the return status value, return length, RF output status, power drive status, protection transaction status, and bus configuration version identifier on the same board-level reference clock edge when fully receiving the returned content. The 5 types of transactions ultimately form 30 node witness moments and 5 status digests. Moreover, the field width, byte order, enumeration value, and version identifier of each status digest are consistent. Therefore, the candidate transaction execution record is rewritten as valid.

[0158] The main controller forms five propagation time segments based on the six witness times of each type of transaction.

[0159] The propagation times for the five segments of the first anchor transaction are 120, 85, 40, 88, and 125 counts, respectively. The propagation times for the second anchor transaction are 121, 85, 41, 89, and 124 counts, respectively. The resulting segment propagation references are 121, 85, 41, 89, and 125 counts, respectively. The allowable deviation for each segment is 1 count.

[0160] The propagation times for the five segments of the forward perturbation transaction are 121, 86, 44, 91, and 126 counts. Among them, the first and second segments have not exceeded the allowable deviation, while the propagation time for the third segment, which was based on 41 counts, increases to 44 counts and is the first to exceed the allowable deviation. The propagation times for the five segments of the reverse perturbation transaction are 121, 85, 42, 90, and 126 counts, all of which have not exceeded the corresponding allowable deviation. The propagation times for the five segments of the recovery transaction have been restored to 121, 85, 41, 89, and 125 counts, and the state summary of the recovery transaction is exactly the same as the state summaries of the two anchored transactions.

[0161] Based on this, the main controller determines the third segment as the first mismatch segment, reduces the current 600 count values ​​of the perturbation by 1 board-level reference clock count value, and sets the perturbation acceptance boundary at 599 count values, or 5.99 microseconds, thus forming a valid segment determination record.

[0162] In the subsequent two standby tests, the device continues to be under the same hardware version, firmware version, bus configuration version, witness transaction chain and transaction identifier conditions. The main controller forms the detection status version corresponding to status read sequence numbers 102 and 103 respectively, and repeats the same detection process.

[0163] All three detection status versions identify the third segment as the first mismatch segment, with corresponding perturbation acceptance boundaries forming 600, 580, and 550 count values ​​respectively. Among them, status reading sequence number 102 shrinks by 20 count values ​​relative to 101, and status reading sequence number 103 continues to shrink by 30 count values ​​relative to 102. The same segment experiences two consecutive boundary shrinkages, reaching the threshold for the number of consecutive shrinkages specified in the fault prediction parameter version.

[0164] The main controller generates a fault prediction record with the predicted state "there is a hidden fault development trend". It records the detection state version corresponding to the third section and the state reading sequence numbers 101 to 103, the three perturbation acceptance boundaries and the two contraction amounts. This result indicates that the upper limit of the internal bus idle time perturbation tolerance of the section that completes state value latching after the RF sensing unit receives the state request continues to decrease, but it does not indicate that the high-frequency electrosurgical unit has experienced an RF output fault.

[0165] The main controller compares the latest 550 count values ​​of the perturbation acceptance boundary with the 580 count values ​​in the current effective link health state version, takes the smaller 550 count values ​​as both the perturbation acceptance boundary of the new link health state version and the upper limit of the perturbation in the pending execution cycle, and makes the new link health state version effective and terminates the previous version in the same indivisible commit.

[0166] After the new version is called in the next detection cycle, the amount of perturbation in the generated positive and negative perturbation transactions must not exceed 550 count values, or 5.5 microseconds, thereby completing the overall closed loop of operation from security status confirmation, read-only transaction selection, perturbation execution, segment location, boundary shrinkage identification to perturbation constraint update in the next cycle.

[0167] All calculations involved in the embodiments are dimensionless numerical calculations, and the preset parameters and thresholds in the calculations are set by those skilled in the art according to the actual situation.

[0168] It should be noted that this invention can be deployed on the device itself to realize embedded applications, or it can run on a PC or other terminal with a user interface, thereby meeting various hardware environments and usage requirements.

[0169] The above embodiments can be implemented, in whole or in part, by software, hardware, firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wireless or wired means; wired transmission methods include optical fiber, twisted pair, coaxial cable, etc.; wireless transmission includes infrared, microwave, etc. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center containing one or more sets of available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a semiconductor medium. A semiconductor medium can be a solid-state drive.

[0170] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and modules described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0171] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or modules may be electrical, mechanical, or other forms.

[0172] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0173] In addition, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0174] If the aforementioned functions are implemented as software functional modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0175] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included 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 method for predicting latent faults in high-frequency electrosurgical units based on internal bus perturbation, characterized in that, include:

1. Read the RF output status, power drive status, bus configuration and protection transaction status, and freeze the detection status version when RF output and power drive are disabled and protection transactions are idle; 2. Select read-only transactions that do not change the output parameters, protection thresholds and drive status according to the detection status version, and form a witness transaction chain in the order of main controller, logic controller and radio frequency sensing unit, and record the witness time of the node.

3. Determine the perturbation amount based on the baseline idle time, the minimum idle time of the protocol, and the perturbation acceptance boundary of the link health status version, and generate positive perturbation transactions and reverse perturbation transactions with the same total duration after exchanging the previous and subsequent idle times. IV. Within the detection status version, execute the anchoring, forward perturbation, anchoring, reverse perturbation, and recovery transactions in sequence to obtain the node witness time and status summary; V. Based on the node witnessing time, the segment propagation time is formed, and the segment propagation benchmark is established with anchored transactions. The first mismatch segment and the perturbation acceptance boundary are determined based on the positive perturbation, the reverse perturbation and the recovery transaction.

6. Arrange the first mismatched segment and the perturbation acceptance boundary according to the detection status version. Form a fault prediction record based on the boundary contraction of the same segment. Write the prediction record and the upper limit of the perturbation in the pending execution cycle into the link health status version.

2. The method for predicting latent faults in high-frequency electrosurgical units based on internal bus perturbation as described in claim 1, characterized in that, The detection status version includes status read sequence number, device identifier, hardware version, firmware version, confirmation period, RF output status, power drive status, bus configuration, bus configuration version identifier, protection transaction status, and status confirmation parameter version. After all fields of the candidate detection status version are successfully written, the record status and validity flag of the candidate detection status version are rewritten to valid in the same indivisible commit, and the termination time and terminated record status are written to the previous valid detection status version.

3. The method for predicting latent faults in high-frequency electrosurgical units based on internal bus perturbation as described in claim 1, characterized in that, A read-only transaction accesses data in the direction of reading, does not generate a write enable signal during execution, and the target register is the status register, which retains its original state after being read. The transaction identifier is written into the fixed transaction identifier field in the read request frame header and remains unchanged along the logic controller, RF sensing unit and return path; The node witness time is recorded in the following order: the main controller requests to send, the logic controller requests to receive, the RF sensing unit requests to receive, the RF sensing unit status is latched, the logic controller returns to load, and the main controller returns to receive.

4. The method for predicting latent faults in high-frequency electrosurgical units based on internal bus perturbation as described in claim 1, characterized in that, The perturbation quantity is the smallest non-negative complete count value among the following: the base idle time before the transaction minus the minimum idle time of the protocol, the base idle time after the transaction minus the minimum idle time of the protocol, and the perturbation acceptance boundary count value. For forward perturbation transactions, the idle time before the transaction decreases the perturbation amount, while the idle time after the transaction increases the perturbation amount. For reverse perturbation transactions, the idle time before the transaction increases the perturbation amount, while the idle time after the transaction decreases the perturbation amount. The transaction body configuration duration and total duration are the same for both.

5. The method for predicting latent faults in high-frequency electrosurgical units based on internal bus perturbation as described in claim 1, characterized in that, The two anchored transactions use the same read-only transaction content, access direction, target register, return length, node routing, bus clock configuration, and base idle time; Each type of transaction obtains six witness moments and latches a status summary consisting of the return status value, return length, RF output status, power drive status, protection transaction status, and bus configuration version identifier when the main controller fully receives the return content; When the five types of transactions, node witness times, and status summaries are complete, the record status and validity flag of the candidate transaction execution record are rewritten as valid.

6. The method for predicting latent faults in high-frequency electrosurgical units based on internal bus perturbation according to claim 1, characterized in that, The five segments are formed according to the order of the witnessing times of adjacent nodes. The propagation time of each segment is the count value of the witnessing time of the next node minus the count value of the witnessing time of the previous node. The segment propagation reference is the sum of the segment propagation times corresponding to the two anchor transactions, divided by two and rounded up. The allowable deviation is the larger of the count value obtained by dividing the absolute value of the difference between the segment propagation times corresponding to the two anchor transactions by two and rounding up, and a board-level reference clock count value.

7. The method for predicting latent faults in high-frequency electrosurgical units based on internal bus perturbation according to claim 6, characterized in that, The segment whose absolute value of the difference between the segment propagation time and the segment propagation reference is greater than the allowable deviation is recorded as the mismatch segment, and the first mismatch segment is determined according to the first segment to the fifth segment; When the absolute value of the difference between each segment of the recovery transaction is not greater than the allowable deviation, and the state summaries of the forward perturbation transaction, the reverse perturbation transaction, and the recovery transaction are all consistent with the common state summary of the anchor transaction, the perturbation acceptance boundary is taken as the current perturbation amount when neither of the two perturbation transactions is mismatched, and the current perturbation amount is taken as the current perturbation amount minus one board-level reference clock count value when there is a mismatch, and the current perturbation amount is taken as zero when it is one count value.

8. The method for predicting latent faults in high-frequency electrosurgical units based on internal bus perturbation according to claim 1, characterized in that, The first mismatch segment and the perturbation acceptance boundary of the detected status version are used to form a segment determination record; Records with identical device identifier, hardware version, firmware version, bus configuration version identifier, witness transaction chain identifier, and transaction identifier are arranged by status reading sequence number. Boundary contraction is determined when adjacent records have the same first mismatch segment and the subsequent perturbation acceptance boundary is reduced by at least one board-level reference clock count value. When the boundary of the same segment contracts once, the predicted record writes the contraction evidence but does not reach the trend threshold. When the boundary of the same segment contracts twice in a row, the record writes that there is a hidden fault development trend.

9. The method for predicting latent faults in high-frequency electrosurgical units based on internal bus perturbation as described in claim 8, characterized in that, Compare the perturbation acceptance boundary of the latest valid segment determination record with the perturbation acceptance boundary of the current valid link health status version, and take the smaller value as both the perturbation acceptance boundary of the new link health status version and the upper limit of perturbation for the pending execution cycle. In the same non-split commit, the record status and validity flag of the new link health status version are rewritten to be valid, and the termination time and terminated record status are written to the previous valid link health status version. The next detection cycle will only call the link health status version where the record status and valid flags are both valid and have not been written to the termination time.

Images