Data processing method for cooperative task, service device and storage medium

Abstract

This application provides a data processing method, service device, and storage medium for collaborative tasks. The method includes: clustering reported data from multiple drones to obtain clusters of collaborative tasks; integrating the clusters to obtain event data for the collaborative tasks; determining the event risk level of the collaborative tasks based on the event data; if the event risk level is greater than or equal to an alarm level threshold, determining and sending first information to a master control device based on the event risk level; and determining and sending second information to a slave control device based on the event risk level. Using embodiments of this application can reduce the consumption of computing resources.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to data processing methods, service devices, and storage media for collaborative tasks. Background Technology

[0002] In scenarios such as search and rescue, inspection, security, and emergency response, multiple drones are typically used to perform collaborative tasks. Each drone detects targets during its mission and reports the detection data to the system. Because multiple drones may repeatedly detect the same target from different perspectives, current systems usually process the data reported by each drone separately. This results in data from the same event being processed multiple times, leading to a waste of computing resources. Summary of the Invention

[0003] This application provides a data processing method, service equipment, and storage medium for collaborative tasks, aiming to reduce the consumption of computing resources.

[0004] Firstly, a data processing method for collaborative tasks is provided, including: Clustering is performed on the data reported from multiple drones to obtain clusters of collaborative tasks; The clusters are integrated to obtain the event data of the collaborative task; Based on the event data, determine the event risk level of the collaborative task; If the event risk level is greater than or equal to the alarm level threshold, then based on the event risk level, a first message to be sent to the master control device and a second message to be sent to the slave control device are determined; based on the event risk level, a second message to be sent to the slave control device and a second message to be sent to the slave control device are determined.

[0005] In this technical solution, data is clustered first and then processed, avoiding the need to process multiple data points of the same event separately, thus reducing the consumption of computing resources. In addition, data integration of clusters allows multiple original reported data points within a cluster to be extracted into a representative data point, eliminating the need to process all the original data within the cluster, further reducing the consumption of computing resources. Furthermore, when the event risk level is greater than or equal to the alarm level threshold, the first information to be sent to the master control device and the second information to be sent to the slave control device are determined based on the same event risk level, enabling the master control device and the slave control device to obtain information content that matches their respective roles, thereby improving the handling efficiency of different roles in collaborative tasks.

[0006] In conjunction with the first aspect, in one possible implementation, the reported data includes a first target category, timestamp, world coordinates, and identification confidence level; The clustering process of reported data from multiple drones to obtain clusters of collaborative tasks includes: Obtain the task context information of the collaborative task, which includes the task start and end time, area boundary, and second target category; Based on the first target category, the timestamp, the world coordinates, the identification confidence level, the task start and end time, the region boundary, and the second target category, clustering processing is performed on the reported data from multiple drones to obtain clusters of collaborative tasks.

[0007] In conjunction with the first aspect, in one possible implementation, the clustering process performed on the reported data from multiple drones based on the first target category, the timestamp, the world coordinates, the identification confidence level, the task start and end times, the region boundary, and the second target category to obtain clusters includes: The target time period for executing the collaborative task is determined based on the task start and end time; from the reported data from multiple drones, the reported data whose timestamps fall within the target time period are determined, resulting in N reported data, where N is a positive integer; The target space domain in which the collaborative task is performed is determined based on the region boundary; from the N reported data, the reported data in which the world coordinates are located in the target space domain is determined, and M reported data are obtained, where M≤N; From the M reported data, determine the reported data whose first target category and second target category are consistent, and obtain K reported data, where K≤M; From the K reported data, the reported data whose difference between the identification confidence level and the confidence level threshold is greater than or equal to a preset threshold are filtered out to obtain the cluster of the collaborative task.

[0008] In conjunction with the first aspect, in one possible implementation, the reported data includes screenshot indexes and video indexes; The process of integrating the data from the clusters to obtain the event data for the collaborative task includes: Obtain the first screenshot corresponding to the screenshot index included in the first reported data, wherein the first reported data is the reported data with the highest identification confidence in the cluster; Obtain the second screenshot corresponding to the screenshot index included in the second reported data, wherein the second reported data is the reported data in the cluster that meets the preset viewpoint conditions; Obtain the video file corresponding to the video index included in the reported data of the cluster; determine the target video file based on the obtained video file; The event data is generated based on the drone identifier corresponding to the cluster, the third target category corresponding to the cluster, the target recognition confidence level corresponding to the cluster, the first screenshot, the second screenshot, and the target video file.

[0009] In conjunction with the first aspect, in one possible implementation, determining the event risk level of the collaborative task based on the event data includes: The event data is analyzed to obtain the third target category, the target identification confidence level, and the target features, wherein the target features include the features of the target to be identified by the collaborative task that match the preset risk concern conditions; The event risk level is determined based on the third target category, the target identification confidence level, and the target characteristics.

[0010] In conjunction with the first aspect, in one possible implementation, determining the event risk level based on the target category, the target identification confidence level, and the target features includes: Based on the third target category, the target identification confidence level, and the target characteristics, the basic risk level corresponding to the event data is determined; Obtain historical events associated with the event data, and determine the risk correlation degree corresponding to the event data based on the historical events; The basic risk level is modified based on the risk correlation to obtain the event risk level.

[0011] In conjunction with the first aspect, in one possible implementation, determining the first information to be sent to the main control device based on the event risk level includes: If the event risk level is the first risk level, then the first information is determined to include strong alarm information, handling suggestion information and confirmation entry information. The confirmation entry information is used for the main control device to perform a confirmation operation on the event data. The handling suggestion information is determined based on the third target category and target characteristics corresponding to the event data. If the event risk level is the second risk level, then the first information is determined to include weak prompt information, and the second risk level is lower than the first risk level.

[0012] In conjunction with the first aspect, in one possible implementation, determining the second information to be sent to the slave device based on the event risk level includes: If the event risk level is the first risk level, then the second information is determined to include the event data, timeline information, and supplementary record entry information. The supplementary record entry information is used for the slave device to perform supplementary record operations on the event data. If the event risk level is the second risk level, then the second information is determined to include weak prompt information.

[0013] Secondly, a data processing device for collaborative tasks is provided, comprising: The clustering module is used to cluster data reported from multiple drones to obtain clusters of collaborative tasks. An integration module is used to integrate the data of the clusters to obtain the event data of the collaborative task; The determination module is used to determine the event risk level of the collaborative task based on the event data; The communication processing module is configured to, if the event risk level is greater than or equal to the alarm level threshold, determine, based on the event risk level, to send a first message to the master control device and to send the first message to the master control device; and to determine, based on the event risk level, to send a second message to the slave control device and to send the second message to the slave control device.

[0014] Thirdly, a service device is provided, including a memory and a processor, the memory being connected to the processor, the processor being configured to execute one or more computer programs stored in the memory, wherein, when executing the one or more computer programs, the processor causes the service device to perform the data processing method for the cooperative task described in the first aspect.

[0015] Fourthly, a computer-readable storage medium is provided, which stores a computer program, the computer program including program instructions, which, when executed by a processor, cause the processor to perform the data processing method of the cooperative task of the first aspect.

[0016] Fifthly, a computer program product is provided that, when run on a service device, causes any of the methods provided in the first aspect to be executed. Attached Figure Description

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

[0018] Figure 1 A schematic diagram of a system architecture provided for an embodiment of this application; Figure 2 A flowchart illustrating a data processing method for collaborative tasks provided in an embodiment of this application; Figure 3This is a schematic diagram of the structure of a data processing device for collaborative tasks provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a service device provided in an embodiment of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0020] It should be noted that, unless there is a conflict, the various features in the embodiments of this application can be combined with each other, all of which are within the protection scope of this application. Furthermore, although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order than the module division in the device or the order in the flowchart. Moreover, the terms "first," "second," and "third" used in this application do not limit the data or execution order, but only distinguish identical or similar items with essentially the same function and effect.

[0021] The technical solution of this application is described in detail below.

[0022] See Figure 1 , Figure 1 A flowchart illustrating the system architecture provided in the embodiments of this application, as shown below. Figure 1 As shown, the system architecture includes service equipment, master control equipment, slave control equipment, and multiple drones. The service equipment is communicatively connected to the master control equipment, slave control equipment, and multiple drones.

[0023] Service equipment is the central processing node of the system architecture. Service equipment is computer equipment that runs data processing services, such as ground servers (dedicated servers deployed in the mission command center), edge computing devices (lightweight computing nodes deployed near the mission site (such as industrial-grade edge computing boxes)), vehicle-mounted computing platforms (vehicle-mounted computers deployed on command vehicles that move with the mission site), cloud servers (service instances deployed in the cloud), etc.

[0024] The master control device is used to create task context information for collaborative tasks. The master control device is a computer device operated by task managers, possessing task creation and decision-making capabilities. Examples include a ground control station (dedicated UAV ground control hardware equipped with a display screen and control interface for commanders to create task context, view key events, and execute confirmation operations), an industrial tablet PC (a ruggedized tablet equipped with dedicated task management software, easily portable to the field), a laptop computer (a laptop with task management client software installed), a command center large-screen terminal (a large-screen interactive terminal deployed in a fixed command center), and a smartphone (a smartphone with a task management app installed), etc.

[0025] Slave devices serve as execution and observation nodes for collaborative tasks. Essentially, a slave device is a computer used by task personnel to view event details and supplement records; examples include industrial tablets, smartphones, laptops, vehicle terminals, and wearable devices (such as smartwatches and head-mounted displays). Drones serve as data acquisition nodes for collaborative tasks.

[0026] See Figure 2 , Figure 2 This is a flowchart illustrating a data processing method for collaborative tasks provided in an embodiment of this application, as shown below. Figure 2 As shown, applied to the aforementioned service equipment, the method includes the following steps: S201 performs clustering processing on the data reported from multiple drones to obtain clusters of collaborative tasks.

[0027] In one implementation, the reported data includes at least one of the following: first target category, target bounding box position, world coordinates, camera pose, timestamp, recognition confidence, screenshot index, and video index.

[0028] The first target category refers to the drone's classification of the target (e.g., through a target detection model), that is, which preset category the detected target belongs to. For example, people, vehicles, animals, specific objects, etc.

[0029] The target bounding box position refers to the location and extent of the target in the image coordinate system, usually represented by a rectangle. For example, the top-left corner coordinates (x, y) plus the width w and height h of the box are (x, y, w, h). This is used to pinpoint the target's exact location in a screenshot and is also the basic data for cross-frame tracking.

[0030] World coordinates refer to the target's location coordinates in real geographic space, calculated jointly from the UAV's GPS position, flight altitude, and attitude. For example, latitude and longitude coordinates (116.3°E, 39.9°N) plus altitude. These are used for map labeling, boundary crossing detection, and spatial correlation of multi-aircraft data.

[0031] UAV attitude refers to the spatial position and attitude parameters of a UAV when it detects a target. It typically includes the UAV's own position coordinates and three attitude angles: roll, pitch, and yaw. These parameters are used to verify the reliability of the world coordinate calculation. The more stable the UAV's attitude, the more accurate the calculated world coordinates. When the attitude is abnormal (such as severe shaking caused by strong winds), the reliability of the world coordinates will decrease accordingly.

[0032] A timestamp is a precise record of the time a target was detected, typically accurate to the millisecond level.

[0033] Recognition confidence refers to the probability score given by the object detection model for "the currently detected object belonging to a certain category". The value is usually a decimal between 0 and 1. For example, if the model detects an object and classifies it as "person", a confidence score of 0.95 means that the model is 95% confident that the object belongs to the "person" category; a confidence score of 0.3 means that the model is not very certain about the category.

[0034] A screenshot index refers to a reference number to a specific screenshot in the drone's local storage. It does not contain the image content itself; it is merely a locator. Once the receiver receives the screenshot index, it can retrieve the corresponding complete screenshot from the drone's local storage when needed. This "transmitting the index rather than the actual image" design avoids the bandwidth pressure of transmitting the image file with every report.

[0035] A video index refers to a reference number to a specific video file in the drone's local storage. Similar to a screenshot index, it does not contain the video content itself. When the receiver needs to view the complete recording, it retrieves the corresponding video file from the drone's local storage using the video index.

[0036] In one implementation, prior to step 201, the master control device creates task context information for the collaborative task. This task context information includes at least one of the following: the master control identifier of the master control device participating in the collaborative task, the slave control identifier of the slave control device participating in the collaborative task, the drone identifier of the drone participating in the collaborative task, the start and end times of the collaborative task, the area boundary of the collaborative task, the alarm level threshold of the collaborative task, the sharing permission policy, risk rules, second target category, and recording policy of the collaborative task.

[0037] The master control identifier refers to the unique identification number of the master control device participating in the collaborative task.

[0038] The slave identifier refers to the unique identification number of the slave device participating in the collaborative task, and may include multiple identifiers (corresponding to multiple slave devices).

[0039] The drone identifier refers to the unique identification number of each drone participating in the collaborative mission, and usually includes multiple identifiers (corresponding to multiple drones).

[0040] The task start and end times refer to the start and end times of the collaborative task. They are used to define the effective time window for the collaborative task.

[0041] The region boundary refers to the geographic spatial extent of the collaborative task, typically represented by a polygonal or circular area described by a sequence of coordinate points. It is used to constrain the effective flight and detection range of the UAV.

[0042] Alarm level threshold refers to the minimum threshold value of the event risk level required to trigger alarm processing.

[0043] Sharing permission policies refer to the rules and restrictions that define the sharing of event data for collaborative tasks, including which roles can initiate sharing, what processing is required for shared content (such as face masking and location blurring), and the validity period of shared links.

[0044] The second target category refers to the category of targets that the collaborative task needs to identify. For example, people, vehicles, animals, specific objects, etc.

[0045] The risk rules include at least one of the following: a preset high-risk category set, a preset low-relevance category set, preset risk attention conditions, and a first confidence threshold. Specifically, the preset high-risk category set characterizes target categories that require priority attention in the collaborative task, such as suspected trapped persons or suspected carriers of hazardous materials; the preset low-relevance category set characterizes target categories that are weakly related to the collaborative task, such as ordinary pedestrians or regular vehicles; the preset risk attention conditions characterize the conditions that the risk-related characteristics of the targets to be identified in the collaborative task must meet; and the first confidence threshold characterizes the minimum identification confidence level required to classify a target category as a high-risk event.

[0046] Risk rules can be configured differently depending on the task type of the collaborative task. The preset high-risk category set, preset low-relevance category set, preset risk attention conditions, and first confidence threshold can be different for different task types. Risk rules are written into the task context information when the collaborative task is created and are invoked when determining the risk level of event data in the collaborative task, so as to keep the risk level determination criteria for event data consistent within the same collaborative task.

[0047] In one implementation, the reported data includes a first target category, timestamp, world coordinates, and identification confidence level; The clustering process of reported data from multiple drones to obtain clusters of collaborative tasks includes: Obtain the task context information of the collaborative task, which includes the task start and end time, area boundary, and second target category; Based on the first target category, the timestamp, the world coordinates, the identification confidence level, the task start and end time, the region boundary, and the second target category, clustering processing is performed on the reported data from multiple drones to obtain clusters of collaborative tasks.

[0048] Further, based on the first target category, the timestamp, the world coordinates, the identification confidence level, the task start and end times, the region boundary, and the second target category, the reported data from multiple drones is clustered to obtain clusters, including: The target time period for executing the collaborative task is determined based on the task start and end time; from the reported data from multiple drones, the reported data whose timestamps fall within the target time period are determined, resulting in N reported data, where N is a positive integer; The target space domain in which the collaborative task is performed is determined based on the region boundary; from the N reported data, the reported data in which the world coordinates are located in the target space domain is determined, and M reported data are obtained, where M≤N; From the M reported data, determine the reported data whose first target category and second target category are consistent, and obtain K reported data, where K≤M; From the K reported data, the reported data whose difference between the identification confidence level and the confidence level threshold is greater than or equal to a preset threshold are filtered out to obtain the cluster of the collaborative task.

[0049] In one embodiment, the time interval defined by the task start and end times is directly determined as the target time period, that is, the start time of the target time period is the task start time in the task start and end times, and the end time of the target time period is the task end time in the task start and end times.

[0050] In another embodiment, considering the potential delay in the transmission of data reported by the UAV, the target time period can also be determined based on the task start and end times: the start time of the target time period is the task start time minus a preset buffer duration (such as 0.5s, 1s, 2s, 4s, 5s or other values), and the end time of the target time period is the task end time plus the preset buffer duration. This ensures that the target time period has a certain tolerance range compared to the interval defined by the task start and end times, preventing misjudgment that it does not belong to the target time period when the timestamp of the reported data falls near the boundary of the task start and end times due to the delay in data transmission.

[0051] In one embodiment, the spatial range enclosed by the region boundary can be directly defined as the target spatial domain, that is, the target spatial domain is consistent with the spatial range defined by the region boundary.

[0052] In another embodiment, considering that the UAV may have positioning errors in estimating the world coordinates of the target, the target spatial domain can also be determined based on the boundary of the region: the boundary of the region is extended outward by a preset buffer distance to obtain an extended spatial range, and the extended spatial range is determined as the target spatial domain, so that the target spatial domain has a certain tolerance range compared with the spatial range defined by the boundary of the region, and avoids the valid reported data near the boundary of the region being misjudged as not belonging to the target spatial domain due to positioning errors in the world coordinate estimation.

[0053] The preset buffer distance can be a pre-configured fixed value, or it can be adaptively determined based on at least one of the following factors: the UAV's flight altitude and the ground sampling distance. The higher the flight altitude, the larger the preset buffer distance; the larger the ground sampling distance, the larger the preset buffer distance. This is to ensure that the preset buffer distance can adapt to the positioning error generated when the UAV estimates the world coordinates of the target, thereby improving the compatibility of the target space domain with the effective reported data.

[0054] In one embodiment, the confidence threshold is determined based on the identification confidence levels of K reported data points. The confidence threshold is the highest identification confidence level among the K reported data points. Alternatively, the confidence threshold is the average or median of the identification confidence levels among the K reported data points.

[0055] For example, suppose the mission context information of a search and rescue collaborative mission is as follows: mission start and end time: 10:00:00—10:30:00 (target time period), area boundary: a rectangular area A (target space domain), second target category: suspected trapped personnel.

[0056] Assume that during the mission execution, a total of 7 data reports were generated from 3 drones (Drone 1, Drone 2, and Drone 3), denoted as Report Data 1-7. Each report includes "first target category, timestamp, world coordinates, and identification confidence level," as follows:

[0057] First, the target time period is determined based on the task start and end time of 10:00:00-10:30:00, and data with timestamps outside this range is removed. The timestamp of reported data 6 is 09:58:30, which is outside the target time period and is therefore removed; the timestamps of the remaining data 1-5 and 7 all fall within the target time period.

[0058] In this study, the target spatial domain was defined as Region A based on the regional boundary (e.g., the coordinate range is approximately x∈[100,150], y∈[50,100]), and data whose world coordinates are not within this domain were removed. The world coordinates of reported data 5 were (450,300), which clearly exceeded the range of Region A and was therefore removed; the world coordinates of the remaining data 1-4 and 7 all fell within Region A.

[0059] In this case, the first target category is compared with the second target category (assuming they are suspected trapped persons), and data that do not match the category are removed. The first target category of reported data 4 is "ordinary pedestrians", which does not match the second target category, so it is removed; the first target category of the remaining data 1-3 and 7 is "suspected trapped persons", which matches the second target category.

[0060] Finally, following the principle that "the confidence threshold is determined based on the identification confidence of K reported data," the confidence threshold is first calculated from the identification confidence of these four reported data (1-3 and 7). For example, the highest identification confidence value among the four reported data is taken as the confidence threshold, and the confidence threshold = max(0.92, 0.88, 0.75, 0.55) = 0.92. Assuming the preset threshold (i.e., the maximum allowed difference) is 0.2, the difference between the confidence of each data and the confidence threshold (0.92) is calculated. The difference for reported data 1 is 0 < 0.2, the difference for reported data 2 is 0.04 < 0.2, the difference for reported data 3 is 0.17 < 0.2, and the difference for reported data 7 is 0.37 > 0.2. Reported data 7 is removed. Therefore, the final cluster of the collaborative task includes reported data 1-3.

[0061] S202, perform data integration on the clusters to obtain the event data of the collaborative task.

[0062] In one implementation, the reported data includes screenshot indexes and video indexes; The process of integrating the data from the clusters to obtain the event data for the collaborative task includes: Obtain the first screenshot corresponding to the screenshot index included in the first reported data, wherein the first reported data is the reported data with the highest identification confidence in the cluster; Obtain the second screenshot corresponding to the screenshot index included in the second reported data, wherein the second reported data is the reported data in the cluster that meets the preset viewpoint conditions; Obtain the video file corresponding to the video index included in the reported data of the cluster; determine the target video file based on the obtained video file; The event data is generated based on the drone identifier corresponding to the cluster, the third target category corresponding to the cluster, the target recognition confidence level corresponding to the cluster, the first screenshot, the second screenshot, and the target video file.

[0063] Each reported data entry within a cluster carries a screenshot index, pointing to the screenshot file captured and stored by the drone when it identified the target. Within each cluster, the recognition confidence scores of the reported data entries are compared, and the entry with the highest confidence score is selected as the first reported data entry. Based on the screenshot index in this reported data entry, the corresponding screenshot file is retrieved and read, and the result is the first screenshot.

[0064] One reported data point is selected from within the cluster based on the "viewpoint" dimension (rather than the confidence level). The screenshot file corresponding to the screenshot index of this reported data is read to obtain the second screenshot. This screenshot is the "optimal viewpoint screenshot." Even if the confidence level of a reported data point is not the highest, if its shooting perspective can present the entire target more completely and clearly (e.g., a frontal view or an unobstructed view), it should still be retained separately as supplementary evidence. This is because the screenshot with the highest confidence level is not necessarily the screenshot with the best visual presentation effect. The two are selected based on different dimensions and complement each other.

[0065] Preset viewing angle conditions are pre-defined criteria for determining whether a reported data point belongs to the "optimal viewing angle." The criteria are based on the camera position and orientation carried in the reported data. Preset viewing angle conditions include: whether the shooting angle is closer to the front or horizontal view of the target (to avoid excessive downward angle that may cause target deformation or obstruction), the completeness of the target in the frame (whether it is obstructed or located at the edge of the frame), and whether the shooting distance is appropriate (neither too far that the target is too small, nor too close that the field of view is limited).

[0066] In addition to the screenshot index, each reported data entry within a cluster also carries a video index, pointing to the corresponding video file recorded by the drone when it detected the target. For each reported data entry within a cluster, the corresponding video file is retrieved and read based on its video index, providing candidate material for subsequently determining the target video file.

[0067] After obtaining multiple video files corresponding to multiple reported data within a cluster, it is necessary to filter or integrate these candidate video files to obtain the final target video file. From multiple video files, select the segment that can most completely record the target's movement trajectory, covers the longest time span, or has the best image continuity (or the result of splicing multiple video files) as the final target video file, to avoid incomplete recording of target behavior due to interruptions or occlusions in a single drone video clip.

[0068] The multiple reported data points aggregated in a cluster originate from which sets of drone identifiers? Since the same cluster may be formed by reports from multiple different drones (such as drone 1, drone 2, and drone 3), which are then merged after deduplication, it is necessary to record the identifiers of all drones that contributed to the cluster when generating event data.

[0069] Although multiple reported data points within a cluster have undergone the aforementioned category consistency screening (i.e., the first target category and the second target category are consistent), a unified target category representing the entire cluster still needs to be determined when generating unified event data. This third target category distinguishes it from the first target category inherent in each individual reported data point and the second target category preset by the task context. Since the first target categories of each reported data point within a cluster are already consistent with each other, the third target category is usually taken as this consistent category, serving as the category attribute presented externally for the entire event data.

[0070] When generating event data, a unified confidence score needs to be determined for each cluster to represent the overall credibility of the cluster, i.e., the target identification confidence score, to distinguish it from the identification confidence scores carried by individual reported data. This unified confidence score can be the highest identification confidence score among all reported data within the cluster (for example, directly taking the confidence score of the first reported data, as it has the highest built-in confidence score in the cluster), or it can be the average of the identification confidence scores included in all reported data within the cluster.

[0071] For example, in the previous example, the cluster included reported data 1, reported data 2, and reported data 3, which came from drone 1, drone 2, and drone 3 respectively, and the target category was "suspected trapped personnel". The information included in these three reported data is as follows:

[0072] First, the identification confidence levels of the three reported data points are 0.92, 0.88, and 0.75, respectively. Among them, reported data 1 has the highest confidence level (0.92), so reported data 1 is identified as the "first reported data". Based on the screenshot index SNAP-001 carried by reported data 1, the corresponding screenshot file is retrieved and used as the first screenshot.

[0073] This time, based on preset viewing angle conditions (such as "the shooting angle is close to a horizontal view and the target is complete and unobstructed"), the camera positions of the three reported data were compared one by one: Reported data 1: Viewed from above at a 45° angle with partial obstruction, does not meet the viewing angle requirements; Reported data 2: Horizontal 15° side view with the target intact and unobstructed, meeting the preset view conditions; Reported data 3: The target is at a 70° angle from above, far away, and small, which does not meet the viewing angle requirements.

[0074] Therefore, reported data 2 was identified as "second reported data". Based on the screenshot index SNAP-002 carried by reported data 2, the corresponding screenshot file was retrieved and used as the second screenshot.

[0075] In this instance, three candidate video files were retrieved based on the video indices VID-001, VID-002, and VID-003 of the three reported data sets. Assuming the comparison yields the following: VID-001 (Drone 1): The recording time covers 2 seconds before the target appears and 1 second after it disappears, with brief blurring of the image due to tree shadows in between. VID-002 (Drone 2): The recording time covers 1 second before the target appears to 3 seconds after it disappears. The footage is continuous and clear, and fully records the target's movement trajectory from stillness to slight struggle. VID-003 (Drone 3): The recording time is short, only covering 2 seconds after the target appears, and the distance is far and the picture is blurry.

[0076] By comprehensively comparing the completeness and continuity of the target's trajectory in the three video clips, it was determined that VID-002 could best record the target's movement trajectory. Therefore, the video file corresponding to UAV 2 was identified as the target video file.

[0077] Finally, the following elements are integrated to generate unified event data corresponding to this cluster: The drone identifiers corresponding to the clusters are: {Drone 1, Drone 2, Drone 3}; The third target category corresponding to the cluster: suspected trapped persons (the categories of the three reported data are consistent, so this category is directly taken); The target identification confidence level corresponding to the cluster is 0.92 (the highest confidence level within the cluster is taken, i.e., the confidence level of the first reported data 1). First screenshot: Screenshot file corresponding to SNAP-001 (highest confidence screenshot); Second screenshot: Screenshot file corresponding to SNAP-002 (optimal view screenshot); Target video file: The video file corresponding to VID-002 (the most complete trajectory segment).

[0078] The final generated event data is the result of integrating the above six elements.

[0079] S203, Based on the event data, determine the event risk level of the collaborative task.

[0080] Among them, the event risk level is used to characterize the urgency or priority of the collaborative task.

[0081] In one implementation, determining the event risk level of the collaborative task based on the event data includes: The event data is analyzed to obtain the third target category, the target identification confidence level, and the target features, wherein the target features include the features of the target to be identified by the collaborative task that match the preset risk concern conditions; The event risk level is determined based on the third target category, the target identification confidence level, and the target characteristics.

[0082] Specifically, based on the first screenshot, second screenshot, and target video file included in the event data, the behavior or state exhibited by the target is identified, and the identified behavior or state is matched with the preset risk concern conditions to obtain the target features that match the preset risk concern conditions. For example, if the third target category is a suspected trapped person, the target features may include features related to being trapped, such as the target remaining still or exhibiting abnormal limb posture; if the third target category is a suspected carrier of dangerous objects, the target features may include features related to risk carrying, such as the outline of abnormally carried items.

[0083] Further, determining the event risk level based on the target category, the target identification confidence level, and the target features includes: Based on the third target category, the target identification confidence level, and the target characteristics, the basic risk level corresponding to the event data is determined; Obtain historical events associated with the event data, and determine the risk correlation degree corresponding to the event data based on the historical events; The basic risk level is modified based on the risk correlation to obtain the event risk level.

[0084] In one embodiment, determining the basic risk level corresponding to the event data based on the third target category, the target identification confidence level, and the target features includes: If the third target category belongs to a preset high-risk category set, the target features meet preset risk concern conditions, and the target identification confidence level is greater than or equal to the first confidence level threshold, then the basic risk level is determined to be the first risk level. If the third target category belongs to a preset low-relevance category set, or if the target feature does not meet the preset risk concern conditions, then the basic risk level is determined to be the third risk level. If the third target category, the target identification confidence level, and the target features do not meet the conditions for determining the basic risk level as the first risk level, and do not meet the conditions for determining the basic risk level as the third risk level, then the basic risk level is determined to be the second risk level.

[0085] The first risk level is higher than the second risk level, and the second risk level is higher than the third risk level.

[0086] The step of acquiring historical events associated with the event data and determining the risk correlation degree corresponding to the event data based on the historical events includes: Based on the third target category corresponding to the event data and the location information corresponding to the event data, query historical events that meet the preset association conditions with the event data from the historical event records to obtain a set of associated historical events. The preset association conditions include at least one of the following: same category and location distance less than or equal to a preset distance threshold. The risk correlation degree is determined based on the number of historical events in the set of related historical events, the historical risk level corresponding to the historical events, and the occurrence time of the historical events.

[0087] The risk correlation degree is determined as follows: For each historical event in the set of associated historical events, a risk weight and a time decay coefficient are determined. The risk weight is positively correlated with the historical risk level of the historical event; that is, the higher the historical risk level, the greater the risk weight. The time decay coefficient is negatively correlated with the time elapsed between the occurrence of the historical event and the current time; that is, the closer the occurrence time is to the current time, the greater the time decay coefficient, and the further back in time the occurrence time is from the current time, the smaller the time decay coefficient.

[0088] The risk weight corresponding to each historical event in the set of related historical events is multiplied by the time decay coefficient to obtain the weighted risk value corresponding to each historical event. Then, the weighted risk values ​​corresponding to each historical event in the set of related historical events are accumulated to obtain the accumulated risk value. Based on the number of historical events in the set of related historical events, the accumulated risk value is normalized to obtain the risk correlation degree.

[0089] The more historical events in the associated historical event set, the more weighted risk value items participate in the accumulation of the accumulated risk value. Under the same conditions, the risk correlation is correspondingly higher, which is used to characterize the higher the frequency of occurrence of historical events corresponding to this type of target or this position and the higher the risk correlation.

[0090] After the risk correlation is determined, the risk correlation level can be determined based on the preset risk correlation level classification rules. The level is used to characterize the correction direction and correction magnitude of the subsequent correction of the basic risk level. For example, when the risk correlation is greater than or equal to the first correlation threshold, the corresponding correction magnitude is greater than the correction magnitude corresponding to when the risk correlation is less than the first correlation threshold and greater than or equal to the second correlation threshold.

[0091] In one embodiment, the step of correcting the basic risk level based on the risk correlation to obtain the event risk level includes: If the risk correlation is greater than or equal to the first correlation threshold, the basic risk level is adjusted to a higher level to obtain the corrected event risk level; for example, if the basic risk level is the second risk level, the corrected event risk level is the first risk level; if the basic risk level is already the first risk level, the corrected event risk level remains the first risk level and is not adjusted upwards. If the risk correlation is less than the first correlation threshold and greater than or equal to the second correlation threshold, then the basic risk level remains unchanged, and the basic risk level is determined as the event risk level, wherein the second correlation threshold is less than the first correlation threshold. If the risk correlation is less than the second correlation threshold, the basic risk level is adjusted to a lower level by one level to obtain the corrected event risk level; for example, if the basic risk level is the second risk level, the corrected event risk level is the third risk level; if the basic risk level is already the third risk level, the corrected event risk level remains the third risk level and is not adjusted downwards.

[0092] The extent to which the basic risk level is adjusted to a higher or lower level can also be determined based on the level of the risk correlation. The higher the level of the risk correlation, the greater the adjustment to a higher level; the lower the level of the risk correlation, the greater the adjustment to a lower level. This allows the event risk level to not only reflect the target category, identification confidence, and target characteristics presented by the current event data itself, but also to further reflect the degree of correlation between the event and the regular risk characteristics reflected in historical event records, thereby improving the accuracy of the event risk level determination results.

[0093] For example, continuing with the above example, parsing the event data generated in the example yields the following information: Third target category: suspected trapped persons; Target recognition confidence level: 0.92; Target characteristics: Based on the second screenshot (SNAP-002, optimal viewing angle, complete and unobstructed target) and the target video file (VID-002, which fully records the target's movement trajectory from stillness to slight struggle), image / behavior analysis was performed to identify that the target exhibits "long-term stillness accompanied by slight struggle movements". This behavior matches the pre-set risk concern conditions (trapped-related characteristics) in the task context risk rules. Therefore, the target characteristic is "exhibiting trapped-related characteristics".

[0094] Assume the risk rules in the task context are set as follows: Preset high-risk category set = {suspected trapped persons, suspected carriers of dangerous objects}; First confidence threshold = 0.85; The comparison results are as follows: the third target category, "suspected trapped persons," belongs to the preset high-risk category set; the target feature, "exhibiting trapped-related characteristics," meets the preset risk concern conditions; the target identification confidence level of 0.92 is greater than or equal to the first confidence threshold of 0.85. Since all three conditions are met, the basic risk level equals the first risk level.

[0095] Based on the third target category "suspected trapped persons" and the location information corresponding to the event, a search of historical event records is conducted. Assuming that two similar "suspected trapped persons" historical events occurred in the area within the previous hour, both with a historical risk level of Level 1 and occurring relatively recently, the calculated risk correlation is high, reaching or exceeding the Level 1 correlation threshold, according to the previous "risk correlation calculation method" (weighted by quantity, historical risk level, and occurrence time).

[0096] Since the basic risk level is already the highest level (the first level), the event risk level after the correction will still be the highest level.

[0097] S204, if the event risk level is greater than or equal to the alarm level threshold, then based on the event risk level, determine the first information to be sent to the master control device and send the first information to the master control device; based on the event risk level, determine the second information to be sent to the slave control device and send the second information to the slave control device.

[0098] In one embodiment, the event risk level includes a first risk level, a second risk level, and a third risk level, wherein the first risk level is higher than the second risk level, and the second risk level is higher than the third risk level; both the first risk level and the second risk level are greater than or equal to the alarm level threshold, and the third risk level is less than the alarm level threshold.

[0099] The alarm level threshold can be configured differently depending on the task type of the collaborative task. Different task types may have different alarm level thresholds, so that the collaborative task can flexibly adjust the sensitivity of triggering alarm delivery according to the actual scenario requirements.

[0100] In one implementation, if the event risk level is less than the alarm level threshold, the event data is silently recorded, and the event status corresponding to the event data is updated to the silent recording status. At this time, neither the first information is sent to the master control device nor the second information is sent to the slave control device, that is, the alarm delivery process is not actively triggered.

[0101] The event data processed by silent recording is still completely retained in the event log. It can be used as a component of the structured task report generated after the subsequent task is completed, and can also be used as the basis for historical event correlation queries when other event data are performed. It is used to determine the risk correlation degree corresponding to other event data, but it does not actively occupy the alarm attention resources of the master control device and slave control device. Thus, while ensuring that the identification results are not lost, it avoids alarm information overload caused by a large number of weakly correlated targets.

[0102] In one implementation, determining the first information to be sent to the master control device based on the event risk level includes: If the event risk level is the first risk level, then the first information is determined to include strong alarm information, handling suggestion information and confirmation entry information. The confirmation entry information is used for the main control device to perform a confirmation operation on the event data. The handling suggestion information is determined based on the third target category and target characteristics corresponding to the event data. If the event risk level is the second risk level, then the first information is determined to include weak prompt information, and the second risk level is lower than the first risk level.

[0103] In one embodiment, the strong alarm information is used to characterize the event risk level corresponding to the event data as the first risk level, and its prompting intensity is higher than that of the weak prompting information, so as to attract the immediate attention of the operator of the main control device to the event data.

[0104] In one embodiment, the handling suggestion information is used to provide the operator of the main control device with suggestions for the next handling action for the event data. Different third target categories and target characteristics correspond to different handling suggestion information so that the handling suggestion information matches the specific situation presented by the event data.

[0105] The system includes a pre-configured rule base for handling suggestions, which maps the combination of target categories and target features to the content of handling suggestions. Based on the third target category and target features corresponding to the event data, the system queries the rule base for handling suggestions that match the combination of the third target category and target features, and determines the retrieved handling suggestions as the handling suggestion information. For example, if the third target category is a suspected trapped person and the target features are features related to being trapped, the matched handling suggestion information is used to suggest dispatching rescue personnel to the location corresponding to the event data for verification and rescue; if the third target category is a suspected carrier of hazardous materials and the target features are features related to carrying hazardous materials, the matched handling suggestion information is used to suggest conducting a nearby investigation and confirmation of the target corresponding to the event data.

[0106] In one embodiment, the disposal suggestion rule base can be configured differently depending on the task type of the collaborative task. The disposal suggestion content matched by the combination of target categories and target features corresponding to different task types can be different, so that the disposal suggestion information is adapted to the actual scenario requirements of the collaborative task.

[0107] In one embodiment, the operator of the master control device can manually confirm the authenticity of the event data or the handling result through the confirmation entry information. After receiving the confirmation result returned by the master control device for the confirmation entry information, the operator updates the event status corresponding to the event data based on the confirmation result and synchronizes the updated event status to the slave control device so that the master control device and the slave control device refer to the same event status for the event data.

[0108] In one implementation, determining the second information to be sent to the slave device based on the event risk level includes: If the event risk level is the first risk level, then the second information is determined to include the event data, timeline information, and supplementary record entry information. The supplementary record entry information is used for the slave device to perform supplementary record operations on the event data. If the event risk level is the second risk level, then the second information is determined to include weak prompt information.

[0109] The timeline information is used to arrange and organize multiple reported data in the cluster corresponding to the event data according to their respective timestamps, so as to present to the slave device the time-series evolution process of the target corresponding to the event data from its first discovery to its continuous observation and confirmation.

[0110] The weak alert information is used to indicate that the event risk level corresponding to the event data is the second risk level. Its alert strength is lower than that of the strong alarm information. It is used to inform the slave device that there is event data with a risk level of the second risk level without triggering the full information push and confirmation entry.

[0111] In one embodiment, the method further includes: Receive supplementary recording data returned by the slave device in response to the supplementary recording entry information; Based on the supplementary recorded data, the event data is updated, and the updated event data is synchronized to the main control device.

[0112] In one embodiment, the method further includes: If the master control device is detected to be offline, the master control device receives and responds to the viewing request and the supplementary recording request for the event data sent by the slave control device. If a sharing request or a closing request for the event data is received from the slave device, the sharing request or the closing request is refused until the master device is detected to be online and confirmation information for the sharing request or the closing request is received from the master device.

[0113] In this embodiment, clustering is performed before data processing, avoiding the separate processing of multiple data points for the same event and reducing the consumption of computing resources. In addition, data integration of clusters allows multiple original reported data points within a cluster to be extracted into a representative data point, eliminating the need to process all the original data within the cluster, further reducing the consumption of computing resources. Furthermore, when the event risk level is greater than or equal to the alarm level threshold, the first information to be sent to the master control device and the second information to be sent to the slave control device are determined based on the same event risk level, enabling the master control device and the slave control device to obtain information content that matches their respective roles, thereby improving the handling efficiency of different roles in collaborative tasks.

[0114] In one implementation, when the master control device or the slave control device initiates external sharing, a pre-sharing verification is performed. The verification includes at least whether the current event status allows sharing, whether the operator has sharing permissions, whether the material contains facial or license plate information that needs to be de-identified, and whether the validity period and access method of the shared object meet policy requirements. After successful verification, the event snapshot is automatically decrypted, its location blurred, and the material cropped. A QR code or link with a password and expiration time is generated as the carrier for external sharing, ensuring that the shared material has a controllable access validity period while meeting privacy protection requirements.

[0115] In one implementation, after the task is completed, a structured task report is automatically generated based on the full event record, master-slave control confirmation log, sharing log and flight trajectory. The structured task report includes the number of events, comparison before and after deduplication, a list of key events, manual confirmation results, sharing records, representative screenshots and abnormal link information, so that the identification results are deposited into a verifiable, traceable and operable task asset.

[0116] In one embodiment, when targets uploaded from multiple drones are close in time but have significant spatial conflicts, they are not forcibly merged into the same event. Instead, they are retained as candidate related events and processed after more observational evidence or manual confirmation to prevent erroneous deduplication.

[0117] When network bandwidth is insufficient, priority is given to transmitting event summary information and event status synchronization information, while video streams are delayed and retransmitted.

[0118] When the master control device is in a short-term offline state, the slave control device can still view and supplement the event data, but operations involving external sharing or closing critical events must be reconfirmed after the master control device is restored to online.

[0119] When the de-identification algorithm has insufficient confidence in de-identifying facial or license plate information in the material, the system will not allow automatic sharing and will transfer the sharing request to manual review.

[0120] When the collaborative task is manually aborted or the flight platform returns to base, the system automatically closes the new sharing entry and marks the unfinished sharing task as pending confirmation or invalid.

[0121] The method of this application has been described above; the apparatus of this application will be described below.

[0122] See Figure 3 , Figure 3 This is a schematic diagram of the structure of a data processing device for collaborative tasks provided in an embodiment of this application, as shown below. Figure 3 As shown, the data processing device 30 for the collaborative task includes: Clustering module 301 is used to perform clustering processing on the data reported from multiple drones to obtain clusters of collaborative tasks; Integration module 302 is used to integrate the data of the clusters to obtain the event data of the collaborative task; The determination module 303 is used to determine the event risk level of the collaborative task based on the event data; The communication processing module 304 is configured to, if the event risk level is greater than or equal to the alarm level threshold, determine and send a first message to the master control device based on the event risk level, and send the first message to the master control device; determine and send a second message to the slave control device based on the event risk level, and send the second message to the slave control device.

[0123] It should be noted that the data processing device 30 for the aforementioned collaborative task can execute the data processing method for the collaborative task provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects for executing the method. Technical details not described in detail in the embodiments can be found in the data processing method for the collaborative task provided in the embodiments of this application.

[0124] See Figure 4 , Figure 4 This is a schematic diagram of the structure of a service device 40 provided in an embodiment of this application. The service device 40 includes a processor 401 and a memory 402. The memory 402 is connected to the processor 401, for example, via a bus.

[0125] Processor 401 is configured to support the service device 40 in performing the corresponding functions in the methods described in the above method embodiments. Processor 401 may be a central processing unit (CPU), a network processor (NP), a hardware chip, or any combination thereof. The aforementioned hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The aforementioned PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof.

[0126] Memory 402 is used to store program code, etc. Memory 402 may include volatile memory (VM), such as random access memory (RAM); memory 402 may also include non-volatile memory (NVM), such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); memory 402 may also include combinations of the above types of memory.

[0127] The memory 402 is used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the collaborative task data processing method in the embodiments of this application. The processor executes various functional applications and data processing of the collaborative task data processing method by running the non-volatile software programs, instructions, and modules stored in the memory, thereby realizing the function of the collaborative task data processing method provided in the above method embodiments.

[0128] The memory 402 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and application programs required for at least one function. The data storage area may store data created based on the use of the 3D simulation circuit display device. In some embodiments, the memory may include memory remotely located relative to the processor, which can be connected to the 3D simulation circuit display device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0129] The one or more modules are stored in the memory. When executed by the one or more processors, they perform the data processing method of the collaborative task in any of the above method embodiments. For example, they perform the method steps described in the above method embodiments to realize the functions of the modules described in the above device embodiments.

[0130] This application also provides a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a computer, cause the computer to perform the method described in the foregoing embodiments.

[0131] This application also provides a computer program product that, when run on a service device, causes any of the above methods to be executed.

[0132] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0133] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. A data processing method for collaborative tasks, characterized in that, include: Clustering is performed on the data reported from multiple drones to obtain clusters of collaborative tasks; The clusters are integrated to obtain the event data of the collaborative task; Based on the event data, determine the event risk level of the collaborative task; If the event risk level is greater than or equal to the alarm level threshold, then the first information to be sent to the main control device is determined based on the event risk level, and the first information to be sent to the main control device is also determined. The second information to be sent to the slave device is determined based on the event risk level, and the second information is sent to the slave device.

2. The method according to claim 1, characterized in that, The reported data includes the first target category, timestamp, world coordinates, and identification confidence level; The clustering process of reported data from multiple drones to obtain clusters of collaborative tasks includes: Obtain the task context information of the collaborative task, which includes the task start and end time, area boundary, and second target category; Based on the first target category, the timestamp, the world coordinates, the identification confidence level, the task start and end time, the region boundary, and the second target category, clustering processing is performed on the reported data from multiple drones to obtain clusters of collaborative tasks.

3. The method according to claim 2, characterized in that, The method involves clustering data reported from multiple drones based on the first target category, the timestamp, the world coordinates, the identification confidence level, the task start and end times, the region boundary, and the second target category to obtain clusters, including: The target time period for executing the collaborative task is determined based on the task start and end time; from the reported data from multiple drones, the reported data whose timestamps fall within the target time period are determined, resulting in N reported data, where N is a positive integer; The target space domain in which the collaborative task is performed is determined based on the region boundary; from the N reported data, the reported data in which the world coordinates are located in the target space domain is determined, and M reported data are obtained, where M≤N; From the M reported data, determine the reported data whose first target category and second target category are consistent, and obtain K reported data, where K≤M; From the K reported data, the reported data whose difference between the identification confidence level and the confidence level threshold is greater than or equal to a preset threshold are filtered out to obtain the cluster of the collaborative task.

4. The method according to claim 2, characterized in that, The reported data includes screenshot indexes and video indexes; The process of integrating the data from the clusters to obtain the event data for the collaborative task includes: Obtain the first screenshot corresponding to the screenshot index included in the first reported data, wherein the first reported data is the reported data with the highest identification confidence in the cluster; Obtain the second screenshot corresponding to the screenshot index included in the second reported data, wherein the second reported data is the reported data in the cluster that meets the preset viewpoint conditions; Obtain the video file corresponding to the video index included in the reported data of the cluster; determine the target video file based on the obtained video file; The event data is generated based on the drone identifier corresponding to the cluster, the third target category corresponding to the cluster, the target recognition confidence level corresponding to the cluster, the first screenshot, the second screenshot, and the target video file.

5. The method according to claim 4, characterized in that, Determining the event risk level of the collaborative task based on the event data includes: The event data is analyzed to obtain the third target category, the target identification confidence level, and the target features, wherein the target features include the features of the target to be identified by the collaborative task that match the preset risk concern conditions; The event risk level is determined based on the third target category, the target identification confidence level, and the target characteristics.

6. The method according to claim 5, characterized in that, Determining the event risk level based on the target category, the target identification confidence level, and the target features includes: Based on the third target category, the target identification confidence level, and the target characteristics, the basic risk level corresponding to the event data is determined; Obtain historical events associated with the event data, and determine the risk correlation degree corresponding to the event data based on the historical events; The basic risk level is modified based on the risk correlation to obtain the event risk level.

7. The method according to claim 1, characterized in that, The determination of the first information to be sent to the main control device based on the event risk level includes: If the event risk level is the first risk level, then the first information is determined to include strong alarm information, handling suggestion information and confirmation entry information. The confirmation entry information is used for the main control device to perform a confirmation operation on the event data. The handling suggestion information is determined based on the third target category and target characteristics corresponding to the event data. If the event risk level is the second risk level, then the first information is determined to include weak prompt information, and the second risk level is lower than the first risk level.

8. The method according to claim 1, characterized in that, The determination of the second information to be sent to the slave device based on the event risk level includes: If the event risk level is the first risk level, then the second information is determined to include the event data, timeline information, and supplementary record entry information. The supplementary record entry information is used for the slave device to perform supplementary record operations on the event data. If the event risk level is the second risk level, then the second information is determined to include weak prompt information.

9. A service device, characterized in that, The device includes a memory and a processor, the memory being connected to the processor, the processor being configured to execute one or more computer programs stored in the memory, the processor causing the service device to implement the method as described in any one of claims 1-8 when executing the one or more computer programs.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, the computer program including program instructions that, when executed by a processor, cause the processor to perform the method as described in any one of claims 1-8.

Images