Overloaded minibus early warning system and method based on IMSI track and vehicle track analysis

Abstract

The invention belongs to but is not limited to the technical field of intelligent traffic and data analysis, and discloses an overload minibus early warning system and method based on IMSI track and vehicle track analysis, and the method comprises the steps: screening a minibus track and an IMSI track from a real-time data stream, and carrying out the preprocessing; the method comprises the following steps: performing space-time collision on a minibus track and an IMSI track, and identifying a mobile phone signal which travels along with each minibus; multiple rules such as multi-gate verification and time continuity analysis are utilized to strictly screen preliminary association results, so that accidental traveling signals are eliminated, and the association reliability is ensured; an early warning model is established based on the number of different IMSIs traveling along with the vehicle and the continuity characteristics of the IMSIs, and once it is found that a certain minibus is continuously associated with IMSIs exceeding a threshold value in the travel, overload early warning is automatically triggered. According to the invention, the accuracy of early warning is effectively improved, and the conversion from fixed-point spot check to whole-course patrol and from passive weighing to active research and judgment is realized.

Description

An overloaded van early warning system and method based on IMSI trajectory and vehicle trajectory analysis Technical Field

[0001] This invention belongs to, but is not limited to, the fields of intelligent transportation and data analysis technology, and particularly relates to an overloaded van early warning system and method based on IMSI trajectory and vehicle trajectory analysis. Background Technology

[0002] With the increasing demand for urban traffic safety management, the problem of vehicle overloading has become increasingly prominent, with overloaded minibuses posing a significant threat to road safety. Current mainstream overload detection solutions can be categorized as follows: First, static weighing. This method involves setting up weighbridges at fixed locations, requiring vehicles to pass through at low speed or while stationary to complete the weighing. Its advantage lies in high detection accuracy, but it suffers from problems such as fixed facilities, high construction and maintenance costs, and the inability to achieve large-scale, dynamic overload monitoring.

[0003] Secondly, there is dynamic weighing, which uses sensors embedded in the road surface to estimate the weight of vehicles as they pass by at a certain speed, resulting in relatively high detection efficiency. However, this solution still relies on dedicated hardware, and the deployment and subsequent maintenance costs are considerable, significantly limiting its coverage.

[0004] Thirdly, video image analysis uses cameras to capture vehicle images and analyzes external deformation features such as tire flattening and leaf spring compression to estimate load. While this method is lower in cost, its detection accuracy is easily affected by environmental factors such as lighting and shooting angle, resulting in insufficient reliability and making it unsuitable as a basis for law enforcement.

[0005] Furthermore, with the widespread adoption of mobile communication technology, using IMSI trajectories for crowd analysis and tracking has become a mature technical approach in the field of public safety. However, a mature solution has yet to be developed that deeply correlates IMSI trajectories with the operational trajectories of specific vehicle types, such as vans, to address the specific issue of vehicle overload warnings.

[0006] The existing vehicle overload detection technology has the following inherent defects: (1) The monitoring range is limited and there are regulatory blind spots: The existing weighing detection technology relies heavily on special hardware facilities. Static weighing requires the construction of fixed weighbridges, and dynamic weighing requires the pre-embedding of road surface sensors. Both are limited to the fixed point deployment mode. This mode is not only expensive to build and maintain, and difficult to achieve full coverage, but also results in a large number of blind spots in the regulatory network. Violating vehicles can easily avoid inspection by detouring and other means.

[0007] (2) Low detection efficiency, making it difficult to meet the needs of large-scale governance: Existing detection technologies are essentially passive and discrete sampling detection methods. Static weighing requires vehicles to stop and cooperate to complete the detection, while dynamic weighing also requires vehicles to pass at low speeds. The overall detection process is time-consuming, and the number of vehicles that can be processed per unit time is limited. Faced with the massive number of vehicles on the road, this inefficient detection mode is difficult to support large-scale and routine overload governance work, and the problem of limited regulatory coverage is prominent.

[0008] (3) Insufficient reliability and limited practicality of non-contact detection: Although non-contact detection methods based on video images have freed them from dependence on dedicated hardware, their detection accuracy is significantly affected by external factors such as ambient light, weather conditions, and shooting angle, resulting in poor stability of recognition results and a high false alarm rate, which cannot meet the actual application needs of precise governance.

[0009] Based on the above analysis, the existing technologies urgently need to address the following technical problems: they rely on dedicated hardware, resulting in high construction and maintenance costs, limited monitoring coverage, and prominent regulatory blind spots; their detection modes are passive, discrete, and inefficient, making them difficult to adapt to the needs of large-scale, routine overload control; non-contact detection is susceptible to external environmental interference, resulting in insufficient accuracy and reliability, and limited practicality; and there is no correlation mechanism between IMSI trajectories and trajectories of specific vehicle types, leaving gaps in relevant overload early warning technology pathways. Summary of the Invention

[0010] To address the problems existing in current technologies, this invention provides an overloaded van early warning system and method based on IMSI trajectory and vehicle trajectory analysis. Specifically, it utilizes IMSI (International Mobile Subscriber Identity) and vehicle trajectory data for comprehensive analysis to detect and warn of potentially overloaded vans, making it particularly suitable for traffic monitoring and vehicle safety management. This invention aims to provide an overloaded vehicle early warning solution with broad coverage, high screening efficiency, and high accuracy, offering an innovative technical approach to improving traffic safety supervision efficiency.

[0011] This invention is implemented as follows: an overloaded van early warning method based on IMSI trajectory and vehicle trajectory analysis, comprising the following steps: Step 1, filtering van trajectories and IMSI trajectories from real-time data streams and performing preprocessing; Step 2, identifying mobile phone signals (IMSIs) traveling with each van by performing spatiotemporal collision analysis (i.e., appearing at the same location and at similar times); Step 3, rigorously filtering the preliminary association results using multiple rules such as "multi-checkpoint verification" and "time continuity analysis" to exclude accidental traveling signals and ensure the reliability of the association; Step 4, establishing an early warning model based on the number of different IMSIs traveling with the vehicle and their continuity characteristics, automatically triggering an overload warning once a van is found to continuously associate with more than a threshold (e.g., 7 IMSIs) during its journey.

[0012] Furthermore, the data preprocessing and storage in step one specifically includes: S11, establishing a van information database, consuming vehicle data from the Kafka message queue, filtering records where the vehicle type is a small van and the license plate format is standardized, and storing the van information in ods_datas.van_info.

[0013] S12, IMSI track data storage: The IMSI track data in Kafka is stored in the daily partitioned IMSI track table ods_datas_ktc.imsi_track (IT table for short); S13, van track data storage: The complete vehicle passage data of a small van is stored in the daily partitioned vehicle passage track table ods_datas_ktc.ovan_car_pass. This table has a 10-day data retention policy and contains complete vehicle passage attribute information; Further, the vehicle track filtering and preprocessing in step two specifically includes: S21, obtaining the vehicle to be analyzed, and iteratively querying ods_datas_van... For unanalyzed records with flag=0 in _info, 1000 records are retrieved in batches (quantity is configurable) for processing each time; S22, analysis status update: for selected vehicle records, the status is marked as "in analysis" (flag='2') to prevent duplicate processing; S23, valid trajectory verification: verify whether the target vehicle passes through at least 2 (configurable) different checkpoints of associated IMSI acquisition devices within the analysis time window, where ${starttime}, ${endtime}, and ${pass_plate_no} are data from the ods_datas.van_info table in step S21; if cnt ≤ 2 (threshold is configurable), the trajectory data is considered insufficient, and it is directly marked as analyzed and processing ends, proceeding to step S24; otherwise, continue to step S23; S24, mark as analyzed and processing ends.

[0014] Further, in step three, the construction of the intermediate table for individual vehicle trajectories specifically includes: creating a dedicated intermediate table `dwd_datas_ktc.van_${unid}` for each verified van; this intermediate table significantly reduces the data scale of subsequent correlation calculations and improves processing efficiency; where `dim_datas_ktc.car_imsi_dev` is the association table between the vehicle checkpoint device and the IMSI device; further, in step four, the IMSI trajectory association and overload judgment specifically includes: S41, spatiotemporal correlation analysis, associating the vehicle intermediate table with the IMSI trajectory table, the association conditions include, under the same associated device, being captured within 120 seconds before and after is counted as one co-car (the 120-second threshold is configurable): Device association: `v.imsi_dev_no = f.dev_no` Time synchronization: `ABS(DATEDIFF(ss, v.pass_datetime, f.collect_time)) <= 120-second time window expansion: the IMSI query time range is expanded to `[${starttime}-10 minutes, ${endtime}+10 minutes]` (10-minute threshold configurable) S42, multi-dimensional verification mechanism, strictly filters successfully associated IMSIs to ensure data validity. The following numbers are all configurable thresholds. The following numbers are relatively accurate warning thresholds obtained through multiple tests. The configuration can also be adjusted according to the situation: Minimum number of times in the same row: COUNT(1) > 2 Multi-gate verification: COUNT(DISTINCT pass_bay_unid) > 2 Multi-device verification: COUNT(DISTINCT dev_no) > 2 Minimum time verification in the same row: (maxtime - mintime) ≥ INTERVAL '10 S43, Continuity Analysis: Using time-slice analysis, the number of consecutive IMSIs traveling together at the beginning and end of the trip is counted: minnum: Number of consecutive IMSIs traveling together at the beginning of the trip (based on a 10-minute window of mintime, threshold configurable); maxnum: Number of consecutive IMSIs traveling together at the end of the trip (based on a 10-minute window of maxtime, threshold configurable). S44, Overload Decision Rules: An overload warning is triggered when the following conditions are met, and the process continues; otherwise, steps S53 and S54 are directly entered: Total associated IMSIs: imsicnt > 6 (based on the assumption that a small van has a certified passenger capacity of 7 people, with one mobile phone per person, threshold configurable) and trip continuity verification: mincnt > 5 OR maxcnt > 5 (threshold configurable). Further, warning information generation and data maintenance include: S51, Summarizing warning information into the vehicle warning table, specifically by summarizing the warning information into the vehicle warning master table dwd_car_pass.In `van_warn_info`; S52, Warning Details Record, the IMSI association details corresponding to vans meeting the overload conditions are stored in the Warning Details table for easy subsequent reverse lookup, `dwd_datas_ktc.van_imsi_detail`; the specific operation is as follows: Vans that travel in the same lane as the van (i.e., are simultaneously captured by the same associated IMSI device within 2 minutes) more than twice, and are associated with at least two vehicle devices and at least two IMSI devices, are added to the association details. The numbers above are configurable thresholds.

[0015] S53, Update Analysis Results: Update the analysis status and result statistics in the van information database; S54, Clean Up Resources: After the analysis is completed, delete the temporary intermediate table created for this vehicle.

[0016] Another objective of this invention is to provide an overloaded van early warning system based on IMSI trajectory and vehicle trajectory analysis, comprising: a data preprocessing module, which filters and preprocesses van trajectories and IMSI trajectories from real-time data streams; a signal identification and filtering module, which identifies mobile phone signals (IMSIs) traveling with each van by performing spatiotemporal collision analysis (i.e., appearing at the same location and at similar times); a result filtering module, which rigorously filters the preliminary association results using multiple rules such as "multi-checkpoint verification" and "time continuity analysis" to exclude accidental traveling signals and ensure the reliability of the association; and an early warning module, which establishes an early warning model based on the number of different IMSIs traveling with the vehicle and their continuity characteristics, and automatically triggers an overload warning once a van is found to continuously associate with more than a threshold (e.g., 7) IMSIs during its journey.

[0017] Another object of the present invention is to provide a computer device, the computer device including a memory and a processor, the memory storing a computer program, and when the computer program is executed by the processor, causing the processor to perform the steps of the overloaded van warning method based on IMSI trajectory and vehicle trajectory analysis.

[0018] Another object of the present invention is to provide a computer-readable storage medium storing a computer program, which, when executed by a processor, causes the processor to perform the steps of the overloaded van warning method based on IMSI trajectory and vehicle trajectory analysis.

[0019] Another objective of this invention is to provide an information data processing terminal, which includes the aforementioned overloaded van early warning system based on IMSI trajectory and vehicle trajectory analysis.

[0020] Combining the above-mentioned technical solutions and the technical problems solved, the advantages and positive effects of the technical solution to be protected by this invention are as follows: In response to the problems existing in the current overload control technology, such as obvious monitoring blind spots, reliance on dedicated hardware, insufficient real-time performance, serious noise interference, and difficulty in large-scale deployment, this invention proposes an intelligent early warning system and method for overloaded vans based on the spatiotemporal correlation of IMSI trajectory and vehicle trajectory depth. This fundamentally changes the traditional technical path of relying on weighing devices for detection, and forms a new paradigm of indirect judgment that can cover the entire area, operate on a large scale, and be auditable.

[0021] Firstly, in terms of monitoring coverage and deployment costs, this invention does not rely on dedicated hardware such as weighbridges and WIMs. Instead, it reuses existing urban traffic checkpoint systems and mobile communication data collection networks. By constructing vehicle trajectory databases and IMSI trajectory databases and performing spatiotemporal collision and correlation analysis, it achieves continuous monitoring of target vehicles. Thus, without adding new road facilities or interfering with traffic operations, it eliminates the regulatory blind spots formed by traditional fixed-point detection, significantly reduces construction and maintenance costs, and improves regulatory coverage and sustainability.

[0022] Secondly, in terms of real-time performance and computational efficiency, this invention adopts a hierarchical filtering and intermediate table pruning strategy to filter the full trajectory data into a high-value candidate subset before performing association analysis and verification calculations. This avoids performing full JOIN and traversal on massive amounts of raw data, thereby significantly reducing the computational load while ensuring the accuracy of analysis, improving the system's concurrency capabilities and the feasibility of city-level deployment, and overcoming the bottleneck of traditional spatiotemporal big data analysis being difficult to run in real time.

[0023] Furthermore, in terms of accuracy and noise resistance, this invention introduces a multi-dimensional combined decision mechanism, including multi-checkpoint verification, multi-device verification, minimum number of times of parallel movement, time continuity analysis, and confidence model. This effectively eliminates occasional overlaps, short-term co-occurrences, and communication noise interference, avoiding misjudgments due to single-point or short-term anomalies. It achieves stable identification of true long-term parallel relationships, thereby significantly improving the reliability and stability of the early warning results.

[0024] Furthermore, this invention, through time-slice analysis and periodic compensation recalculation mechanism, can not only eliminate short-term occasional interference, but also avoid long-term missed judgments caused by sparse equipment or missing data collection, thereby achieving continuous identification and dynamic correction of long-term stable correlations and enhancing the system's adaptability to complex real-world scenarios.

[0025] Furthermore, this invention generates a complete auditable chain of evidence simultaneously during the early warning output stage, including associated trajectories, equipment information, time series, and confidence calculation details, making the early warning results traceable and verifiable by humans, meeting the requirements of law enforcement and regulatory scenarios for evidence compliance and interpretability, and making up for the shortcomings of indirect judgment methods in terms of legal application.

[0026] In summary, this invention is the first to systematically and deeply correlate IMSI trajectories with vehicle trajectories in spatiotemporal terms to estimate the number of people inside a vehicle and to provide overload warnings. It breaks through the technological path dependence of "weighing is necessary to control overloading" and overcomes technical biases such as high communication data noise and uncertainty of personnel carrying loads. It achieves a comprehensive balance between accuracy, coverage, cost control, and scalability, and solves a key technical problem that has long existed in the industry but has not been effectively resolved. Therefore, it has outstanding substantive features and significant progress, and meets the inventiveness requirements of an invention patent. Attached Figure Description

[0027] Figure 1 is a flowchart of the overloaded van early warning method based on IMSI trajectory and vehicle trajectory analysis provided in an embodiment of the present invention; Figure 2 is a system business process diagram provided in an embodiment of the present invention; Figure 3 is the result of the overloaded suspected vehicle early warning list of the system provided in an embodiment of the present invention in actual operation; Figure 4 is a schematic diagram of the details of associated IMSI times provided in an embodiment of the present invention; Figure 5 is a detailed effect diagram of the number of associated IMSI times of vehicles provided in an embodiment of the present invention. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0029] As shown in Figure 1, this embodiment of the invention provides an overloaded van early warning method based on IMSI trajectory and vehicle trajectory analysis, including the following steps: Step 1, filtering van trajectories and IMSI trajectories from real-time data streams and performing preprocessing; Step 2, identifying mobile phone signals (IMSIs) traveling with each van by performing spatiotemporal collision analysis (i.e., appearing at the same location and at similar times); Step 3, strictly filtering the preliminary association results using multiple rules such as "multi-checkpoint verification" and "time continuity analysis" to exclude accidental traveling signals and ensure the reliability of the association; Step 4, establishing an early warning model based on the number of different IMSIs traveling with the vehicle and their continuity characteristics, automatically triggering an overload warning once a van is found to continuously associate with more than a threshold (e.g., 7 IMSIs) during its journey.

[0030] Furthermore, the data preprocessing and storage in step one specifically includes: S11, establishing a van information database, consuming vehicle data from the Kafka message queue, filtering records where the vehicle type is a small van and the license plate format is standardized, and storing the van information in ods_datas.van_info.

[0031] S12, IMSI track data storage: The IMSI track data in Kafka is stored in the daily partitioned IMSI track table ods_datas_ktc.imsi_track (IT table for short); S13, van track data storage: The complete vehicle passage data of a small van is stored in the daily partitioned vehicle passage track table ods_datas_ktc.ovan_car_pass. This table has a 10-day data retention policy and contains complete vehicle passage attribute information; Further, the vehicle track filtering and preprocessing in step two specifically includes: S21, obtaining the vehicle to be analyzed, and iteratively querying ods_datas_van... For unanalyzed records with flag=0 in _info, 1000 records are retrieved in batches (quantity is configurable) for processing each time; S22, analysis status update: for selected vehicle records, the status is marked as "in analysis" (flag='2') to prevent duplicate processing; S23, valid trajectory verification: verify whether the target vehicle passes through at least 2 (configurable) different checkpoints of associated IMSI acquisition devices within the analysis time window, where ${starttime}, ${endtime}, and ${pass_plate_no} are data from the ods_datas.van_info table in step S21; if cnt ≤ 2 (threshold is configurable), the trajectory data is considered insufficient, and it is directly marked as analyzed and processing ends, proceeding to step S24; otherwise, continue to step S23; S24, mark as analyzed and processing ends.

[0032] Further, in step three, the construction of the intermediate table for individual vehicle trajectories specifically includes: creating a dedicated intermediate table `dwd_datas_ktc.van_${unid}` for each verified van; this intermediate table significantly reduces the data scale of subsequent correlation calculations and improves processing efficiency; where `dim_datas_ktc.car_imsi_dev` is the association table between the vehicle checkpoint device and the IMSI device; further, in step four, the IMSI trajectory association and overload judgment specifically includes: S41, spatiotemporal correlation analysis, associating the vehicle intermediate table with the IMSI trajectory table, the association conditions include, under the same associated device, being captured within 120 seconds before and after is counted as one co-car (the 120-second threshold is configurable): Device association: `v.imsi_dev_no = f.dev_no` Time synchronization: `ABS(DATEDIFF(ss, v.pass_datetime, f.collect_time)) <= 120-second time window expansion: the IMSI query time range is expanded to `[${starttime}-10 minutes, ${endtime}+10 minutes]` (10-minute threshold configurable) S42, multi-dimensional verification mechanism, strictly filters successfully associated IMSIs to ensure data validity. The following numbers are all configurable thresholds. The following numbers are relatively accurate warning thresholds obtained through multiple tests. The configuration can also be adjusted according to the situation: Minimum number of times in the same row: COUNT(1) > 2 Multi-gate verification: COUNT(DISTINCT pass_bay_unid) > 2 Multi-device verification: COUNT(DISTINCT dev_no) > 2 Minimum time verification in the same row: (maxtime - mintime) ≥ INTERVAL '10 S43, Continuity Analysis: Using time-slice analysis, the number of consecutive IMSIs traveling together at the beginning and end of the trip is counted: minnum: Number of consecutive IMSIs traveling together at the beginning of the trip (based on a 10-minute window of mintime, threshold configurable); maxnum: Number of consecutive IMSIs traveling together at the end of the trip (based on a 10-minute window of maxtime, threshold configurable). S44, Overload Decision Rules: An overload warning is triggered when the following conditions are met, and the process continues; otherwise, steps S53 and S54 are directly entered: Total associated IMSIs: imsicnt > 6 (based on the assumption that a small van has a certified passenger capacity of 7 people, with one mobile phone per person, threshold configurable) and trip continuity verification: mincnt > 5 OR maxcnt > 5 (threshold configurable). Further, warning information generation and data maintenance include: S51, Summarizing warning information into the vehicle warning table, specifically by summarizing the warning information into the vehicle warning master table dwd_car_pass.In `van_warn_info`; S52, Warning Details Record, the IMSI association details corresponding to vans meeting the overload conditions are stored in the Warning Details table for easy subsequent reverse lookup, `dwd_datas_ktc.van_imsi_detail`; the specific operation is as follows: Vans that travel in the same lane as the van (i.e., are simultaneously captured by the same associated IMSI device within 2 minutes) more than twice, and are associated with at least two vehicle devices and at least two IMSI devices, are added to the association details. The numbers above are configurable thresholds.

[0033] S53, Update Analysis Results: Update the analysis status and result statistics in the van information database; S54, Clean Up Resources: After the analysis is completed, delete the temporary intermediate table created for this vehicle.

[0034] This invention provides an overloaded van early warning system based on IMSI trajectory and vehicle trajectory analysis, comprising: a data preprocessing module, which filters and preprocesses van trajectories and IMSI trajectories from real-time data streams; a signal identification and filtering module, which identifies mobile phone signals (IMSIs) traveling with each van by performing spatiotemporal collision analysis (i.e., appearing at the same location and at similar times); a result filtering module, which rigorously filters the preliminary association results using multiple rules such as "multi-checkpoint verification" and "time continuity analysis" to exclude accidental traveling signals and ensure the reliability of the association; and an early warning module, which establishes an early warning model based on the number of different IMSIs traveling with the vehicle and their continuity characteristics, and automatically triggers an overload warning once a van is found to continuously associate with more than a threshold (e.g., 7 IMSIs) during its journey.

[0035] The core business process diagram of the system (as shown in Figure 2) includes the following steps: Step 1, data preprocessing and storage.

[0036] 1.1 The van information database is established by consuming vehicle data from the Kafka message queue, filtering records where the vehicle type is a small van (pass_car_type='K26') and the license plate format is standardized, and storing these records in the van information database ods_datas.van_info. The main fields of this table include: 1.2 IMSI Track Data Storage: The IMSI track data in Kafka is stored in a daily partitioned IMSI track table ods_datas_ktc.imsi_track (IT table for short), which contains the following key fields: 1.3. Minivan trajectory data storage: Complete vehicle passage data for minivans is stored in a daily partitioned vehicle passage trajectory table ods_datas_ktc.ovan_car_pass. This table has a 10-day data retention policy and contains complete vehicle passage attribute information. The main attributes are as follows: Step 2: Vehicle Trajectory Filtering and Preprocessing 2.1 Obtain unanalyzed records from ods_datas.van_info where flag=0, retrieving 1000 records at a time (quantity configurable) for processing. The specific SQL is as follows: 2.2 Analyze the status update. For the selected vehicle records, mark the status as "Under Analysis" (flag='2') to prevent duplicate processing. The specific SQL is as follows, where ${unids} is selected: 2.3 Valid Trajectory Verification: Verify whether the target vehicle passes through at least two (configurable) different checkpoints associated with IMSI data acquisition devices within the analysis time window. Here, ${starttime}, ${endtime}, and ${pass_plate_no} are data from the ods_datas.van_info table in step 2.1. The specific SQL is as follows: If cnt ≤ 2 (threshold is configurable), then the trajectory data is considered insufficient, and the process is directly marked as analyzed and the processing ends, proceeding to step 2.4; otherwise, proceed to step 3.

[0037] 2.4. SQL statements marked as analyzed and processed are as follows: Step 3: Individual Vehicle Trajectory Intermediate Table Construction. A dedicated trajectory intermediate table, dwd_datas_ktc.van_${unid}, is created for each verified van. This table integrates vehicle trajectory information and its associated IMSI acquisition device information. This intermediate table significantly reduces the data size of subsequent related calculations, improving processing efficiency.

[0038] The `dim_datas_ktc.car_imsi_dev` table is the association table between vehicle checkpoint devices and IMSI devices. Its main fields are as follows: Step 4, IMSI trajectory correlation and overload assessment: The specific SQL is as follows: ; The specific steps are described as follows: 4.1 Spatiotemporal correlation analysis: The vehicle intermediate table is associated with the IMSI trajectory table. The association conditions include: being captured within 120 seconds before and after the same associated device is counted as one co-travel (the 120-second threshold is configurable): Device association: v.imsi_dev_no = f.dev_no Time synchronization: ABS(DATEDIFF(ss, v.pass_datetime, f.collect_time)) <= 120-second time window expansion: The IMSI query time range is expanded to [${starttime}-10 minutes, ${endtime}+10 minutes] (the 10-minute threshold is configurable) 4.2 Multi-dimensional verification mechanism: The successfully associated IMSI is strictly screened to ensure data validity. The following numbers are all configurable thresholds. The following numbers are relatively accurate warning thresholds that can be obtained after multiple tests. The configuration can also be adjusted according to the situation: Minimum number of co-travels: COUNT(1) > 2 Multi-checkpoint verification: COUNT(DISTINCT pass_bay_unid) > 2 Multi-device verification: COUNT(DISTINCT `dev_no) > 2` Minimum travel time verification: `(maxtime - mintime) ≥ INTERVAL '10 minute'` 4.3 Continuity analysis uses time slice analysis to count the number of continuous traveler IMSIs at the beginning and end of the trip: `minnum`: Number of continuous traveler IMSIs at the beginning of the trip (based on a 10-minute window of `mintime`, threshold configurable); `maxnum`: Number of continuous traveler IMSIs at the end of the trip (based on a 10-minute window of `maxtime`, threshold configurable). 4.4 Overload decision rules trigger an overload warning and continue; otherwise, proceed directly to steps 5.3 and 5.4: Total associated IMSI count: `imsicnt > 6` (based on the assumption that a small van has a rated passenger capacity of 7 people, and each person has a mobile phone, threshold configurable) and trip continuity verification: `mincnt > 5` OR `maxcnt > 5` (threshold configurable). Step 5: Warning information generation and data maintenance 5.1 Warning information is aggregated into the vehicle warning table dwd_car_pass.van_warn_info. The table fields are as follows: The specific SQL is as follows: 5.2 The warning details record stores the IMSI associated details of vans that meet the overload conditions in the warning details table, dwd_datas_ktc.van_imsi_detail, for easy and quick reverse lookup later. The fields include the following: The specific SQL operation is as follows. The SQL below will add vehicles that travel in the same direction as the van (that is, are captured by the same IMSI device within 2 minutes) more than twice, and that are associated with at least 2 vehicle devices and at least 2 IMSI devices to the association details. The numbers above are all configurable thresholds.

[0039] ; 5.3 Update Analysis Results: Update the analysis status and results statistics in the van information database: 5.4 After the resource cleanup analysis is completed, delete the temporary intermediate tables created for this vehicle: The effect diagrams are shown in Figures 3, 4, and 5: Figure 3 shows the results of the warning list of suspected overloaded vehicles in actual operation of the system.

[0040] As can be seen from the figure, some vehicles in the test sample had IMSI association numbers far exceeding their normal passenger capacity. For example, a Shanghai-registered minivan had 24 associated IMSIs during a trip, far exceeding its capacity of 7 people. Even considering the possibility that some passengers were carrying dual-SIM phones, this is still clearly abnormal. Multiple vehicles had IMSI numbers exceeding the threshold of 7, such as 9, 20, 24, and 9 IMSIs (multiple times). These were automatically identified as highly suspected overloaded vehicles.

[0041] This demonstrates the key effect of the present invention: it can determine "abnormal occupant number" without weighing, and its early warning screening accuracy is significantly higher than that of video appearance recognition methods. Figure 4 shows the "details of associated IMSI counts". The system performs rigorous triple verification on all identified IMSIs: Taking the data in Figure 4 as an example: IMSI A: 5 associated vehicle checkpoints, 3 IMSI devices, 6 times traveling together; IMSI B: 6 associated vehicle checkpoints, 4 IMSI devices, 7 times traveling together; IMSI C: 4 associated vehicle checkpoints, 3 IMSI devices, 5 times traveling together. These data prove that: the reliability of IMSI and vehicle travel together is extremely high and is not a coincidence. The filtering rules of this invention effectively eliminate noise and fixed equipment signals.

[0042] Figure 5 shows the "Details of Vehicle-Associated IMSI Times". As can be seen from the figure, each record includes: (vehicle passing image, IMSI number, corresponding IMSI device location, vehicle capture time, IMSI capture time). By comparing the pass_time and collect_time in the same detail, it can be seen that the time difference between the same vehicles is within the rule of 0 to 120 seconds, which meets the "same vehicle behavior" judgment criteria defined in this invention.

[0043] These data demonstrate that the spatiotemporal model of this invention can accurately identify actual IMIS users riding in the vehicle, that their behavior is consistent and continuous, and that the judgment logic is rigorous, verifiable, and auditable.

[0044] It should be noted that embodiments of the present invention can be implemented in hardware, software, or a combination of both. The hardware portion can be implemented using dedicated logic; the software portion can be stored in memory and executed by a suitable instruction execution system, such as a microprocessor or dedicated-design hardware. Those skilled in the art will understand that the above-described devices and methods can be implemented using computer-executable instructions and / or included in processor control code, for example, such code provided on a carrier medium such as a disk, CD, or DVD-ROM, a programmable memory such as read-only memory (firmware), or a data carrier such as an optical or electronic signal carrier. The devices and modules of the present invention can be implemented by hardware circuitry such as very large-scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, or programmable hardware devices such as field-programmable gate arrays, programmable logic devices, etc., or by software executed by various types of processors, or by a combination of the above-described hardware circuitry and software, such as firmware.

[0045] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any modifications, equivalent substitutions, and improvements made by those skilled in the art within the scope of the technology disclosed in the present invention, and within the spirit and principles of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A method for early warning of overloaded minibuses based on IMSI trajectory and vehicle trajectory analysis, characterized in that, The process includes the following steps: Step 1, filtering vehicle trajectory data and corresponding IMSI trajectory data of small vans from the real-time data stream and preprocessing them; Step 2, performing spatiotemporal collision analysis on the vehicle trajectory data and IMSI trajectory data, determining the vehicle-to-vehicle relationship under the condition of the same device and a time difference not exceeding 120 seconds; Step 3, performing multi-checkpoint verification and time continuity analysis on the vehicle-to-vehicle relationship data to filter out occasional vehicle-to-vehicle data; Step 4, establishing early warning decision rules based on the number of different IMSIs traveling alongside the van and their duration characteristics, triggering an overload warning when the overload condition is met.

2. The method as described in claim 1, characterized in that, Step one includes: receiving vehicle passage data from the message queue, filtering records with vehicle type of minivan and license plate format as standard and storing them in the minivan information database; storing IMSI trajectory data in the IMSI trajectory table partitioned by day; and storing minivan passage trajectory data in the vehicle passage trajectory table partitioned by day.

3. The method as described in claim 1, characterized in that, Before step two, the following steps are performed: the validity of the vehicle trajectory to be analyzed is verified, which verifies that the vehicle passes through at least two different associated acquisition devices within the analysis time window; if this condition is not met, the analysis and processing of the vehicle is terminated.

4. The method as described in claim 1, characterized in that, After step two, a corresponding intermediate trajectory table is created for each verified van. The intermediate trajectory table contains only the vehicle's trajectory data and IMSI trajectory data related to its time window.

5. The method as described in claim 1, characterized in that, Step 3 includes the following verification conditions: the number of times the same vehicle travels is greater than 2; the number of checkpoints passed is greater than 2; the number of associated data collection devices is greater than 2; and the time difference between the earliest and latest time of traveling together is not less than 10 minutes.

6. The method as described in claim 1, characterized in that, Step four includes: counting the number of continuous fellow traveler IMSIs at the beginning of the trip and the number of continuous fellow traveler IMSIs at the end of the trip; triggering an overload warning when the total number of associated IMSIs is greater than 6 and the number of continuous fellow traveler IMSIs at the beginning or end of the trip is greater than 5.

7. An overloaded van early warning system based on IMSI trajectory and vehicle trajectory analysis, characterized in that, include: The data preprocessing module is used to filter and preprocess the trajectory data of the minivan and the IMSI trajectory data; The correlation analysis module is used to perform spatiotemporal collision analysis on vehicle trajectory data and IMSI trajectory data to determine the relationship between vehicles traveling in the same lane. The results filtering module is used to perform multi-checkpoint verification and time continuity analysis to eliminate occasional peer data; The early warning module is used to make overload decisions and trigger early warnings based on the different IMSI quantities and their duration characteristics.

8. The system as described in claim 7, characterized in that, The correlation analysis module uses a time difference of no more than 120 seconds under the same acquisition device as the condition for determining peers.

9. The system as described in claim 7, characterized in that, The warning module triggers a warning when the following conditions are met: the number of different associated IMSIs is greater than 6 and the number of consecutive IMSIs in the same process at the beginning or end of the trip is greater than 5.

10. A warning device for implementing the method according to any one of claims 1 to 6, characterized in that, It includes a processor and a memory, wherein the memory stores a computer program that, when executed by the processor, implements the steps of the method according to any one of claims 1 to 6.

Images