Logistics vehicle-mounted Internet of Things data processing device and method based on edge calculation

Abstract

The invention relates to the technical field of intelligent logistics and Internet of Things, in particular to a logistics vehicle-mounted Internet of Things data processing device and method based on edge computing, and the processing method comprises the following steps: S1, collecting the multi-source sensing data of a transport vehicle in real time; s2, executing a preset security initialization and equipment identity verification process; s3, generating a risk prediction result; s4, generating a key data packet and uploading the key data packet to the cloud platform; s5, starting a corresponding emergency response process based on the type of the abnormality judgment result; by introducing a safety initialization and equipment identity dual verification mechanism, equipment credibility and system safety are guaranteed from the source, millisecond-level local identification and early warning of abnormal events are realized, the problems of large cloud processing delay and strong network dependence are fundamentally solved, a complete closed loop from on-site rapid processing to multi-department cooperative scheduling is formed, and the system reliability is improved. And the safety management level of transportation of high-risk goods such as dangerous chemicals is obviously improved.

Description

Technical Field

[0001] This invention relates to the technical field of smart logistics and the Internet of Things, and in particular to a logistics vehicle-mounted Internet of Things data processing device and method based on edge computing. Background Technology

[0002] With the intelligent development of the logistics and transportation industry, vehicle-mounted Internet of Things (IoT) systems have been widely applied to vehicle monitoring, cargo status sensing, and transportation management. Current technologies primarily rely on centralized cloud platforms for data processing and analysis. This is especially true given the increasingly stringent safety management requirements for the transportation of hazardous chemicals. Traditional logistics and transportation management systems, which largely depend on centralized cloud platforms for data processing, suffer from problems such as large data transmission delays, strong network dependence, and insufficient real-time performance. Particularly in the transportation of hazardous chemicals, the inability to achieve second-level response in the event of leaks, overloading, or route deviations can easily lead to safety accidents. Furthermore, existing IoT terminal devices have security vulnerabilities during the startup phase, such as malicious detection and data tampering, affecting the overall security of the system. Summary of the Invention

[0003] To address the technical problems existing in the background art, this invention proposes a logistics vehicle-mounted Internet of Things (IoT) data processing device and method based on edge computing, the specific solution of which is as follows: A logistics vehicle IoT data processing method based on edge computing includes the following steps: S1. Real-time acquisition of multi-source sensor data of transport vehicles, including vehicle status data, cargo status data and environmental perception data; S2. Execute the preset security initialization and device authentication process, and enter the secure operation state after successful authentication; S3. Under the safe operating state, based on the multi-source sensor data, generate fused data; perform rule matching analysis on the fused data to generate anomaly determination results; perform machine learning model inference analysis on the fused data to generate risk prediction results; S4. When the anomaly determination result shows that there is an abnormal event, execute a local early warning operation, and based on the abnormal event, extract the corresponding key data fragments from the fused data, process the key data fragments, generate key data packets, and upload them to the cloud platform. S5. The cloud platform receives and parses the critical data packet, obtains the anomaly determination result, and initiates the corresponding emergency response process based on the type of the anomaly determination result.

[0004] Furthermore, in S1, the vehicle status data includes position, speed, acceleration, and tire pressure information; the cargo status data includes temperature, humidity, vibration amplitude, tilt angle, pressure value, and gas concentration information; and the environmental perception data includes video streams and external meteorological information.

[0005] Furthermore, in S2, the preset security initialization and device authentication process is executed as follows: Read the boot flag and determine the boot type based on the boot flag; If the result indicates that it is a first-time boot, then a hardware self-test is performed to generate a pin status list and the device's unique machine code is read. The pin status list and the unique machine code are encrypted to generate verification request data; Receive a response to the verification request data, the response being generated after comparison and verification with a pre-stored database of legitimate device information; If the response is a successful verification response, the corresponding execution code is written, the startup flag is modified, and the system restarts; if the response is a failed verification response, the startup flag is modified, and the system enters restricted mode.

[0006] Furthermore, the response is generated after comparison and verification with a pre-stored legitimate device information database, as follows: determining whether the unique machine code exists in the legitimate device list, and determining whether the matching degree between the pin status list and the pre-stored baseline pin status list exceeds a preset threshold.

[0007] Furthermore, in S3, rule matching analysis is performed on the fused data to generate anomaly judgment results, as follows: the parameters in the fused data are compared with preset rule thresholds in real time to generate anomaly judgment results. The preset rule thresholds include thresholds for judging speeding, route deviation, fatigue driving, excessive temperature, excessive vibration, or excessive gas concentration.

[0008] Furthermore, the fused data is subjected to machine learning model inference analysis to generate risk prediction results, as follows: The fused data is input into a pre-trained and deployed machine learning model to obtain at least one risk prediction indicator among the vehicle component failure probability, cargo deterioration risk level, or traffic accident occurrence probability, and risk prediction results are generated.

[0009] Furthermore, in S4, the execution of the local early warning operation includes at least one of triggering an audible and visual alarm, displaying early warning information, or sending a voice prompt signal.

[0010] Furthermore, in S5, the corresponding emergency response process is initiated as follows: based on the type and level of the anomaly determination result, an emergency plan template is matched to generate an emergency report, and the emergency report is pushed to the preset regulatory department information system.

[0011] An edge computing-based in-vehicle IoT data processing device for logistics includes: The data acquisition module is used to collect multi-source sensor data of the transport vehicle in real time. The multi-source sensor data includes vehicle status data, cargo status data and environmental perception data. The initialization verification module is used to execute the preset security initialization and device authentication process, and enters the secure operation state after successful verification; An edge processing module is used to generate fused data based on the multi-source sensor data under the safe operating state; perform rule matching analysis on the fused data to generate anomaly determination results; and perform machine learning model inference analysis on the fused data to generate risk prediction results. The early warning reporting module is used to perform local early warning operations when the anomaly determination result shows that there is an abnormal event, and based on the abnormal event, extract the corresponding key data fragments from the fused data, process the key data fragments, generate key data packets, and upload them to the cloud platform. The cloud response module is used by the cloud platform to receive and parse the critical data packets, obtain the anomaly determination result, and initiate the corresponding emergency response process based on the type of the anomaly determination result.

[0012] Compared with the prior art, the present invention can achieve at least the following beneficial effects: 1. This invention generates anomaly detection results without uploading all raw data to the cloud through data fusion, rule matching, and machine learning inference. Upon detecting an anomaly, it immediately executes local warnings, enabling rapid on-site response and resolving latency issues caused by network transmission and cloud processing. This is particularly beneficial for the immediate handling of emergencies such as hazardous chemical leaks. Anomaly detection and warning do not rely on a continuous and stable network connection, allowing independent operation even during network outages. Only filtered and compressed key data packets are asynchronously uploaded to the cloud platform, significantly reducing reliance on network bandwidth and continuity, and improving the system's robustness in remote or mobile environments. Through secure initialization and device authentication processes, it ensures that only legitimate and tamper-proof devices can enter a secure operating state, mitigating the risks of unauthorized terminal access and malicious firmware tampering. By automatically parsing data, matching contingency plans, and initiating cross-departmental emergency response processes through the cloud platform, it upgrades traditional manual and telephone reporting to automated and structured information delivery, greatly shortening the time from incident occurrence to multi-departmental collaborative handling and significantly improving the ability to respond to high-risk transportation accidents.

[0013] 2. This invention ensures device trustworthiness and system security from the source by introducing a dual verification mechanism of security initialization and device identity; it achieves millisecond-level local identification and early warning of abnormal events by integrating a local rule engine and machine learning model to perform real-time fusion analysis of multi-source sensor data, fundamentally solving the problems of large cloud processing latency and strong network dependence; at the same time, by automatically extracting key data and initiating cloud-based collaborative emergency response, it forms a complete closed loop from rapid on-site handling to multi-departmental collaborative scheduling, significantly improving the safety management level of high-risk cargo transportation such as hazardous chemicals. Attached Figure Description

[0014] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. Wherein: Figure 1 This is a flowchart of the method of the present invention.

[0015] Figure 2 This is a schematic diagram of the device system of the present invention. Detailed Implementation

[0016] Embodiments of the present invention are described in detail below. Examples of these embodiments are illustrated in the accompanying drawings, wherein the same or similar symbols denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0017] Please refer to Figure 1 This invention provides a logistics vehicle-mounted Internet of Things (IoT) data processing method based on edge computing, comprising the following steps: S1. Real-time acquisition of multi-source sensor data of transport vehicles, including vehicle status data, cargo status data and environmental perception data.

[0018] It should be noted that multi-source sensor data refers to a set of physical quantity data that reflects the state of all elements of the transportation process, which is synchronously acquired through a heterogeneous sensor network deployed on transport vehicles.

[0019] In S1, the vehicle status data includes position, speed, acceleration, and tire pressure information; the cargo status data includes temperature, humidity, vibration amplitude, tilt angle, pressure value, and gas concentration information; and the environmental perception data includes video streams and external meteorological information.

[0020] It should be noted that the vehicle status data is primarily used to monitor the operational safety and compliance of the transport vehicle itself. Specifically: Location information: obtained through a global satellite positioning system module, such as GPS / BeiDou, used to track vehicle coordinates and driving trajectory in real time, and compare them with preset electronic fence routes.

[0021] Speed ​​and acceleration information: Read via the vehicle's CAN bus interface or acquired by a separate inertial measurement unit. Speed ​​is used to determine if speeding is occurring; abnormal fluctuations in acceleration can be used to indirectly determine sharp turns, sudden braking, or potential collision events.

[0022] Tire pressure information: Acquired wirelessly via tire pressure monitoring sensors installed in each tire, abnormal tire pressure is an important precursor to tire blowout risk.

[0023] It should be noted that the aforementioned cargo status data is crucial for ensuring the quality and safety of transported goods, especially high-value or highly sensitive goods (such as hazardous chemicals, cold-chain fresh produce, and precision instruments). Specifically: Temperature and humidity information: acquired by digital temperature and humidity sensors placed in different locations inside the cargo container, used to monitor the temperature control environment of cold chain transportation or the special humidity requirements of certain goods.

[0024] Vibration amplitude and tilt angle information: acquired via triaxial vibration and tilt sensors. Excessive vibration may damage precision instruments, while abnormal tilt angles may indicate loose cargo strapping or abnormal vehicle posture, such as a risk of rollover.

[0025] Pressure information: obtained through pressure sensors, such as those used to monitor the internal pressure of canned liquids or gases. Sudden pressure changes may indicate a leak.

[0026] Gas concentration information: acquired through specific gas sensors, such as oxygen, carbon dioxide, volatile organic compound (VOC) sensors, or hazardous chemical characteristic gas sensors. For the transportation of hazardous chemicals, monitoring the concentration of specific gases is a direct means of early warning of leaks.

[0027] It should be noted that the environmental perception data provides contextual information about the vehicle's external environment, assisting in comprehensive risk assessment. Specifically: Video stream information: Acquired through cameras deployed at the front, rear, and cargo box of the vehicle, providing intuitive visual information that can be used to assist in judging road conditions, recording traffic accidents, and visually confirming the loading and unloading status of goods.

[0028] External weather information: acquired through onboard weather sensors or from roadside units connected to the vehicle network, including ambient temperature, humidity, air pressure, wind speed, and rainfall. Severe weather is a significant external factor affecting transportation safety; for example, heavy rain may increase the risk of skidding, and high temperatures may affect the stability of certain goods.

[0029] It should be noted that the above-mentioned multiple types of data are collected synchronously or quasi-synchronously through different interfaces integrated in the vehicle edge computing terminal, and are tagged with a unified timestamp and spatial location label to form a raw data stream with spatiotemporal dimensions, which prepares for subsequent fusion and analysis.

[0030] S2. Execute the preset security initialization and device authentication process, and enter the secure operation state after successful authentication.

[0031] It should be noted that the aforementioned security initialization and device authentication process is a key mechanism to ensure that the entire in-vehicle IoT data processing system is in a trusted and secure state during the startup phase. It aims to prevent unauthorized device access, malicious firmware tampering, or attacks via physical detection, thus establishing a hardware-level secure root of trust for the core data processing functions.

[0032] In S2, the preset security initialization and device authentication process is executed as follows: Read the boot flag and determine the boot type based on the boot flag; If the result indicates that it is a first-time boot, then a hardware self-test is performed to generate a pin status list and the device's unique machine code is read. It should be noted that the startup flag is a multi-state flag stored at a specific address in the non-volatile memory (such as Flash memory) of the vehicle edge computing terminal. For example, it can be represented by two binary digits: 00 represents the first startup, such as the first power-on after the device leaves the factory or after a firmware upgrade; 01 represents a normal startup (daily startup after successful verification); and 10 or 11 can represent an abnormal or failed startup state. After the system powers on, it first reads this flag from this fixed address to determine the subsequent execution path.

[0033] It should be noted that when the system detects an initial boot, it will execute a hardware self-test. This program will iterate through and scan the states (high, low, or high impedance) of all general-purpose input / output (GPIO) pins of the device's main control chip, recording the current level value of each pin and generating an ordered list of pin states. This list acts like a hardware fingerprint for the device, possessing uniqueness and stability due to factors such as PCB layout, pull-up / pull-down resistor configuration, and the initial state of external sensors. Simultaneously, the system reads a globally unique machine code (such as a chip ID) from the chip's inherent read-only memory area. This machine code, together with the hardware fingerprint, constitutes a dual identity credential for the device.

[0034] The pin status list and the unique machine code are encrypted to generate verification request data; It should be noted that the encryption process is designed to protect the confidentiality and integrity of the device's identity credentials during transmission. Specifically, the pin status list and a unique machine code are concatenated, and then encrypted using a symmetric encryption algorithm (such as AES) negotiated with the cloud platform or an asymmetric encryption algorithm (using the cloud platform's public key) to generate a verification request data packet. This data packet is then sent to the cloud platform via a secure network connection (such as HTTPS based on TLS).

[0035] It should be noted that the pre-stored legitimate device information database is a secure database deployed on a cloud platform. Each legitimate device leaving the factory has a pre-registered record, which contains at least two key fields: 1) the legitimate device's unique machine code; and 2) a list of baseline pin states scanned and stored during the device's factory testing. This baseline list is obtained under known secure and tamper-proof baseline conditions, serving as the original template for subsequent comparisons.

[0036] Receive a response to the verification request data, the response being generated after comparison and verification with a pre-stored database of legitimate device information; If the response is a successful verification response, the corresponding execution code is written, the startup flag is modified, and the system restarts; if the response is a failed verification response, the startup flag is modified, and the system enters restricted mode.

[0037] The response is generated after comparison and verification with a pre-stored database of legitimate device information, as follows: determining whether the unique machine code exists in the list of legitimate devices, and determining whether the matching degree between the pin status list and the pre-stored baseline pin status list exceeds a preset threshold.

[0038] It should be noted that the comparison and verification process is executed by the cloud platform after receiving the verification request. Specifically, it includes two levels of verification: Identity verification: Decrypt the request data packet, extract the unique machine code reported by the device, query the legitimate device information database, and determine whether the machine code exists in the list of legitimate devices. This step is used to confirm whether the device is a legitimate device authorized by the system.

[0039] Hardware integrity verification: The pin status list reported by the device is compared with the baseline pin status list corresponding to the machine code in the database. The matching degree between the two lists is calculated, for example, the percentage of pins with completely identical pin statuses out of the total number of pins. When this matching degree exceeds a preset threshold (e.g., 95%), the device hardware is considered to have not been illegally desoldered, shorted, or bridging, and its physical integrity is good. This step is used to detect whether the device has been physically tampered with.

[0040] It should be noted that, based on the verification results, the system will enter different state branches: Verification Successful Response: The cloud platform generates a verification successful command, along with an encrypted, complete application execution code package, and sends it to the vehicle terminal. Upon receiving the package, the terminal decrypts the execution code and writes it to its program storage area. Simultaneously, it modifies the startup flag to 01 (normal startup) and then performs a reboot. After rebooting, the device will directly run legitimate applications and enter a fully functional and secure operating state.

[0041] Verification Failure Response: The cloud platform returns a verification failure command. Upon receiving this command, the terminal modifies the startup flag to 10 (verification failed) and performs a restart. After restarting, due to the abnormal flag state, the system will enter restricted mode. In restricted mode, the system may only maintain the most basic communication functions to await remote diagnostics, or it may be completely locked, refusing to perform any data acquisition and processing tasks, thereby preventing the spread of potential security risks.

[0042] S3. Under the safe operating state, based on the multi-source sensor data, generate fused data; perform rule matching analysis on the fused data to generate anomaly determination results; perform machine learning model inference analysis on the fused data to generate risk prediction results.

[0043] It should be noted that generating fused data is a crucial data preprocessing step. Because multi-source sensor data collected from different sensors differ in sampling frequency, data format, timestamp accuracy, and physical meaning, direct analysis is inefficient and inaccurate. Therefore, this step first performs time alignment, unifying the data streams to the same time reference; then, it performs spatial correlation, such as binding all sensor readings to the current GPS location information; finally, it performs data cleaning, such as removing obviously erroneous outliers and filling in reasonable missing values ​​caused by brief signal loss. After these processes, a fused dataset with a unified spatiotemporal framework and a well-structured architecture is formed. For example, a single fused data record may contain multiple synchronized fields such as time T, location (X, Y), vehicle speed V, cargo temperature Temp, vibration amplitude Vib, etc.

[0044] In S3, rule matching analysis is performed on the fused data to generate anomaly judgment results, as follows: the parameters in the fused data are compared with preset rule thresholds in real time to generate anomaly judgment results. The preset rule thresholds include thresholds for judging speeding, route deviation, fatigue driving, excessive temperature, excessive vibration, or excessive gas concentration.

[0045] It should be noted that the rule matching analysis described is a real-time anomaly detection method based on explicit logic and thresholds, characterized by fast response, transparent logic, and deterministic results. In specific implementation, the system maintains a configurable rule base, where each rule includes: monitoring parameters, comparison operators, preset thresholds, and the corresponding anomaly event type. The analysis engine scans each piece of fused data in real time, comparing the parameters with the rule base. The preset rule thresholds include, but are not limited to: Speeding: Determines whether the vehicle speed continuously exceeds the road speed limit or a preset safe speed threshold.

[0046] Route Deviation: Determines whether the vehicle's real-time location deviates from the preset electronic fence route by more than the allowable buffer distance.

[0047] Fatigue driving: A comprehensive judgment is made by combining continuous driving time (timing from ignition) and steering wheel micro-movements (indirectly analyzed by acceleration sensors or steering angle sensors).

[0048] Temperature exceeding the limit: Determine whether the temperature of the goods exceeds their safe storage temperature range.

[0049] Vibration exceeding limits: Determine whether the vibration amplitude exceeds the energy threshold that may damage the goods, such as the power spectral density (PSD) threshold in the ISO 13355 standard.

[0050] Gas concentration exceeding the standard: Determine whether the concentration of a specific gas exceeds a safety threshold, such as the warning concentration for a hazardous chemical leak.

[0051] Once any rule is triggered, an anomaly determination result is generated immediately. This result includes at least the anomaly type, trigger time, relevant sensor readings, and severity level.

[0052] The fused data is subjected to machine learning model inference analysis to generate risk prediction results, as follows: The fused data is input into a pre-trained and deployed machine learning model to obtain at least one risk prediction indicator among the vehicle component failure probability, cargo deterioration risk level, or traffic accident occurrence probability, and risk prediction results are generated; the parameters of the machine learning model support remote incremental iteration, and the iteration time is when the vehicle is stationary and connected to the network.

[0053] It should be noted that the machine learning model inference analysis described is a data-driven method for predicting potential risks. Its key feature is its ability to discover complex, non-linear relationships and achieve proactive early warning. The pre-trained model is deployed in the computing module of the in-vehicle terminal. During inference, the system uses the current fused data as a feature vector and inputs it into the model. The risk prediction index output by the model is a probabilistic judgment about the future, for example: Vehicle component failure probability: For example, based on multi-dimensional data such as engine vibration spectrum, oil temperature, and speed, predict the probability of failure occurring in the next 24 hours.

[0054] Cargo spoilage risk level: For example, in cold chain transportation, based on historical temperature fluctuations, current humidity, and transportation time, the probability that the goods will still be fresh upon arrival is predicted and quantified into low, medium, and high risk levels.

[0055] Traffic accident probability: For example, based on current vehicle speed, following distance, lane keeping status, and weather conditions, a comprehensive prediction of the risk of collision or loss of control in the next few minutes.

[0056] It should be noted that the parameters of the machine learning model support remote incremental iteration. This means that the model deployed on the terminal is not static. The specific iteration process is as follows: when the vehicle is stationary and connected to a wireless network, such as Wi-Fi at a parking depot or cellular networks during low-cost nighttime hours, the terminal communicates with the cloud platform. The cloud platform retrains and optimizes the model based on broader operational data from the entire fleet, generating a lightweight model differential update package. This update package is securely distributed to the terminal, which can then use it to iterate the model's parameters, continuously evolving its predictive capabilities without needing to download and replace the entire large model file. This mechanism ensures continuous improvement in model performance while significantly saving network bandwidth and terminal storage resources.

[0057] It should be noted that rule matching analysis and machine learning model inference analysis run in parallel at the edge, forming a three-dimensional security protection system that combines real-time precision strikes with forward-looking risk warnings. The rule engine is responsible for handling clearly defined explicit anomalies that require immediate response; while the machine learning model is responsible for uncovering deep-seated and complex hidden risks. The two complement each other, jointly achieving a leap in intelligent supervision of the transportation process from post-event alarms to in-event intervention and even pre-event prediction.

[0058] S4. When the anomaly determination result shows that there is an abnormal event, execute a local early warning operation, and based on the abnormal event, extract the corresponding key data fragments from the fused data, process the key data fragments, generate key data packets, and upload them to the cloud platform. In S4, the execution of the local early warning operation includes at least one of triggering an audible and visual alarm, displaying early warning information, or sending a voice prompt signal.

[0059] It should be noted that the aforementioned execution of local warning operations is a direct human-machine interaction response directed to the vehicle's cockpit. Its primary objective is to immediately attract the attention of the driver or accompanying personnel so that emergency response measures can be taken. This operation is executed in parallel or selectively through multiple output channels of the onboard terminal, specifically including: Triggering the audible and visual alarm: The terminal controls its integrated buzzer to emit a rapid alarm sound, while simultaneously illuminating a bright LED indicator (usually red). This sensory combination effectively penetrates ambient noise, delivering an emergency signal immediately.

[0060] Displaying warning information: Structured warning information is displayed on the terminal's screen or the vehicle's central control screen connected to the terminal, either as a pop-up or highlighted window. This information includes at least: the type of abnormal event (such as excessive gas concentration), the time of occurrence, a brief description (such as the concentration of a certain gas: 150 ppm, exceeding the safety threshold of 100 ppm), and preliminary handling suggestions (such as ventilate immediately and check the cargo box seal).

[0061] Send voice prompts: Play pre-recorded or real-time synthesized voice warnings through the vehicle's audio system, such as "Warning! An abnormally high temperature has been detected in the cargo. Please check immediately." Voice broadcasts enable information delivery without the driver taking their eyes off the road, further enhancing driving safety.

[0062] In S4, the corresponding key data segments are extracted from the fused data, and the key data segments are processed as follows: based on the time point when the anomaly determination result is generated, a segment of the fused data of a preset duration is extracted forward and backward to generate key data segments. The key data segments are then compressed and encrypted to generate key data packets.

[0063] It should be noted that extracting the corresponding key data segments from the fused data is an intelligent data filtering process aimed at providing the most relevant and complete contextual information for cloud analysis, rather than uploading all massive amounts of data. The key technology lies in defining and capturing the critical time window surrounding the abnormal event. In specific implementation, the event trigger time T0 recorded in the anomaly determination result is used as the baseline time point. A preset forward capture duration (e.g., T0-30 seconds) is used to capture the event's triggers or precursors, such as how the temperature gradually increased or what road sections the vehicle passed through before the leak; a preset backward capture duration (e.g., T0+60 seconds) is used to capture the initial state evolution after the event, such as the initial trend of leak spread and the vehicle's dynamics after the driver applied the brakes. This forms a key data segment within the time interval from before T0-ΔT to after T0+ΔT. This segment contains the multi-source sensor data sequence necessary to fully describe the abnormal event.

[0064] It should be noted that the compression and encryption of the critical data segments are to meet the efficiency and security requirements of wireless transmission. Specifically, this includes two steps: Compression processing: Considering that the fused data is mostly numerical and enumerated data, efficient lossless compression algorithms (such as LZ4 and Zstandard) can be used to compress data fragments, significantly reducing the size of data packets. Typically, the data can be compressed to 30%-50% of its original size, thereby reducing cellular network traffic consumption and speeding up upload speed.

[0065] Encryption Processing: Compressed data needs to be encrypted to ensure confidentiality and integrity during transmission. Typically, a high-strength symmetric encryption algorithm (such as AES-256) pre-negotiated with the cloud platform is used to encrypt the data packets. The encryption keys are managed and synchronized through a secure channel.

[0066] It should be noted that the compressed and encrypted data is encapsulated into a key data packet with a specific format. In addition to the processed data body, this data packet typically includes metadata in its header, such as the Vehicle Identification Number (VIN), event ID, time window range, and data format version. Subsequently, the terminal uploads this data packet to the designated cloud platform interface via its IoT communication module (4G / 5G / NB-IoT).

[0067] It should be noted that the division of responsibilities between the edge and the cloud has been optimized. The edge side is responsible for millisecond-level real-time perception, judgment, and on-site early warning, ensuring immediate control over emergencies. At the same time, it intelligently filters and reports high-value key data fragments, enabling the cloud to conduct in-depth analysis, visualization, archiving, and initiate broader emergency coordination based on refined data. This avoids the impact of raw data deluge on network and cloud resources, forming an efficient and collaborative two-tier response system.

[0068] S5. The cloud platform receives and parses the critical data packet, obtains the anomaly determination result, and initiates the corresponding emergency response process based on the type of the anomaly determination result.

[0069] It should be noted that the cloud platform is a software system deployed in a cloud data center, possessing high availability and elastic scalability. It continuously monitors and receives critical data packets uploaded from vehicle-mounted terminals across the entire network via a publicly available application programming interface (API). Upon receipt, the cloud platform first performs reverse processing on the data packets: decrypting them using a key negotiated with the terminals, and then using a corresponding decompression algorithm to reconstruct the original critical data fragments and related metadata. By parsing this data, the cloud platform not only obtains the anomaly judgment results generated at the edge, such as hazardous chemical leak: ethanol, level: severe, but also obtains a complete multi-source sensor data sequence with spatiotemporal context surrounding the event, providing a data foundation for subsequent in-depth analysis and decision-making.

[0070] It should be noted that initiating the corresponding emergency response process based on the anomaly determination result is an automated and intelligent decision-making and distribution process. The cloud platform internally maintains an emergency response rule engine and an emergency plan template library. The rule engine automatically matches the most suitable emergency plan template based on the parsed anomaly type (e.g., fire, leak, traffic accident, cargo loss) and level (e.g., general, severe, major). For example, for a hazardous chemical leak—a severe incident—a standardized template including multiple stages such as initial accident reporting, command and dispatch, on-site handling, environmental monitoring, and information dissemination will be matched.

[0071] In S5, the corresponding emergency response process is initiated as follows: based on the type and level of the anomaly determination result, an emergency plan template is matched to generate an emergency report, and the emergency report is pushed to the preset regulatory department information system; when the transportation of hazardous chemicals is involved, the emergency report is automatically associated with and attached with the legally required reporting information items corresponding to the hazardous chemicals, including their official name, UN number, quantity and emergency contact number.

[0072] It should be noted that the generation of the emergency report is a template instantiation process. The parsed event information (time, location, vehicle / driver information, sensor readings, video screenshots, etc.) is automatically populated into the corresponding fields of the matching emergency plan template, dynamically generating a structured preliminary emergency report. This report not only describes what happened (the facts of the event), but also provides possible development trends (risk assessment) and preliminary suggested measures (response recommendations) based on data and models.

[0073] It should be noted that pushing the emergency report to the pre-set regulatory department information system enables automated information dissemination across systems and departments. The cloud platform is pre-configured with interfaces for regulatory department systems related to different emergency scenarios. For example, it can simultaneously connect to the regulatory platform of the transportation department, the emergency command information system of the emergency management department, the traffic police command platform of the public security department, and the environmental risk monitoring system of the ecological environment department. According to the emergency response rules, the report is automatically and in parallel pushed to the system interfaces of one or more relevant departments, achieving information synchronization within seconds and completely changing the traditional lagging mode that relies on manual telephone reporting.

[0074] It is particularly important to note that in the high-risk scenario of transporting hazardous chemicals, this invention achieves deep integration with regulations. The automatic association and attachment of legally required reporting information is achieved as follows: at the start of a transport mission, the compliance information of the batch of hazardous chemicals is already linked to the vehicle's mission file. When a relevant emergency report is generated, the system automatically retrieves and extracts this legally required information from the mission file, appending it as a separate section or standardized field to the end of the report. For example, the report will clearly state the chemical involved: ethanol, UN1170, quantity: 5 tons, and the consignor's emergency contact person and telephone number. This ensures that the generated emergency report fully complies with the requirements of regulations such as the "Regulations on the Safety Management of Hazardous Chemicals" regarding accident reporting content, greatly improving the standardization and effectiveness of reported information, and providing authoritative data support for regulatory authorities to conduct accurate and rapid emergency command.

[0075] It should be noted that by fully leveraging the advantages of cloud platforms in data aggregation, rule calculation, resource coordination, and cross-system integration, the real-time sensing capabilities of in-vehicle IoT are effectively transformed and amplified into socialized and professional emergency management and public service capabilities, thereby achieving a fundamental improvement in the level of supervision of logistics and transportation safety, especially the safety of dangerous goods transportation.

[0076] Please refer to Figure 2 This invention provides a logistics vehicle-mounted Internet of Things (IoT) data processing device based on edge computing, comprising: The data acquisition module is used to collect multi-source sensor data of the transport vehicle in real time. The multi-source sensor data includes vehicle status data, cargo status data and environmental perception data. The initialization verification module is used to execute the preset security initialization and device authentication process, and enters the secure operation state after successful verification; An edge processing module is used to generate fused data based on the multi-source sensor data under the safe operating state; perform rule matching analysis on the fused data to generate anomaly determination results; and perform machine learning model inference analysis on the fused data to generate risk prediction results. The early warning reporting module is used to perform local early warning operations when the anomaly determination result shows that there is an abnormal event, and based on the abnormal event, extract the corresponding key data fragments from the fused data, process the key data fragments, generate key data packets, and upload them to the cloud platform. The cloud response module is used by the cloud platform to receive and parse the critical data packets, obtain the anomaly determination result, and initiate the corresponding emergency response process based on the type of the anomaly determination result.

[0077] In summary, this patent application has constructed a low-latency, high-security, weak-network-dependent, and intelligently collaborative logistics vehicle IoT data processing system, realizing a paradigm shift in transportation safety supervision from post-event traceability to real-time intervention and even pre-event risk warning. In particular, it provides reliable technical support for the transportation safety management of high-risk goods such as hazardous chemicals.

[0078] Furthermore, any content not described in detail in this specification is existing technology known to those skilled in the art.

[0079] In the embodiments provided by this invention, it should be understood that the disclosed system or method can be implemented in other ways. For example, the embodiments of the invention described above are merely illustrative; for instance, the division of modules is only a logical functional division, and there may be other division methods in actual implementation.

[0080] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0081] Furthermore, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated module can be implemented in hardware or in the form of hardware plus software functional modules.

[0082] For those skilled in the art, it is obvious that the present invention is not limited to the details of the above exemplary embodiments, and that the present invention can be implemented in other specific forms without departing from the basic characteristics of the present invention.

[0083] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A data processing method for logistics vehicle-mounted Internet of Things based on edge computing, characterized in that, Includes the following steps: S1. Real-time acquisition of multi-source sensor data of transport vehicles, including vehicle status data, cargo status data and environmental perception data; S2. Execute the preset security initialization and device authentication process, and enter the secure operation state after successful authentication; S3. Under the safe operating state, generate fused data based on the multi-source sensor data; Perform rule matching analysis on the fused data to generate anomaly detection results; Machine learning model inference analysis is performed on the fused data to generate risk prediction results; S4. When the anomaly determination result shows that there is an abnormal event, execute a local early warning operation, and based on the abnormal event, extract the corresponding key data fragments from the fused data, process the key data fragments, generate key data packets, and upload them to the cloud platform. S5. The cloud platform receives and parses the critical data packet, obtains the anomaly determination result, and initiates the corresponding emergency response process based on the type of the anomaly determination result.

2. The logistics vehicle IoT data processing method based on edge computing as described in claim 1, characterized in that: In S1, the vehicle status data includes position, speed, acceleration, and tire pressure information; the cargo status data includes temperature, humidity, vibration amplitude, tilt angle, pressure value, and gas concentration information; and the environmental perception data includes video streams and external meteorological information.

3. The logistics vehicle-mounted IoT data processing method based on edge computing as described in claim 1, characterized in that: In S2, the preset security initialization and device authentication process is executed as follows: Read the boot flag and determine the boot type based on the boot flag; If the result indicates that it is a first-time boot, then a hardware self-test is performed to generate a pin status list and the device's unique machine code is read. The pin status list and the unique machine code are encrypted to generate verification request data; Receive a response to the verification request data, the response being generated after comparison and verification with a pre-stored database of legitimate device information; If the response is a successful verification response, the corresponding execution code is written, the startup flag is modified, and the system restarts; if the response is a failed verification response, the startup flag is modified, and the system enters restricted mode.

4. The logistics vehicle IoT data processing method based on edge computing as described in claim 3, characterized in that: The response is generated after comparison and verification with a pre-stored database of legitimate device information, as follows: determining whether the unique machine code exists in the list of legitimate devices, and determining whether the matching degree between the pin status list and the pre-stored baseline pin status list exceeds a preset threshold.

5. The logistics vehicle IoT data processing method based on edge computing as described in claim 1, characterized in that: In S3, rule matching analysis is performed on the fused data to generate anomaly judgment results, as follows: the parameters in the fused data are compared with preset rule thresholds in real time to generate anomaly judgment results. The preset rule thresholds include thresholds for judging speeding, route deviation, fatigue driving, excessive temperature, excessive vibration, or excessive gas concentration.

6. The logistics vehicle-mounted IoT data processing method based on edge computing as described in claim 5, characterized in that: The fused data is subjected to machine learning model inference analysis to generate risk prediction results, as follows: The fused data is input into a pre-trained and deployed machine learning model to obtain at least one risk prediction indicator among the vehicle component failure probability, cargo deterioration risk level, or traffic accident occurrence probability, and risk prediction results are generated.

7. The logistics vehicle-mounted IoT data processing method based on edge computing as described in claim 1, characterized in that: In S4, the corresponding key data segments are extracted from the fused data, and the key data segments are processed as follows: based on the time point when the anomaly determination result is generated, a segment of the fused data of a preset duration is extracted forward and backward to generate key data segments. The key data segments are then compressed and encrypted to generate key data packets.

8. The logistics vehicle-mounted IoT data processing method based on edge computing as described in claim 1, characterized in that: In S4, the execution of the local early warning operation includes at least one of triggering an audible and visual alarm, displaying early warning information, or sending a voice prompt signal.

9. The logistics vehicle-mounted IoT data processing method based on edge computing as described in claim 1, characterized in that: In S5, the corresponding emergency response process is initiated as follows: based on the type and level of the anomaly determination result, an emergency plan template is matched to generate an emergency report, and the emergency report is pushed to the preset regulatory department information system.

10. A logistics vehicle-mounted IoT data processing device based on edge computing, employing the logistics vehicle-mounted IoT data processing method based on edge computing as described in any one of claims 1-9, characterized in that, include: The data acquisition module is used to collect multi-source sensor data of the transport vehicle in real time. The multi-source sensor data includes vehicle status data, cargo status data and environmental perception data. The initialization verification module is used to execute the preset security initialization and device authentication process, and enters the secure operation state after successful verification; An edge processing module is used to generate fused data based on the multi-source sensor data under the safe operating state; Perform rule matching analysis on the fused data to generate anomaly detection results; Machine learning model inference analysis is performed on the fused data to generate risk prediction results; The early warning reporting module is used to perform local early warning operations when the anomaly determination result shows that there is an abnormal event, and based on the abnormal event, extract the corresponding key data fragments from the fused data, process the key data fragments, generate key data packets, and upload them to the cloud platform. The cloud response module is used by the cloud platform to receive and parse the critical data packets, obtain the anomaly determination result, and initiate the corresponding emergency response process based on the type of the anomaly determination result.

Images