Error processing method and device and storage medium

Abstract

The invention discloses an error processing method and device and a storage medium, and relates to the technical field of intelligent Internet of Things. The error processing method is applied to target data acquisition equipment, the target data acquisition equipment is any one of the data acquisition equipment, and the data acquisition equipment is used for acquiring personal health data and sending the personal health data to the data acquisition equipment. An error event object is generated according to a preset format, and the error event object at least comprises an error type; and sending the error event object to the data collection equipment, so that the data collection equipment analyzes the error event object according to a preset analysis mode corresponding to the preset format to obtain an error type, and executes a preset response strategy corresponding to the error type. According to the invention, real-time finding and reporting of errors are realized, the timeliness of error feedback is improved, manual intervention requirements are reduced, and the automation degree and the operation and maintenance efficiency of a multi-device collaborative acquisition system are improved.

Description

Technical Field

[0001] This application relates to the field of smart Internet of Things (IoT) technology, and in particular to an error handling method, device, and storage medium. Background Technology

[0002] With the rapid development of the Internet of Things, smart wearables, and mobile healthcare technologies, the collection of personal health data has expanded from single devices and single clinical environments to multi-device, multi-scenario collaborative collection in daily life. Utilizing heterogeneous devices such as smartwatches, wristbands, smart rings, chest straps, and medical-grade devices for collaborative data collection enables data complementarity and cost optimization, providing a crucial data foundation for chronic disease management, health trend analysis, and medical research.

[0003] However, in heterogeneous environments with multiple devices, error detection and correction during data acquisition face significant challenges. Currently, error detection in data acquisition devices largely relies on local device logs or periodic status polling, requiring manual intervention for analysis. This results in poor real-time performance and high feedback latency. Especially in continuous monitoring scenarios requiring high consistency, the existing architecture cannot meet the need for stable operation with minimal human intervention.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide an error handling method, device, and storage medium, aiming to propose an error handling scheme to achieve real-time error detection and reporting, improve the timeliness of error feedback, reduce the need for manual intervention, and improve the automation level and operation and maintenance efficiency of multi-device collaborative data acquisition systems.

[0006] To achieve the above objectives, this application proposes an error handling method, which is applied to a target data acquisition device, wherein the target data acquisition device is any one of various data acquisition devices, each of which is used to collect personal health data and send it to a data collection device. The error handling includes: When an error event is detected, an error event object is generated according to a preset format, wherein the error event object includes at least an error type; The error event object is sent to the data collection device so that the data collection device can parse the error event object according to a preset parsing method corresponding to the preset format to obtain the error type, and execute a preset response strategy corresponding to the error type.

[0007] Optionally, the error event object further includes an error level, which characterizes the severity of the error. After the step of generating the error event object according to a preset format upon detecting an error, the method further includes: Detect whether the error level and / or the error type are within the subscription range indicated by pre-stored subscription information, wherein the subscription information is received and stored from the data collection device; If so, then the step of sending the error event object to the data collection device is performed; If not, then store the error event object.

[0008] Optionally, after the step of sending the error event object to the data collection device, the method further includes: The system receives a sensor restart command or a device restart command sent by the data collection device, wherein the data collection device sends a sensor restart command or a device restart command to the target data acquisition device when it determines that the error type is a critical sensor error. In response to the sensor restart command or the device restart command, the sensor or device is restarted, and an indication message indicating that the restart is complete is sent to the data collection device, so that after receiving the indication message, the data collection device can send a synchronization time synchronization command to each of the data collection devices, including the target data collection device. Receive the synchronization time command and execute the synchronization time command in response to the synchronization time command.

[0009] Optionally, the error handling method is applied to a data collection device, which collects personal health data collected and transmitted by various data acquisition devices, and the error handling includes: The system receives an error event object sent by a target data acquisition device, wherein the error event object includes at least an error type, the target data acquisition device is any one of the data acquisition devices, and the target data acquisition device generates the error event object according to a preset format when it detects an error event. The error type is obtained by parsing the error event object according to the preset parsing method corresponding to the preset format; Execute the preset response strategy corresponding to the error type.

[0010] Optionally, before the step of receiving the error event object sent by the target data acquisition device, the method further includes: After establishing a communication connection with the target data acquisition device, the latest subscription information is obtained from a local or remote database; The subscription information is sent to the target data acquisition device so that, after generating the error event object, the target data acquisition device, if it determines the error level and / or the error type in the error event object within the subscription range indicated by the subscription information, will send the error event object to the data collection device, wherein the error level is used to characterize the severity of the error.

[0011] Optionally, the error handling method further includes: The subscription information is generated in response to user input received in the first preset user interface; The subscription information is stored locally or uploaded to the remote database.

[0012] Optionally, the step of executing a preset response strategy corresponding to the error type includes: If the error type is a critical sensor error, an alarm message is generated and displayed in a second preset user interface; Send a sensor restart command or a device restart command to the target data acquisition device so that the target data acquisition device can restart the sensor or restart the device based on the command; After detecting that the target data acquisition device has completed sensor restart or device restart, a synchronization time synchronization command is sent to each of the data acquisition devices, including the target data acquisition device, so that each of the data acquisition devices can complete the synchronization time synchronization.

[0013] Optionally, the step of sending a sensor restart command or a device restart command to the target data acquisition device includes: If the system detects that it is currently in a preset non-interference mode, it sends a sensor restart command or a device restart command to the target data acquisition device. If it is detected that the current state is not in the preset non-interference mode, a prompt message is output in the second preset user interface to prompt the user to trigger a sensor restart command or a device restart command. In response to the user input received in the second preset user interface, a sensor restart command or a device restart command is generated and sent to the target data acquisition device.

[0014] In addition, to achieve the above objectives, this application also proposes an error handling device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the error handling method described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the error handling method described above.

[0016] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the error handling method described above.

[0017] One or more technical solutions proposed in this application have at least the following technical effects: This application standardizes the error report format of heterogeneous devices by using a standardized preset format for error event objects, enabling data collection devices to automatically parse and process error information; it establishes a mechanism for devices to proactively report errors, realizing real-time error detection and reporting, and significantly improving the timeliness of error feedback; by associating error types with preset response strategies, it achieves automated error correction, greatly reducing the need for manual intervention and improving the automation level and operation and maintenance efficiency of multi-device collaborative data acquisition systems. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating the first embodiment of the error handling method of this application; Figure 2 This is a flowchart illustrating the second embodiment of the error handling method of this application. Figure 3 This is a schematic diagram of the error handling process executed on the device side according to one embodiment of this application; Figure 4 This is a schematic diagram of the error handling process executed by the APP terminal according to one embodiment of this application; Figure 5 This is a schematic diagram of the device structure of the hardware operating environment involved in the error handling method in the embodiments of this application.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0024] In heterogeneous environments with multiple devices, error detection and correction during data acquisition face significant challenges. Currently, error detection in data acquisition devices largely relies on local device logs or periodic status polling, requiring manual intervention for analysis. This results in poor real-time performance and high feedback latency. Especially in continuous monitoring scenarios requiring high consistency, the existing architecture cannot meet the need for stable operation with minimal human intervention.

[0025] This application proposes a solution that unifies the error report format of heterogeneous devices by standardizing error event objects with preset formats, enabling data collection devices to automatically parse and process error information; it establishes a mechanism for devices to proactively report errors, realizing real-time error detection and reporting, and significantly improving the timeliness of error feedback; by associating error types with preset response strategies, it achieves automated error correction, greatly reducing the need for manual intervention and improving the automation level and operation and maintenance efficiency of multi-device collaborative data acquisition systems.

[0026] Reference Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the error handling method of this application.

[0027] In this embodiment, the error handling method is applied to the target data acquisition device. The target data acquisition device is any one of the various data acquisition devices, each used to collect personal health data and send it to the data collection device. Each data acquisition device can be an electronic device used to collect personal health data, typically integrating sensors and communication modules, such as medical-grade devices (e.g., electrocardiographs), smartwatches, smart rings, bracelets, and chest straps. The data collection device is an electronic device used to receive, store, and process data sent from the data acquisition device, such as smartphones, tablets, and personal computers. In this embodiment, the error handling method includes steps S10-S20: Step S10: If an error event is detected, an error event object is generated according to a preset format, wherein the error event object includes at least an error type.

[0028] Error events refer to abnormal or malfunction situations that occur during the operation of the target data acquisition device. These events may affect the accuracy of data acquisition or the normal operation of the device, such as memory access errors (when the device attempts to access an invalid memory address), sensor errors (such as the heart rate sensor being unable to read data), time synchronization failure (the device's internal clock fails to synchronize), and sensor data drift (the sensor output data gradually deviates from the true value).

[0029] Preset format refers to the pre-agreed data format between various data acquisition devices and data collection devices, such as using JSON or binary structure, to ensure that error event objects can be correctly encoded, transmitted and parsed, facilitating the transmission and parsing of error event objects between data collection devices and data acquisition devices.

[0030] An error event object is a structured data entity that encapsulates detailed information about an error event. The error type is a predefined error category used to identify the nature of the error. Error types can be defined using a hierarchical classification approach, including, for example, the following main categories: System crash type, referring to serious errors that prevent the device from functioning properly, which can be further divided into subtypes such as memory access errors and system deadlock; Core function loss type, referring to errors that affect the core capabilities of data acquisition, which can be further divided into subtypes such as critical sensor errors, time synchronization failures, and important file access errors; Functional degradation but usable type, referring to errors that allow the device to still operate but with degraded performance, which can be further divided into subtypes such as sensor data drift and clock skew; Non-core function anomaly type, referring to errors that do not affect the main acquisition functions, which can be further divided into subtypes such as minor sensor errors and non-critical file access errors. In some implementations, to standardize data transmission formats, device status change information (such as device startup complete, time synchronization complete, etc.) and detailed debugging information can also be transmitted using the same data format as error event objects. In this case, the error type can be further expanded to include status change type and debugging type. The status change type can be further divided into subtypes such as device startup complete, sensor initialization complete, and time synchronization complete, while the debugging type can be further divided into subtypes such as function call tracing and variable status recording. It should be noted that debugging type information is mainly visible during the development phase and is usually set to an invisible state in the release version.

[0031] Error event objects may also include other information, such as a timestamp (recording when the error occurred for error tracking and time-series analysis), an error code (a unique numeric or string identifier for quick error identification), the cause of the error (e.g., startup failure, damage, etc., aiding in diagnosis), and the sensor ID and type that caused the error (specifying which sensor malfunctioned, facilitating problem localization). This information collectively provides the complete context of the error, enabling the data collection device to fully understand the error and take appropriate action.

[0032] Detecting whether an error event has occurred is achieved through a monitoring mechanism built into the target data acquisition device. For example, the sensor driver checks whether the data is within the expected range, or the system service monitors resource usage. In one feasible implementation, the target data acquisition device may include an error detection module, which is anomaly detection code in the target data acquisition device firmware. Once an anomaly is detected (such as abnormal sensor readings or memory leaks), an error event object in a preset format is immediately created.

[0033] Step S20: Send the error event object to the data collection device so that the data collection device can parse the error event object according to a preset parsing method corresponding to the preset format to obtain the error type, and execute a preset response strategy corresponding to the error type.

[0034] The target data acquisition device and the data collection device can connect wirelessly, such as using Bluetooth Low Energy (BLE) binary transmission, to efficiently utilize bandwidth and power consumption. The communication connection is established after the devices are paired and can be kept active as needed through a keep-alive mechanism.

[0035] The preset parsing method, corresponding to the preset format, refers to the data collection device parsing the error event object according to the preset format (such as JSON field mapping), extracting the error type, and possibly extracting other fields. The response strategy is a pre-set response measure for different error types, such as sending error correction commands to the target data acquisition device, like synchronization commands (for time synchronization issues) or restart commands (for sensor or device recovery). Different response strategies are set because different error types require targeted handling to optimize resource utilization and recovery efficiency.

[0036] In one feasible implementation, differentiated response strategies are set for different error types: For system crash errors, the data collection device's corresponding preset response strategy may be to display alarm information in a preset user interface, prompting the user that the device has a serious malfunction; for core function loss errors, in addition to displaying alarm information, corresponding error correction measures will be executed according to the specific subtype, such as sending a sensor restart command or device restart command when the error type is a critical sensor error, sending a synchronization time correction command when time synchronization fails, and attempting file repair or reinitialization when there is an important file access error; for function degradation but usability errors, the response strategy may include displaying alarm information and taking corresponding measures in combination with the specific subtype, such as performing data calibration when sensor data drifts, and sending a time correction command when there is a clock deviation; for non-core function abnormality errors, the response strategy may only display prompt information without immediately taking error correction action; for status change errors, the data collection device may take corresponding actions according to the specific status, such as sending a synchronization time correction command after receiving device startup completion information; for debugging errors, the data collection device usually does not process or only logs.

[0037] In one feasible implementation, the target data acquisition device may further include a notification distribution module. This module communicates directly with the App in the data acquisition device, receives error event objects transmitted by the error detection module or the event management module, encodes the objects into a format suitable for transmission on the BLE channel (e.g., converts them into a compact binary byte stream), and actively sends the information to the App in real time using the notify feature through the established Bluetooth connection. The App may include a connection management module and a notification processing module. The connection management module is the Bluetooth module in the App responsible for establishing, maintaining, and reconnecting with the target data acquisition device. It is responsible for device discovery, pairing, connection, keep-alive, reconnection, and unpairing. The notification processing module is responsible for listening to, parsing, and responding to error event objects sent by the device, and sending error correction instructions to the device when necessary.

[0038] In this embodiment, by standardizing the error event object with a preset format, the error report format of heterogeneous devices is unified, enabling data collection devices to automatically parse and process error information; a mechanism for devices to actively report errors is established, realizing real-time error detection and reporting, and significantly improving the timeliness of error feedback; by associating error types with preset response strategies, automated error correction is achieved, greatly reducing the need for manual intervention and improving the automation level and operation and maintenance efficiency of the multi-device collaborative data collection system.

[0039] In one feasible implementation, after step S10, steps S30 to S40 are further included: Step S30: Detect whether the error level and / or the error type are within the subscription range indicated by pre-stored subscription information, wherein the subscription information is received and stored from the data collection device.

[0040] Error event objects also include error levels, which characterize the severity of the error. Different types of errors can have predefined error levels, such as numerical levels (e.g., 1-5, 1 being the lowest and 5 the highest) or categorical levels (e.g., low, medium, high). For example, a complete sensor failure is defined as a high-level error, while slight data drift is defined as a low-level error. Subscription information is configuration information issued by the data collection device, specifying which error types and levels of error events the target data acquisition device should report. The subscription scope indicated by the subscription information refers to the set of error types and / or error levels (which can be limited to error types only, error levels only, or both) defined in the subscription information. Only error events falling within this scope will be reported.

[0041] In one feasible implementation, the data collection device receives user-inputted subscription preferences through a user interface (such as an App settings page), generates subscription information, and stores the subscription information in a local or remote database. After the data collection device establishes a communication connection with the target data acquisition device, it retrieves the latest subscription information from the local or remote database and sends the subscription information to the target data acquisition device. The target data acquisition device stores the subscription information for filtering purposes.

[0042] In one feasible implementation, the data collection device may further include a subscription module, which serves as the management center for subscription information and is primarily responsible for the following functions: providing a user configuration interface and internal logic, enabling users to select the error types and / or error levels they need to subscribe to as needed; persistently storing user-defined subscription preferences, such as saving them to a local or remote database; generating and managing subscription information, and automatically sending the latest subscription information to the target data collection device after establishing or resuming a Bluetooth connection through the connection management module; simultaneously, this module is also responsible for maintaining the consistency of the subscription status, ensuring that the subscription relationship is maintained after the device disconnects and reconnects, avoiding information loss, and thus ensuring the continuous and effective operation of the error filtering mechanism.

[0043] If yes, proceed to step S20 in step S40; otherwise, store the error event object.

[0044] If the error type and level are within the subscription range, the error event object is sent to the data collection device; otherwise, the error event object is only stored locally on the target data acquisition device (such as internal memory or file system) and not reported to the data collection device. This reduces unnecessary data transmission, saving bandwidth and power consumption. In one feasible implementation, the target data acquisition device may also include an event management module, responsible for analyzing the error type and level of the error event, and querying the stored subscription information (such as a subscription table) to decide whether to send it. If sending, the sending task is dispatched to the notification distribution module; if not sending, the error event object is stored in the device file system.

[0045] In practical applications, if the target data acquisition device indiscriminately reports all detected error events, it would lead to a large amount of non-critical or debugging information occupying the communication channel, increasing system power consumption, and interfering with the data collection device's identification and processing of critical errors. This implementation uses a subscription-notification model. The data collection device can send subscription information, precisely defining the error types and severity ranges to be reported. The target data acquisition device filters based on the subscription information, reporting only error events within its scope of interest. This effectively reduces unnecessary data transmission, saving Bluetooth channel resources and device power consumption. This mechanism improves the targeting and effectiveness of error information reporting, allowing the data collection end to focus more on handling critical issues and optimizing system resource allocation.

[0046] In one feasible implementation, the target data acquisition device can also perform (configurable to be performed via an event management module) adaptive subscription optimization, specifically including: continuously collecting and persistently storing two types of data: one type is all error event objects generated by the target data acquisition device during operation, which include error type, error level, and occurrence timestamp; the other type is a device status snapshot synchronously collected each time an error occurs, which includes at least one or more parameters such as CPU utilization, remaining memory space, and current battery level; periodically calling its built-in analysis logic to perform correlation analysis on the stored historical error data and device status snapshots to identify stable patterns, such as discovering that when the device's remaining memory is consistently below a certain threshold, the probability of a specific type of memory error occurs significantly; this analysis logic can be a set of predefined correlation rules, or... It is a lightweight machine learning model that is distributed from the data collection device and stored locally on the device. Based on the analyzed and identified patterns, it dynamically generates or updates a local adaptive subscription strategy. This strategy is specifically manifested in the adjustment of the original subscription behavior, such as temporarily raising the subscription level of some frequently occurring and potentially evolving non-critical errors to the level that needs to be reported, or automatically adding a set of system performance warning errors to the subscription range that needs to be reported when the device is detected to be under high load. When performing filtering judgment for reporting error event objects, the local adaptive subscription strategy is merged with the subscription information distributed from the data collection device and used as the basis for judgment. The specific fusion method can adopt a logical "OR" operation, that is, as long as the error event object meets the reporting conditions specified in any subscription strategy, it is determined that the error event object belongs to the reporting range, thereby triggering the subsequent reporting process.

[0047] In one feasible implementation, after step S20, steps S50 to S70 are further included: Step S50: Receive a sensor restart command or device restart command sent by the data collection device, wherein the data collection device sends a sensor restart command or device restart command to the target data acquisition device when it determines that the error type is a critical sensor error.

[0048] A critical sensor error refers to a serious malfunction that affects the core functions of a data acquisition device. For example, the sensor may completely fail to function or provide invalid data, leading to interrupted or distorted data acquisition. In cases of critical sensor errors, the pre-defined response strategy in the data acquisition device is to send a sensor restart command or a device restart command to attempt to restore the normal function of the sensor or device.

[0049] Step S60: In response to the sensor restart command or the device restart command, the sensor or device is restarted, and an indication message indicating that the restart is complete is sent to the data collection device, so that after receiving the indication message, the data collection device sends a synchronization time synchronization command to each of the data collection devices, including the target data collection device.

[0050] After the target data acquisition device restarts, it can send an indication message (such as a simple confirmation message "Restart Complete") to inform the data collection device that the restart is complete. Alternatively, it can send the indication message using an error event object, in which case the error type is the state change type. Upon receiving the indication message, the data collection device sends a synchronization command to all data acquisition devices to ensure time synchronization across multiple devices, preparing for the resumption of data acquisition.

[0051] Step S70: Receive the synchronization time synchronization instruction and execute the synchronization time synchronization process in response to the synchronization time synchronization instruction.

[0052] The time synchronization process refers to the process by which the target data acquisition device obtains the current time from the data collection device and adjusts its internal clock to unify the time base, for example, through the Network Time Protocol (NTP) or a custom time synchronization mechanism.

[0053] In this implementation, a timely feedback and error correction mechanism is established for multi-device data acquisition. When a critical sensor or device experiences a serious error and is corrected, the devices re-perform preparations for synchronous acquisition, such as sensor time calibration. This ensures that the devices promptly restore a unified pace and that the acquired data is consistent after recovery, reducing the acquisition cycle and increasing the accuracy and availability of the acquired data. Especially in long-range acquisition scenarios, such as continuous data acquisition at night, this mechanism ensures timely recovery in the event of device or sensor errors, maximizing the effectiveness and continuity of data acquisition and reducing the extension of the acquisition cycle due to interruptions and repairs.

[0054] In one feasible implementation, after completing the synchronization and time synchronization process, the target data acquisition device can initiate a high-priority time synchronization result verification request to the data collection device or a known Public Network Time Protocol (NTP) server to obtain a reliable reference timestamp; calculate the absolute time deviation between its own synchronized system time and the obtained reference timestamp; encapsulate the absolute time deviation value into a time synchronization confirmation message (its format can be consistent with the error event object, but the type field is identified as "time synchronization result"); and send the time synchronization confirmation message to the data collection device. The data collection device has a preset time synchronization quality threshold. Upon receiving the time synchronization confirmation message, it parses the absolute time deviation value and compares it with the time synchronization quality threshold; if the deviation value is less than or equal to the time synchronization quality threshold, the time synchronization is considered successful, and the process ends; if the deviation value is greater than the time synchronization quality threshold, the time synchronization is determined to have failed, and a rollback strategy is triggered. The specific implementation of this rollback strategy includes: the data collection device resending a synchronization command to the target data acquisition device (the maximum number of retries can be recorded and limited); simultaneously, the data collection device sets a "time unreliable" status flag for the target data acquisition device in its internal storage. For all subsequent personal health data received from the target data acquisition device, the data collection device can attach a "low timestamp confidence" metadata tag to the personal health data during storage or processing, for differentiated processing in subsequent data analysis stages.

[0055] Based on the first embodiment described above, a second embodiment of the error handling method of this application is proposed. In this embodiment, content that is the same as or similar to that in the first embodiment can be referred to the above description, and will not be repeated hereafter. In this embodiment, the error handling method is applied to a data collection device, which is used to collect personal health data collected and transmitted by various data acquisition devices, referring to... Figure 2 The error handling includes A10~A30: Step A10: Receive an error event object sent by the target data acquisition device, wherein the error event object includes at least an error type, the target data acquisition device is any one of the data acquisition devices, and the target data acquisition device generates the error event object according to a preset format when it detects an error event.

[0056] Step A20: Parse the error event object according to the preset parsing method corresponding to the preset format to obtain the error type.

[0057] Step A30: Execute the preset response strategy corresponding to the error type.

[0058] The explanation, specific implementation method and corresponding technical effect of steps A10 to A30 in this embodiment can be referred to the explanation, specific implementation method and corresponding technical effect of steps S10 to S20 in the above embodiment, and will not be repeated here.

[0059] In one feasible implementation, before step A10, steps A40 to A50 are further included: Step A40: After establishing a communication connection with the target data acquisition device, obtain the latest subscription information from a local or remote database.

[0060] Step A50: Send the subscription information to the target data acquisition device so that, after generating the error event object, the target data acquisition device, if it determines the error level and / or the error type in the error event object within the subscription range indicated by the subscription information, sends the error event object to the data collection device, wherein the error level is used to characterize the severity of the error.

[0061] The explanation, specific implementation method and corresponding technical effect of steps A40 to A50 in this embodiment can be referred to the explanation, specific implementation method and corresponding technical effect of steps S30 to S40 in the above embodiment, and will not be repeated here.

[0062] In one feasible embodiment, the error handling method further includes steps A60-A70: Step A60: In response to user input received in the first preset user interface, the subscription information is generated.

[0063] The first preset user interface refers to the settings interface on the data collection device where users can configure error subscription preferences. Users can select the error types and / or error levels they want to pay attention to in this interface.

[0064] Step A70: Store the subscription information locally or upload it to the remote database.

[0065] The explanation, specific implementation method and corresponding technical effect of steps A60 to A70 in this embodiment can be referred to the explanation, specific implementation method and corresponding technical effect of steps S30 to S40 in the above embodiment, and will not be repeated here.

[0066] In one feasible embodiment, step A30 includes A301 to A303: Step A301: If the error type is a sensor critical error, generate alarm information and display the alarm information in the second preset user interface.

[0067] The second preset user interface refers to the main interface or dedicated alarm interface on the data collection device used to display error alarms and system status. Alarm information may include an error description, time of occurrence, device identifier, and suggested handling measures. Its purpose is to promptly inform the user of the abnormal status of the device, so that the user can understand the situation and take appropriate actions.

[0068] Step A302: Send a sensor restart command or a device restart command to the target data acquisition device so that the target data acquisition device can restart the sensor or restart the device based on the command.

[0069] Step A303: After detecting that the target data acquisition device has completed sensor restart or device restart, a synchronization time synchronization command is sent to each of the data acquisition devices, including the target data acquisition device, so that each of the data acquisition devices can complete the synchronization time synchronization.

[0070] The explanation, specific implementation method and corresponding technical effect of steps A301 to A303 in this embodiment can be referred to the explanation, specific implementation method and corresponding technical effect of steps S50 to S70 in the above embodiment, and will not be repeated here.

[0071] In one feasible embodiment, step A302 includes A3021~A3022: Step A3021: If it is detected that the current state is in a preset non-interference mode, a sensor restart command or a device restart command is sent to the target data acquisition device.

[0072] Preset non-interference mode refers to the operating mode in which users do not want to be disturbed in specific scenarios, such as sleep mode or meeting mode. In this mode, the system will automatically handle errors without requiring manual confirmation from the user.

[0073] Step A3022: If it is detected that the current state is not in the preset non-interference mode, a prompt message is output in the second preset user interface to prompt the user to trigger a sensor restart command or a device restart command. In response to the user input received in the second preset user interface, a sensor restart command or a device restart command is generated and sent to the target data acquisition device.

[0074] The prompt message may include a description of the device malfunction and suggestions for restarting.

[0075] To aid in understanding the above embodiments of the error handling method of this application, an implementation method combining the error handling methods in the above embodiments is proposed. In this implementation, the error handling scheme is implemented based on two main modules: a device and an app. The device is integrated into data collection devices such as smart bracelets and watches, and mainly includes an error detection module, an event management module, and a notification distribution module. The app runs on data collection devices such as smartphones and mainly includes a connection management module, a subscription module, and a notification processing module. The device and app communicate using the Bluetooth Low Energy (BLE) protocol for binary data transmission, while the modules within the app interact using JSON data format.

[0076] The functional division of each module on the device side is as follows: The error detection module is the anomaly detection code implemented in the device firmware. Once a sensor anomaly or system failure is detected during operation, it immediately creates an error event object according to a preset format. The event management module is responsible for receiving error event objects, analyzing the error type and error level contained therein, and querying the subscription information table stored locally on the device to determine whether to report the error event. If it is determined that reporting is necessary, a task will be dispatched to the notification distribution module; if no reporting is necessary, the error event object will be stored in the device file system. The notification distribution module is responsible for communicating directly with the App, transmitting the error event objects that need to be reported to the App via a BLE connection.

[0077] The functional division of each module on the App is as follows: The Connection Management module is the core component responsible for establishing, maintaining, and managing Bluetooth connections with devices. Its functions include device discovery, pairing, connection establishment, connection keep-alive, reconnection after disconnection, and unpairing. The Subscription module manages user subscription preferences, providing a user configuration interface and internal logic for users to select the error types and / or error levels they need to subscribe to. This module persistently saves user subscription settings to the database and sends subscription information to the device after the Bluetooth connection is established. Simultaneously, this module manages the subscription status, ensuring that subscription information is automatically restored after device reconnection to avoid loss. The Notification Processing module listens for, parses, and processes error event objects sent by the device, and sends error correction commands to the device when necessary according to preset strategies. When a device restarts and reconnects due to a critical sensor error or device-level error, this module can trigger a synchronization time synchronization process to ensure that all data acquisition devices promptly restore time synchronization, thereby ensuring consistent data acquisition.

[0078] The following example illustrates the collaborative workflow between the device and the app, using a specific example of a primary sensor initialization failure. Figure 3 The diagram shows the error handling process on the device side, such as... Figure 4 The following is the error handling process on the APP side: The connection management module in the app first scans and discovers the device, then initiates pairing and connection. After the connection is successfully established, the subscription module immediately reads the user's subscription preferences (e.g., only subscribing to urgent errors) from a local or remote database and sends this subscription information to the device; the device receives and updates its stored subscription list.

[0079] When the error detection module on the device detects a sensor initialization failure, it immediately generates an error event object according to a preset format. This object contains information such as the error type, error level (e.g., emergency level), and specific error code. Subsequently, it publishes the error event object to the event management module by calling an internal function.

[0080] After receiving the error event object, the event management module first stores it locally on the device, and then queries the stored subscription information list. When it is determined that the current error level falls within the range subscribed by the APP, the error event object is sent to the notification distribution module.

[0081] After receiving the object, the notification distribution module encodes it into a format suitable for transmission over Bluetooth Low Energy, and actively sends the encoded information to the APP in real time via the established Bluetooth connection and the Notify feature.

[0082] After receiving the information, the notification processing module parses it and then displays the corresponding alarm information on the user interface. In scenarios where data is continuously collected and the user cannot intervene in time (such as when the user is asleep), the app can automatically send a sensor restart command to the device through the same communication channel to actively correct the error.

[0083] After the device restarts and restores its connection, the app can send a synchronization command to it. The device responds to the command and executes the synchronization process, thus aligning its data acquisition pace with that of other data acquisition devices.

[0084] Current multi-device collaborative data acquisition scenarios suffer from several issues: differences in device performance and communication protocols exist, yet a high degree of consistency in the acquisition process must be maintained with minimal human intervention; error checking mechanisms heavily rely on manual intervention, limiting the investigation perspective to a single device, resulting in poor real-time performance and delayed feedback. To address these problems, this implementation proposes an error handling mechanism based on a subscription-notification model. This mechanism enables real-time reporting and proactive error correction across multiple devices, significantly reducing manual intervention and improving the real-time troubleshooting and feedback capabilities of multi-device systems. By filtering error events through a subscription mechanism, devices are prevented from occupying Bluetooth channels for extended periods to transmit non-critical information, thus ensuring the efficiency of business data transmission and achieving event-driven, on-demand transmission. Furthermore, the solution establishes a closed-loop feedback and error correction mechanism. When a critical sensor or device experiences a serious error and is corrected, the system automatically triggers synchronization preparation work among multiple devices (such as unified time synchronization), ensuring timely restoration of unified synchronization among devices, effectively improving the consistency and availability of acquired data, and shortening the acquisition cycle caused by error interruptions. From an operation and maintenance perspective, the solution provided in this implementation method significantly reduces the cost of troubleshooting errors in multi-device systems through centralized error information display and management, making problems more intuitive and greatly facilitating equipment debugging and system maintenance.

[0085] This application provides an error handling device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the error handling method described in Embodiment 1 above. In a specific embodiment, the eye-tracking device may be a data acquisition device or a data collection device.

[0086] The following is for reference. Figure 5 It shows a schematic diagram of the structure of an error handling device suitable for implementing the embodiments of this application. Figure 5 The error handling device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0087] like Figure 5As shown, the error handling device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the error handling device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the error handling device to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows error handling devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0088] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0089] Compared with the prior art, the beneficial effects of the error handling device provided in this application embodiment are the same as those of the error handling method provided in the above embodiment, and other technical features in the error handling device are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0090] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0091] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the error handling method described in the above embodiments.

[0092] The computer-readable storage medium provided in this application embodiment may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0093] The aforementioned computer-readable storage medium may be included in the error handling device or may exist independently without being assembled into the error handling device.

[0094] The aforementioned computer-readable storage medium carries one or more programs, which, when executed by an error handling device, cause the error handling device to perform the functions defined in the methods of the embodiments disclosed in this application.

[0095] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0096] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0097] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0098] The readable storage medium provided in this application embodiment is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for performing the above-described error handling method. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application embodiment are the same as the beneficial effects of the error handling method provided in the above-described embodiments, and will not be repeated here.

[0099] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. An error handling method, characterized in that, The error handling method is applied to a target data acquisition device, which is any one of the various data acquisition devices. Each of the data acquisition devices is used to collect personal health data and send it to the data collection device. The error handling includes: When an error event is detected, an error event object is generated according to a preset format, wherein the error event object includes at least an error type; The error event object is sent to the data collection device so that the data collection device can parse the error event object according to a preset parsing method corresponding to the preset format to obtain the error type, and execute a preset response strategy corresponding to the error type.

2. The error handling method as described in claim 1, characterized in that, The error event object also includes an error level, which characterizes the severity of the error. Following the step of generating the error event object according to a preset format upon detecting an error, the method further includes: Detect whether the error level and / or the error type are within the subscription range indicated by pre-stored subscription information, wherein the subscription information is received and stored from the data collection device; If so, then the step of sending the error event object to the data collection device is performed; If not, then store the error event object.

3. The error handling method as described in claim 1 or 2, characterized in that, After the step of sending the error event object to the data collection device, the method further includes: The system receives a sensor restart command or a device restart command sent by the data collection device, wherein the data collection device sends a sensor restart command or a device restart command to the target data acquisition device when it determines that the error type is a critical sensor error. In response to the sensor restart command or the device restart command, the sensor or device is restarted, and an indication message indicating that the restart is complete is sent to the data collection device, so that after receiving the indication message, the data collection device sends a synchronization time synchronization command to each of the data collection devices, including the target data collection device. Receive the synchronization time command and execute the synchronization time command in response to the synchronization time command.

4. An error handling method, characterized in that, The error handling method is applied to a data collection device, which collects personal health data collected and transmitted by various data collection devices. The error handling includes: The system receives an error event object sent by a target data acquisition device, wherein the error event object includes at least an error type, the target data acquisition device is any one of the data acquisition devices, and the target data acquisition device generates the error event object according to a preset format when it detects an error event. The error type is obtained by parsing the error event object according to the preset parsing method corresponding to the preset format; Execute the preset response strategy corresponding to the error type.

5. The error handling method as described in claim 4, characterized in that, Before the step of receiving the error event object sent by the target data acquisition device, the method further includes: After establishing a communication connection with the target data acquisition device, the latest subscription information is obtained from a local or remote database; The subscription information is sent to the target data acquisition device so that, after generating the error event object, the target data acquisition device, if it determines the error level and / or the error type in the error event object within the subscription range indicated by the subscription information, will send the error event object to the data collection device, wherein the error level is used to characterize the severity of the error.

6. The error handling method as described in claim 5, characterized in that, The error handling method further includes: The subscription information is generated in response to user input received in the first preset user interface; The subscription information is stored locally or uploaded to the remote database.

7. The error handling method as described in claim 4, characterized in that, The step of executing the preset response strategy corresponding to the error type includes: If the error type is a critical sensor error, an alarm message is generated and displayed in a second preset user interface; Send a sensor restart command or a device restart command to the target data acquisition device so that the target data acquisition device can restart the sensor or restart the device based on the command; After detecting that the target data acquisition device has completed sensor restart or device restart, a synchronization time synchronization command is sent to each of the data acquisition devices, including the target data acquisition device, so that each of the data acquisition devices can complete the synchronization time synchronization.

8. The error handling method as described in claim 7, characterized in that, The step of sending a sensor restart command or a device restart command to the target data acquisition device includes: If the system detects that it is currently in a preset non-interference mode, it sends a sensor restart command or a device restart command to the target data acquisition device. If it is detected that the current state is not in the preset non-interference mode, a prompt message is output in the second preset user interface to prompt the user to trigger a sensor restart command or a device restart command. In response to the user input received in the second preset user interface, a sensor restart command or a device restart command is generated and sent to the target data acquisition device.

9. An error handling device, characterized in that, The error handling device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the error handling method as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the error handling method as described in any one of claims 1 to 8.

Images