Cargo information monitoring management method, device and equipment and storage medium

Abstract

The application provides a cargo information monitoring management method, device and equipment and a storage medium, the method comprises the following steps: collecting real-time data in a cargo transportation process through a plurality of types of sensors arranged on a transportation vehicle to obtain sensor data; determining a deployment scheme of a data processing service according to a current cargo type and a transportation area feature; sequentially inputting the sensor data into a data filtering service, a data aggregation service and an event processing service allocated according to the deployment scheme for processing to obtain an abnormal event detection result; generating early warning information according to the abnormal event detection result and pushing the early warning information to a monitoring terminal, and storing the early warning information to a database for visual display. The application can dynamically adjust the deployment position of the data processing service according to the cargo type and the transportation area feature, solves the problem of monitoring interruption in an unstable network area, meets the real-time early warning demand of high-value cargo, and optimizes the resource utilization efficiency of the edge device and the cloud.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method, apparatus, equipment and storage medium for monitoring and managing cargo information. Background Technology

[0002] With the development of IoT technology, the logistics industry widely adopts various sensors such as GPS positioning devices, temperature and humidity sensors, and vibration sensors to monitor goods in real time during transportation. Traditional logistics monitoring systems typically employ an "edge acquisition-cloud processing" architecture. This means that onboard devices or edge devices at logistics stations are responsible for collecting sensor data, uploading it to a cloud server via 4G / 5G networks, where cloud-based data processing services perform data filtering, fusion analysis, and anomaly detection, ultimately pushing alerts to management personnel. This architecture can meet basic monitoring needs in scenarios with stable networks and a limited variety of goods.

[0003] The main problem with existing technologies is that the deployment location of data processing services is fixed in the cloud, making it impossible to adjust according to dynamic changes in cargo type and transportation environment. When transport vehicles enter areas with weak network coverage, sensor data collected by edge devices cannot be uploaded to the cloud in real time, causing monitoring service interruptions and making it impossible to detect emergencies such as abnormal temperatures and route deviations in a timely manner. For high-value goods, the end-to-end latency of cloud processing is often very high, which cannot meet the needs of real-time early warning. Summary of the Invention

[0004] The main objective of this invention is to solve the technical problems in existing logistics cargo monitoring systems where the data processing service is deployed in fixed locations, leading to monitoring interruptions in areas with unstable networks and the inability to meet the real-time requirements of high-value goods. This invention provides a method for monitoring and managing cargo information, characterized in that the method includes: Sensor data is obtained by collecting real-time data during the transportation process using various types of sensors deployed on transport vehicles. Determine the deployment plan for data processing services based on the current cargo type and transportation area characteristics; The sensor data is sequentially input into the data filtering service, data aggregation service, and event processing service allocated according to the deployment scheme for processing, to obtain the abnormal event detection results; Based on the abnormal event detection results, an early warning message is generated and pushed to the monitoring terminal through a long connection channel. At the same time, the cargo status data and the abnormal event detection results are stored in the database for visualization.

[0005] The present invention also provides a cargo information monitoring and management device, characterized in that the cargo information monitoring and management device comprises: The data acquisition module is used to collect real-time data during the transportation of goods through various types of sensors deployed on transport vehicles, and obtain sensor data. The deployment decision module is used to determine the deployment plan for data processing services based on the current cargo type and transportation area characteristics; Anomaly detection module is used to sequentially input the sensor data into the data filtering service, data aggregation service and event processing service allocated according to the deployment scheme for processing, and obtain anomaly event detection results; The early warning display module is used to generate early warning information based on the abnormal event detection results and push it to the monitoring terminal through a long connection channel. At the same time, it stores the cargo status data and the abnormal event detection results in the database for visualization display.

[0006] The present invention also provides a cargo information monitoring and management device, comprising: a memory and at least one processor, wherein the memory stores instructions, and the memory and the at least one processor are interconnected via a line; the at least one processor invokes the instructions in the memory to cause the cargo information monitoring and management device to perform the steps of the above-described cargo information monitoring and management method.

[0007] The present invention also provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the steps of the above-described cargo information monitoring and management method.

[0008] The aforementioned cargo information monitoring and management method, device, equipment, and storage medium collect real-time data during cargo transportation through multiple types of sensors deployed on transport vehicles, obtaining sensor data. A deployment scheme for data processing services is determined based on the current cargo type and transportation area characteristics. The sensor data is sequentially input into data filtering, data aggregation, and event processing services allocated according to the deployment scheme for processing, resulting in abnormal event detection results. Early warning information is generated based on the abnormal event detection results and pushed to the monitoring terminal, while simultaneously stored in a database for visualization. This invention can dynamically adjust the deployment location of data processing services according to cargo type and transportation area characteristics, solving the problem of monitoring interruption in areas with unstable networks, meeting the real-time early warning needs of high-value cargo, and optimizing the resource utilization efficiency of edge devices and the cloud.

[0009] Beneficial Effects: By dynamically determining the deployment scheme of data processing services based on the current cargo type and transportation area characteristics, data filtering, data aggregation, and event processing services can be allocated to onboard edge devices, relay nodes, or cloud servers according to the actual transportation scenario. When transport vehicles enter areas with weak network coverage, since the data processing services are already deployed on edge devices or relay nodes closer to the sensors, sensor data can be processed and anomaly detection completed without being uploaded to the cloud via a remote network, thus avoiding monitoring service interruptions caused by network outages. Furthermore, assigning different deployment schemes to different cargo types prioritizes the deployment of data processing services for high-value cargo on low-latency edge devices, while general cargo can be deployed on cloud servers. This meets the monitoring needs of different cargo types while reducing resource consumption and network bandwidth usage on edge devices.

[0010] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained in accordance with the structures particularly pointed out in the description, claims and drawings.

[0011] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0012] Figure 1 This is a schematic diagram of the first embodiment of the cargo information monitoring and management method in this invention; Figure 2 This is a schematic diagram of a second embodiment of the cargo information monitoring and management method in this invention; Figure 3 This is a schematic diagram of one embodiment of the cargo information monitoring and management device in this invention; Figure 4 This is a schematic diagram of one embodiment of the cargo information monitoring and management device in this invention. Detailed Implementation

[0013] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0014] The terms "comprising" and "having," and any variations thereof, used in the embodiments of this invention are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the steps or units listed, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0015] To facilitate understanding of this embodiment, a detailed description of a cargo information monitoring and management method disclosed in this embodiment of the invention will be provided first. For example... Figure 1 As shown, this method includes the following steps: 101. Real-time data during cargo transportation is collected by various types of sensors deployed on transport vehicles to obtain sensor data; In this embodiment, the process of collecting real-time data during cargo transportation by using multiple types of sensors deployed on the transport vehicle to obtain sensor data includes: collecting the current position coordinates, speed, and direction of the transport vehicle using positioning sensors deployed on the transport vehicle to obtain position data; collecting temperature, humidity, and vibration acceleration values ​​using temperature sensors, humidity sensors, and vibration sensors deployed in the cargo storage area to obtain environmental monitoring data; adding timestamps to the position data and the environmental monitoring data and converting them into a unified data format, and sending them to a message queue for caching to obtain sensor data.

[0016] Specifically, the positioning sensor can be a GPS module, a BeiDou positioning module, or a combined positioning module integrating multiple satellite positioning systems. The positioning sensor receives satellite signals to calculate the current latitude and longitude coordinates of the transport vehicle, and simultaneously calculates the speed and direction of movement based on position changes over continuous time. For example, the positioning sensor outputs position data at regular intervals, which includes information such as longitude, latitude, velocity vector, and heading angle.

[0017] Environmental monitoring data is obtained by collecting temperature, humidity, and vibration values ​​through temperature sensors, humidity sensors, and vibration acceleration sensors deployed in the cargo storage area.

[0018] In this embodiment, a temperature sensor detects temperature changes within the cargo storage area using a thermistor, a humidity sensor measures relative humidity using a moisture-sensitive material, and a vibration sensor detects the vibration of the cargo during transportation using an accelerometer. It is understood that different types of cargo have different environmental monitoring requirements; for example, cold chain cargo requires high-frequency temperature monitoring, while the monitoring frequency for ordinary cargo can be appropriately reduced.

[0019] The location data and environmental monitoring data are timestamped and converted into a unified data format, and then sent to a message queue for caching to obtain sensor data.

[0020] In this embodiment, the location data and environmental monitoring data come from different types of sensors, and their original output formats may differ. The vehicle-mounted edge device needs to convert these data into a structured data format (such as JSON) and add a timestamp to each data entry. The timestamp records the precise moment the data was collected, which is crucial for subsequent spatiotemporal correlation analysis in data aggregation services. For example, when it is necessary to determine whether "temperature rise" and "vehicle stationary" occur simultaneously, the timestamp can help the system determine the temporal correlation between the two events.

[0021] Subsequently, the in-vehicle edge device sends the formatted sensor data to a message queue for caching. The message queue serves to decouple data producers and consumers. When the amount of data generated by the sensors peaks within a short period, the message queue can smooth out peaks and troughs, preventing data loss due to excessive instantaneous load on the data processing service. Understandably, the data processing service can subscribe to specific topic data streams from the message queue, based on the deployment plan, to receive the required sensor data.

[0022] 102. Determine the deployment plan for data processing services based on the current cargo type and transportation area characteristics; In this embodiment, fixed service deployment strategies can be pre-defined for different types of goods. For example, for cold chain goods, due to their high real-time requirements for temperature monitoring, data filtering services can be deployed on in-vehicle edge devices, while data aggregation and event processing services can be deployed on cloud servers to fully utilize cloud computing resources for complex data analysis. For ordinary goods, all data processing services can be uniformly deployed in the cloud to save computing resources on in-vehicle edge devices.

[0023] Specifically, upon receiving the cargo type identifier, the deployment decision module first reads the deployment strategy record corresponding to that cargo type from a pre-set configuration database. This record stores the mapping relationship between various data processing services and physical devices. For example, when the cargo type identifier is "cold chain vaccine," the deployment decision module reads that the data filtering service should run on the vehicle-mounted edge device, while the data aggregation service and event processing service should run on the cloud server. Then, based on the read mapping relationship, the deployment decision module generates a deployment plan containing the correspondence between each service node and the target deployment device, and distributes this deployment plan to the service management components of each physical device.

[0024] It's important to note that after receiving a deployment plan, the service management component will start the corresponding container or process based on the service nodes specified in the plan. For example, after receiving an instruction to start the data filtering service, the service management component on the vehicle edge device will load the container image of the data filtering service from the local image repository and start the container to run. Simultaneously, the service management component on the cloud server will also start the data aggregation service and event handling service accordingly. The advantage of this fixed deployment strategy is its simple configuration and fast deployment decision-making, but its disadvantage is that it cannot adjust to real-time changes in the transportation environment. For instance, when a vehicle enters an area with weak network coverage, services fixedly deployed in the cloud may fail to function properly due to network interruptions.

[0025] In another embodiment, the service deployment location can be dynamically adjusted based on the current network connectivity status. Specifically, the vehicle-mounted edge device continuously monitors the network signal strength between itself and the cloud server through a network monitoring module. The network monitoring module acquires the current 4G or 5G signal strength value every preset time interval (e.g., per second) and compares this value with a preset signal strength threshold. When the detected network signal strength is greater than a first threshold (e.g., -75dBm), the deployment decision module determines that the current network status is good and the data aggregation service and event processing service can be deployed on the cloud server; when the detected network signal strength is less than a second threshold (e.g., -90dBm), the deployment decision module determines that the network status is poor or about to be interrupted, and these services need to be switched to the vehicle-mounted edge device or the nearest relay node.

[0026] Therefore, when the deployment decision module determines that a service deployment location needs to be switched, it performs the following operations: First, it sends a service start command to the new target deployment device, enabling the corresponding service pre-installed on that device to enter a running state; second, it updates the routing configuration of the message queue, directing data flow to the newly started service instance; finally, after confirming that the new service instance is running normally, it sends a service stop command to the original deployment device, releasing its computing resources. This dynamic switching strategy can adjust the service location according to real-time changes in network conditions, but when network conditions fluctuate frequently, it may lead to frequent service migrations, affecting stability.

[0027] 103. The sensor data is sequentially input into the data filtering service, data aggregation service, and event processing service allocated according to the deployment scheme for processing to obtain abnormal event detection results; In this embodiment, the step of sequentially inputting the sensor data into the data filtering service, data aggregation service, and event processing service allocated according to the deployment scheme to obtain the abnormal event detection result includes: determining the target deployment device corresponding to each service node according to the deployment scheme; subscribing to the sensor data stream from the message queue and distributing it to the corresponding target deployment device; running the data filtering service on the target deployment device to perform threshold filtering on the sensor data stream, retaining abnormal data and discarding normal data to obtain filtered data; inputting the filtered data into the data aggregation service to perform spatiotemporal correlation analysis on the data from multiple sensors, identifying multi-source combined abnormal patterns, and obtaining the abnormal event detection result.

[0028] Specifically, it should be noted that the deployment plan records the mapping relationship between each service node and the target deployment device. For example, the deployment plan may specify that the data filtering service should run on the in-vehicle edge device, the data aggregation service should run on the edge server of the logistics station, and the event processing service should run on the cloud server. After the service management components on each target deployment device start their corresponding services, these services will subscribe to data streams on specific topics from the message queue.

[0029] Specifically, the data filtering service, as the first step in data processing, needs to subscribe to the raw sensor data stream. This service sends a subscription request to the message queue's subscription management module, including the name of the topic to be subscribed to (e.g., "vehicle-sensor-data") and the service's identification information. Upon receiving the subscription request, the message queue pushes newly generated messages under that topic to the target deployment device where the data filtering service resides. Understandably, since the data filtering service may be deployed on different physical devices (vehicle edge devices or relay nodes), the message queue needs to dynamically adjust the data stream distribution target according to the deployment plan.

[0030] In this embodiment, the main function of the data filtering service is to filter out potentially abnormal data from a large amount of sensor data, thereby reducing the amount of data requiring further processing. Upon receiving sensor data, the data filtering service judges the data based on preset threshold conditions. For example, for temperature sensor data, if the detected temperature value is within the normal range (e.g., the temperature of cold chain goods is between 2°C and 8°C), the data is judged as normal and discarded; if the temperature value exceeds the normal range, or the rate of temperature change exceeds a preset rate of change threshold, the data is judged as abnormal and retained.

[0031] Furthermore, the data filtering service can also detect abnormal fluctuations in the data. Specifically, the data filtering service maintains a sliding time window, which stores sensor data from the most recent period. For newly received data, the data filtering service calculates the degree of deviation between the data and the historical data within the window. If the deviation exceeds a preset threshold, it is considered that an abnormal fluctuation has occurred. For example, in a temperature monitoring scenario, if the temperature rises or falls too much in a short period of time, even if the temperature value is still within the normal range, it may be judged as an abnormal fluctuation and the data may be retained.

[0032] It should be noted that by discarding normal data, the data filtering service can significantly reduce the processing load on subsequent data aggregation and event processing services. For example, during normal vehicle operation, environmental parameters such as temperature and humidity of the goods are mostly within normal ranges. The data filtering service can filter out this redundant normal data, passing only a small amount of abnormal data to downstream services, thereby saving network bandwidth and computing resources.

[0033] In this embodiment, the data aggregation service receives filtered data from the data filtering service. This data may come from different types of sensors (such as temperature sensors, GPS sensors, vibration sensors, etc.). The core function of the data aggregation service is to perform correlation analysis on this multi-source data to identify combined anomaly patterns that cannot be detected by a single sensor.

[0034] Specifically, the data aggregation service uses spatiotemporal correlation analysis to determine the correlation between data from different sensors. Spatiotemporal correlation analysis refers to comprehensively considering the temporal and spatial dimensions of the data to make correlation judgments. In the temporal dimension, the data aggregation service uses the timestamps of each data point to determine whether multiple abnormal events occurred within a short period. For example, if the timestamps of abnormal temperature data and GPS data (showing the vehicle is stationary) differ within a preset time window (e.g., within 5 seconds), then these two events are considered temporally correlated. In the spatial dimension, the data aggregation service uses GPS location data to determine the vehicle's location at the time the abnormal event occurred. For example, by querying a preset geographic information database, it can determine whether the vehicle is currently located in a specific area such as a cold storage unloading area or a highway service area.

[0035] Furthermore, the data aggregation service identifies multi-source combined anomaly patterns based on preset association rules. A multi-source combined anomaly pattern refers to an anomaly situation where data from multiple sensors must collectively meet specific conditions for a determination. For example, for the anomaly event of "illegal door opening," a temperature rise alone is insufficient for judgment, as a vehicle exposed to direct sunlight could also cause a temperature increase. The data aggregation service needs to comprehensively assess the following conditions: first, the rate of temperature rise exceeds a preset threshold; second, GPS data shows the vehicle is stationary; and third, GPS location coordinates indicate the vehicle is not currently within the preset cold storage unloading area. Only when all three conditions are met simultaneously does the data aggregation service determine that an "illegal door opening" anomaly event has occurred.

[0036] Understandably, data aggregation services can effectively reduce false alarm and false negative rates through spatiotemporal correlation analysis of multi-source data. Relying solely on threshold judgments from a single sensor may misclassify normal situations as abnormal (e.g., misjudging a normal temperature rise during cold storage unloading as illegal door opening), or it may miss genuine anomalies (e.g., an abnormal door opening where the vehicle is stationary outside the unloading area but the temperature rises at a slow rate). By combining data from multiple sensors and integrating contextual information such as time and location for comprehensive judgment, abnormal events can be identified more accurately.

[0037] Therefore, after completing the spatiotemporal correlation analysis, the data aggregation service outputs abnormal event detection results. These results include the identified abnormal event types (such as "illegal door opening," "abnormal temperature," "severe vibration," etc.), the time of the abnormal event, the vehicle location, and related sensor data values, which are then used by subsequent event processing services.

[0038] 104. Generate early warning information based on the abnormal event detection results and push it to the monitoring terminal through a long connection channel. At the same time, store the cargo status data and the abnormal event detection results in the database for visualization.

[0039] In this embodiment, after receiving the abnormal event detection results, the event processing service extracts key information such as event type, occurrence time, vehicle location, and relevant sensor values, and generates structured warning information based on a preset warning information template. Furthermore, the event processing service sets different warning levels for the warning information according to the severity of the anomaly; for example, a slight temperature exceedance is set as a low-level warning, while a serious anomaly such as detecting unauthorized door opening is set as a high-level warning.

[0040] After generating an alert, the event processing service pushes the alert to the monitoring terminal via a persistent connection channel. A persistent connection channel refers to a persistent, two-way communication connection established between the monitoring terminal and the server. The server can proactively push messages to the client without requiring repeated requests from the client, thus reducing message push latency. The monitoring terminal establishes a persistent connection with the server upon startup. The server maintains the connection information of all online terminals, and when an alert is generated, it pushes the alert through the corresponding persistent connection channel based on the target recipient.

[0041] Meanwhile, the event handling service stores cargo status data and anomaly detection results in the database. Cargo status data includes real-time location, temperature, humidity, and other environmental parameters during transportation, while anomaly detection results record detailed information on various anomalies. This data, once stored, can be accessed by monitoring dashboards or management backends to generate visual charts such as temperature change curves, transportation trajectory maps, and anomaly statistics tables, helping managers intuitively understand the cargo transportation status.

[0042] In this embodiment, real-time data during cargo transportation is collected by multiple types of sensors deployed on transport vehicles, yielding sensor data. A deployment scheme for data processing services is determined based on the current cargo type and transportation area characteristics. The sensor data is sequentially input into data filtering, data aggregation, and event processing services allocated according to the deployment scheme for processing, resulting in abnormal event detection results. Early warning information is generated based on the abnormal event detection results and pushed to the monitoring terminal, while also being stored in a database for visualization. This invention can dynamically adjust the deployment location of data processing services according to cargo type and transportation area characteristics, solving the problem of monitoring interruptions in areas with unstable networks, meeting the real-time early warning needs of high-value cargo, and optimizing the resource utilization efficiency of edge devices and the cloud.

[0043] Please see Figure 2 Another embodiment of the cargo information monitoring and management method in this application includes: 201. Real-time data during cargo transportation is collected by various types of sensors deployed on transport vehicles to obtain sensor data; In this embodiment, step 201 is similar to step 101 in the first embodiment, and will not be described again here.

[0044] 202. Determine the area of ​​interest based on the cargo type identifier and the current location coordinates of the transport vehicle, wherein the area of ​​interest includes at least one of high-risk transport sections, areas with weak network coverage, and areas for transporting high-value goods; In this embodiment, the monitored area refers to a specific area that requires close monitoring during cargo transportation. Due to their unique geographical environment, network conditions, or cargo value, these areas necessitate more intensive data monitoring strategies or specific service deployment schemes. Based on the cargo type identifier and the current location coordinates of the transport vehicle, it is determined whether the vehicle has entered or is about to enter the monitored area.

[0045] Specifically, the system first queries the geographic information database for regional attribute information related to the current location coordinates. The geographic information database pre-stores attribute labels for various regions; for example, a road segment might be marked as a "mountain tunnel," indicating a region with weak network coverage, or as an "accident-prone section," indicating a high-risk transportation route. The vehicle's current latitude and longitude coordinates are then compared with the regional boundaries in the geographic information database to determine whether the vehicle is located within a specific marked region.

[0046] The system also considers cargo type identification to determine whether the current area should be designated as an area of ​​concern. The so-called high-value cargo transportation area does not refer to a fixed geographical region, but rather any area that high-value goods (such as cold chain vaccines or valuables) pass through during transportation. All such areas should be considered areas of concern to ensure close monitoring of these goods throughout their journey. For example, when the cargo type is identified as "cold chain vaccines," the current area will be designated as an area of ​​concern regardless of whether the vehicle is currently on a city road or a highway.

[0047] The determination of areas of interest can also be predicted by combining vehicle transport trajectories and historical data. For example, based on the vehicle's current location coordinates, direction of movement, and speed, the location the vehicle will reach in the next few minutes can be predicted. If the predicted location is in an area with weak network coverage or a high-risk road section, the area the vehicle is about to enter can be identified as an area of ​​interest in advance, allowing for adjustments to service deployment plans. This predictive area of ​​interest determination mechanism ensures that relevant data processing services have been deployed and adjusted before the vehicle actually enters a special area, avoiding monitoring interruptions caused by temporary adjustments.

[0048] The division of areas of concern is dynamic. When a vehicle leaves a region with weak network coverage or a high-risk road section, the determination of the area of ​​concern will be updated accordingly, so that the area will no longer be considered an area of ​​concern. At the same time, if the goods are handed over or sorted during transportation, resulting in a change in the type of goods (such as changing from cold chain goods to general goods), the area of ​​concern will be reassessed and the monitoring strategy will be adjusted.

[0049] 203. Obtain available computing resources of the vehicle-mounted edge device, network connection status of the relay node, and communication latency of the cloud server to obtain device resource status information; In this embodiment, the device resource status information reflects the current available resources and network connectivity of each physical device. This information is crucial for subsequent service deployment decisions. It is necessary to obtain the real-time resource status of the vehicle-mounted edge devices, relay nodes, and cloud servers to ensure that the selected target deployment devices can meet the resource requirements for service operation.

[0050] Specifically, the available computing resources of an in-vehicle edge device mainly include CPU utilization, memory usage, and remaining storage space. A resource monitoring component running on the in-vehicle edge device periodically collects this resource usage data and calculates the current available computing resources. For example, if the in-vehicle edge device has a total CPU capacity of four cores, and two cores are currently occupied by other processes, then two CPU cores are available. The resource monitoring component reports this available resource information to the system for evaluation when allocating services.

[0051] The network connectivity status of relay nodes reflects the network connectivity and quality between the vehicle-mounted edge device and the relay node. Network connectivity status is typically acquired through active probing, whereby the vehicle-mounted edge device periodically sends probe messages (such as ICMP ping messages or application-layer heartbeat messages) to known relay nodes and determines the network connectivity status based on the response to these messages. If a response is received from the relay node within a preset time, the network connection is considered normal; otherwise, if no response is received within the timeout period, the network connection is considered interrupted or unreachable. Furthermore, network connectivity status can also include quality indicators such as network signal strength, packet loss rate, and network jitter, which reflect the stability of the network connection.

[0052] Communication latency in a cloud server refers to the time elapsed from when a vehicle-mounted edge device sends data to the cloud server to when it receives a response. Communication latency can be measured using round-trip time (RTT) testing. The vehicle-mounted edge device sends a timestamped test message to the cloud server, which immediately responds. The vehicle-mounted edge device calculates the round-trip time based on the sending and receiving timestamps. Communication latency reflects the speed of data transmission between the vehicle-mounted edge device and the cloud server. For data requiring real-time processing (such as temperature monitoring of cold chain goods), communication latency is a crucial indicator for evaluating the suitability of a cloud server as a target deployment device.

[0053] Device resource status information is dynamic. The available computing resources of in-vehicle edge devices change as services are started and stopped; the network connection status of relay nodes changes as vehicles move and the network environment changes; and the communication latency of cloud servers fluctuates due to network congestion. Therefore, it is necessary to continuously obtain the latest device resource status information so that service deployment plans can be adjusted in a timely manner when significant changes occur in device resource status.

[0054] 204. Based on the region type of the region of interest and the device resource status information, assign target deployment devices to the data filtering service, data aggregation service and event processing service respectively to obtain a deployment plan; In this embodiment, the step of allocating target deployment devices for the data filtering service, data aggregation service, and event processing service according to the region type of the region of interest and the device resource status information to obtain a deployment scheme includes: constructing a service function tree containing the data filtering service, the data aggregation service, and the event processing service based on the cargo type identifier; determining the resource constraints of each service node in the service function tree, including sensor coverage constraints, device computing resource constraints, network latency constraints, and link capacity constraints; and sequentially selecting target deployment devices that meet the resource constraints from the vehicle edge device, the relay node, and the cloud server for each service node in the service function tree to obtain a deployment scheme.

[0055] Specifically, a service function tree is a hierarchical structure used to describe the dependencies and data flow between data processing services. In a service function tree, each node represents a data processing service, and the connections between nodes indicate the direction of data flow. Data flows from the leaf nodes (data filtering services) to the root node (event processing services), passing through data aggregation service nodes in between.

[0056] Specifically, based on the cargo type identifier, a corresponding template is selected from a pre-defined service function tree template library. This library stores service function tree structures designed for different cargo types. For example, a service function tree template for cold chain cargo includes multiple filtering service nodes such as temperature filtering, humidity filtering, and GPS filtering. The outputs of these filtering service nodes converge to an environmental data aggregation service node, which is then passed to an event processing service node. A service function tree template for ordinary cargo might only include a GPS filtering service and a simplified event processing service. By using different templates, corresponding service function tree structures can be constructed according to the monitoring needs of different cargo types.

[0057] Sensor coverage constraints refer to the requirement that certain service nodes must be deployed on devices that have direct access to specific sensors. For example, a temperature filtering service node needs to receive raw data from a temperature sensor, therefore this service can only be deployed on the vehicle edge device where the temperature sensor is located. This constraint exists because sensor data acquisition is physically bound, and the data filtering service needs to process data close to the data source.

[0058] Device computing resource constraints refer to the requirement that devices must possess sufficient CPU and memory resources to run service nodes. Network latency constraints are typically achieved by limiting the number of network hops between service nodes, such as requiring that the number of hops between the data filtering service and the data aggregation service not exceed three hops, to ensure that data transmission latency meets real-time requirements. Link capacity constraints refer to the requirement that the network bandwidth occupied by data transmission between service nodes cannot exceed the maximum transmission capacity of the physical link. In this embodiment, a bottom-up traversal strategy is adopted, starting from the leaf nodes of the service function tree and selecting target deployment devices for each service node layer by layer upwards. Bottom-up means prioritizing the selection of devices for data filtering service nodes, followed by data aggregation service nodes and event processing service nodes in sequence. The advantage of this traversal order is that data filtering service nodes are usually limited by sensor coverage constraints, resulting in a smaller range of selectable devices. Prioritizing the determination of the deployment locations of these nodes provides clearer constraints for the deployment decisions of subsequent nodes.

[0059] Specifically, for the service node to be assigned, candidate devices that meet the sensor coverage constraints are first selected from all physical devices. Then, it is checked whether the available computing resources of the candidate devices meet the resource requirements of the service node. Furthermore, network latency constraints and link capacity constraints are checked, the network hop count between the candidate device and the device where the preceding service node is located is calculated, and whether the traversed physical links have sufficient remaining bandwidth. After completing the checks on all constraints, one of the remaining candidate devices is selected as the target deployment device for the current service node, and the available resource status of that device is updated.

[0060] It should be noted that after the device allocation for all service nodes in the service function tree is completed, a complete deployment plan will be generated. This deployment plan records the mapping relationship between each service node and its target deployment device, as well as the data transmission path between service nodes.

[0061] Furthermore, the step of constructing a service function tree containing the data filtering service, the data aggregation service, and the event processing service based on the cargo type identifier includes: selecting a corresponding service function tree template from a preset service function tree template library based on the cargo type identifier, wherein the service function tree template library includes a first template for cold chain cargo, a second template for hazardous chemicals, and a third template for general cargo; determining the sensor type and sampling frequency required for the data filtering service, and the data association rules required for the data aggregation service, based on the selected service function tree template; and constructing the service function tree based on the determined sensor type, sampling frequency, and data association rules, wherein when the transport vehicle leaves the area of ​​interest, the service function tree is pruned, removing the service node of the data aggregation service and retaining only the service nodes of the data filtering service and the event processing service.

[0062] Specifically, in this embodiment, the service function tree template library pre-stores service function tree structure templates designed for different cargo types. These templates reflect the differentiated needs of different cargo types in the transportation monitoring process. For example, cold chain cargo has high requirements for temperature and humidity monitoring, requiring intensive environmental data collection and complex multi-source data correlation analysis; hazardous chemicals require key monitoring of temperature, vibration, and possible gas leaks, and need rapid anomaly response mechanisms; while general cargo mainly focuses on location tracking and basic transportation status monitoring, with relatively simple data processing requirements.

[0063] Specifically, the first template for cold chain goods defines multiple leaf nodes, including temperature filtering service nodes, humidity filtering service nodes, and GPS filtering service nodes. The outputs of these leaf nodes converge to an environmental data aggregation service node, which is responsible for performing spatiotemporal correlation analysis on temperature, humidity, and location data. The second template for hazardous chemicals, in addition to temperature and GPS filtering service nodes, also includes vibration filtering service nodes and gas sensor filtering service nodes. Its aggregation service node is configured with anomaly pattern recognition rules specific to hazardous chemicals. The third template for general goods has the simplest structure, typically containing only a GPS filtering service node and a simplified event processing service node, without complex data aggregation services.

[0064] The template library is designed to quickly determine the appropriate service function tree structure based on the type of goods, without having to redesign the combination and connection relationships of service nodes each time. This template-based approach ensures the relevance of monitoring strategies for different types of goods while avoiding the computational overhead that could result from real-time construction of the service function tree.

[0065] In this embodiment, the service function tree template not only defines the structure of the service nodes but also includes the configuration of the operating parameters for each service node. For the data filtering service, the template specifies the type of sensor data that the service needs to receive, as well as the sensor sampling frequency. The sampling frequency refers to the number of times a sensor generates data per unit time. Different types of goods have different requirements for sampling frequency. Cold chain goods, due to the potential for temperature changes to affect their quality in a short period, typically require a higher sampling frequency for temperature sensors; while the GPS positioning sampling frequency for ordinary goods can be appropriately reduced to save energy and network bandwidth.

[0066] Furthermore, the template also defines the data association rules required for the data aggregation service. These data association rules refer to the logical conditions used by the aggregation service to determine abnormal events when comprehensively analyzing data from multiple sensors. For example, the data association rules in the cold chain cargo template might stipulate that a "illegal door opening" abnormal event occurs when the temperature rise rate exceeds a certain range per minute, GPS data shows the vehicle is stationary, and the vehicle is not within the cold storage unloading area based on its location coordinates. These association rules embody the combined judgment logic of multi-source data and are the key difference between data aggregation services and simple data filtering.

[0067] Understandably, by pre-configuring sensor types, sampling frequencies, and data association rules through templates, the service function tree can immediately run according to the predetermined strategy after instantiation, ensuring that the monitoring strategy matches the characteristics of the cargo type.

[0068] In this embodiment, the dynamic pruning of the service function tree is a mechanism for adjusting the monitoring intensity according to changes in the transportation environment. When the transport vehicle is within the area of ​​interest, because this area is a high-risk road segment, a weak network coverage area, or transports high-value goods, a complete service function tree is required for comprehensive monitoring. However, when the vehicle leaves the area of ​​interest and enters a regular transportation segment, the monitoring requirement decreases, and the service function tree structure can be simplified to save computing resources and network bandwidth.

[0069] Specifically, the service function tree is pruned by stopping the data aggregation service node. When a vehicle is detected to have left the area of ​​interest, a service stop command is sent to the device where the data aggregation service is deployed, causing the service to enter a dormant state or stop running completely. Simultaneously, the message queue routing configuration is updated so that filtered data output by the data filtering service is no longer sent to the data aggregation service, but directly to the event processing service.

[0070] In the pruned service function tree, the event handling service receives filtered data from various data filtering services, rather than data that has undergone aggregation and analysis. At this point, the event handling service employs simplified anomaly detection logic, typically performing threshold checks on single sensor data instead of conducting spatiotemporal correlation analysis of multi-source data. For example, in non-interested areas, the event handling service might only determine if the temperature exceeds the normal range, without comprehensively considering the correlation between temperature changes and factors such as vehicle location and dwell time.

[0071] By dynamically pruning the service function tree, comprehensive monitoring can be ensured within the areas of interest while reducing resource consumption in non-interested areas. This mechanism of dynamically adjusting monitoring intensity based on the transportation environment avoids the resource waste caused by applying uniform high-intensity monitoring to all transportation segments, while ensuring that important anomalies are not missed due to insufficient monitoring in key areas.

[0072] Furthermore, after each service node in the service function tree selects a target deployment device that meets the resource constraints from the vehicle edge device, the relay node, and the cloud server to obtain a deployment scheme, the method further includes: when the target deployment device selected for the current service node results in no available device that meets the constraints for subsequent service nodes, the deployment decision of the current service node is revoked, and a new target deployment device is selected from the remaining candidate devices; when a candidate device meets the sensor coverage constraint but not the device computing resource constraint, a breadth-first search is performed starting from the candidate device to find the available device in the physical network that has the fewest hops from the candidate device and meets the resource constraints as the target deployment device, and a data forwarding path is established from the candidate device to the available device.

[0073] Specifically, in this embodiment, when selecting target deployment devices for service nodes, a choice that appears to satisfy all constraints at the time may result in subsequent service nodes being unable to find suitable devices. This situation typically occurs in scenarios with limited device resources or complex network topologies. For example, when a vehicle-mounted edge device is selected for a data filtering service, most of the device's computing resources are occupied, causing the subsequent data aggregation service to be deployed to be unable to find sufficient computing resources on any device that meets network latency constraints.

[0074] Specifically, when searching for target deployment devices for subsequent service nodes, all candidate devices are traversed and each one is checked to see if it meets the resource constraints. If, after the traversal, no device is found to simultaneously meet all constraints, the current deployment plan is deemed problematic. In this case, a backtracking mechanism is triggered to revert the most recent deployment decision made for the current service node.

[0075] The so-called reversal of a deployment decision refers to removing the mapping relationship between the current service node and the target deployment device from the deployment plan, releasing the computing resources previously occupied by the current service node, and restoring the device to its available resource state. Then, the currently selected target deployment device is added to the exclusion list, and a new target deployment device is selected from the remaining candidate devices. This newly selected device must not have been tried before to avoid a cycle of repeated selections.

[0076] It's important to note that the backtracking mechanism is essentially a trial-and-error strategy. When the current decision path fails to provide a complete deployment solution, the most recent decision is reversed, and other possible options are tried to explore different decision paths until a feasible solution is found that allocates suitable equipment to all service nodes. This strategy is particularly important when there are a large number of service nodes, limited equipment resources, or complex network topology constraints, as it can effectively improve the success rate of deployment solutions.

[0077] In this embodiment, the extended search mechanism handles a special case: a candidate device can access the sensors required by the service node (satisfying the sensor coverage constraint), but its own computing resources are insufficient to run the service node (not satisfying the device computing resource constraint). In this situation, simply abandoning the candidate device might result in not finding other devices that satisfy the sensor coverage constraint. The extended search mechanism, by searching for other devices closer to the candidate device in the physical network, allows the service node to be deployed on devices with sufficient computing resources, while simultaneously acquiring sensor data from the candidate device through the data forwarding path.

[0078] Specifically, starting with candidate devices that do not meet the computational resource constraints, a breadth-first search is performed in the physical network topology. Breadth-first search is a graph traversal algorithm that prioritizes exploring nodes closer to the starting point. In this embodiment, the physical network topology is abstracted as a graph structure, where each physical device is a node in the graph, and the network connections between devices are edges. The breadth-first search begins with the starting device and first checks devices directly connected to it (i.e., devices within one hop). If any of these devices is available and meets all resource constraints, the device with the fewest hops is selected as the target deployment device. If no available device is within one hop, the search continues to devices within two hops, and so on, until a device meeting the conditions is found or the preset maximum search hop count is reached.

[0079] Furthermore, after finding available devices through breadth-first search, a data forwarding path needs to be established between the candidate devices (i.e., devices with sensors) and the target deployment device (i.e., the device actually running the service). The data forwarding path refers to the sequence of intermediate nodes that sensor data passes through when transmitting from the candidate device to the target deployment device. For example, if the target deployment device is two hops away from the candidate device, the data forwarding path includes one intermediate node; the sensor data is first sent from the candidate device to the intermediate node, and then forwarded by the intermediate node to the target deployment device.

[0080] Understandably, establishing a data forwarding path requires configuring data forwarding rules on candidate devices and intermediate nodes. Candidate devices need to forward received sensor data to the next-hop node instead of directly handing it over to the local service node (due to insufficient local resources). After receiving the data, the intermediate node continues to pass it to the target deployment device according to the forwarding rules. Through this multi-hop forwarding mechanism, service nodes can operate on devices far from the sensors while still receiving the necessary sensor data.

[0081] It's important to note that the core value of the extended search mechanism lies in improving the flexibility and success rate of deployment schemes. When there are conflicts between sensor coverage constraints and device computing resource constraints, extended search decouples the originally bound "data acquisition location" and "data processing location" by introducing a data forwarding path. This allows for the search for suitable target deployment devices over a wider range, thereby reducing the probability of deployment failure due to insufficient device resources.

[0082] 205. The sensor data is sequentially input into the data filtering service, data aggregation service, and event processing service allocated according to the deployment scheme for processing to obtain the abnormal event detection results; 206. Generate early warning information based on the abnormal event detection results and push it to the monitoring terminal through a long connection channel. At the same time, store the cargo status data and the abnormal event detection results in the database for visualization.

[0083] In this embodiment, steps 205-206 are similar to steps 103-104 in the first embodiment, and will not be described again here.

[0084] In this embodiment, real-time data during cargo transportation is collected by multiple types of sensors deployed on transport vehicles, yielding sensor data. A deployment scheme for data processing services is determined based on the current cargo type and transportation area characteristics. The sensor data is sequentially input into data filtering, data aggregation, and event processing services allocated according to the deployment scheme for processing, resulting in abnormal event detection results. Early warning information is generated based on the abnormal event detection results and pushed to the monitoring terminal, while also being stored in a database for visualization. This invention can dynamically adjust the deployment location of data processing services according to cargo type and transportation area characteristics, solving the problem of monitoring interruptions in areas with unstable networks, meeting the real-time early warning needs of high-value cargo, and optimizing the resource utilization efficiency of edge devices and the cloud.

[0085] The above describes the cargo information monitoring and management method in the embodiments of the present invention. The following describes the cargo information monitoring and management device in the embodiments of the present invention. Please refer to [link to relevant documentation] for details on this cargo information monitoring and management device. Figure 3One embodiment of the cargo information monitoring and management device in this invention includes: The data acquisition module 301 is used to collect real-time data during the transportation of goods through multiple types of sensors deployed on the transport vehicle, and obtain sensor data. Deployment decision module 302 is used to determine the deployment scheme of data processing services based on the current cargo type and transportation area characteristics; Anomaly detection module 303 is used to sequentially input the sensor data into the data filtering service, data aggregation service and event processing service allocated according to the deployment scheme for processing, and obtain anomaly event detection results; The early warning display module 304 is used to generate early warning information based on the abnormal event detection results and push it to the monitoring terminal through a long connection channel. At the same time, it stores the cargo status data and the abnormal event detection results in the database for visualization display.

[0086] In this embodiment of the invention, the cargo information monitoring and management device operates the aforementioned cargo information monitoring and management method. The device collects real-time data during cargo transportation using multiple types of sensors deployed on transport vehicles, obtaining sensor data. Based on the current cargo type and transportation area characteristics, it determines a deployment scheme for data processing services. The sensor data is sequentially input into data filtering, data aggregation, and event processing services allocated according to the deployment scheme for processing, resulting in abnormal event detection results. Based on the abnormal event detection results, early warning information is generated and pushed to the monitoring terminal, while simultaneously being stored in a database for visualization. This invention can dynamically adjust the deployment location of data processing services according to cargo type and transportation area characteristics, solving the problem of monitoring interruptions in areas with unstable networks, meeting the real-time early warning needs of high-value cargo, and optimizing the resource utilization efficiency of edge devices and the cloud.

[0087] above Figure 3 The cargo information monitoring and management device in this embodiment of the invention will be described in detail from the perspective of unitized functional entities. The cargo information monitoring and management equipment in this embodiment of the invention will be described in detail from the perspective of hardware processing.

[0088] Figure 4This is a schematic diagram of the structure of a cargo information monitoring and management device 400 provided in an embodiment of the present invention. The cargo information monitoring and management device 400 can vary significantly due to different configurations or performance. It may include one or more central processing units (CPUs) 410 (e.g., one or more processors) and a memory 420, and one or more storage media 430 (e.g., one or more mass storage devices) for storing application programs 433 or data 432. The memory 420 and storage media 430 can be temporary or persistent storage. The program stored in the storage media 430 may include one or more units (not shown in the diagram), each unit may include a series of instruction operations on the cargo information monitoring and management device 400. Furthermore, the processor 410 may be configured to communicate with the storage media 430 and execute the series of instruction operations in the storage media 430 on the cargo information monitoring and management device 400 to implement the steps of the aforementioned cargo information monitoring and management method.

[0089] The cargo information monitoring and management device 400 may also include one or more power supplies 440, one or more wired or wireless network interfaces 450, one or more input / output interfaces 460, and / or one or more operating systems 431, such as Windows Server, Mac OS X, Unix, Linux, FreeBSD, etc. Those skilled in the art will understand that... Figure 4 The illustrated cargo information monitoring and management device structure does not constitute a limitation on the cargo information monitoring and management device provided by the present invention. It may include more or fewer components than illustrated, or combine certain components, or have different component arrangements.

[0090] The present invention also provides a computer-readable storage medium, which can be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium, wherein the computer-readable storage medium stores instructions that, when the instructions are executed on a computer, cause the computer to perform the steps of the cargo information monitoring and management method.

[0091] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system, device, or unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0092] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0093] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for monitoring and managing cargo information, characterized in that, The cargo information monitoring and management method includes: Sensor data is obtained by collecting real-time data during the transportation process using various types of sensors deployed on transport vehicles. Determine the deployment plan for data processing services based on the current cargo type and transportation area characteristics; The sensor data is sequentially input into the data filtering service, data aggregation service, and event processing service allocated according to the deployment scheme for processing, to obtain the abnormal event detection results; Based on the abnormal event detection results, an early warning message is generated and pushed to the monitoring terminal through a long connection channel. At the same time, the cargo status data and the abnormal event detection results are stored in the database for visualization.

2. The cargo information monitoring and management method according to claim 1, characterized in that, The process of collecting real-time data during cargo transportation through multiple types of sensors deployed on transport vehicles yields sensor data including: Location data is obtained by collecting the current location coordinates, speed, and direction of transport of the transport vehicle through positioning sensors deployed on the vehicle. Environmental monitoring data is obtained by collecting temperature, humidity and vibration acceleration values ​​by deploying temperature sensors, humidity sensors and vibration sensors in the cargo storage area; The location data and environmental monitoring data are timestamped and converted into a unified data format, and then sent to a message queue for caching to obtain sensor data.

3. The cargo information monitoring and management method according to claim 1, characterized in that, The deployment scheme for determining data processing services based on the current cargo type and transportation area characteristics includes: The area of ​​interest is determined based on the cargo type identifier and the current location coordinates of the transport vehicle. The area of ​​interest includes at least one of high-risk transport sections, areas with weak network coverage, and areas for transporting high-value goods. The available computing resources of the vehicle-mounted edge device, the network connection status of the relay node, and the communication latency of the cloud server are obtained to obtain device resource status information; Based on the region type of the region of interest and the device resource status information, target deployment devices are allocated to the data filtering service, data aggregation service and event processing service respectively to obtain a deployment plan.

4. The cargo information monitoring and management method according to claim 3, characterized in that, The step of allocating target deployment devices to the data filtering service, data aggregation service, and event processing service based on the region type of the region of interest and the device resource status information, resulting in a deployment scheme, includes: Construct a service function tree based on the cargo type identifier, which includes the data filtering service, the data aggregation service, and the event processing service; Determine the resource constraints for each service node in the service function tree, including sensor coverage constraints, device computing resource constraints, network latency constraints, and link capacity constraints. Each service node in the service function tree sequentially selects a target deployment device that meets the resource constraints from the vehicle edge device, the relay node, and the cloud server to obtain a deployment scheme.

5. The cargo information monitoring and management method according to claim 4, characterized in that, The process of constructing a service function tree based on the cargo type identifier, including the data filtering service, the data aggregation service, and the event processing service, includes: According to the cargo type identifier, the corresponding service function tree template is selected from the preset service function tree template library. The service function tree template library includes a first template for cold chain cargo, a second template for hazardous chemicals, and a third template for general cargo. The sensor type and sampling frequency required for the data filtering service, as well as the data association rules required for the data aggregation service, are determined based on the selected service function tree template. The service function tree is constructed based on the determined sensor type, sampling frequency, and data association rules. When the transport vehicle leaves the area of ​​interest, the service function tree is pruned, removing the service node of the data aggregation service and retaining only the service nodes of the data filtering service and the event processing service.

6. The cargo information monitoring and management method according to claim 4, characterized in that, After each service node in the service function tree selects a target deployment device that meets the resource constraints from the vehicle edge device, the relay node, and the cloud server to obtain a deployment plan, the process further includes: If the target deployment device selected for the current service node results in no available device for subsequent service nodes that meets the constraints, the deployment decision for the current service node is revoked, and a new target deployment device is selected from the remaining candidate devices. When a candidate device satisfies the sensor coverage constraint but not the device computing resource constraint, a breadth-first search is performed starting from the candidate device to find the available device in the physical network that has the fewest hops from the candidate device and satisfies the resource constraint condition, and a data forwarding path is established from the candidate device to the available device.

7. The cargo information monitoring and management method according to claim 1, characterized in that, The process of sequentially inputting the sensor data into the data filtering service, data aggregation service, and event processing service allocated according to the deployment scheme for processing, and obtaining the abnormal event detection result includes: Based on the deployment scheme, the target deployment devices corresponding to each service node are determined, and the sensor data stream is subscribed from the message queue and distributed to the corresponding target deployment devices. A data filtering service is run on the target deployment device to perform threshold filtering on the sensor data stream, retaining abnormal data and discarding normal data to obtain filtered data. The filtered data is input into the data aggregation service to perform spatiotemporal correlation analysis on data from multiple sensors, identify multi-source combined anomaly patterns, and obtain anomaly event detection results.

8. A cargo information monitoring and management device, characterized in that, The cargo information monitoring and management device includes: The data acquisition module is used to collect real-time data during the transportation of goods through various types of sensors deployed on transport vehicles, and obtain sensor data. The deployment decision module is used to determine the deployment plan for data processing services based on the current cargo type and transportation area characteristics; Anomaly detection module is used to sequentially input the sensor data into the data filtering service, data aggregation service and event processing service allocated according to the deployment scheme for processing, and obtain anomaly event detection results; The early warning display module is used to generate early warning information based on the abnormal event detection results and push it to the monitoring terminal through a long connection channel. At the same time, it stores the cargo status data and the abnormal event detection results in the database for visualization display.

9. A cargo information monitoring and management device, characterized in that, The cargo information monitoring and management device includes: a memory and at least one processor, wherein the memory stores instructions; The at least one processor invokes the instructions in the memory to cause the cargo information monitoring and management device to perform the steps of the cargo information monitoring and management method as described in any one of claims 1-7.

10. A computer-readable storage medium storing instructions thereon, characterized in that, When the instruction is executed by the processor, it implements the steps of the cargo information monitoring and management method as described in any one of claims 1-7.

Images