Animal behavior event generation method and system, electronic device and storage medium

Abstract

The application relates to the technical field of pet intelligent wearable devices, and discloses an animal behavior event generation method and system, an electronic device and a storage medium, which comprise the following steps: receiving a data batch uploaded by a wearable device; creating an algorithm running record; pre-processing and window dividing are performed on the data batch to obtain a plurality of time windows; quality judgment is performed on the time windows to generate window quality marks; window-level model reasoning is performed on the time windows to output candidate behavior labels and confidence degrees of each time window; the time windows are subjected to stabilization treatment according to the window quality marks, adjacent window label consistency, window duration and confidence degrees to obtain behavior segments; behavior events are generated according to the behavior segments; the behavior events are bound to the data batch and the algorithm running record at the same time; and the structured behavior events are used to update front-end readable activity states or health analysis inputs; the application sorts candidate judgments of a plurality of windows into stable and reviewable behavior events.

Description

Technical Field

[0001] This invention relates to the field of smart wearable devices for pets, specifically to a method, system, electronic device, and storage medium for generating animal behavior events. Background Technology

[0002] Pet collars, tags, or harnesses typically collect three-axis acceleration and three-axis angular velocity data. Some devices also upload location information, battery level, temperature, sound summaries, or device status. Using this data to identify a pet's activity level is a common function in smart pet hardware.

[0003] Existing technologies often employ triaxial accelerometer, six-axis IMU, or multi-sensor data to identify pet movement patterns. These methods typically slice the raw data into sliding windows, extract features, or feed them into machine learning or deep learning models, ultimately outputting behavior categories such as "walking," "running," "sleeping," and "jumping." While this approach addresses the question of "what action does a particular segment of sensor data resemble," it doesn't adequately solve several more practical problems within product systems.

[0004] First, the output results are too close to the model layer. The window labels output by the model may change every few seconds. If the front-end directly consumes these labels, the page will show frequent jumps between resting, walking, lying down, and active states. For health analysis, fragmented labels are also not conducive to statistical analysis of sleep duration, active duration, or the number of abnormal behaviors.

[0005] Second, there is a lack of unified processing for low-quality windows. Real-world equipment may experience issues such as abnormal sampling intervals, short-term data loss, retransmissions, loose mounting, and strong impacts. If windows are not first marked with quality indicators, and all windows are directly handed over to the model or all model outputs are treated as valid conclusions, behavioral events are easily contaminated by low-quality data.

[0006] Third, there is insufficient traceability of results. Pet behavior results are displayed on the homepage status, health report, and alerts. If a user questions the results, the system needs to know which device the result was uploaded from, the sampling time, the model version, which windows, and which post-processing rules it came from. If algorithm execution records and source batch bindings are missing, this link is broken. Summary of the Invention

[0007] The purpose of this invention is to provide a method, system, electronic device, and storage medium for generating animal behavioral events by organizing the candidate judgments of a model for multiple windows into stable, displayable, analyzable, and verifiable behavioral events.

[0008] This invention is implemented as follows: A method for generating animal behavioral events includes the following steps: S1. Receive a batch of data uploaded by the wearable device, wherein the batch of data includes at least three-axis acceleration data and three-axis angular velocity data; S2. Create an algorithm execution log. The algorithm execution log should at least record the algorithm name, algorithm version, model version, pet identifier processed, source batch identifier, input time range, input water level, output water level, and execution parameters. S3. Preprocess and window segment the data batch to obtain multiple time windows. Each window is bound to a pet identifier, device identifier, source batch identifier, window start time, and window end time. S4. Perform quality judgment on the time window and generate a window quality mark; S5. Perform window-level model inference on the time window and output the candidate behavior label and confidence score for each time window; S6. Stabilize the corresponding time windows based on window quality markers, consistency of adjacent window labels, window duration, and confidence level to obtain behavior segments; S7. Generate structured behavior events based on the behavior segments. The behavior events include at least the behavior event identifier, pet identifier, device identifier, source batch identifier, algorithm running identifier, event start time, event end time, event type, action code, action name, action category, confidence level, and extended payload. S8. Bind the behavior event to both the data batch and the algorithm execution record. Use the source batch identifier to trace back to the original uploaded data and use the algorithm execution identifier to trace back to the algorithm version, model version, input time range, and execution parameters. S9. Update the front-end readable activity status or health analysis input based on the structured behavioral events.

[0009] Furthermore, the methods for generating window quality markers include: The missing rate quality score is calculated based on the proportion of missing data within the window. The timestamp continuity quality score is calculated based on the continuity of timestamps of adjacent sampling points within the window. The signal stability quality score is calculated based on the changes in acceleration modulus and angular velocity energy within the window. The mass score of the wearing state is calculated based on the stability of gravity direction within the window; The window quality score is obtained by weighted summing of the missing rate quality score, timestamp continuity quality score, signal stability quality score, and wearing status quality score. Where Q is the window quality score, is the missing rate score, and is the timestamp continuity quality score. The signal stability quality score is [value], and the wearing condition quality score is [value]. , , , These are the weighting coefficients.

[0010] Furthermore, the corresponding time window is stabilized to obtain the behavior segment. This can be achieved through at least one of the following methods: When adjacent windows have the same label and the time is consecutive, they are merged into the same line segment; If the duration of a time window is less than the preset short action confirmation time, and both the window before and after it is in a high-confidence stable state, then no independent behavioral event will be generated, and it will be incorporated into the stable segment before and after it. Long state transitions will only be performed after preset duration and confidence threshold conditions are met. Low-confidence time windows do not generate definite behavioral events; they are marked as pending review or saved only as extended information. Time windows with a quality score below a preset threshold are downweighted in segment-level confidence calculations.

[0011] Furthermore, the methods for calculating the segment-level confidence level within a time window include: ,in, This indicates the segment-level confidence level for a behavior segment to belong to category c. Let represent the model probability of the i-th window for class c. This represents the duration of the i-th window. This represents the quality score of the i-th window.

[0012] Furthermore, it also includes: When a device reconnects after going offline and retransmits historical data, a time window is constructed based on the sampling time. Create a new algorithm execution record for the batch of supplementary data transmission, with the input time range of the record being the historical sampling time range; The behavioral events generated by the retransmission data are bound to the retransmission batch through the data batch identifier, and to the corresponding processing record through the algorithm execution identifier.

[0013] Furthermore, when the model version is upgraded, window splitting, model inference, and behavior segment stabilization are re-executed for the same data batch or the same time range to generate new algorithm running records; The results of the new and old versions are distinguished by different algorithm identifiers, and the results of the old version are not overwritten.

[0014] An animal behavior event generation system, characterized in that it includes: a batch management module for receiving data batches uploaded by a wearable device, wherein the data batches include at least three-axis acceleration data and three-axis angular velocity data; The algorithm execution module is used to create algorithm execution records. The algorithm execution record should at least record the algorithm name, algorithm version, model version, pet identifier processed, source batch identifier, input time range, input water level, output water level, and execution parameters. The window construction module is used to preprocess the data batch and divide it into windows to obtain multiple time windows. Each window is bound to a pet identifier, a device identifier, a source batch identifier, a window start time, and a window end time. The window quality module is used to determine the quality of the time window and generate a window quality mark. The model inference module is used to perform window-level model inference on time windows and output the candidate behavior labels and confidence scores for each time window. The stabilization module is used to stabilize the corresponding time window based on the window quality label, the consistency of adjacent window labels, the window duration, and the confidence level, to obtain the behavior segment; The behavior event generation module is used to generate structured behavior events based on the behavior segments. The behavior events include at least the behavior event identifier, pet identifier, device identifier, source batch identifier, algorithm execution identifier, event start time, event end time, event type, action code, action name, action category, confidence level, and extended payload. The traceability module is used to simultaneously bind behavioral events to data batches and algorithm execution records. It traces back to the original uploaded data through the source batch identifier and traces back to the algorithm version, model version, input time range, and execution parameters through the algorithm execution identifier. The front-end service module is used to update the front-end readable activity status or health analysis input based on the structured behavioral events.

[0015] An electronic device, characterized in that it comprises: One or more processors; Storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the above-described method for generating animal behavior events.

[0016] A computer-readable storage medium having a computer program stored thereon, characterized in that the computer program, when executed by a processor, implements the above-described method for generating animal behavioral events.

[0017] A computer program product, comprising a computer program or computer-executable instructions, characterized in that, when the computer program or computer-executable instructions are executed by a processor, they implement the above-described method for generating animal behavioral events.

[0018] Compared with the prior art, the beneficial effects of the present invention are: This invention organizes the model's window-level output into continuous behavioral events, which can reduce short-term misjudgments and front-end state jitter, making the pet's state seen by the user closer to the actual activity process.

[0019] This invention incorporates quality judgment at the window level, which can reduce the impact of loose fitting, short-term impact, missing data, and abnormal retransmission on behavioral conclusions, and avoid low-quality windows directly generating definite events.

[0020] This invention preserves the association between behavioral events and algorithm execution records and uploaded batches. After a behavioral event enters health analysis or triggers an alarm, the system can still retrieve the input data range, model version, algorithm parameters, and source batch, facilitating interpretation, recalculation, and model iteration.

[0021] This invention decouples algorithm output from front-end display. The front-end reads stable activity states or behavioral events, without directly relying on window-level model results, resulting in lower system maintenance costs. Attached Figure Description

[0022] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained from these drawings without creative effort.

[0023] Figure 1 This is a flowchart of the method of the present invention; Figure 2 This is a schematic diagram of the system structure of the present invention; Figure 3 This is a diagram illustrating the conversion of window-level labels into action segments; Figure 4 This is a diagram illustrating the relationship between behavioral events; Figure 5 This is a diagram illustrating the handling of low confidence levels and abnormal wearing conditions. Detailed Implementation

[0024] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, not all of them. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to represent selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0025] Please see Figure 1 A method for generating animal behavioral events, comprising the following steps: S1. Receive a batch of data uploaded by the wearable device, wherein the batch of data includes at least three-axis acceleration data and three-axis angular velocity data; Specifically, a data batch can include a batch identifier, pet identifier, device identifier, data mode, sampling start time, sampling end time, reception time, processing status, and original payload location. The data mode can be triaxial acceleration data and triaxial angular velocity data, i.e., six-axis sequence data, or it can be mixed data containing triaxial acceleration data and triaxial angular velocity data with location, power, temperature, or other status.

[0026] The system receives triaxial acceleration data and triaxial angular velocity data, or mixed data, and parses it to identify the pet, device, sampling time, and data mode. It also generates a batch identifier for each upload and maintains processing statuses such as reception, parsing, algorithm execution, completion, and failure.

[0027] S2. Create an algorithm execution log. The algorithm execution log should at least record the algorithm name, algorithm version, model version, pet identifier processed, source batch identifier, input time range, input water level, output water level, and execution parameters. Specifically, before processing the data batch, the cloud generates an algorithm execution record. This record saves the algorithm name, algorithm version, model version, pets processed, source batch, input time range, input water level, output water level, running parameters, algorithm execution identifier, error messages, start time, end time, and running status. Subsequent generated behavioral events can be traced back through this record to review the algorithm processing.

[0028] The system creates an operation record before each processing and writes the output water level, operation indicators and error information after the processing is completed.

[0029] S3. Preprocess and window segment the data batch to obtain multiple time windows. Each window is bound to a pet identifier, device identifier, source batch identifier, window start time, and window end time. Specifically, the data batches are sorted according to their sampling time, and missing points, time reversal, inconsistent sampling rates, and abnormal peaks are checked. Then, the continuous six-axis sequence in the data batch is divided into multiple windows according to the preset window length and overlap ratio. Each window is bound to a pet identifier, device identifier, upload batch, window start time, and window end time.

[0030] S4. Perform quality judgment on the time window and generate a window quality mark; Furthermore, the methods for generating window quality markers include: The missing rate quality score is calculated based on the proportion of missing data within the window. The timestamp continuity quality score is calculated based on the continuity of timestamps of adjacent sampling points within the window. The signal stability quality score is calculated based on the changes in acceleration modulus and angular velocity energy within the window. The mass score of the wearing state is calculated based on the stability of gravity direction within the window; The window quality score is obtained by weighted summing of the missing rate quality score, timestamp continuity quality score, signal stability quality score, and wearing status quality score. ; Where Q is the window quality score, The missing rate score, The quality score is the continuity score of the timestamp. The signal stability quality score. The quality score is based on the wearing condition. , , , These are the weighting coefficients. Each weight can be adjusted based on the device type, sampling rate, and model version.

[0031] Specifically, the system judges the quality of a window based on factors such as timestamp continuity, missing proportion, acceleration modulus variation, angular velocity energy, and stability of gravity direction during stationary periods. For windows that may have issues such as loose fitting, short-term detachment, strong impact, or abnormal retransmission, the system can reduce their weight or mark them as pending review.

[0032] When the device becomes loose or falls off briefly, the sensor signal may exhibit the following characteristics: a significant change in the direction of gravity within a short period of time, an abnormal peak in angular velocity (e.g., exceeding 15 rad / s), a significant increase in the deviation of the acceleration modulus from 1g, and uneven timestamp intervals.

[0033] The system comprehensively evaluates each window using a window quality score Q: , in: This is a quality score related to the missing data rate, calculated based on the proportion of missing data within the window. If the missing data rate is ≥30%,... Assign a value of 0; if the missing percentage is ≤5%, Assign a value of 1; use linear interpolation for intermediate values.

[0034] The timestamp continuity quality score is calculated based on the standard deviation of the time interval between adjacent sampling points. If time reversal exists or the interval exceeds three times the sampling period, reduce.

[0035] The sensor signal stability quality score is calculated based on the standard deviation of the acceleration modulus and the angular velocity energy. If the standard deviation of the acceleration modulus is ≥2g or the angular velocity energy is ≥300 rad² / s², reduce.

[0036] The mass score is calculated based on the degree of change in the direction of gravity within a window. If the change in the direction of gravity exceeds 30°, reduce.

[0037] Weighting coefficient , , , Adjustments can be made based on device type, sampling rate, and model version. For example, the wearing stability of a collar device is lower than that of a chest / back device. (Wearing status weight) can be appropriately increased.

[0038] Based on at least one of the following factors: species, body size, wearing position and device form, differentiate configuration of at least one parameter of window length, behavior segment confirmation time, state switching hysteresis time and confidence threshold; The parameters of the differentiated configuration are recorded in the algorithm execution log.

[0039] There are significant differences in the movement patterns of cats and dogs: cats' jumping, grooming, and scratching are usually shorter (each action lasts a few seconds), while dogs' walking, running, and outdoor activities last longer (on the order of minutes). The same behavioral event generation logic can be reused for both cats and dogs, but the parameter thresholds need to be automatically adjusted according to the species, as shown in Table 1.

[0040] Table 1. System parameter sets configured differently for cats and dogs. Within the same species, body size (small vs. large) and wearing position (collar vs. harness vs. tag) can also affect signal characteristics. For example, harnesses are more secure than collars, and the weighting coefficient for window quality scores is higher. (Wearing status weight) can be adjusted accordingly.

[0041] All differentiated parameters are saved during algorithm execution. When a user questions a particular behavior event, the reviewer can use the algorithm execution identifier to query the species parameters, body size parameters, and wearing position parameters used in that processing to confirm whether the parameter selection was reasonable.

[0042] S5. Perform window-level model inference on the time window and output the candidate behavior label and confidence score for each time window; Furthermore, the methods for calculating segment-level confidence include: ,in, This indicates the segment-level confidence level for a behavior segment to belong to category c. Let represent the model probability of the i-th window for class c. This represents the duration of the i-th window. This represents the quality score of the i-th window.

[0043] Specifically, it reads a windowed six-axis sequence and, by combining information such as species, body size, and wearing location, outputs candidate behavior labels, probability distributions, and confidence levels. This output serves only as a candidate result and is not directly written to the front-end state.

[0044] Behavioral tags can be divided into algorithmic tags and display tags. Algorithmic tags are geared towards models and health analysis, such as low activity, walking, running, jumping, scratching, grooming, eating, drinking, sleeping, abnormal stillness, abnormal wearing, and pending verification. Display tags are geared towards the front end, such as resting, active, sleeping, potentially abnormal, and abnormal device status.

[0045] Cats and dogs can use the same event structure, but the parameters do not need to be exactly the same. Cats' jumps, grooming, and scratching are usually shorter, while dogs' walking, running, and outdoor activities may last longer. The system can adjust the threshold based on species, body size, wearing position, and device type, and record these parameters in the algorithm's runtime log.

[0046] S6. Stabilize the corresponding time windows based on window quality markers, consistency of adjacent window labels, window duration, and confidence level to obtain behavior segments; Furthermore, the corresponding time window is stabilized to obtain the behavior segment. This can be achieved through at least one of the following methods: When adjacent windows have the same label and the time is consecutive, they are merged into the same line segment; For details, please refer to Figure 3 Taking cats and dogs wearing wearable devices for nighttime sleep monitoring as an example, this paper explains how the system handles window-level label fluctuations caused by short-term posture adjustments during sleep.

[0047] When the pet enters a sleep state at night, the overall change in the six-axis inertial signal is relatively small, with the acceleration modulus approaching 1g and the angular velocity energy remaining at a low level. The system continuously segments and infers the six-axis sequence using a sliding window method (e.g., window length of 5 seconds, overlap ratio of 50%), outputting window-level candidate labels. Most windows are labeled "sleep" or "resting," with high confidence levels.

[0048] If the duration of a time window is less than the preset short action confirmation time, and both the window before and after it is in a high-confidence stable state, then no independent behavioral event will be generated, and it will be incorporated into the stable segment before and after it. Specifically, when a pet rolls over during sleep, its angular velocity and acceleration will briefly increase within several consecutive windows. The model may output candidate labels such as "active," "rolling over," or "uncertain." If the front-end state is updated directly with window-level labels, the sleep segment will be frequently interrupted into multiple short segments on the app, affecting user experience and the accuracy of sleep duration statistics.

[0049] The stabilization module handles this situation as follows: First, a window sequence is detected where the current candidate label is inconsistent with the previous stable behavior segment (sleep segment).

[0050] Secondly, check the duration of the short abnormal segment. If it is less than the preset short action confirmation time (e.g., 20 seconds) and both the preceding and following windows are high-confidence sleep or resting windows (confidence ≥ 0.85), the system will not identify the segment as an independent behavioral event.

[0051] Finally, the system merges the abnormal windows into the preceding and following sleep segments to maintain the continuity of sleep behavior events. At the same time, it records the time period, number of windows, and peak average angular velocity in the "Internal Attitude Adjustment Record" field of the sleep event extended load for subsequent verification.

[0052] If the abnormal window caused by turning over lasts for more than a preset threshold, or is accompanied by a high acceleration peak (e.g., exceeding 3g), the system will determine it as "awakening" or "abnormal activity", and will terminate the current sleep event accordingly and generate a new behavioral event.

[0053] Application of the segment-level confidence calculation formula in this embodiment: If the window quality score of the turning-over window is low, its impact on the segment-level confidence is further weakened, which helps to maintain a high confidence judgment of the sleep segment.

[0054] Long state transitions will only be performed after preset duration and confidence threshold conditions are met. Specifically, taking the example of a pet suddenly stopping after running, we can illustrate the role of the state transition delay mechanism in the stabilization of behavioral events.

[0055] When the pet continues to run, the system generates a "fast running" behavior event, and its start time, end time, average confidence score, and window quality summary are all written to the behavior event record. After the pet suddenly stops, the window-level model may output labels such as "running," "walking," "standing," and "low activity" in several subsequent windows, with rapid transitions between these labels.

[0056] The system processes this scenario according to the following rules: First, calculate the segment-level confidence of the candidate behavior segments. For "low activity" candidate segments, the system accumulates the windows that are continuously judged as low activity and calculates P_s(low activity). Only when the cumulative duration reaches a preset switching threshold (e.g., 30 seconds) and the segment-level confidence P_s(low activity) ≥ 0.80, does the system meet the condition for ending the running event.

[0057] Second, before the switching conditions are met, the system maintains the current "running" behavior event unchanged, and the front-end activity state remains "running", to avoid the state from jumping to "walking", "standing" and "resting" in a few seconds.

[0058] Third, when the low-activity window lasts for a sufficient period of time and reaches the confidence requirement, the system ends the running event (writes the end time), generates a new "low-activity" or "dormant" behavior event, and writes the switching record into the event extended payload, including: a summary of the window label sequence before the switch, the average probability of each candidate label, and the actual switching delay time.

[0059] Fourth, if the quality of the pause window after running is low (e.g., signal abnormality caused by loose device wearing), the low-quality window will be downweighted in the segment-level confidence calculation, which may require a longer confirmation time to trigger the state switch, thereby avoiding false switches caused by wearing abnormalities.

[0060] Low-confidence time windows do not generate definite behavioral events; they are marked as pending review or saved only as extended information. Specifically, taking cat scratching behavior as an example, this illustrates the process of identifying short-term, repetitive abnormal behaviors, generating events, and integrating them with health analysis.

[0061] The scratching behavior manifests in the six-axis signal as strong local angular velocity changes and periodic acceleration changes within multiple short windows. The system processes this behavior using the following steps:

[0062] Step 1: Window Segmentation and Model Inference. The system segments the six-axis sequence into short windows (e.g., window length 2 seconds, overlap ratio 50%). The model outputs candidate labels and probability distributions for each window. When the probability of scratching candidate labels for multiple consecutive windows exceeds a preset threshold (e.g., P_i(scratching) ≥ 0.70) and the window quality score Qi ≥ 0.60, the system marks these windows as scratching candidate segments.

[0063] Step 2: Behavior Segment Stabilization. The system merges adjacent crawling candidate windows according to temporal continuity and calculates the segment-level confidence of the crawling behavior segment:

[0064] when When the (scratching) value is ≥0.75 and the scratching segment duration is between 2 and 30 seconds, the system generates a scratching behavior event.

[0065] Step 3: Write the structured behavior event. The scratching behavior event record includes: behavior event identifier, pet identifier, device identifier, source batch identifier, algorithm execution identifier, event start time, end time, event type ("behavior"), action code (e.g., "SCRATCH"), action name ("scratching"), action category ("abnormal behavior"), intensity (calculated based on peak angular velocity, normalized to the 0~1 range), confidence level (P_s(scratching)), and extended load.

[0066] The extended payload includes: number of windows, average window confidence, peak confidence, triggering rules (e.g., "5 consecutive windows with a scratch probability ≥ 0.70 and a segment-level confidence ≥ 0.75"), and window quality summaries (for each window). (mean and minimum value).

[0067] Step 4: Health Analysis Integration. If the frequency of scratching events exceeds a threshold (e.g., cat ≥ 10 times / hour) within a preset time window (e.g., 24 hours), the system sends an alert signal to the alarm module. The health analysis module traces back to the input data range and model version through the algorithm execution identifier associated with the scratching events, and triggers an alarm only after confirming the reliability of the results.

[0068] Please see Figure 5 Time windows with a quality score below a preset threshold are downweighted in segment-level confidence calculations.

[0069] Specifically, when the window quality score Q ≤ 0.40, the system marks the window as "abnormal wearing" or "data unreliable". Windows judged as abnormal wearing are handled as follows:

[0070] In window-level model inference, the output probabilities of these windows are downweighted in segment-level confidence calculation (the influence of the window quality score is reduced after being substituted into the formula).

[0071] It will not directly generate specific behavioral events such as "running" or "jumping" based solely on these windows.

[0072] If multiple windows are judged to be worn abnormally, the system generates an "Abnormal Device Wearing" or "Data Pending Verification" event, which is displayed on the front end as "Device status abnormal, please check wearing".

[0073] The original data and quality markers of the exception window are preserved in the algorithm running record, which facilitates subsequent review and parameter tuning.

[0074] S7. Generate structured behavior events based on the behavior segments. The behavior events include at least the behavior event identifier, pet identifier, device identifier, source batch identifier, algorithm running identifier, event start time, event end time, event type, action code, action name, action category, confidence level, and extended payload. Specifically, the extended payload can record the number of windows, average confidence, proportion of low-confidence windows, merged short segments, window quality summary, and triggering rules.

[0075] S8. Bind the behavior event to both the data batch and the algorithm execution record. Use the source batch identifier of the data batch to trace back to the original uploaded data, and use the algorithm execution identifier of the algorithm execution record to trace back to the algorithm version, model version, input time range, and execution parameters. For details, please refer to Figure 4 The system updates the pet's latest activity status or page snapshot based on stable behavioral events. The front end reads the stabilized activity status or behavioral event details, rather than the model's real-time output to a single window. If subsequent recalculation, interpretation, or comparison of results from different model versions is needed, this process can be followed.

[0076] S9. Update the front-end readable activity status or health analysis input based on the structured behavioral events.

[0077] Specifically, the activity status that can be read by the front end is stored and provided in the form of activity status snapshots. The activity status snapshots include at least: pet identifier, latest sampling time, latest behavior update time, activity status, health risk level, displayed extended information, snapshot generation time and update time.

[0078] After a behavioral event is generated, the service layer updates the pet's activity status snapshot based on the most recent stable events. As shown in Table 2, the activity status snapshot includes the following fields:

[0079] Table 2. Relationship between Activity Status Snapshot Fields and Descriptions The mapping relationship between front-end activity states and behavior event types is as follows: The activity status is "sleep" when the most recent behavioral event is "sleep" or "resting" and lasts for more than 30 minutes.

[0080] When the most recent behavioral event is "walking", "running", or "jumping", the activity status is "active".

[0081] When the most recent behavioral event is "low activity", the activity status is "resting".

[0082] When the most recent behavioral event is "abnormal wearing" or the segment-level confidence level P_s < 0.50, the activity status is "status pending confirmation" or "device status abnormal".

[0083] If an abnormal frequency of "scratching" or "abnormal stillness" is detected in recent behavioral events, the health risk level will be adjusted accordingly.

[0084] The front-end app reads activity state snapshots via API, no longer directly accessing raw sampling points or window-level model output. This design decouples the front-end display logic from the internal algorithm implementation. The front-end doesn't need to understand post-processing details such as window merging, delayed confirmation, and confidence calculation; it only consumes the stabilized, structured results. When algorithm parameters or model versions are adjusted, as long as the behavioral event output format remains consistent, the front-end code does not need to be modified synchronously, reducing system maintenance costs.

[0085] Query pet behavior event records within a preset time range; The daily aggregated statistics are generated by accumulating statistics based on event type and action category. Daily aggregated statistics are used for health trend analysis and anomaly alerts.

[0086] Every day at midnight (e.g., 00:30), the system triggers a daily aggregation task to collect the previous day's behavioral event records for each pet and generate daily aggregated statistics.

[0087] The daily aggregation task executes the following steps: Step 1: Query the time range. Determine the statistical time range (00:00:00 to 23:59:59 of the previous day), and query all behavioral events of the pet within this range.

[0088] Step Two: Itemized Statistics. Statistics are compiled separately according to event type and action category:

[0089] Total sleep duration: The sum of the total duration of all “sleep” type events.

[0090] Total active duration: The sum of the durations of "walking", "running", and "jumping" events.

[0091] Total duration of low activity: The sum of the durations of "low activity" and "lying down" events.

[0092] Scratching count: Counts the number of times the "scratching" event is triggered.

[0093] Jump count: Counts the number of times the "jump" event is triggered.

[0094] Abnormal stillness period: Statistics on the time period and duration of "abnormal stillness" events.

[0095] Low activity periods: Statistics on the distribution of start and end times of "low activity" events.

[0096] Step 3: Confidence Level Screening. During statistical analysis, only behavioral events with a segment-level confidence level P_s ≥ 0.60 are included. Events with confidence levels below this threshold are only recorded in the extended loads and are not included in the calculation of the main statistics for health trend analysis.

[0097] Step 4: Write the daily aggregation record. The daily aggregation record includes the pet identifier, the statistical date, the statistical values ​​of each sub-item, the number of events participating in the statistics, the number of low-confidence excluded events, and a list of associated algorithm running identifiers (used to trace which algorithm versions generated the events participating in the statistics).

[0098] Step 5: Health Trend Analysis. The health analysis module reads multi-day aggregated records and generates sleep duration trend charts, activity level change trends, and abnormal behavior frequency change curves, which are available for viewing in the user's app. When data anomalies occur on a particular day (such as a sudden 50% reduction in sleep duration), the analysis module can initiate an alarm and trace back to the original data through the algorithm execution identifier associated with the daily aggregated records to verify whether the cause is a change in behavior or an adjustment of algorithm parameters.

[0099] Also includes: When a device reconnects after going offline and retransmits historical data, a time window is constructed based on the sampling time. Create a new algorithm execution record for the batch of supplementary data transmission, with the input time range of the record being the historical sampling time range; The behavioral events generated by the retransmission data are bound to the retransmission batch through the data batch identifier, and to the corresponding processing record through the algorithm execution identifier.

[0100] Comparing old and new results can be achieved by querying all algorithm execution records associated with the same batch from the same source, grouping them by algorithm version and model version, compiling lists of behavioral events generated by each version, and comparing the differences in event types, durations, and confidence levels within the same time range. Results from older versions will not be overwritten, and changes in performance can be retrospectively evaluated after model iterations.

[0101] When the model version is upgraded, window splitting, model inference and behavior segment stabilization are re-executed for the same data batch or the same time range to generate new algorithm running records; The results of the new and old versions are distinguished by different algorithm identifiers, and the results of the old version are not overwritten.

[0102] Specifically, taking the restoration of connection and retransmission of historical six-axis sequence data after the device goes offline as an example, this explains how the system handles non-real-time data batches, supports recalculation after model version upgrades, and maintains the distinguishability between results of different versions.

[0103] If a pet wearing a device regains network connectivity after several hours in areas with poor signal coverage (such as underground parking garages or remote outdoor areas), it may need to re-transmit several hours of historical six-axis data at once. The system will process this according to the following procedure:

[0104] Step 1: Data Reception and Batch Creation. The access layer receives the retransmitted data batch, parses the pet identifier, device identifier, data modality, and sampling time range (sampling start time and sampling end time), generates an upload batch identifier, and saves the original payload to the storage system. Unlike real-time data, the data reception time for offline retransmitted batches may be much later than the sampling end time, but the system uses the sampling time rather than the reception time to construct subsequent windows.

[0105] Step 2: Create an algorithm execution record. Before processing the retransmission batch, the algorithm layer creates an algorithm execution record, which includes: algorithm execution identifier, algorithm name and version, model version, pet identifier, source batch identifier, input time range (from the start to the end of sampling), input water level and output water level (used for incremental processing and breakpoint continuation calculation), and running parameters (window length, overlap ratio, various thresholds, etc.).

[0106] Step 3: Window Construction and Model Inference. The system sorts and preprocesses historical data according to sampling time, then segments the data into windows based on preset window length and overlap ratio. Window segmentation is independent of data reception time, ensuring the temporal consistency of historical data. Model inference outputs candidate labels and confidence scores for each window.

[0107] Step 4: Behavior segment stabilization and event generation. Similar to the real-time data processing flow, the system generates structured behavior events after stabilizing the window-level candidate results through behavior segments. The behavior events are bound to the source batch identifier of the retransmission batch and the algorithm execution identifier of this current run.

[0108] Step 5: Recalculation after Model Version Upgrade. If the system subsequently upgrades the model version and it is necessary to regenerate behavioral results for comparison based on historical data within the same time range, the administrator can initiate a recalculation task. The system will re-execute steps two through four for the same batch from the same source (or the same pet, within the same time range), but will generate new algorithm execution records (new algorithm execution identifiers). Both the old and new version results will be retained and distinguished by different algorithm execution identifiers.

[0109] Please see Figure 2 An animal behavior event generation system includes: a batch management module for receiving data batches uploaded by a wearable device, wherein the data batches include at least three-axis acceleration data and three-axis angular velocity data; The algorithm execution module is used to create algorithm execution records. The algorithm execution record should at least record the algorithm name, algorithm version, model version, pet identifier processed, source batch identifier, input time range, input water level, output water level, and execution parameters. The window construction module is used to preprocess the data batch and divide it into windows to obtain multiple time windows. Each window is bound to a pet identifier, a device identifier, a source batch identifier, a window start time, and a window end time. The window quality module is used to determine the quality of the time window and generate a window quality mark. The model inference module is used to perform window-level model inference on time windows and output the candidate behavior labels and confidence scores for each time window. The stabilization module is used to stabilize the corresponding time window based on the window quality label, the consistency of adjacent window labels, the window duration, and the confidence level, to obtain the behavior segment; The behavior event generation module is used to generate structured behavior events based on the behavior segments. The behavior events include at least the behavior event identifier, pet identifier, device identifier, source batch identifier, algorithm execution identifier, event start time, event end time, event type, action code, action name, action category, confidence level, and extended payload. The traceability module is used to simultaneously bind behavioral events to data batches and algorithm execution records. It traces back to the original uploaded data through the source batch identifier and traces back to the algorithm version, model version, input time range, and execution parameters through the algorithm execution identifier. The front-end service module is used to update the front-end readable activity status or health analysis input based on the structured behavioral events.

[0110] An electronic device includes: one or more processors; a storage device for storing one or more programs; and when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the above-described method for generating animal behavior events.

[0111] A computer-readable storage medium having a computer program stored thereon, characterized in that the computer program, when executed by a processor, implements the above-described method for generating animal behavioral events.

[0112] A computer program product includes a computer program or computer-executable instructions, which, when executed by a processor, implement the above-described method for generating animal behavioral events.

[0113] The model inference of this invention can be deployed in the cloud, on a device, or at an edge gateway. If the device has already output window-level candidate labels and confidence scores, the cloud can still perform behavior segment stabilization, behavior event generation, and traceability recording.

[0114] The system of this invention can also access data such as location, sound, temperature, or heart rate. These data are not necessary for generating behavioral events, but can serve as auxiliary indicators. For example, when walking events coincide with changes in location trajectory, the credibility of the activity status can be improved; when scratching events occur simultaneously with increased frequency at night, they can serve as evidence for health analysis.

[0115] Different device types can use different parameters. The wearing stability of collars, tags, and chest / back devices varies, and the window quality and behavior segment stabilization parameters can also differ. Parameters are recorded and saved during algorithm execution for subsequent verification.

[0116] Behavioral events can also be included in the daily aggregation process. The system can collect statistics on daily sleep duration, active duration, scratching frequency, jumping frequency, periods of low activity, and abnormal inactivity periods for use in health trend analysis.

[0117] Compared with the prior art, the present invention has the following beneficial effects: This invention organizes the model's window-level output into continuous behavioral events, which can reduce short-term misjudgments and front-end state jitter, making the pet's state seen by the user closer to the actual activity process.

[0118] This invention incorporates quality judgment at the window level, which can reduce the impact of loose fitting, short-term impact, missing data, and abnormal retransmission on behavioral conclusions, and avoid low-quality windows directly generating definite events.

[0119] This invention preserves the association between behavioral events and algorithm execution records and uploaded batches. After a behavioral event enters health analysis or triggers an alarm, the system can still retrieve the input data range, model version, algorithm parameters, and source batch, facilitating interpretation, recalculation, and model iteration.

[0120] This invention decouples algorithm output from front-end display. The front-end reads stable activity states or behavioral events, without directly relying on window-level model results, resulting in lower system maintenance costs.

[0121] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the invention by those skilled in the art. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the invention should be included within the scope of protection of the invention.

Claims

1. A method for generating animal behavioral events, characterized in that: Includes the following steps: S1. Receive a batch of data uploaded by the wearable device, wherein the batch of data includes at least three-axis acceleration data and three-axis angular velocity data; S2. Create an algorithm execution log. The algorithm execution log should at least record the algorithm name, algorithm version, model version, pet identifier processed, source batch identifier, input time range, input water level, output water level, and execution parameters. S3. Preprocess and window segment the data batch to obtain multiple time windows. Each window is bound to a pet identifier, device identifier, source batch identifier, window start time, and window end time. S4. Perform quality judgment on the time window and generate a window quality mark; S5. Perform window-level model inference on the time window and output the candidate behavior label and confidence score for each time window; S6. Stabilize the corresponding time windows based on window quality markers, consistency of adjacent window labels, window duration, and confidence level to obtain behavior segments; S7. Generate structured behavior events based on the behavior segments. The behavior events include at least the behavior event identifier, pet identifier, device identifier, source batch identifier, algorithm running identifier, event start time, event end time, event type, action code, action name, action category, confidence level, and extended payload. S8. Bind the behavior event to both the data batch and the algorithm execution record. Use the source batch identifier to trace back to the original uploaded data and use the algorithm execution identifier to trace back to the algorithm version, model version, input time range, and execution parameters. S9. Update the front-end readable activity status or health analysis input based on the structured behavioral events.

2. The method for generating animal behavioral events according to claim 1, characterized in that, Methods for generating window quality markers include: The missing rate quality score is calculated based on the proportion of missing data within the window. The timestamp continuity quality score is calculated based on the continuity of timestamps of adjacent sampling points within the window. The signal stability quality score is calculated based on the changes in acceleration modulus and angular velocity energy within the window. The mass score of the wearing state is calculated based on the stability of gravity direction within the window; The window quality score is obtained by weighted summing of the missing rate quality score, timestamp continuity quality score, signal stability quality score, and wearing status quality score. Where Q is the window quality score, is the missing rate score, and is the timestamp continuity quality score. The signal stability quality score is [value], and the wearing condition quality score is [value]. , , , These are the weighting coefficients.

3. The method for generating animal behavioral events according to claim 1, characterized in that, The methods for stabilizing the corresponding time window to obtain the behavior segment include at least one of the following: When adjacent windows have the same label and the time is consecutive, they are merged into the same line segment; If the duration of a time window is less than the preset short action confirmation time, and both the window before and after it is in a high-confidence stable state, then no independent behavioral event will be generated, and it will be incorporated into the stable segment before and after it. Long state transitions will only be performed after preset duration and confidence threshold conditions are met. Low-confidence time windows do not generate definite behavioral events; they are marked as pending review or saved only as extended information. Time windows with a quality score below a preset threshold are downweighted in segment-level confidence calculations.

4. The method for generating animal behavioral events according to claim 3, characterized in that, Methods for calculating segment-level confidence scores within a time window include: ,in, This indicates the segment-level confidence level for a behavior segment to belong to category c. Let represent the model probability of the i-th window for class c. This represents the duration of the i-th window. This represents the quality score of the i-th window.

5. The method for generating animal behavioral events according to claim 1, characterized in that, Also includes: When a device reconnects after going offline and retransmits historical data, a time window is constructed based on the sampling time. Create a new algorithm execution record for the batch of supplementary data transmission, with the input time range of the record being the historical sampling time range; The behavioral events generated by the retransmission data are bound to the retransmission batch through the data batch identifier, and to the corresponding processing record through the algorithm execution identifier.

6. The method for generating animal behavioral events according to claim 5, characterized in that, When the model version is upgraded, window splitting, model inference and behavior segment stabilization are re-executed for the same data batch or the same time range to generate new algorithm running records; The results of the new and old versions are distinguished by different algorithm identifiers, and the results of the old version are not overwritten.

7. An animal behavior event generation system, characterized in that, include: The batch management module is used to receive data batches uploaded by wearable devices, wherein the data batches include at least three-axis acceleration data and three-axis angular velocity data; The algorithm execution module is used to create algorithm execution records. The algorithm execution record should at least record the algorithm name, algorithm version, model version, pet identifier processed, source batch identifier, input time range, input water level, output water level, and execution parameters. The window construction module is used to preprocess the data batch and divide it into windows to obtain multiple time windows. Each window is bound to a pet identifier, a device identifier, a source batch identifier, a window start time, and a window end time. The window quality module is used to determine the quality of the time window and generate a window quality mark. The model inference module is used to perform window-level model inference on time windows and output the candidate behavior labels and confidence scores for each time window. The stabilization module is used to stabilize the corresponding time window based on the window quality label, the consistency of adjacent window labels, the window duration, and the confidence level, to obtain the behavior segment; The behavior event generation module is used to generate structured behavior events based on the behavior segments. The behavior events include at least the behavior event identifier, pet identifier, device identifier, source batch identifier, algorithm execution identifier, event start time, event end time, event type, action code, action name, action category, confidence level, and extended payload. The traceability module is used to simultaneously bind behavioral events to data batches and algorithm execution records. It traces back to the original uploaded data through the source batch identifier and traces back to the algorithm version, model version, input time range, and execution parameters through the algorithm execution identifier. The front-end service module is used to update the front-end readable activity status or health analysis input based on the structured behavioral events.

8. An electronic device, characterized in that, include: One or more processors; Storage device for storing one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the animal behavior event generation method as described in any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method for generating animal behavioral events as described in any one of claims 1 to 6.

10. A computer program product comprising a computer program or computer-executable instructions, characterized in that, When the computer program or computer-executable instructions are executed by a processor, the method for generating animal behavioral events as described in any one of claims 1 to 6 is implemented.

Images