A rehabilitation device control and data backtracking method and system

Abstract

The application discloses a rehabilitation equipment control and data backtracking method and system, and relates to the technical field of health Internet of Things communication. The method comprises the following steps: a session object is created and a session identifier is allocated in response to a treatment session starting instruction; a session flow is driven according to a predefined state machine, and the state flow is triggered by a timing event, a sensor event and / or an external instruction; a running state snapshot object is generated according to a preset condition during the session; when a safety trigger condition is detected, the system is switched to a protection state and a safety protection action is executed locally by the equipment, and a safety report is generated; the session context is continuously written to a non-volatile storage; after the equipment is recovered, a continuation or termination is performed on a non-terminated session according to a continuation decision logic; a treatment session summary object is generated when the session ends; and corresponding snapshots, summaries and / or safety reports are returned in response to a query request. Through standardized session management, state machine control and local safety closed loop, the continuity, safety and traceability of the control are improved.

Description

Technical Field

[0001] This invention belongs to the field of health Internet of Things communication technology, and specifically relates to a method and system for controlling and tracking data of rehabilitation equipment. Background Technology

[0002] Fascia guns, eye massagers, leg air wave massagers, neck massagers, and other rehabilitation and physiotherapy equipment typically only support discrete commands such as start, stop, speed adjustment, and mode switching in existing protocols. During equipment operation, the reported information is mostly instantaneous fields such as current speed, battery level, and fault codes, lacking a unified business object built around a complete treatment course.

[0003] In traditional methods, there is often no standardized summary object to record key results such as start time, end time, actual runtime, reason for completion, average intensity, maximum pressure, or highest temperature after a treatment session. If the treatment session ends abnormally due to user interruption, overheat protection, low battery, or fault lockout, the system usually only obtains scattered error codes and cannot reconstruct the runtime context at the time of triggering.

[0004] Furthermore, in actual use, there are interruption scenarios such as power outages, Bluetooth disconnections, and abnormal terminal exits. Existing devices typically cannot persist the context of the treatment course, nor can they determine whether the course should continue or from where after recovery. After-sales service and the platform also lack a unified data foundation for analyzing safety trends and abnormal evolution across multiple treatment courses.

[0005] Therefore, a new technical solution is needed to enable rehabilitation equipment to manage a single treatment session as a standard session, and to uniformly organize operational control, safety protection, status retrospection, and historical analysis around that session. Summary of the Invention

[0006] To address the aforementioned issues, this application aims to provide a method for controlling and tracking data in rehabilitation equipment. This method defines each treatment session as a standard session unit, establishing a unified business workflow; it manages the normal flow and abnormal branches of the treatment session through a state machine, improving cross-model consistency; it generates runtime snapshot objects during the treatment session, storing the runtime context at any given time; it generates a treatment summary object at the end of the treatment session, storing the final statistical results and completion reasons; it generates safety report objects in abnormal safety scenarios, with the device locally executing a physical safety protection loop; it executes continuation decisions based on the persistent context after power failure or connection loss recovery; it supports terminals or platforms in querying and tracking the current operating status and historical treatment results; and it performs trend analysis and early warning based on safety reports accumulated from multiple treatment sessions.

[0007] To achieve the above objectives, the technical solution of the present invention is as follows.

[0008] Session modeling

[0009] This invention abstracts a complete treatment course of a rehabilitation device into a session. Each session contains at least the following semantic elements: session identifier, session start time, target treatment course duration, current program mode, current intensity / pressure / temperature, current area selection, current operating status, current safety status, and session end result. The session identifier is used to associate the running status snapshot object, treatment course summary object, and safety report object with the same treatment course.

[0010] State machine control

[0011] In a preferred embodiment, the device establishes a standard state machine around the treatment session. The states include at least: ready, preheating, running, paused, cooling down, completed, aborted, and fault-locked. The state machine transitions based on user actions, time progress, sensor detection results, and safety conditions. Typical state paths include:

[0012] 1. From ready state to preheating state to running state to completion state;

[0013] 2. From running state to paused state;

[0014] 3. From running state to terminated state;

[0015] 4. From preheating state to fault lockout state;

[0016] 5. From running state to fault-locked state;

[0017] 6. From running state to cooling state to completion state.

[0018] runtime snapshot generation mechanism

[0019] The device generates a runtime snapshot object during the treatment process to record the session context at a specific moment. The runtime snapshot object includes at least: snapshot identifier, report time, current session identifier, current operating stage, remaining duration, current mode number, current intensity level, current pressure value or pressure level, current temperature value or temperature control level, current area bitmap, current fault code, current safety lock code, and current battery level. The runtime snapshot can be generated at the following times: when responding to a running status query, when the state machine switches states, when the mode / intensity / pressure / temperature changes, when a pause / resumption / protection / fault event occurs, and during periodic reporting.

[0020] Treatment course summary solidification mechanism

[0021] When a treatment session is completed normally or ends abnormally, the device generates a treatment session summary object and binds it to the session identifier. The treatment session summary object includes at least: session identifier, start time, end time, actual runtime, program mode, average intensity, maximum pressure, highest temperature, actual area bitmap, completion reason, number of failures, user interruption flag, interruption flag, and continuation flag. The completion reason is used to distinguish different termination types, such as normal completion, user-initiated stoppage, safety protection termination, fault termination, and power failure termination.

[0022] Security report recording mechanism

[0023] When the device triggers safety protection or fault lock during the treatment process, the device generates a safety report object. The safety report object includes at least: safety report identifier, report time, current session identifier, operating stage at the time of triggering, safety status code, fault code, safety lock code, actual temperature, actual pressure, source subsystem, alarm level, protection action type, protection action execution result, and snapshots of physical quantities before and after protection.

[0024] Safety protection physical closed loop

[0025] In a preferred embodiment, when the device detects a safety trigger condition, it not only generates a safety report object but also autonomously executes a safety protection closed loop via its local state machine. The closed loop includes:

[0026] Detection: Real-time acquisition of physical quantities such as temperature, pressure, and current, and comparison with safety thresholds;

[0027] Decision: Switch to target protection state based on trigger condition type and severity level;

[0028] Execution: Issue protection action commands to the corresponding hardware subsystem;

[0029] Verification: Continuously monitor whether the relevant physical quantities fall back to a safe range within a preset time window;

[0030] Record: Write the results of the protection action and the verification results into the security report object.

[0031] The protection actions may include cutting off the heating circuit, opening the pressure relief valve, stopping the motor drive, disconnecting the main power output, or a combination thereof. This closed loop is completed locally on the device, without relying on a terminal or cloud intermediary.

[0032] Power failure or disconnection continuity mechanism

[0033] During the treatment, the device continuously writes key session context to non-volatile storage. This context includes at least: session identifier, current state, elapsed duration, current mode, current intensity / pressure / temperature, current region bitmap, and cumulative number of failures. When the device regains power or re-establishes a connection, the system performs the following follow-up processing: checks for any abnormally terminated session records; determines whether the interruption was due to power failure, disconnection, or safety protection; makes a follow-up decision based on the interruption reason and elapsed duration; if follow-up is allowed, the session context is restored and the treatment continues from the point of interruption; if follow-up is not allowed, the original session is terminated and the reason is recorded in the summary object.

[0034] Query backtracking mechanism

[0035] Terminals or platforms can use query commands to trace back the following objects: current session running status: corresponding to the running status snapshot object; most recent treatment result: corresponding to the treatment summary object; specified session history result: corresponding to the summary object of the specified session identifier; specified security event record: corresponding to the security report object.

[0036] Cross-session security trend warning

[0037] In a preferred embodiment, the device or platform aggregates safety report objects from multiple sessions by device identifier to form a time series of safety indicators, and performs trend analysis on the highest temperature, maximum pressure, threshold approach count, and protection action trigger frequency. When preset conditions are met, the system generates a tiered early warning notification to support predictive maintenance.

[0038] To clarify that this invention is not an abstract business concept, this invention provides a method for controlling and tracking data of rehabilitation equipment, the specific computer execution steps of which include the following unconventional operational details and rules:

[0039] 1. When the device starts the treatment, a standard session object is instantiated in memory, a globally unique session identifier is allocated, and the session context is initialized;

[0040] 2. The session flow is driven by a predefined state machine, where: the running state includes preheating state, running state, cooling state, and completion state; the abnormal state includes pause state, abort state, and fault lockout state; the flow triggering events include timer interrupts (such as countdown reaching zero triggering the transition from running state to completion state), sensor threshold exceeding interrupts (such as temperature change triggering the transition from running state to fault lockout state), and network control commands from external terminals (such as user-issued pause triggering the transition from running state to pause state).

[0041] 3. During the session flow (such as when a state switch occurs or during a timed sampling period at a preset time interval), generate and update a runtime snapshot object containing multiple key fields (including current stage, pressure, temperature, fault code, etc.).

[0042] 4. When a safety trigger condition is detected, the state machine immediately switches to the fault-locked protection state and the underlying controller autonomously executes the physical closed loop of safety protection (such as cutting off the heating relay), while generating a safety report object containing a snapshot of the trigger time and the results of the protection action;

[0043] 5. During the session, a double-buffering mechanism is used to continuously persist the above-mentioned key context to the device's non-volatile memory;

[0044] When the device experiences a power outage and restart or a communication reconnection, the following connection detection and decision logic tree is executed: Detection content: Read from non-volatile memory whether there are dirty data records whose session status is not marked as completed or terminated; Decision logic: If the interruption is caused by user-initiated pause and the interruption duration is less than a preset threshold, then perform hot recovery, load the context and continue the treatment; If the interruption is caused by power failure due to safety protection or timeout reaching a preset threshold, then perform termination and clear the original session and mark it as abnormal termination in the summary;

[0045] 7. When the session ends (whether normal or abnormal), aggregate all snapshot data to generate a treatment summary object containing statistical results (such as average intensity and reason for completion);

[0046] Responding to query requests from terminals or cloud platforms, it returns the corresponding runtime snapshot object, treatment summary object, or safety report object;

[0047] 9. Employ a time-based sliding window-based security degradation analysis algorithm to aggregate security reports from multiple sessions by device dimension and implement trend warnings: Algorithm rules: The system sets a sliding window (such as the most recent preset number of treatments). If the number of protective actions triggered within this window exceeds a preset threshold, or if the system detects that a certain physical parameter shows a monotonically increasing percentage that approaches the upper limit of the safety threshold multiple times, the algorithm outputs a judgment result; Execution action: The platform automatically generates a warning work order based on the judgment result and sends it to the after-sales system for intervention.

[0048] This invention also provides a rehabilitation equipment control and data backtracking system, which internally includes the following collaborative logic execution modules:

[0049] 1. Session Creation Module: Used to assign a session identifier and initialize the context when the device starts a treatment.

[0050] 2. State Machine Management Module: The core control engine, used to respond to timers, sensor interrupts, or network commands, and drive the legitimate transition of session states;

[0051] 3. Running snapshot generation module: used to collect real-time physical quantities and generate snapshot objects when state switching or timer period arrives;

[0052] 4. Safety report generation module and safety protection closed-loop execution module: used to cut off the physical circuit to execute protection actions when a safety trigger condition is detected, and to generate safety report objects before and after the trigger;

[0053] 5. Session Context Persistence Module: Used to write critical session information into the device's non-volatile memory in real time using a double-buffering mechanism;

[0054] 6. Session continuation module: Used to perform logic tree judgment when the device restarts or recovers from a disconnection, and decide whether to perform hot recovery or terminate the foolproof protection.

[0055] 7. Treatment Summary Solidification Module: This module is used to aggregate and statistically analyze all snapshot data of the entire treatment process at the end of the session, and generate the final treatment summary object.

[0056] 8. Query and backtracking module: Network interface module, used to parse the query protocol of the terminal or platform and return the specified session history object;

[0057] 9. Security Trend Early Warning Module: Deployed on a cloud platform, it is used to execute the sliding window degradation analysis algorithm and dispatch early warning work orders.

[0058] Compared with the prior art, the beneficial effects of this application are as follows:

[0059] 1. Abstract a treatment course into a standard session unit, establish a unified business thread, and enable the system to determine which states and data belong to the same treatment course;

[0060] 2. By unifying the normal process and abnormal branches through state machines, cross-model consistency is improved, and the App, platform, test and equipment have a consistent understanding of the running state;

[0061] 3. By using runtime snapshot objects, the runtime context of any point in the treatment process can be preserved, facilitating archiving, querying, and comparison;

[0062] 4. By summarizing treatment course data, the final statistical results and reasons for completion of a treatment course can be collected, thereby improving the ability to query historical treatment courses, analyze compliance, and track after-sales service;

[0063] 5. By recording the context of safety events through safety reporting objects, the ability to trace faults is improved, while providing a complete closed-loop control from detection to protection action execution and verification;

[0064] 6. Reduce security response delay and improve reliability by implementing a security protection closed loop locally on the device;

[0065] 7. By establishing a mechanism for resuming treatment after power failure or disconnection, repeated treatments can be avoided, thus improving user experience and compliance;

[0066] 8. Provide a unified data foundation for App, platform, testing, and after-sales through a query and backtracking mechanism;

[0067] 9. Support predictive maintenance and early intervention for anomalies through cross-session security trend alerts. Attached Figure Description

[0068] Figure 1 This is a schematic diagram of a state machine, illustrating the transition relationships between the various states;

[0069] Figure 2 A timing diagram was generated for the runtime snapshot, illustrating the triggering timing and process of snapshot generation;

[0070] Figure 3 A flowchart for solidifying treatment summaries is provided, illustrating the summary generation process after the session ends;

[0071] Figure 4 The security protection closed-loop flowchart illustrates the complete closed-loop process from detection to verification.

[0072] Figure 5 The flowchart for power failure reconnection illustrates the reconnection detection and decision-making process after an interruption.

[0073] Figure 6 The overall architecture diagram of the session illustrates the hierarchical relationships and collaborative working methods of the various logical modules in the system. Detailed Implementation

[0074] 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 and not intended to limit the invention.

[0075] Example 1:

[0076] In this embodiment, a rehabilitation therapy device with heating and pressure regulation functions is used as an example to illustrate the complete process of the present invention from the start to the end of the treatment.

[0077] When a user triggers a treatment start command via the terminal app or device panel, the device's session creation module responds to the command by instantiating a session object in memory, assigning a globally unique session identifier (such as "SESS-20260805-001") to the session object, and initializing the session context, including recording the session start time, setting the target treatment duration (such as 30 minutes), loading the default program mode (such as "soothing mode"), and the default intensity level (such as level 3).

[0078] Subsequently, the state machine management module drives the session flow according to the predefined state machine. For example... Figure 1As shown, the session first enters the ready state, and then enters the preheating state after completing the device self-test. In the preheating state, the device starts the heating unit, gradually raising the temperature to the target operating temperature. When preheating is complete and the sensor detects that the temperature has reached the preset threshold, the state machine automatically transitions to the running state. In the running state, the device continuously outputs therapeutic effects according to the set mode, intensity, and temperature, while the state machine continuously monitors the countdown progress.

[0079] During session transition, the runtime snapshot generation module generates and updates runtime snapshot objects according to preset trigger conditions. For example... Figure 2 As shown, when the state machine switches from the preheating state to the running state, the snapshot generation module collects snapshot data at the current moment. In the running state, the snapshot generation module automatically generates a snapshot every preset time period (e.g., 5 seconds). When the user adjusts the intensity level through the terminal app, the snapshot generation module immediately responds to the parameter change event and generates a new snapshot. Each snapshot object records key fields such as snapshot identifier, report time, current session identifier, current running stage, remaining duration, current mode number, current intensity level, current temperature value, current area bitmap, current fault code, current safety lock code, and current battery level. All snapshot objects are bound to the session identifier, forming complete running trajectory data.

[0080] The context persistence module operates continuously throughout the entire session. Whenever a substantial change occurs in the session context (such as state switching, parameter adjustment, snapshot generation, etc.), the persistence module employs a double-buffering mechanism to write critical session context data to non-volatile storage media (such as EEPROM or Flash memory), ensuring that critical session state information is not lost in the event of a power outage. The double-buffering mechanism guarantees the atomicity of write operations and data integrity by alternately using two storage areas.

[0081] When the treatment countdown reaches zero, a timer interrupt triggers the state machine to transition from the running state to the cooling state. In the cooling state, the device gradually reduces its output power, allowing the temperature to steadily drop to a safe range. Once cooling is complete, the state machine transitions to the completion state, and the session ends normally. Figure 3 As shown, at this point, the treatment summary generation module is triggered, reading all runtime snapshot data associated with the session from non-volatile storage, performing aggregation and statistics, and generating a treatment summary object containing fields such as session identifier, start time, end time, actual runtime (e.g., 28 minutes and 35 seconds, excluding pause time), program mode, average intensity (e.g., level 3.2), maximum pressure, highest temperature, actual area bitmap, completion reason (marked as "normal completion"), number of failures, user interruption flag, interruption flag, and continuation flag. This summary object is stored locally on the device and can be reported to the cloud platform for subsequent querying and analysis.

[0082] Example 2:

[0083] This embodiment details the processing mechanism when the device detects a safety trigger condition during operation, which is one of the important features that distinguishes this invention from the prior art.

[0084] Assuming the device continuously outputs therapeutic effects during operation, the temperature sensor monitors the temperature of the heating unit in real time. The detection unit in the safety protection execution module collects temperature data at a high frequency (e.g., once every 100 milliseconds) and compares it with a preset safety threshold (e.g., the maximum allowable temperature of 45°C).

[0085] When the temperature sensor detects that the current temperature has reached or exceeded the safety threshold, the detection unit immediately triggers a safety interrupt. In response to this sensor out-of-bounds interrupt event, the state machine management module forcibly switches the state machine from the running state to the fault-locked state. Simultaneously, the decision unit in the safety protection execution module determines the target protection state and protection action type based on the trigger condition type (overheat protection) and severity level (temperature exceeding limit).

[0086] Subsequently, the execution unit directly issues protection action commands to the corresponding hardware subsystem. In this embodiment, the execution unit commands the relay in the heating circuit to disconnect, and simultaneously commands the motor drive unit to reduce its output power or stop operating. The issuance and execution of the aforementioned protection action commands are both completed locally on the device, without going through a terminal app or cloud platform. The response latency can be controlled at the millisecond level, far superior to remote protection schemes that rely on network communication.

[0087] After the protection action is executed, the verification unit continuously monitors whether the relevant physical quantities have fallen back to a safe range within a preset time window (e.g., 5 seconds). In this embodiment, the verification unit continuously monitors whether the temperature value drops below a safe threshold. If the temperature falls back to a safe range within the preset time window, the verification result is "pass"; if it fails to fall back within the specified time, the verification result is "fail", and the system can trigger higher-level protection measures (e.g., complete power outage).

[0088] The recording unit writes complete information about the entire protection process into the safety report object, including: safety report identifier, report time, current session identifier, operational stage at trigger (e.g., "operating state"), safety status code, fault code, safety lockout code, actual trigger temperature, actual pressure, source subsystem (e.g., "heating subsystem"), alarm level (e.g., "critical"), protection action type (e.g., "cut off heating circuit"), protection action execution result (e.g., "success"), and snapshots of physical quantities before and after protection (temperature before protection: 45.2℃, temperature after protection: 42.1℃, etc.). This safety report object is bound to the current session identifier, becoming a traceable record of the safety event for that session. The complete closed-loop process from detection to decision-making, execution, verification, and finally recording is as follows: Figure 4As shown, the entire process is completed autonomously by the device's local state machine, without relying on the terminal or cloud relay.

[0089] In fault-locked mode, the device stops all therapeutic outputs, maintaining only basic communication and status indication functions. Users can view safety report information through the terminal app or device panel to understand the reason for the protection trigger. The device does not automatically resume operation in fault-locked mode; users need to manually reset it after confirming the safety status, or after-sales personnel need to intervene.

[0090] Example 3:

[0091] This embodiment details the device's recovery mechanism after a power outage during treatment, a key technology for improving user experience and treatment adherence.

[0092] Suppose the device is performing a treatment session while running, having already run for 15 minutes with 15 minutes remaining. Suddenly, due to an external power failure or battery depletion, the device loses power. Before the power outage, the context persistence module had already continuously written the session context data to non-volatile storage. Therefore, when the device loses power, the latest session state is stored in the non-volatile storage, including key information such as session identifier, current state (running mode), running time (15 minutes), current mode, current intensity, current temperature, current region bitmap, and cumulative number of failures.

[0093] When the user re-powers the device or replaces the battery, the device performs a power-on initialization process. For example... Figure 5 As shown, the session continuation module first performs a continuation detection, scanning the non-volatile storage medium to check for any session records that have not been terminated properly, i.e., dirty data records whose session status field is not marked as "complete" or "aborted".

[0094] If an unterminated session record is detected, the session continuation module further determines the cause of the interruption. In this embodiment, since the device was in operation before the power outage and there was no safety protection trigger record, the continuation module determines the cause of the interruption as "unexpected power outage". Next, the continuation module executes a decision according to a preset continuation decision logic tree: it checks the time difference between the current time and the session start time. In this embodiment, 10 minutes have passed from the start of the session to the restoration of power, which is less than a preset threshold (such as 30 minutes). Therefore, the decision result is "allow continuation".

[0095] The follow-up module then performs a hot recovery operation: it loads the complete session context data from non-volatile storage, reconstructs the session object in memory, restores the session state to its pre-interruption state (including restoring 15 minutes of running time, 15 minutes of remaining time, current mode, current intensity, and all other parameters), and then resumes the treatment from the point of interruption. Users do not need to restart the treatment; the device automatically resumes operation from the breakpoint, greatly improving the user experience.

[0096] In another scenario, if the interruption is caused by a power outage triggered by safety protection (such as the device automatically shutting down after overheat protection), the decision logic of the continuation module will determine that "continuation is not allowed" and perform a termination error prevention operation: clear the original session record, mark the completion reason as "safety protection abort" in the treatment summary object, and keep the device in a fault-locked state or standby state. The new treatment can only be restarted after the user confirms the safety status.

[0097] In another scenario, if the interruption duration exceeds a preset threshold (e.g., if the user does not resume treatment after pausing for more than 30 minutes), the continuation module will also perform a termination error prevention operation, marking the completion reason as "timeout termination" in the treatment summary object to prevent safety risks or experience problems caused by the user forgetting the treatment status after a long pause.

[0098] Example 4:

[0099] This embodiment details the mechanism by which the system performs trend analysis and early warning based on security reports from multiple historical sessions. This is an important application of the present invention in after-sales maintenance and predictive maintenance.

[0100] The cloud platform's security trend early warning module aggregates security report data from all historical sessions of a device, categorized by device identifier. For each device, the module maintains a time-ordered sequence of security events, with each record containing key indicators from the security report: report time, operational stage at trigger time, security status code, actual temperature, actual pressure, source subsystem, alarm level, and protection action type.

[0101] The safety trend early warning module employs a degradation analysis algorithm based on a time-sliding window. The system sets a sliding window (e.g., the last 20 treatment sessions) and within this window, it statistically analyzes the trigger frequency of various safety events and the changing trends of key physical parameters.

[0102] For example, if the algorithm detects that the fault-locked protection action has been triggered more than a preset threshold (e.g., 3 times) in the last 20 treatment sessions, it determines that the device has a systemic safety risk. Similarly, if the algorithm detects that the "maximum pressure value" shows a monotonically increasing trend in multiple consecutive treatment sessions, and the current value is approaching a preset percentage (e.g., 95%) of the upper limit of the safety threshold, it determines that the device's pneumatic system may have progressive aging or wear.

[0103] Once the algorithm outputs its judgment result, the platform automatically executes the corresponding action: In this embodiment, the platform generates a "Progressive Aging Early Warning for Gas Circuit Valves" work order, which includes equipment identification, warning type, warning level, and relevant data evidence (such as pressure value change curves, trigger count statistics, etc.), and sends the work order to the after-sales system. After-sales personnel proactively contact the user based on the work order information to perform equipment repair or component replacement, intervening before the actual failure occurs and achieving predictive maintenance.

[0104] This trend warning mechanism is not only applicable to single devices, but can also perform aggregated analysis by device model, batch, usage duration, and other dimensions to help manufacturers discover systemic defects in product design or manufacturing, and guide product improvement and quality control.

[0105] Example 5:

[0106] This embodiment details the mechanism by which a terminal or platform traces back various session objects through query commands.

[0107] Users can initiate various types of query requests through the terminal app. When a user wants to know the real-time status of the ongoing treatment, the app sends a "Query Current Running Status" command to the device. After parsing the command, the query backtracking module on the device reads the latest running status snapshot of the current session object from memory, encapsulates it into a response data packet, and returns it to the app. Based on this, the app displays real-time running parameters on the interface, such as the current stage, remaining duration, current temperature, and current intensity.

[0108] When a user wants to view the results of their most recent treatment session, the app sends a "Query Summary of Most Recent Treatment Session" command. The query backtracking module reads the most recently generated treatment session summary object from non-volatile storage and returns it. The app displays summary information, including the start and end times of the treatment session, actual runtime, average intensity, and reason for completion, allowing the user to clearly understand the completion status of each treatment session.

[0109] When users or after-sales personnel wish to trace a specific historical treatment session, they can initiate the "Query Specified Session History Results" command by specifying a session identifier. The query and traceback module retrieves the corresponding treatment summary object and all associated runtime snapshots and security reports from storage based on the session identifier, returning complete historical treatment data.

[0110] When after-sales personnel wish to analyze the details of a security incident, they can initiate a "Query Security Event Record" command by specifying a security report identifier or session identifier. The query and backtracking module returns the corresponding security report object, which includes complete contextual information such as the operational stage at the time of triggering, the triggered physical quantity, the type of protection action, the execution result of the protection action, and snapshots of the physical quantities before and after protection, providing sufficient data support for root cause analysis of the fault.

[0111] The aforementioned query and traceability mechanism provides a unified data access interface for the App user interface, cloud management platform, testing system, and after-sales system. All parties can obtain standardized and structured session history data without needing to concern themselves with the underlying data storage details.

[0112] Example 6:

[0113] This embodiment illustrates the deployment method and collaborative working mechanism of each logic module of the present invention on physical devices. For example... Figure 6 The overall session architecture diagram shown below illustrates the hierarchical relationships and collaborative working methods among the modules:

[0114] In a preferred embodiment, the session creation module, state machine management module, runtime snapshot generation module, security protection execution module, context persistence module, session continuation module, treatment summary generation module, and query backtracking module are deployed in the embedded system local to the rehabilitation device and implemented by a microcontroller unit (MCU) running firmware. These modules directly manipulate hardware resources (temperature sensors, pressure sensors, heating units, motor drive units, non-volatile memory, etc.) to ensure minimal response latency to security events.

[0115] The security trend early warning module is deployed on a cloud platform and interacts with the query and backtracking module on the device side via IoT communication protocols. The device side periodically or at the end of the session reports treatment summary objects and security report objects to the cloud platform. The security trend early warning module performs cross-session trend analysis and dispatches early warning work orders based on the aggregated multi-device data.

[0116] The collaborative workflow between the modules is as follows: The user issues a treatment start command through the terminal App. This command reaches the query and backtracking module on the device side via the communication link. The query and backtracking module parses the command and passes it to the session creation module. After creating the session object, the session creation module hands over control to the state machine management module. The state machine management module drives the session flow and triggers the runtime snapshot generation module to generate snapshots at each state transition point and timed period. The context persistence module continuously monitors changes in the session context and writes key data to non-volatile storage. When a security event occurs, the security protection execution module preemptively intervenes and enforces the protection loop. When the session ends, the treatment summary generation module is triggered to generate a summary. The query and backtracking module responds to external query requests at any time and returns the corresponding data object. The session continuation module automatically performs continuation detection and decision-making when the device restarts.

[0117] The modules are clearly divided and their responsibilities are well-defined. The modules communicate with each other through standardized interfaces, which facilitates both implementation and subsequent functional expansion and maintenance.

[0118] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for controlling and tracking data of rehabilitation equipment, characterized in that, include: Session creation steps: In response to the treatment start command of the rehabilitation device, a session object is created in memory, a session identifier is assigned to the session object, and the session context is initialized; State machine control steps: Drive the session object according to a predefined state machine, wherein the state machine includes at least a running state and an abnormal state, and the state transition of the state machine is triggered by timing events, sensor detection events and / or external control commands; Runtime snapshot generation step: During the flow of the session object, a runtime snapshot object is generated and updated according to preset trigger conditions. The runtime snapshot object includes at least the current running stage, the current physical running parameters, and the current fault information. Safety protection execution steps: When a safety trigger condition is detected, the state machine switches to the protection state, and the device locally executes the safety protection action, while generating a safety report object; Context persistence step: During the flow of the session object, the session context data is continuously written to a non-volatile storage medium; Session continuation steps: After the device restores power or re-establishes the communication connection, it checks whether there are any session records that have not been terminated properly in the non-volatile storage medium. If so, it performs continuation processing or termination processing on the session records according to the preset continuation decision logic. Treatment summary generation steps: When the session object ends, the runtime snapshot data associated with the session object is aggregated to generate a treatment summary object; Query backtracking steps: In response to an external query request, return the runtime snapshot object, treatment summary object, and / or safety report object corresponding to the query request.

2. The method for controlling and tracking data of rehabilitation equipment according to claim 1, characterized in that, In the state machine control steps, the state machine includes at least the following states: ready state, preheating state, running state, paused state, cooling state, completed state, aborted state, and fault lockout state; the triggering events for the state transition include timer interrupt events, sensor out-of-bounds interrupt events, and external terminal control command events.

3. The method for controlling and tracking data of rehabilitation equipment according to claim 1, characterized in that, In the security protection execution steps, the security protection actions executed locally by the device include: a detection step, which collects physical quantities in real time and compares them with a safety threshold; a decision step, which switches to the target protection state according to the trigger condition type; an execution step, which issues a protection action instruction to the corresponding hardware subsystem; a verification step, which verifies whether the physical quantities have fallen back to the safe range within a preset time window; and a recording step, which writes the protection action result and the verification result into the security report object.

4. The method for controlling and tracking data of rehabilitation equipment according to claim 1, characterized in that, In the session continuation step, the preset continuation decision logic includes: if the interruption reason is user-initiated pause and the interruption duration is less than a preset threshold, then perform continuation processing, restore the session context and continue the session object from the interruption point; if the interruption reason is security protection trigger or the interruption duration is greater than or equal to the preset threshold, then perform termination processing, end the session object and record the termination reason in the treatment summary object.

5. The method for controlling and tracking data of rehabilitation equipment according to claim 1, characterized in that, In the step of generating the runtime snapshot, the preset triggering condition includes at least one of the following: responding to a runtime status query, the state machine undergoing a state switch, the runtime parameters changing, a pause, recovery, protection, or fault event occurring, or a periodic timed trigger.

6. The method for controlling and tracking data of rehabilitation equipment according to claim 1, characterized in that, It also includes a security trend warning step: aggregating security report data from multiple historical sessions by device dimension to form a security indicator time series, performing trend analysis on the security indicator time series, and generating a warning notification when preset warning conditions are met.

7. A rehabilitation equipment control and data backtracking system, characterized in that, include: The session creation module is used to create a session object in memory in response to the treatment start command of the rehabilitation device, assign a session identifier to the session object and initialize the session context; The state machine management module is used to drive the transition of the session object according to a predefined state machine. The state machine includes at least a running state and an abnormal state. The state transition of the state machine is triggered by timing events, sensor detection events and / or external control commands. The runtime snapshot generation module is used to generate and update a runtime snapshot object according to preset triggering conditions during the flow of the session object. The runtime snapshot object includes at least the current running stage, the current physical running parameters, and the current fault information. The safety protection execution module is used to control the state machine to switch to the protection state and execute the safety protection action locally by the device when a safety trigger condition is detected, and at the same time generate a safety report object; The context persistence module is used to continuously write session context data to a non-volatile storage medium during the transition of the session object. The session continuation module is used to detect whether there are any session records that have not been terminated properly in the non-volatile storage medium after the device restores power or re-establishes a communication connection. If so, it performs continuation processing or termination processing on the session record according to the preset continuation decision logic. The treatment summary generation module is used to aggregate the runtime snapshot data associated with the session object and generate a treatment summary object when the session object ends. The query backtracking module is used to respond to external query requests and return the runtime snapshot object, treatment summary object, and / or safety report object corresponding to the query request.

8. The rehabilitation equipment control and data backtracking system according to claim 7, characterized in that, In the state machine management module, the state machine includes at least the following states: ready state, preheating state, running state, paused state, cooling state, completed state, aborted state, and fault locked state; the triggering events for the state transition include timer interrupt events, sensor out-of-bounds interrupt events, and external terminal control command events.

9. The rehabilitation equipment control and data backtracking system according to claim 7, characterized in that, The security protection execution module includes: a detection unit for real-time acquisition of physical quantities and comparison with security thresholds; a decision unit for switching to the target protection state based on the trigger condition type; an execution unit for issuing protection action instructions to the corresponding hardware subsystem; a verification unit for verifying whether the physical quantities have fallen back to the safe range within a preset time window; and a recording unit for writing the protection action results and verification results into the security report object.

10. The rehabilitation equipment control and data backtracking system according to claim 7, characterized in that, It also includes a security trend warning module, which aggregates security report data from multiple historical sessions by device dimension to form a security indicator time series, performs trend analysis on the security indicator time series, and generates a warning notification when preset warning conditions are met.

Images