Medical device system with communication self-recovery capability

Abstract

The application discloses a medical device system with communication self-recovery capability, and belongs to the technical field of medical device communication reliability, and comprises: an abnormal input layer, which is arranged on an upper computer and / or a lower computer, and is used for acquiring abnormal state information of a communication link; a strategy decision layer, which is used for determining a strategy decision result according to the abnormal state information; a recovery control layer, which is used for generating a control instruction according to the strategy decision result; a cooperative control layer, which is used for splitting the control instruction into an upper computer instruction and a lower computer instruction and performing synchronous scheduling; a communication execution layer, which is used for executing the upper computer instruction and the lower computer instruction after the synchronous scheduling respectively on the upper computer and the lower computer, and returning an execution result; and each layer is connected through a unified context object to realize data flow conversion and form a closed-loop recovery link. The application can realize automatic recovery of a communication link abnormality, improve communication reliability and system stability, and is suitable for a communication link abnormality recovery scene between an upper computer and a lower computer of a medical device.

Description

Technical Field

[0001] This invention belongs to the field of medical device communication reliability technology, and specifically relates to a medical device system with communication self-recovery capability. Background Technology

[0002] In medical devices (such as cardiac rhythm management programmable controllers), the programmable controller is a core tool for clinical follow-up and parameter adjustment. Programmable controllers typically employ a master-slave architecture. The master computer (programmable controller software) is responsible for data processing, human-computer interaction, and decision support, while the slave computer (programming head) interacts with the implanted device via near-field communication. The communication link between the master and slave computers is a critical hub for system operation; its stability directly affects the reliability of medical procedures and patient safety.

[0003] However, in actual clinical use environments, communication links often face multiple challenges, including complex electromagnetic interference, software anomalies, and occasional hardware failures, leading to abnormal phenomena such as communication interruptions, no response, or communication freezes (the link physically exists but there is no effective data exchange). If these anomalies are not resolved in a timely manner, they may result in programmable operation failures, data loss, or even clinical misjudgments, posing serious safety risks.

[0004] Existing technologies already offer some solutions for communication link anomalies. For example, Chinese patent application CN115915229A proposes a system for automatically recovering from malfunctions in leaky cable monitoring equipment. Its core idea is to achieve a complete power-off restart and factory calibration data recovery through the collaboration of hardware modules, an MCU control unit, and an external watchdog timer, thus possessing a certain degree of self-recovery capability. However, this solution focuses on hardware-level device self-recovery, primarily relying on watchdog timers and power management for overall reset. It lacks a targeted detection and tiered processing mechanism for communication link anomalies, and its recovery strategy is relatively fixed, making it difficult to adapt to the dynamic needs of different anomaly scenarios.

[0005] Chinese patent application CN120614242A proposes an intelligent fault monitoring system for switches. Its core is driven by AI and big data, employing multimodal data acquisition, deep learning feature extraction, and reinforcement learning decision-making to achieve fault prediction, root cause localization, and self-healing strategy optimization. While this solution represents a significant improvement in intelligence and system coordination, it primarily targets network communication equipment, focusing on overall equipment maintenance and lacking a systematic design specifically for abnormal communication links between host and slave devices in medical equipment. Furthermore, its complex AI model presents significant deployment challenges in real-time and resource-constrained medical scenarios.

[0006] In summary, existing technologies still have the following shortcomings: First, they lack a unified and coordinated mechanism for system-level anomaly detection, intelligent decision-making, and tiered recovery of medical device communication links; second, recovery methods are mostly fixed patterns, unable to dynamically adjust recovery strategies based on the type and severity of the anomaly; and third, most solutions focus on overall device failure, lacking specificity for communication link anomalies. Therefore, there is an urgent need for a system-level intelligent fault recovery solution for the communication links between upper and lower level computers of medical devices. Summary of the Invention

[0007] In view of the above, the purpose of this invention is to provide a medical device system with communication self-recovery capability. Based on a layered architecture, unified data context, and multi-layer scheduling mechanism, it realizes self-sensing, self-decision-making, and self-recovery closed-loop operation of communication link anomalies. This solves the problems of functional dispersion, lack of system-level coordination, and fixed recovery methods in the prior art, reduces manual intervention, improves communication reliability and system stability, and is applicable to communication link anomaly recovery scenarios between medical device host and slave computers.

[0008] To achieve the above-mentioned objectives, the present invention provides the following technical solution: In a first aspect, an embodiment of the present invention provides a medical device system with communication self-recovery capability, comprising: An abnormal input layer, deployed on the host computer and / or the slave computer, is used to obtain abnormal status information of the communication link; The strategy decision-making layer is used to determine the strategy decision-making results based on abnormal state information. The recovery control layer is used to generate control commands based on the results of policy decisions. The collaborative control layer is used to break down control commands into upper-level computer commands and lower-level computer commands and perform synchronous scheduling. The communication execution layer is used to send the synchronized and scheduled upper computer instructions and lower computer instructions to the upper computer and lower computer respectively for execution, and return the execution results; Data flows between layers through a unified context object, forming a closed-loop recovery link from abnormal input to execution feedback.

[0009] Preferably, the abnormal input layer includes: The standardized unit is used to verify the legality of abnormal status information, convert the verified abnormal status information into a standard format, and trigger subsequent policy decisions and recovery operations. Specifically, if the duration in the abnormal status information is less than a preset time threshold, the verification fails and the recovery process is not triggered; if the duration is greater than or equal to the preset time threshold, the verification passes. The de-jitter unit is used to determine whether repeated reports of the same abnormality type are the same abnormal event based on the timestamp of the abnormal status information. When the time interval between two adjacent reports is less than the preset de-jitter threshold, it is determined to be the same abnormal event and the repeated reports are filtered out. When the time interval is greater than or equal to the preset de-jitter threshold, it is determined to be a new abnormal event and reported. The caching unit is used to store the standardized and debouncing abnormal state information into a first-in-first-out queue for the policy decision layer to read in sequence.

[0010] Preferably, the strategy decision layer includes: The strategy invocation unit is used to invoke the external strategy module to generate the corresponding strategy decision result based on the abnormal status information, and to map the priority information in the strategy decision result to discrete priority levels. The throttling control unit is used to limit the minimum call cycle to external policy modules. When the time interval between two adjacent calls is less than the preset throttling threshold, the current call is rejected and the policy decision result of the previous call is reused. The reuse control unit is used to reuse the generated strategy decision results when the same abnormal state information recurs within a preset time interval, thus avoiding repeated calls to external strategy modules. The round control unit is used to maintain the current recovery round count. When the recovery round exceeds the preset maximum round threshold, the recovery process is stopped and a recovery failure is reported.

[0011] Preferably, the recovery control layer includes: The policy mapping unit stores the mapping relationship between policy identifiers and target devices, and is used to determine the target device based on the policy identifier in the policy decision result. The parameter configuration unit stores preset execution parameters corresponding to different policy identifiers or configuration rules for dynamically parsing external policy parameters, so that the policy identifier can obtain the timeout time and retry count corresponding to the target device and generate control commands.

[0012] Preferably, the collaborative control layer includes: The instruction splitting unit is used to split the control instruction into host computer instructions and slave computer instructions according to the target device field in the control instruction; The synchronization scheduling unit is used to trigger the execution of host computer instructions and slave computer instructions according to preset synchronization time constraints. When the deviation between the actual execution time of the host computer instruction and the actual execution time of the slave computer instruction does not exceed the preset synchronization error threshold, the collaborative execution is determined to be successful; when the deviation exceeds the preset synchronization error threshold, the collaborative execution is determined to be unsuccessful. The timeout monitoring unit is used to monitor the execution time of upper computer instructions and lower computer instructions. When the execution time of any instruction exceeds the timeout time in the control instruction, the instruction is determined to have timed out. The state recording unit is used to write the collaborative execution results into the collaborative state field of the context object for the communication execution layer to read.

[0013] Preferably, the communication execution layer includes: The execution scheduling unit is used to issue corresponding instructions to the host computer and the slave computer respectively according to the synchronization scheduling results output by the collaborative control layer; The status tracking unit is used to record the execution status of the host computer instructions and the slave computer instructions in real time. The execution status includes not started, in execution, and completed. The result determination unit is used to comprehensively determine whether the recovery was successful based on the execution status and the communication recovery identifier obtained from the communication link, and generate an execution result that includes a recovery success identifier and the recovery time.

[0014] Preferably, the context object includes an exception status field, a strategy decision result field, a control instruction field, a coordination status field, an execution result field, a loop count field, and a timestamp field, wherein the loop count field is used to record the current recovery round, and the timestamp field is used to record the update time of the context object.

[0015] Preferably, when data flows through a unified context object, each layer concurrently accesses the unified context object through a read-write lock control mechanism or an atomic state update mechanism. The unified context object is equipped with a write protection lock and a version identifier. When any layer needs to update a target field in the unified context object, it first acquires the write protection lock, increments the version identifier after writing the updated data, and releases the write protection lock. Other layers verify the version identifier when reading the target field to ensure data consistency and timing correctness during cross-thread flow.

[0016] Preferably, the unified context object uses an event-driven mechanism or the observer pattern to realize data flow between layers; when any layer updates the corresponding field in the unified context object, a state update event is triggered and the subsequent layers that subscribe to the field are notified. The subsequent layers respond to the state update event by reading the updated field through a callback function and executing the corresponding processing logic to achieve asynchronous decoupled operation across layers.

[0017] Secondly, embodiments of the present invention also provide an execution method for a medical device system with communication self-recovery capability as described above, comprising the following steps: S1, the exception input layer obtains the exception status information of the communication link and writes it into the exception status field of the unified context object; S2, the strategy decision layer reads the abnormal status field, determines the strategy decision result based on the abnormal status information, and writes it into the strategy decision result field of the unified context object; S3, the control layer reads the policy decision result field, generates control instructions based on the policy decision result, and writes them into the control instruction field of the unified context object; S4, the collaborative control layer reads the control instruction field, splits the control instruction into upper computer instruction and lower computer instruction and performs synchronous scheduling, and writes the collaborative state into the collaborative state field of the unified context object; S5, the communication execution layer reads the coordination status field, sends the synchronized upper computer instructions and lower computer instructions to the upper computer and lower computer respectively for execution, returns the execution result and writes it to the execution result field of the unified context object; S6. Determine whether communication has been restored based on the execution result field. If it has been restored, the process ends. If it has not been restored and the current restoration round is less than the preset maximum round threshold, update the loop count field of the unified context object and return to step S2 to enter the next round of restoration.

[0018] Compared with the prior art, the beneficial effects of the present invention include at least the following: (1) This invention constructs a five-layer collaborative architecture consisting of an abnormal input layer, a strategy decision layer, a recovery control layer, a collaborative control layer, and a communication execution layer. It also uses a unified data context for data flow between layers, forming a closed-loop recovery link from abnormal input to execution feedback. This achieves system-level integration and collaborative operation of detection, decision-making, and recovery functions, solving the problems of scattered functional modules and lack of unified coordination mechanism in the prior art, and effectively improving the success rate of communication recovery.

[0019] (2) This invention implements call frequency limits, reuse of repeated state decision results, and recovery round limits for abnormal state responses by setting up throttling control units, reuse control units, and round control units at the strategy decision layer. This achieves adaptive scheduling for different abnormal scenarios and avoids the ineffective occupation of system resources. At the same time, through the strategy mapping mechanism of the recovery control layer, it supports mapping control instructions containing target devices, timeout times, and retry counts according to different strategy identifiers. This enables the system to flexibly adapt to various abnormal types such as communication interruption, communication no response, and communication freeze, and has differentiated recovery capabilities under complex abnormal scenarios.

[0020] (3) This invention establishes a synchronization scheduling unit in the collaborative control layer to enforce synchronization constraints on the split upper-end and lower-end machine instructions, ensuring the timing consistency of the recovery actions at both ends. Simultaneously, the communication execution layer tracks the instruction execution status in real time and comprehensively determines the success of the recovery based on the communication recovery flag, forming a complete execution feedback loop. This mechanism enables the system to maintain an orderly collaborative recovery process even in complex electromagnetic environments, effectively avoiding secondary anomalies caused by asynchronous actions at both ends, improving the overall stability of the system, and reducing the need for manual intervention.

[0021] (4) The present invention realizes the flexible access and replacement of anomaly detection methods, strategy decision logic and recovery execution actions. The system interacts with each layer through a unified data model. It does not depend on specific detection methods, does not limit specific strategy implementation or specific recovery methods, and has good scalability. It can be widely used in different medical device communication systems and industrial control scenarios. Attached Figure Description

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

[0023] Figure 1 This is a schematic diagram of the structure and process of a medical device system with communication self-recovery capability provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the data flow of the unified context object provided in an embodiment of the present invention; Figure 3 This is a flowchart illustrating the collaborative control layer provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of the closed-loop scheduling process provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the execution method of a medical device system with communication self-recovery capability provided in an embodiment of the present invention. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and do not limit the scope of protection of this invention.

[0025] The inventive concept of this invention is as follows: Addressing the problems in existing technologies where communication link anomaly detection, decision-making, and recovery functions are fragmented, lack a system-level coordination mechanism, have a single and fixed recovery method, and primarily focus on overall equipment failure rather than the communication link itself, this invention provides a medical device system with self-recovery communication capabilities. This system constructs a five-layered collaborative architecture comprising an anomaly input layer, a strategy decision layer, a recovery control layer, a collaborative control layer, and a communication execution layer. A unified context object is used for inter-layer data flow, forming a closed-loop recovery link from anomaly input to execution feedback. This enables automatic detection, strategy decision-making, and tiered recovery of communication link anomalies, allowing for adaptive recovery from various anomaly scenarios such as communication interruption, communication unresponsiveness, and communication freeze.

[0026] like Figure 1 As shown, this embodiment provides a medical device system 100 with communication self-recovery capability, including an abnormal input layer 110, a strategy decision layer 120, a recovery control layer 130, a collaborative control layer 140, and a communication execution layer 150. A specific example is provided using a cardiac rhythm management device's programmable controller (the host computer 160 is the programmable controller software, and the slave computer 170 is the programmable controller head). It should be noted that each layer can be deployed entirely on the host computer, entirely on the slave computer, or distributed across both the host and slave computers (e.g., the strategy decision layer 120 is deployed on the host computer, and the collaborative control layer 140 is deployed on the slave computer). This invention does not limit this.

[0027] First, a system-level unified context object, `System_Context`, is defined. Data flow between layers is achieved through this unified context object, forming a closed-loop recovery chain from exception input to execution feedback. Specifically, it includes the exception state field `abnormal_state`, the policy decision result field `decision_result`, the control command field `control_command`, the coordination state field `coordination_state`, the execution result field `execution_result`, the loop counter field `loop_counter` (8-bit unsigned integer (uint8), and the timestamp field `Timestamp` (64-bit unsigned integer (uint64)). The loop counter field records the current recovery cycle, and the timestamp field records the update time of the context object. For example... Figure 2 As shown, each layer achieves data flow and state synchronization by reading and updating the context object. System operation constraints include: decision cycle ≥ 100ms, maximum number of recovery attempts = 5 (any value between 3 and 7, preferably 5), global timeout = 5000ms (any value between 1000ms and 30000ms, preferably 5000ms), and synchronization error ≤ 50ms.

[0028] When data flows through a unified context object, each layer concurrently accesses the unified context object through a read-write lock control mechanism or an atomic state update mechanism. The unified context object is equipped with a write protection lock and a version identifier. When any layer needs to update a target field in the unified context object, it first acquires the write protection lock, increments the version identifier after writing the updated data, and releases the write protection lock. Other layers verify the version identifier when reading the target field to ensure data consistency and timing correctness during cross-thread flow.

[0029] Meanwhile, the unified context object uses an event-driven mechanism or the observer pattern to realize data flow between layers. When any layer updates the corresponding field in the unified context object, a state update event is triggered and the subsequent layers that subscribe to the field are notified. The subsequent layers respond to the state update event by reading the updated field through a callback function and executing the corresponding processing logic to achieve asynchronous decoupled operation across layers.

[0030] (1) An abnormal input layer 110 is deployed on the host computer 160 and / or the slave computer 170. It is used to receive abnormal status information output by the external abnormal detection module, and output the abnormal status information after standardization, debouncing and buffer management. The abnormal input layer 110 includes a standardization unit 111, a debouncing unit 112 and a buffer unit 113.

[0031] The abnormal state information Abnormal_State data structure received by the abnormal input layer 110 is as follows: Abnormal_State = {state_code: 16-bit unsigned integer (uint16), severity: 8-bit unsigned integer (uint8), duration_ms: 32-bit unsigned integer (uint32), timestamp: 64-bit unsigned integer (uint64)}, Among them, state_code represents the exception type identifier (from the exception detection module), severity represents the severity (value range is 1~5), duration_ms represents the duration of the exception state (unit: milliseconds), and timestamp represents the time when the exception occurred.

[0032] Standardization unit 111 is used to verify the legality of abnormal status information, converting the verified abnormal status information into a standard format and triggering subsequent policy decisions and recovery operations. Specifically, it first verifies that the abnormal status information satisfies severity∈[1,5] and duration_ms>0. Then, it performs a threshold verification. If the duration_ms is less than a preset time threshold (e.g., 500ms), the verification fails and the recovery process is not triggered; if the duration_ms is greater than or equal to the preset time threshold (500ms), the verification passes.

[0033] The debouncing unit 112 is used to determine whether repeated reports of the same exception type (state_code) are the same exception event based on the timestamp of the exception state information. When the time interval between two adjacent reports is less than the preset debouncing threshold (preferably any value within 50ms to 500ms, more preferably 200ms), it is determined to be the same exception event and the repeated reports are filtered out; when the time interval is greater than or equal to the preset debouncing threshold (200ms), it is determined to be a new exception event and reported.

[0034] Parameter examples are as follows: Abnormal_State_1={state_code:0x03,severity:3,duration_ms:0,timestamp:105230}, Abnormal_State_2={state_code:0x03,severity:3,duration_ms:0,timestamp:105290}, Δt=105290-105230=60ms<200ms, therefore, Abnormal_State_1 and Abnormal_State_2 are determined to be the same abnormal event, and the abnormal state information reported later is used as the current abnormal state information.

[0035] The cache unit 113 is used to store the abnormal state information after standardization and debouncing into a first-in-first-out queue (the queue length is preferably 16~128, more preferably 32) for the policy decision layer 120 to read in sequence.

[0036] The output of the abnormal input layer 110 is written to the System_Context.abnormal_state field.

[0037] (2) The strategy decision layer 120 is communicatively connected to the abnormal input layer 110. It is used to receive abnormal status information, call the external strategy module to obtain the strategy decision result based on the abnormal status information, and output the strategy decision result after performing throttling control, reuse control and round control. The strategy decision layer 120 includes a strategy call unit 121, a throttling control unit 122, a reuse control unit 123 and a round control unit 124.

[0038] The strategy invocation unit 121 receives the abnormal state information `abnormal_state`, calls the external strategy module through the strategy interface, and obtains the corresponding strategy decision result `decision_result = Decision_API(abnormal_state)`. The strategy decision result `decision_result` contains the strategy identifier `strategy_id` and the normalized priority score `Priority(Pi)` (Pi is the i-th strategy decision result, with a value range of 0~1). This system converts the normalized priority score into a discrete priority level `priority_level` (with a value range of 1~10) through a preset mapping relationship for subsequent control instruction scheduling. A specific mapping example is `priority_level = ceil(Priority(Pi) × 10)`, where `ceil()` represents rounding up. The complete strategy decision result is represented as `decision_result = { strategy_id: 16-bit unsigned integer (uint16), priority_level: 8-bit unsigned integer (uint8)}`, which is read and used by the recovery control layer 130.

[0039] Parameter examples are as follows: strategy_id=3, Priority(Pi)=0.2, priority_level=ceil(0.2×10)=2, decision_result={3,2}.

[0040] The throttling control unit 122 is used to limit the minimum call cycle of the external strategy module. When the time interval between two adjacent calls is less than the preset throttling threshold (preferably any value within 10ms to 1000ms, more preferably 100ms), the current call is rejected and the previous strategy decision result is reused.

[0041] The reuse control unit 123 is used to reuse the generated strategy decision results when the same abnormal state information recurs within a preset time interval (e.g., 500ms), thereby avoiding repeated calls to external strategy modules.

[0042] The round control unit 124 is used to maintain the current recovery round count. According to the loop count field loop_counter, when the recovery round exceeds the preset maximum round threshold (e.g., 5 times), the recovery process is stopped and a recovery failure is reported.

[0043] The output of the strategy decision layer 120 is written to the System_Context.decision_result field.

[0044] (3) The recovery control layer 130 is connected to the strategy decision layer 120 and is used to receive the strategy decision results after control, map the strategy decision results into control instructions for the host computer 160 and / or the slave computer 170 and output them. The recovery control layer 130 includes a strategy mapping unit 131 and a parameter configuration unit 132.

[0045] The policy mapping unit 131 stores the mapping relationship between policy identifiers and control commands, and is used to determine the corresponding control command based on the policy identifier in the policy decision result (decision_result). The control command includes the target device, timeout time, and number of retries. The Control_Command data structure is as follows: Control_Command={strategy_id: 16-bit unsigned integer (uint16), target_device: 8-bit unsigned integer (uint8), timeout: 32-bit unsigned integer (uint32), retry_count: 8-bit unsigned integer (uint8)}, Where strategy_id represents the strategy identifier, target_device represents the target device (0: host computer, 1: slave computer, 2: dual-end), timeout represents the timeout period (in milliseconds), and retry_count represents the number of retries.

[0046] The parameter configuration unit 132 stores preset parameter configurations corresponding to different policy identifiers, including timeout time and retry count. When the policy mapping unit 131 determines the control command based on the policy identifier, it retrieves the corresponding timeout time and retry count from the parameter configuration unit 132 and fills it into the control command.

[0047] Examples of preset parameter configurations for different strategies are as follows: The silent retransmission strategy has a timeout of 100ms and a retry count of 3. The software reset strategy has a timeout of 300ms and a retry count of 2. The port reset policy has a timeout of 500ms and a retry count of 1.

[0048] The output of the restored control layer 130 is written to the System_Context.control_command field.

[0049] (4) The collaborative control layer 140, which is communicatively connected to the recovery control layer 130, is used to receive control commands, split the control commands into upper-level computer commands and lower-level computer commands, and output the upper-level computer commands and lower-level computer commands after performing synchronization scheduling. The collaborative control layer 140 includes a command splitting unit 141, a synchronization scheduling unit 142, and a timeout monitoring unit 143, and the process is as follows: Figure 3 As shown.

[0050] The instruction splitting unit 141 is used to split the control instruction into a host instruction (Host_Command) and a slave instruction (Device_Command) based on the target device field in the control instruction (control_command). For example, when the policy is PORT_RESET, Host_Command is close_port() to close the port, and Device_Command is reset_controller() to reset the controller.

[0051] The synchronization scheduling unit 142 is used to trigger the execution of host computer instructions and slave computer instructions according to preset synchronization time constraints. The difference Δt between the execution times T_host and T_device of the host computer instructions and the slave computer instructions must satisfy the synchronization constraint |T_host-T_device|≤T_threshold, where T_threshold is a preset synchronization error threshold (preferably any value within 10ms~100ms, more preferably 50ms). When the deviation between the actual execution time of the host computer instructions and the actual execution time of the slave computer instructions does not exceed the preset synchronization error threshold, the collaborative execution is determined to be successful; when the deviation exceeds the preset synchronization error threshold, the collaborative execution is determined to be unsuccessful.

[0052] The timeout monitoring unit 143 is used to monitor the execution time of the host computer instructions and the slave computer instructions. When the execution time of any instruction exceeds the timeout time in the control instruction, it is determined that the instruction has timed out.

[0053] The coordination control layer 140 writes the coordination execution result to the coordination state field of the context object. The coordination state coordination_state data structure is as follows: coordination_state={host_status: 8-bit unsigned integer (uint8), device_status: 8-bit unsigned integer (uint8), sync_flag: bool}, Among them, host_status indicates the execution status of the host machine (0: not started, 1: in execution, 2: completed), device_status indicates the execution status of the slave machine (same as above), and sync_flag indicates whether synchronization is complete.

[0054] The output of the coordination control layer 140 is written to the System_Context.coordination_state field.

[0055] (5) Communication execution layer 150, which is communicatively connected to collaborative control layer 140, is used to receive upper computer instructions and lower computer instructions after synchronization scheduling, send them to the upper computer and lower computer for execution respectively, and obtain the execution results. Communication execution layer 150 includes execution scheduling unit 151, status tracking unit 152 and result determination unit 153.

[0056] The execution scheduling unit 151 is used to issue corresponding instructions to the host computer 160 and the slave computer 170 respectively according to the synchronization scheduling result of the collaborative control layer 140, and trigger execution by T_host and T_device.

[0057] The status tracking unit 152 is used to record the execution status of host computer instructions and slave computer instructions in real time. The execution status Execution_Status data structure is as follows: Execution_Status={host_done:bool,device_done:bool,start_time:64-bit unsigned integer (uint64),end_time:64-bit unsigned integer (uint64)}, Here, `host_done` indicates whether the host machine has completed execution, `device_done` indicates whether the slave machine has completed execution, `start_time` indicates the start time, and `end_time` indicates the end time. Execution status includes three states: not started, executing, and completed.

[0058] The result determination unit 153 is used to comprehensively determine whether the recovery was successful based on the execution status and the communication recovery flag obtained from the communication link, and to generate an execution result containing a recovery success flag and the recovery time. The execution completion determination condition is `execution_complete=(host_done ==true)&&(device_done==true)`, meaning that execution is considered complete when both the host computer and the slave computer have completed execution, where `host_done` represents the host computer's execution completion flag and `device_done` represents the slave computer's execution completion flag. The communication recovery flag is provided by an external communication status detection module; this system does not implement the detection function. If the execution time exceeds the timeout period `timeout_ms`, the execution is considered to have timed out and failed.

[0059] The execution result (Execution_Result) data structure is as follows: Execution_Result={success:bool,recovery_time_ms:32-bit unsigned integer (uint32),coordination_flag: bool}, Here, `success` indicates whether the recovery was successful, `recovery_time_ms` indicates the recovery time (in milliseconds), and `coordination_flag` indicates whether the coordination constraints were met. The recovery success condition is: `success = (execution_complete == true) && (communication recovery == true)`.

[0060] The output of the communication execution layer is written to the System_Context.execution_result field.

[0061] like Figure 4 As shown, the closed-loop operation mechanism of this system is as follows: Step 1: Write the abnormal state (abnormal_state) to the abnormal input layer 110; Step 2: Strategy decision layer 120 generates strategy decision_result; Step 3: Restore control layer 130 to generate control command control_command; Step 4: Split and synchronize the collaborative control layer 140; Step 5: The communication execution layer 150 executes and generates the execution result execution_result; Step 6: Update System_Context; Step 7: If recovery is not achieved, increment the count loop_counter by 1 and proceed to the next recovery round until the preset maximum number of times is reached, at which point the recovery process ends.

[0062] In summary, medical device systems with communication self-recovery capabilities are suitable for medical device systems involving communication reliability and self-recovery control, especially in scenarios where data interaction occurs between a host computer and a slave computer via a communication link. These include, but are not limited to, cardiac rhythm management device controllers, external control systems for implantable medical devices, and medical data acquisition and transmission systems. By constructing a system architecture with communication self-recovery capabilities, the communication link can be automatically restored in the event of communication anomalies, improving the stability and reliability of the system.

[0063] Taking the recovery from a communication link freeze in medical devices as an example, in the cardiac rhythm management device's controller, the system structure includes a host computer (controller software), a slave computer (controller head), and the communication interface between them. When a communication freeze occurs, the abnormal status information received by the abnormal input layer 110 is: state_code=0x03, severity=3, duration_ms=2000, timestamp=105200. The execution flow is as follows: Round 1: The strategy decision layer 120 calls the external strategy module based on the abnormal status information to obtain the silent retransmission strategy (strategy_id corresponds to silent retransmission). The recovery control layer 130 maps it to a control command (timeout=100ms, retry_count=3). The coordination control layer 140 splits it into upper-level computer commands and lower-level computer commands and performs synchronous scheduling. The communication execution layer 150 issues the execution, and the execution result is failure. Round 2: The strategy decision layer 120 retrieves the software reset strategy (timeout=300ms, retry_count=2), and the execution result is failure; Round 3: The strategy decision layer 120 obtains the port reset policy (timeout=500ms, retry_count=1). The strategy mapping unit 131 of the recovery control layer 130 determines the control command based on the policy identifier, obtains the corresponding timeout time and retry count from the parameter configuration unit 132, and fills it into the control command (target_device=2 dual-end). The command splitting unit 141 of the collaborative control layer 140 splits the control command into the host computer command close_port() and the slave computer command reset_controller(). The synchronization scheduling unit 142 performs synchronization scheduling. The actual synchronization error is 20ms (≤50ms), and the collaborative execution is judged to be successful. The communication execution layer 150 issues the execution. After obtaining the communication recovery identifier, the result judgment unit comprehensively judges that the recovery is successful, and the output result is success=true, recovery_time_ms=1200ms.

[0064] Furthermore, this invention can also be applied to industrial control systems, embedded devices, and other systems with high requirements for communication reliability, such as industrial automation control systems, remote equipment control systems, and mission-critical communication systems. In complex electromagnetic environments or communication instability scenarios, this invention achieves automatic detection, response, and recovery control of communication anomalies through a system-level collaborative control mechanism.

[0065] This invention is applicable to various communication methods, including but not limited to serial communication, USB communication, network communication and wireless communication, and is not dependent on specific communication protocols and communication interface forms. It is applicable to self-recovery control in any communication link.

[0066] This invention is based on a layered architecture design. Through the collaborative work of abnormal information input, strategy decision-making and recovery control, it realizes system-level closed-loop control for communication anomaly handling. The anomaly detection method, strategy decision-making mechanism and specific recovery execution method can all be implemented or extended by external modules, and this invention does not limit them.

[0067] This invention can also be applied to host computer software systems, embedded firmware systems, or communication middleware to build system-level solutions with communication self-recovery capabilities.

[0068] Based on the same inventive concept, such as Figure 5 As shown, this embodiment of the invention also provides an execution method for a medical device system with communication self-recovery capability as described above, comprising the following steps: S1, the exception input layer obtains the exception status information of the communication link and writes it into the exception status field of the unified context object; S2, the strategy decision layer reads the abnormal status field, determines the strategy decision result based on the abnormal status information, and writes it into the strategy decision result field of the unified context object; S3, the control layer reads the policy decision result field, generates control instructions based on the policy decision result, and writes them into the control instruction field of the unified context object; S4, the collaborative control layer reads the control instruction field, splits the control instruction into upper computer instruction and lower computer instruction and performs synchronous scheduling, and writes the collaborative state into the collaborative state field of the unified context object; S5, the communication execution layer reads the coordination status field, sends the synchronized upper computer instructions and lower computer instructions to the upper computer and lower computer respectively for execution, returns the execution result and writes it to the execution result field of the unified context object; S6. Determine whether communication has been restored based on the execution result field. If it has been restored, the process ends. If it has not been restored and the current restoration round is less than the preset maximum round threshold, update the loop count field of the unified context object and return to step S2 to enter the next round of restoration.

[0069] It should be noted that the execution method of the medical device system with communication self-recovery capability provided in the above embodiments belongs to the same inventive concept as the medical device system with communication self-recovery capability. For details of its specific implementation process, please refer to the embodiments of the medical device system with communication self-recovery capability, which will not be repeated here.

[0070] The specific embodiments described above illustrate the technical solution and beneficial effects of the present invention in detail. It should be understood that the above description is only the most preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, additions, and equivalent substitutions made within the scope of the principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A medical device system with self-recovery communication capability, characterized in that, include: An abnormal input layer, deployed on the host computer and / or the slave computer, is used to obtain abnormal status information of the communication link; The strategy decision-making layer is used to determine the strategy decision-making results based on abnormal state information. The recovery control layer is used to generate control commands based on the results of policy decisions. The collaborative control layer is used to break down control commands into upper-level computer commands and lower-level computer commands and perform synchronous scheduling. The communication execution layer is used to send the synchronized and scheduled upper computer instructions and lower computer instructions to the upper computer and lower computer respectively for execution, and return the execution results; Data flows between layers through a unified context object, forming a closed-loop recovery link from abnormal input to execution feedback.

2. The medical device system with communication self-recovery capability according to claim 1, characterized in that, The abnormal input layer includes: The standardized unit is used to verify the legality of abnormal status information, convert the verified abnormal status information into a standard format, and trigger subsequent policy decisions and recovery operations. Specifically, if the duration in the abnormal status information is less than a preset time threshold, the verification fails and the recovery process is not triggered; if the duration is greater than or equal to the preset time threshold, the verification passes. The de-jitter unit is used to determine whether repeated reports of the same abnormality type are the same abnormal event based on the timestamp of the abnormal status information. When the time interval between two adjacent reports is less than the preset de-jitter threshold, it is determined to be the same abnormal event and the repeated reports are filtered out. When the time interval is greater than or equal to the preset de-jitter threshold, it is determined to be a new abnormal event and reported. The caching unit is used to store the standardized and debouncing abnormal state information into a first-in-first-out queue for the policy decision layer to read in sequence.

3. The medical device system with communication self-recovery capability according to claim 1, characterized in that, The strategy decision-making layer includes: The strategy invocation unit is used to invoke the external strategy module to generate the corresponding strategy decision result based on the abnormal status information, and to map the priority information in the strategy decision result to discrete priority levels. The throttling control unit is used to limit the minimum call cycle to external policy modules. When the time interval between two adjacent calls is less than the preset throttling threshold, the current call is rejected and the policy decision result of the previous call is reused. The reuse control unit is used to reuse the generated strategy decision results when the same abnormal state information recurs within a preset time interval, thus avoiding repeated calls to external strategy modules. The round control unit is used to maintain the current recovery round count. When the recovery round exceeds the preset maximum round threshold, the recovery process is stopped and a recovery failure is reported.

4. The medical device system with communication self-recovery capability according to claim 1, characterized in that, The recovery control layer includes: The policy mapping unit stores the mapping relationship between policy identifiers and target devices, and is used to determine the target device based on the policy identifier in the policy decision result. The parameter configuration unit stores preset execution parameters corresponding to different policy identifiers or configuration rules for dynamically parsing external policy parameters, so that the policy identifier can obtain the timeout time and retry count corresponding to the target device and generate control commands.

5. The medical device system with communication self-recovery capability according to claim 1, characterized in that, The collaborative control layer includes: The instruction splitting unit is used to split the control instruction into host computer instructions and slave computer instructions according to the target device field in the control instruction; The synchronization scheduling unit is used to trigger the execution of host computer instructions and slave computer instructions according to preset synchronization time constraints. When the deviation between the actual execution time of the host computer instruction and the actual execution time of the slave computer instruction does not exceed the preset synchronization error threshold, the collaborative execution is determined to be successful; when the deviation exceeds the preset synchronization error threshold, the collaborative execution is determined to be unsuccessful. The timeout monitoring unit is used to monitor the execution time of upper computer instructions and lower computer instructions. When the execution time of any instruction exceeds the timeout time in the control instruction, the instruction is determined to have timed out. The state recording unit is used to write the collaborative execution results into the collaborative state field of the unified context object for the communication execution layer to read.

6. The medical device system with communication self-recovery capability according to claim 1, characterized in that, The communication execution layer includes: The execution scheduling unit is used to issue corresponding instructions to the host computer and the slave computer respectively according to the synchronization scheduling results output by the collaborative control layer; The status tracking unit is used to record the execution status of the host computer instructions and the slave computer instructions in real time. The execution status includes not started, in execution, and completed. The result determination unit is used to comprehensively determine whether the current recovery is successful based on the execution status and the communication recovery identifier obtained from the communication link. The result determination unit also includes a timeout fault tolerance module, which is used to start a communication recovery detection timer. If the communication recovery identifier returned by the external communication status detection module is not obtained within the preset recovery confirmation timeout period, the current recovery is determined to have timed out and an execution result containing the recovery failure identifier is generated and written to a unified context object to trigger the next round of recovery or termination process.

7. The medical device system with communication self-recovery capability according to claim 1, characterized in that, The unified context object includes an exception status field, a strategy decision result field, a control instruction field, a collaboration status field, an execution result field, a loop count field, and a timestamp field. The loop count field is used to record the current recovery round, and the timestamp field is used to record the update time of the unified context object.

8. The medical device system with communication self-recovery capability according to claim 1 or 7, characterized in that, When data flows through a unified context object, each layer concurrently accesses the unified context object through a read-write lock control mechanism or an atomic state update mechanism. The unified context object is equipped with a write protection lock and a version identifier. When any layer needs to update a target field in the unified context object, it first acquires the write protection lock, increments the version identifier after writing the updated data, and releases the write protection lock. Other layers verify the version identifier when reading the target field to ensure data consistency and timing correctness during cross-thread flow.

9. The medical device system with communication self-recovery capability according to claim 8, characterized in that, The unified context object uses an event-driven mechanism or the observer pattern to realize data flow between layers. When any layer updates the corresponding field in the unified context object, a state update event is triggered and the subsequent layers that subscribe to the field are notified. The subsequent layers respond to the state update event by reading the updated field through a callback function and executing the corresponding processing logic to achieve asynchronous decoupled operation across layers.

10. A method for executing a medical device system with communication self-recovery capability as described in any one of claims 1 to 9, characterized in that, Includes the following steps: S1, the exception input layer obtains the exception status information of the communication link and writes it into the exception status field of the unified context object; S2, the strategy decision layer reads the abnormal status field, determines the strategy decision result based on the abnormal status information, and writes it into the strategy decision result field of the unified context object; S3, the control layer reads the policy decision result field, generates control instructions based on the policy decision result, and writes them into the control instruction field of the unified context object; S4, the collaborative control layer reads the control instruction field, splits the control instruction into upper computer instruction and lower computer instruction and performs synchronous scheduling, and writes the collaborative state into the collaborative state field of the unified context object; S5, the communication execution layer reads the coordination status field, sends the synchronized upper computer instructions and lower computer instructions to the upper computer and lower computer respectively for execution, returns the execution result and writes it to the execution result field of the unified context object; S6. Determine whether communication has been restored based on the execution result field. If it has been restored, the process ends. If it has not been restored and the current restoration round is less than the preset maximum round threshold, update the loop count field of the unified context object and return to step S2 to enter the next round of restoration.

Images