A multi-source data fusion storage method and system for a smart watch

Abstract

This invention discloses a multi-source data fusion storage method and system for smartwatches, belonging to the field of wearable device data processing. The method includes: periodically collecting data from multiple sensors such as heart rate and motion at a variable sampling frequency; encapsulating the data from the same period into fixed-format data frames, with fixed slot lengths for each sensor data within the frame; sequentially writing the data frames into a circular buffer to form a data stream; and providing a frame-by-frame reading interface. This invention employs a fixed frame format combined with periodic frame number reset and reserved slot design, achieving sampling frequency encoding, backward compatibility, and efficient on-demand reading; and ensures the security of critical data through water level warnings and event-triggered data transfer. This invention solves the problems of high parsing overhead and difficulty in supporting multiple applications in existing technologies, and has advantages such as high parsing efficiency, predictable storage, natural time alignment, and support for multi-rate applications. It can be widely applied to resource-constrained embedded devices such as smartwatches.

Description

Technical Field

[0001] This invention belongs to the field of wearable devices and data processing technology, specifically relating to a multi-source data fusion and storage method and system for smartwatches. Background Technology

[0002] Current wearable devices such as smartwatches integrate multiple sensors, including heart rate sensors, accelerometers, gyroscopes, and positioning modules, requiring the simultaneous collection of multimodal data for applications such as health monitoring, motion analysis, and safety alerts. However, due to the limited processor performance and battery capacity of smartwatches, there are extremely high requirements for data processing efficiency and power consumption. Existing technologies typically employ the following methods when processing this type of multi-source data:

[0003] Method 1: Data from each sensor is stored independently, and the application layer reads it as needed. This method results in scattered data, making time alignment difficult. Application development requires handling multiple data streams, increasing development complexity.

[0004] Method 2: Use text formats such as JSON and XML for structured storage. While this method is easy for humans to read, it incurs high parsing overhead, leading to significant increases in CPU usage and power consumption on resource-constrained embedded devices. Furthermore, the data length is variable, making it impossible to predict storage space requirements.

[0005] Method 3: Employ a subscription-notification mechanism, where the data collection module pushes data to various applications. However, as the number of third-party applications increases, the push overhead multiplies, and different applications have different data frequency requirements (some only need 1Hz, while others need 20Hz or higher). A "one-size-fits-all" push strategy leads to resource waste.

[0006] Furthermore, the lack of a unified data format in existing technologies that can simultaneously achieve both "real-time performance" and "traceability" makes it difficult to develop third-party applications, resulting in severe data silos and hindering the formation of an open ecosystem.

[0007] It should be noted that although fixed-frame format communication similar to the CAN bus protocol exists in the field of industrial control, the identifiers in CAN frames are static addresses used to distinguish message priority and content, and are not designed for time alignment and on-demand reading of multi-sensor data; although circular buffers are used in industrial data acquisition systems, they usually lack a collaborative mechanism that combines dynamic adjustment of sampling frequency and event-triggered data transfer; and time alignment in sensor data fusion is often done by the application layer, without native support at the data storage level.

[0008] This invention is specifically designed for wearable devices such as smartwatches, which have extremely limited resources, and proposes a solution for efficient and scalable multi-source data fusion at the data storage layer. Summary of the Invention

[0009] 1. Technical problems to be solved

[0010] The technical problem to be solved by this invention is to provide a unified, efficient, and scalable multi-source data fusion and storage method to address the problems of high parsing overhead, resource waste, and difficulty in developing third-party applications in existing multi-source data processing methods for smartwatches.

[0011] 2. Technical Solution

[0012] The core concept of this invention lies in employing a fixed-format data frame structure to align and encapsulate multi-source sensor data in time into a unified data unit, allowing upper-layer applications to read it on demand. Specifically, this invention provides the following technical solution:

[0013] A method for multi-source data fusion and storage for smartwatches includes the following steps:

[0014] Multiple sensor data are periodically acquired at a variable sampling frequency, and the multiple sensor data includes at least heart rate data and motion data;

[0015] Multiple sensor data collected within the same sampling period are packaged into a fixed-format data frame in a predetermined order; the data frame includes multiple data slots, each data slot corresponds to a sensor data type and has a fixed byte length;

[0016] The data frames are written sequentially into a circular buffer to form a continuous data stream;

[0017] In response to read requests from upper-layer applications, an interface is provided to read data from the data stream frame by frame.

[0018] Preferably, the data frame further includes a flag byte, which identifies the sampling frequency or operating mode of the current data frame. Further, the flag byte includes a sampling frequency encoding bit, which identifies the sampling frequency corresponding to the current data frame, enabling upper-layer applications to autonomously determine which data frames to read based on this encoding.

[0019] Preferably, the data frame further includes a frame sequence number field, which increments within each sampling period. Furthermore, the frame sequence number is reset within each preset time period, ensuring that data frames within the same time period have consecutive sequence numbers.

[0020] A key application of periodically resetting frame sequence numbers is that different upper-layer applications may have different sampling frequency requirements for the same sensor data. By using frame sequence numbers, each application can independently select to read data frames with specific sequence numbers, achieving "one-time acquisition, multi-rate multiplexing." This mechanism avoids the system frequently adjusting the sampling frequency to meet different application needs, and also avoids the push overhead of subscription-notification mechanisms.

[0021] Preferably, the data frame also includes at least one reserved data slot, which is used to accommodate new sensor data types added in the future, so as to achieve backward compatibility.

[0022] Preferably, the circular buffer is implemented using a ring buffer and is equipped with a water level warning mechanism, which triggers a warning when the buffer usage rate reaches a preset threshold (e.g., 80%).

[0023] Preferably, the method further includes: extracting a sequence of consecutive data frames within a specified time window from the circular buffer according to the frame sequence number, wherein the sequence is used to construct a dynamic baseline or perform statistical operations, the statistical operations including but not limited to calculating the mean, median, and standard deviation.

[0024] Preferably, the method further includes: supporting multiple upper-layer applications to read the data stream simultaneously, with each application choosing to read all or part of the data frames according to its own needs.

[0025] Preferably, the method further includes: when the water level warning is triggered, or when an event marker instruction is received, transferring a specified data frame in the circular buffer to a non-volatile memory.

[0026] Accordingly, the present invention also provides a multi-source data fusion storage system for smartwatches, comprising:

[0027] The data acquisition module is used to periodically acquire data from multiple sensors at a variable sampling frequency, wherein the multiple sensor data includes at least heart rate data and motion data;

[0028] The frame encapsulation module is used to encapsulate multiple sensor data collected within the same sampling period into a fixed-format data frame in a predetermined order; the data frame includes multiple data slots, each data slot corresponds to a sensor data type and has a fixed byte length;

[0029] The cache management module is used to write the data frames sequentially into a circular buffer to form a continuous data stream;

[0030] The interface module is used to respond to read requests from upper-layer applications and provide an interface for reading data frame by frame from the data stream.

[0031] 3. Beneficial effects

[0032] Compared with the prior art, the present invention has the following beneficial effects:

[0033] (1) Low parsing overhead: Since the data frame format is fixed, the upper layer application can directly read the required data by byte offset without protocol parsing, which greatly reduces CPU usage and power consumption, making it particularly suitable for resource-constrained embedded devices.

[0034] (2) Predictable storage space: Fixed-length data frames make buffer capacity planning simple. Developers can accurately calculate the storage space required for a specified duration, avoiding memory overflow or waste.

[0035] (3) Support for multi-rate applications: By carrying sampling frequency encoding or frame sequence number in the data frame, upper-layer applications with different needs can choose to read all frames, some frames or frames with specific sequence numbers, realizing an efficient data distribution mode of "write once, read many times" and avoiding the push overhead brought by the subscription-notification mechanism.

[0036] (4) Multi-application decoupling and resource reuse: This invention achieves the core advantages of "write once, read by multiple applications, and reuse at multiple rates". The system only needs to collect data once at the highest sampling frequency, and each application can obtain the data of its required frequency by reading the frame sequence number modulo. There is no need to push data to each application separately, nor is there any need to compromise the sampling frequency between applications. This mechanism fundamentally solves the problem of "frequency conflict" in multi-application scenarios and significantly reduces the total system overhead.

[0037] (5) Naturally supports time alignment: Multiple source data within the same data frame are naturally aligned in time, providing an accurate time reference for subsequent data fusion analysis.

[0038] (6) High scalability: The design of reserved data slots ensures that when adding new sensor types in the future, there is no need to change the existing data format and parsing code, thus achieving forward compatibility.

[0039] (7) Facilitates the construction of real-time analysis datasets: Since the multi-source data within the same data frame are strictly aligned in time and the data frames are stored continuously in the circular buffer, the system can easily extract data sequences within any time window for use in constructing dynamic baselines, calculating moving averages, performing trend analysis and other aggregation operations.

[0040] (8) Efficient sharing among multiple applications: The write-once, read-many mechanism allows multiple applications to access the same data stream simultaneously. Each application reads on demand without interfering with each other, significantly reducing system overhead.

[0041] (9) Reliable data preservation: The combination of water level warning and event-triggered transfer design ensures that critical data will not be lost due to cyclic overwriting, meeting the requirements for secure data preservation.

[0042] The table below visually compares the performance differences between this invention and existing mainstream solutions:

[0043]

[0044] The present invention also provides a computer-readable storage medium having a computer program stored thereon, wherein the program, when executed by a processor, implements the method described in any of the preceding claims. The storage medium may be any medium capable of storing program code, such as ROM, RAM, flash memory, hard disk, or optical disk.

[0045] Those skilled in the art should understand that, based on the content disclosed in this specification, computer programs for implementing the methods can be written by those skilled in the art according to actual needs and stored in various computer-readable media.

[0046] It should be noted that the core of this invention lies in a multi-source data fusion and storage method, which can be implemented through a computer program. Regardless of the hardware device on which the program runs—including but not limited to smartwatches, smart bracelets, smart wristwatches, mobile phones, tablets, in-vehicle terminals, VR / AR devices, etc.—as long as the device executes the program of this invention, the technical solution of this invention is realized. Therefore, the scope of protection of this invention should not be limited to a specific hardware form, but should extend to all devices running the program of this invention. Attached Figure Description

[0047] Figure 1 This is a schematic diagram of the structure of a data frame in an embodiment of the present invention.

[0048] Figure 2 This is a schematic diagram illustrating the process of sensor data encapsulation, caching, and application reading in an embodiment of the present invention.

[0049] Figure 3 This is a schematic diagram illustrating how multiple upper-layer applications read data frames on demand in an embodiment of the present invention. Detailed Implementation

[0050] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be described in detail below with reference to the accompanying drawings and specific embodiments. It should be noted that the following embodiments are only for explaining the invention and are not intended to limit the scope of protection of the invention.

[0051] Example 1: Smartwatch Data Acquisition and Cache Management

[0052] This embodiment uses a smartwatch integrating a heart rate sensor, accelerometer, and BeiDou positioning module as an example to specifically illustrate the method of the present invention.

[0053] Step 1: Data Collection

[0054] The system periodically collects heart rate data (2 bytes), acceleration data (6 bytes), and location data (8 bytes) at a sampling frequency of 10Hz. In normal mode, it can switch to 1Hz or 5Hz, and in emergency mode, it can increase to 10Hz or higher.

[0055] Step 2: Frame Encapsulation

[0056] Each time data is collected, the above data is encapsulated into a 28-byte data frame, in the following format: Figure 1 As shown:

[0057] Byte 0: Flag byte (bit 7: 0 = normal mode, 1 = emergency mode; bits 6-4: sampling frequency encoding, such as 000 = 1Hz, 001 = 5Hz, 010 = 10Hz; bits 3-0: reserved)

[0058] Byte 1: Frame sequence number (The frame sequence number increments from 0 in each cycle and is reset once at the preset cycle. For example, at 10Hz sampling, 10 data frames are generated per second, with frame numbers 0, 1, 2, ..., 8, 9. If the preset reset occurs once per second, it will start from 0 again in the next second. If the sampling frequency is adjusted to 20Hz, 20 data frames are generated per second, with frame numbers 0, 1, 2, ..., 18, 19, and it will start from 0 again in the next second).

[0059] Bytes 2-3: Heart rate data

[0060] Bytes 4-9: Acceleration data

[0061] Bytes 10-17: Location data

[0062] Bytes 18-27: Reserved slots (for future addition of sensors)

[0063] The ingenious design of the frame sequence number lies in the fact that, since it is reset once every preset period (e.g., every second), the frame sequence number implicitly contains time information. Applications only need to calculate the time position of the data based on the frame sequence number and the sampling frequency encoding, without the need for additional timestamp parsing.

[0064] Step 3: Cache management (e.g.) Figure 2 (as shown)

[0065] Data frames are sequentially written to a circular buffer (for example, the buffer is configured to store data with a 30-second window period and a 20Hz sampling frequency). A water level warning is triggered when the buffer usage reaches 80%; a forced rollover is triggered when it reaches 90%.

[0066] Step 4: Application Reading

[0067] Application 1 reads the required data from the cache.

[0068] Application 2 reads the required data from the transfer area.

[0069] Application 3 reads data from both the cache and the transfer area.

[0070] It should be noted that the arrangement order of the data slots (heart rate → acceleration → positioning) and the byte length of each slot (heart rate 2 bytes, acceleration 6 bytes, positioning 8 bytes, reserved 10 bytes) in this embodiment are illustrative. In practical applications, those skilled in the art can flexibly adjust the arrangement order of the data slots, the byte length of each slot, and the length of the reserved slot according to the sensor type, data accuracy requirements, and system resource constraints. As long as the data frame format remains fixed, it falls within the protection scope of this invention.

[0071] In this embodiment, step 1 is executed by the data acquisition module, step 2 by the frame encapsulation module, step 3 by the cache management module, and step 4 by the interface module. Those skilled in the art will understand that these modules can be implemented in software, hardware, or firmware and integrated into the smartwatch's processor.

[0072] Example 2: Event-triggered transfer

[0073] When a user triggers an event marker by pressing a key, the system records the current frame number and extracts data from the circular buffer for 300 frames before and after that frame number (corresponding to 30 seconds), transferring it to non-volatile memory (such as a Flash chip). This data can be used for post-event tracing or for judicial evidence preservation. In this embodiment, the transfer trigger condition can also be that the water level reaches 90% or an external command.

[0074] Example 3: Construction of Dynamic Heart Rate Baseline

[0075] The system can periodically extract heart rate data (corresponding to 100 heart rate data) from the most recent corresponding number of frames in the circular buffer according to a preset time window (e.g., 10 seconds). Statistical operations (e.g., calculating their arithmetic mean and median) are then performed to serve as a dynamic baseline.

[0076] An anomaly warning is triggered when real-time heart rate data deviates significantly from the baseline (e.g., more than twice the standard deviation). This embodiment utilizes the continuous storage and time alignment of data frames in this invention, making baseline calculation extremely efficient.

[0077] Example 4: Hybrid application of different sampling frequencies

[0078] In actual operation, the system can dynamically switch the sampling frequency according to task requirements. For example, when user movement is detected, the sampling frequency increases from 1Hz to 5Hz. The sampling frequency code in the flag byte is updated accordingly, and the application layer can determine the data density based on this code. If application B needs to fix the data at 1Hz, it only needs to read the frame with frame number 0, without needing to care about the change in sampling frequency.

[0079] Example 5: Multi-application, multi-rate, on-demand reading

[0080] This example demonstrates how frame numbers can be used to meet the different sampling frequency requirements of different applications for the same sensor data.

[0081] Assume the system collects heart rate data at a sampling frequency of 20Hz (generating 20 data frames per second). Assume the reset period is 1 second, and the frame number increments from 0 every second, sequentially as 0, 1, 2, ..., 19, and restarts from 0 in the next second.

[0082] The system runs three upper-layer applications simultaneously (see...) Figure 3 ):

[0083] Application A: Requires 1Hz heart rate data (1 time per second).

[0084] Application B: Requires 2Hz heart rate data (twice per second)

[0085] Application C: Requires 4Hz heart rate data (4 beats per second)

[0086] The reading strategies for each application are as follows:

[0087] Application A: Reads frame number 0 (reads 1 frame every 20 frames), and obtains heart rate data at a frequency of 1Hz.

[0088] Application B: Read frames with sequence numbers 0 and 10 (read 1 frame every 10 frames), and obtain heart rate data at a frequency of 2Hz.

[0089] Application C: Read frames with sequence numbers 0, 5, 10, and 15 (read 1 frame every 5 frames), and obtain heart rate data at a frequency of 4Hz.

[0090] It should be noted that the selection of frame numbers to read by the above applications is merely illustrative. In practical applications, those skilled in the art can flexibly adjust this selection based on factors such as system load and data timeliness requirements. For example, application B can read frames with frame numbers 0 and 10, frames with frame numbers 1 and 11, or two frames offset by any fixed value, as long as the reading interval remains at 10 frames (i.e., one frame is read every 10 frames), a reading frequency of 2Hz can be achieved. Similarly, application C can choose frame numbers 2, 7, 12, and 17 as reading points, or any sequence with an interval of 5 frames. The core of this invention lies in achieving on-demand interval reading through frame numbers, rather than limiting a specific starting frame number.

[0091] The above reading strategy can be uniformly described as follows: Let the system sampling frequency be F, and the frequency required by the application be f. Then, the application reads data frames whose frame numbers satisfy "frame number mod (F / f) = 0", or reads any congruence class of frame numbers satisfying "frame number ≡ k (mod F / f)", where k is any integer between 0 and (F / f)-1. When F / f is an integer, the required frequency can be accurately achieved.

[0092] It should be noted that when the required frequency f is not a divisor of the system sampling frequency F, there may be a slight error between the actual reading frequency and the target frequency. For example, if the system sampling frequency is 20Hz and an application requires 3Hz of data, then 20 / 3≈6.67, which is not divisible. In this case, a rounding strategy can be adopted (e.g., reading 1 frame every 7 frames, the actual frequency is approximately 2.86Hz; or reading 1 frame every 6 frames, the actual frequency is approximately 3.33Hz), choosing an appropriate approximation scheme based on the application's tolerance for accuracy.

[0093] Furthermore, those skilled in the art can adjust the frame sequence number reset period (e.g., changing the reset every second to every 3 seconds) or reset time point as needed for the actual scenario to meet the time alignment requirements of different upper-layer applications. These adjustments are standard design choices for those skilled in the art and require no inventive effort.

[0094] Each application can achieve on-demand reading by using the above-mentioned modulus conditions, without requiring the system to change the underlying acquisition frequency or to push data separately to each application. This embodiment demonstrates the core advantage of the present invention, "one-time acquisition, multi-rate multiplexing," which significantly reduces system overhead and is particularly suitable for devices such as smartwatches with limited sensor resources.

[0095] Example 6: Application of smartwatches in safety monitoring of construction workers

[0096] This embodiment applies the method of the present invention to a smart safety watch for construction workers. In addition to integrating a heart rate sensor, accelerometer and Beidou positioning module, the watch is also equipped with environmental sensors (such as temperature and humidity sensors, dust concentration sensors and carbon monoxide sensors) and barometric altimeter.

[0097] Step 1: Data Collection

[0098] The system collects multi-source data at a variable sampling frequency. Under normal conditions, the sampling frequency is 1Hz (i.e., the sampling period is 1 second). When high-altitude operations are detected (determined by a barometric altimeter) or entry into a dangerous area is detected (by matching the positioning with a preset electronic fence), the frequency is automatically increased to 10Hz.

[0099] Step 2: Frame Encapsulation

[0100] Each data acquisition session encapsulates the data into a fixed-format data frame. The frame structure is designed as follows (taking 42 bytes as an example):

[0101] Byte 0: Flag byte (same as in Example 1)

[0102] Byte 1: Frame sequence number (reset every second)

[0103] Bytes 2-3: Heart rate data

[0104] Bytes 4-9: Acceleration data

[0105] Bytes 10-17: Location data

[0106] Bytes 18-19: Barometric Altitude

[0107] Bytes 20-21: Temperature

[0108] Bytes 22-23: Humidity

[0109] Bytes 24-25: Dust Concentration

[0110] Bytes 26-27: Carbon monoxide concentration

[0111] Bytes 28-41: Reserved slots (14 bytes)

[0112] Step 3: Cache Management

[0113] Data frames are written to a circular buffer, which can hold 60 seconds of data (calculated based on the highest sampling frequency). An alert is triggered when the water level reaches 80%, and a data transfer is initiated when it reaches 90%.

[0114] Step 4: Application Reading

[0115] Application A (Safety Monitoring Center): Reads all data frames, analyzes workers' physiological status and environmental risks in real time, and automatically alarms when there is abnormal heart rate, excessive dust, or sudden drop in altitude.

[0116] Application B (Field Administrator): Reads only low-frequency data (e.g., one frame every 10 frames) to view overall trends.

[0117] Application C (Event Log): When a worker actively presses the SOS button, the system saves all data frames from 60 seconds before and after the event to Flash and uploads them to the cloud via 4G network as evidence.

[0118] The beneficial effects of this embodiment are: it demonstrates the seamless expansion capability of the method of the present invention for adding new sensors (by reserving slots), and the flexible support for multiple applications and multiple rate requirements, while also proving the applicability of the method in the field of industrial safety.

[0119] Industrial applicability

[0120] Although this invention is illustrated using a smartwatch as an example, those skilled in the art will understand that the technical solutions of this invention are also applicable to other resource-constrained embedded devices, especially other types of wearable devices such as smart bracelets, smart rings, and smart glasses, as long as these devices require the collection, efficient storage, and processing of multi-source sensor data. Any device employing the core concept of this invention—namely, combining fixed-format, time-aligned data frames with an on-demand reading mechanism—falls within the protection scope of this invention.

Claims

1. A method for multi-source data fusion and storage in smartwatches, characterized in that, Includes the following steps: Multiple sensor data are periodically acquired at a variable sampling frequency, and the multiple sensor data includes at least heart rate data and motion data; Multiple sensor data collected within the same sampling period are packaged into a fixed-format data frame in a predetermined order; the data frame includes multiple data slots, each data slot corresponds to a sensor data type and has a fixed byte length; The data frames are written sequentially into a circular buffer to form a continuous data stream; In response to read requests from upper-layer applications, an interface is provided to read data from the data stream frame by frame.

2. The method according to claim 1, characterized in that, The data frame also includes a flag byte, which is used to identify the sampling frequency or operating mode of the current data frame.

3. The method according to claim 2, characterized in that, The flag byte includes a sampling frequency encoding bit, which identifies the sampling frequency corresponding to the current data frame, enabling the upper-layer application to decide which data frames to read based on this encoding.

4. The method according to claim 1, characterized in that, The data frame also includes a frame sequence number field, which increments in each sampling period.

5. The method according to claim 4, characterized in that, The frame sequence number is reset within each preset time period, so that data frames within the same time period have consecutive sequence numbers.

6. The method according to claim 1, characterized in that, The data frame also includes at least one reserved data slot for accommodating new sensor data types to be added in the future.

7. The method according to claim 1, characterized in that, The circular buffer is implemented using a ring buffer and is equipped with a water level warning mechanism. When the buffer usage rate reaches a preset threshold, an early warning is triggered.

8. The method according to claim 4, characterized in that, Also includes: Based on the frame sequence number, a continuous data frame sequence is extracted from the circular buffer, and the continuous data frame sequence corresponds to a preset time window; The sequence is used to construct a dynamic baseline or to perform statistical operations, including but not limited to calculating the mean, median, and standard deviation.

9. The method according to claim 1, characterized in that, Also includes: It supports multiple upper-layer applications reading the data stream simultaneously, with each application choosing to read all or part of the data frames according to its own needs.

10. The method according to claim 7, characterized in that, Also includes: When the water level warning is triggered, or when an event marker instruction is received, the specified data frame in the circular buffer is transferred to non-volatile memory.

11. A multi-source data fusion storage system for smartwatches, characterized in that, include: The data acquisition module is used to periodically acquire data from multiple sensors at a variable sampling frequency; The frame encapsulation module is used to encapsulate multiple sensor data collected within the same sampling period into a fixed-format data frame in a predetermined order; the data frame includes multiple data slots, each data slot corresponds to a sensor data type and has a fixed byte length; The cache management module is used to write the data frames sequentially into a circular buffer to form a continuous data stream; The interface module is used to respond to read requests from upper-layer applications and provide an interface for reading data frame by frame from the data stream.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 10.

Images