Heavy truck intelligent operation management system

Abstract

The application discloses a heavy truck intelligent operation management system. The existing system independently processes positioning data from transport order business, and uses a single physical threshold to determine abnormalities, resulting in excessive invalid alarms. The system comprises a positioning track center, an account center, a message center and multiple access terminals. The account center assigns an identity and maintains a mapping table to dynamically bind a transport order identity, and each transport order identity is associated with a predetermined path. The positioning track center receives real-time positioning data reported by the access terminals. When a positioning distance difference is greater than a first threshold, the transport order identity is queried according to the identity, and the predetermined path is called. The deviation degree is calculated. If the deviation degree is greater than a second threshold dynamically configured according to the transport task type, the system determines that the track is abnormal at the business level. The message center sends an abnormality notification to the identity and other access terminals associated with the transport order. Otherwise, the data is marked as physical fluctuation data. The system is mainly used for track monitoring and abnormal early warning in heavy truck transportation.

Description

Technical Field

[0001] This invention relates to the field of heavy-duty truck operation management technology. More specifically, this invention relates to a smart operation management system for heavy-duty trucks. Background Technology

[0002] In heavy-duty truck transportation operation management systems, vehicle positioning monitoring is one of the core functional modules. Existing positioning monitoring systems typically employ the following approach: the vehicle-mounted terminal or the driver's mobile device reports GPS positioning data at a fixed sampling frequency. After receiving the data, the positioning monitoring center calculates the distance difference between two adjacent positioning points to determine if the vehicle's position is abnormal. When this distance difference exceeds a preset fixed threshold, the positioning monitoring center generates a trajectory anomaly alarm record and pushes the alarm information to the monitoring terminal. The above solution has the following problems in actual operation: First, there is a lack of a mechanism to distinguish between physical anomalies in location data and trajectory anomalies at the operational level. During actual transportation, normal operational behaviors of heavy trucks, such as entering service areas for rest, temporary stops, avoiding road obstacles, or detouring based on real-time road conditions, can all cause significant differences in physical distance between adjacent location points, triggering preset thresholds and generating a large number of invalid alarms. Faced with a large number of invalid alarms, operations management personnel cannot quickly identify the truly business-level anomalies requiring intervention, leading to reduced monitoring efficiency. Secondly, the location monitoring system and the waybill management system are independent of each other, and the location data itself does not contain waybill context information. When the system detects a physical anomaly in the location data, it cannot determine which waybill the vehicle is currently executing, what the scheduled route of the waybill is, or whether the anomaly will affect the timely fulfillment of the waybill. Therefore, whether it is necessary to notify the customer, dispatch a backup vehicle, or adjust subsequent waybill arrangements all require managers to manually verify the waybill status by phone or other means before making a decision, which is slow and prone to omissions. The root cause of the above problems is that existing positioning monitoring systems treat positioning data as an independent physical signal and do not establish an index linking positioning data with operational business data. At the same time, existing systems all use a single physical threshold as the basis for anomaly judgment and lack the technical means to place physical fluctuations in the business context for secondary judgment.

[0003] Furthermore, the existing system faces a technical challenge: even when comparing location data with waybill routes, the tolerance for route deviation varies significantly across different transportation task types. Long-haul trunk transportation has a lower tolerance for route deviation, while short-haul delivery, due to the complex road conditions at the end of the route, has a relatively higher tolerance. The existing single threshold judgment method cannot adapt to the different needs of different transportation task types, and if a uniform threshold is used, it is difficult to balance the false alarm rate and the missed alarm rate.

[0004] The aforementioned problems are not unique to the heavy-duty truck transportation industry, but rather data processing deficiencies arising from the application of existing positioning and monitoring technology architecture in business scenarios. Summary of the Invention

[0005] One object of the present invention is to solve at least the above-mentioned problems and to provide at least the advantages that will be described later.

[0006] To achieve these objectives and other advantages of the present invention, a smart operation management system for heavy-duty trucks is provided, comprising: a positioning trajectory center, an account center, a message center, and multiple access terminals; The account center assigns a unique identity to each account and maintains a context association mapping table. The context association mapping table is used to dynamically bind the identity to the waybill identifier in the current operation task. Each waybill identifier is associated with corresponding predetermined business path data. The positioning trajectory center receives real-time positioning data carrying the identity identifier reported by the access terminal at a first sampling frequency; When the positioning trajectory center detects that the distance difference between the current positioning data and the previous positioning data is greater than a first threshold, the positioning trajectory center performs the following business context coupling judgment steps: S1. Query the context association mapping table in the account center according to the identity identifier to obtain the currently bound waybill identifier; S2. Retrieve the corresponding scheduled business path data according to the waybill identifier; S3. Calculate the degree of deviation between the current location data and the scheduled business path data; If the deviation is greater than the second threshold, the positioning trajectory center determines that it is a business-level trajectory abnormality, and calls the message center to send a trajectory abnormality notification carrying the waybill identifier to the access terminal corresponding to the identity identifier and the access terminals corresponding to other identity identifiers associated with the waybill identifier. If the deviation is not greater than the second threshold, the positioning trajectory center will mark the current positioning data as physical fluctuation data and store it in the trajectory record, without triggering the trajectory abnormality notification; Wherein, the second threshold is greater than the first threshold, and the second threshold is dynamically configured according to the transportation task type corresponding to the waybill identifier.

[0007] Preferably, after the location trajectory center determines that the business-level trajectory is abnormal, it also queries the current waybill's transportation stage information based on the waybill identifier: If the current waybill is in the loading stage, the message center is invoked to send a loading location anomaly notification to the access terminal corresponding to the customer account associated with the waybill identifier; If the current waybill is in transit, the message center is invoked to send a route deviation alarm to the access terminal corresponding to the administrator's account, and the abnormal start position and abnormal duration are marked in the trajectory record; If the current waybill is in the unloading stage, the message center is invoked to send an unloading location verification prompt to the access terminal corresponding to the identity identifier, and the access terminal is triggered to forcibly collect a return receipt photo of the current geographical location.

[0008] Preferably, after the positioning trajectory center determines that the business-level trajectory is abnormal, it also calls the message center to generate a to-do item creation instruction carrying the waybill identifier and sends it to the to-do center; The to-do center generates a trajectory anomaly handling to-do item associated with the waybill identifier based on the to-do item creation instruction, and simultaneously pushes the trajectory anomaly handling to-do item to the access terminal corresponding to the management personnel account associated with the waybill identifier and the access terminal corresponding to the identity identifier.

[0009] Preferably, when the to-do center receives a status change request for the to-do item related to the trajectory anomaly handling, it executes an atomic state synchronization process: The task center extracts the associated waybill identifier based on the task to be handled based on the trajectory anomaly, and sends a lock command to the file center, instructing the file center to lock the abnormal event folder associated with the waybill identifier; After receiving the successful lock response from the file center, the to-do center updates the status of the trajectory anomaly handling to-do item in the to-do database to "processed" and sends an anomaly confirmation mark to the location trajectory center. The location trajectory center stops judging the degree of deviation of subsequent location data for the waybill identifier based on the confirmed anomaly marker.

[0010] Preferably, the first threshold is a fixed distance threshold, and the second threshold is a dynamic distance threshold, wherein the dynamic distance threshold is dynamically configured based on at least one of the following factors: The waybill identifier corresponds to the transportation task type, which includes long-distance transportation, short-distance delivery, and dangerous goods transportation. The road type of the predetermined business path data includes expressways, national highways, and provincial highways; The location trajectory center obtains the current time period weather condition information through an external interface.

[0011] Preferably, before performing step S1, the positioning trajectory center first verifies whether the identity identifier is bound to the currently active waybill identifier: If there is no waybill identifier bound to the identity identifier in the context association mapping table, the current location data is marked as no business context data, and steps S1 to S3 are not executed. If the context association mapping table contains a waybill identifier bound to the identity identifier but the waybill status corresponding to the waybill identifier is completed, then the current location data is marked as redundant data of the completed waybill, and steps S1 to S3 are not executed.

[0012] Preferably, in step S3, the degree of deviation is calculated in the following way: The predetermined business path data includes path centerline and path width data: Using the path centerline as a reference, calculate the ratio of the shortest distance from the current positioning data to the path centerline to the path width data, and use the ratio as the degree of deviation.

[0013] Preferably, the system further includes an interface center. After the positioning trajectory center determines that a business-level trajectory is abnormal, it sends trajectory abnormality event data carrying the waybill identifier to an external scheduling system through the interface center. The external scheduling system re-plans the transportation scheduling scheme based on the trajectory anomaly event data, and returns the updated predetermined business path data to the positioning trajectory center through the interface center. The positioning trajectory center replaces the original predetermined service path data with the updated predetermined service path data, and continues to perform subsequent deviation judgments according to the updated predetermined service path data.

[0014] Preferably, the multiple access terminals include an App execution terminal operated by the driver, a Web management terminal operated by the administrator, a WeChat mini-program terminal operated by the customer, and an official account terminal operated by the franchisee or supplier. The App execution terminal reports real-time location data carrying the identity identifier according to the first sampling frequency; The web management terminal is used to configure the predetermined business path data corresponding to the waybill identifier and the value of the second threshold.

[0015] Preferably, after successful authentication, the account center returns an authentication token to the access terminal that initiated the authentication request, and the identity identifier carried in the real-time location data is obtained by the access terminal through parsing the authentication token; When the authentication token expires, the location tracking center returns an expired token response to the access terminal, and the access terminal re-initiates an authentication request to the account center to obtain a new authentication token and the currently bound waybill identifier.

[0016] The present invention has at least the following beneficial effects: After detecting a change in physical distance, the location trajectory center further performs a business context coupling judgment based on the waybill identifier, which distinguishes the physical fluctuations of the location data from trajectory anomalies at the operational business level. This ensures that location fluctuations caused by normal vehicle parking, detours, etc., will not trigger invalid alarms, and managers can focus their attention on abnormal events that truly involve business deviations.

[0017] The system utilizes the dynamic binding relationship between identity identifiers and waybill identifiers maintained by the account center to link location data to specific waybills and their predetermined routes, enabling the correlation judgment between abnormal vehicle location and the impact on waybill fulfillment. Based on this, the message center can simultaneously send trajectory anomaly notifications to multiple access points related to the waybill, improving the efficiency of anomaly information transmission and reducing the time required for manual verification of waybill status via telephone or other means.

[0018] By setting the second threshold to be greater than the first threshold and dynamically configuring it according to the type of transportation task, the system can adapt to the tolerance differences of different transportation scenarios when judging the degree of deviation. Different task types such as long-distance transportation, short-distance delivery, and dangerous goods transportation correspond to different deviation judgment standards, which helps to achieve a balance between false alarms and false negatives and improve the accuracy of anomaly detection.

[0019] The system also employs differentiated follow-up processing methods based on whether the waybill is in the loading, transit, or unloading stage. These include sending loading location anomaly notifications to customers, sending route deviation alarms to managers and recording abnormal trajectories, or triggering unloading location photo verification at the driver's end, ensuring that anomaly handling aligns with specific operational processes. After anomalies are converted into pending tasks, managers and drivers can simultaneously receive and track their progress on their respective terminals. Combined with atomic state synchronization processes and interface linkage with external dispatch systems, this facilitates closed-loop management of anomalies and timely adjustments to transportation plans. Furthermore, the access end uses an authentication token mechanism to verify identity and synchronize binding relationships. Upon token expiration, automatic re-authentication and acquisition of the current waybill identifier ensure continuous consistency of identity information and waybill context across all system endpoints.

[0020] Other advantages, objectives and features of the present invention will become apparent in part from the following description, and in part from those skilled in the art through study and practice of the invention. Detailed Implementation

[0021] The present invention will be further described in detail below with reference to embodiments, so that those skilled in the art can implement it based on the description.

[0022] This invention provides a smart operation and management system for heavy-duty trucks, including: a positioning trajectory center, an account center, a message center, and multiple access terminals; The account center assigns a unique identity to each account and maintains a context association mapping table. The context association mapping table is used to dynamically bind the identity to the waybill identifier in the current operation task. Each waybill identifier is associated with corresponding predetermined business path data. The positioning trajectory center receives real-time positioning data carrying the identity identifier reported by the access terminal at a first sampling frequency; When the positioning trajectory center detects that the distance difference between the current positioning data and the previous positioning data is greater than a first threshold, the positioning trajectory center performs the following business context coupling judgment steps: S1. Query the context association mapping table in the account center according to the identity identifier to obtain the currently bound waybill identifier; S2. Retrieve the corresponding scheduled business path data according to the waybill identifier; S3. Calculate the degree of deviation between the current location data and the scheduled business path data; If the deviation is greater than the second threshold, the positioning trajectory center determines that it is a business-level trajectory abnormality, and calls the message center to send a trajectory abnormality notification carrying the waybill identifier to the access terminal corresponding to the identity identifier and the access terminals corresponding to other identity identifiers associated with the waybill identifier. If the deviation is not greater than the second threshold, the positioning trajectory center will mark the current positioning data as physical fluctuation data and store it in the trajectory record, without triggering the trajectory abnormality notification; Wherein, the second threshold is greater than the first threshold, and the second threshold is dynamically configured according to the transportation task type corresponding to the waybill identifier.

[0023] Specifically, the heavy-duty truck intelligent operation management system includes a positioning trajectory center, an account center, a message center, and multiple access terminals. These centers and access terminals are connected via network communication. The positioning trajectory center serves as the node for aggregating and processing positioning data, the account center serves as the management node for the association between identity and waybill, and the message center serves as the notification distribution node. The account center assigns a unique identity identifier to each registered account. This identity identifier can be a string composed of numbers and letters, with a length of 16 or 32 characters. The account center internally maintains a context association mapping table, which is stored in key-value pairs. The key is the identity identifier, and the value is the waybill identifier bound to that identity identifier in the current operational task. This binding relationship is dynamically updated. When a driver receives a new waybill task through the access terminal, the account center binds the driver's identity identifier to the waybill identifier of the new waybill. The binding is released when the waybill is completed. Each waybill identifier is associated with corresponding predetermined business route data in the system. This predetermined business route data can be a navigation route from the loading point to the unloading point, pre-drawn or imported by the administrator on the web management terminal. This route is represented by a sequence of latitude and longitude coordinates.

[0024] The positioning trajectory center receives real-time positioning data reported by the access terminal at a first sampling frequency. This real-time positioning data carries the aforementioned identity identifier. The access terminal can be an app executed by the driver, running on the driver's smartphone or in-vehicle tablet device. Its built-in positioning module can be a GPS positioning module or a Beidou positioning module. This positioning module acquires the current geographical location at the first sampling frequency, which can be once every 10 seconds, once every 15 seconds, or once every 30 seconds. Then, it encapsulates the current latitude and longitude coordinates and the identity identifier into real-time positioning data and reports it to the positioning trajectory center via a 4G or 5G cellular network. When the positioning trajectory center receives the current positioning data, it calculates the distance difference between it and the previous positioning data. This distance difference is calculated using the semi-sine formula to determine the spherical distance between the two latitude and longitude coordinates. If the distance difference is greater than a first threshold, subsequent business context coupling judgment steps are triggered. The first threshold is a fixed distance threshold, which can be set to 200m, 300m, or 500m. The specific value can be set by the system administrator during initial configuration.

[0025] After triggering the business context coupling judgment step, the positioning trajectory center first executes step S1, which involves sending a query request to the account center based on the identity identifier carried in the current positioning data. The request includes this identity identifier. Upon receiving the query request, the account center searches for the currently bound waybill identifier corresponding to this identity identifier in its maintained context association mapping table and returns the query result to the positioning trajectory center. If a waybill identifier is found, step S2 is executed. The positioning trajectory center uses this waybill identifier as an index to retrieve the corresponding predetermined business path data from the system's path database. This predetermined business path data includes the path centerline coordinate sequence and path width data. The path width data can be set according to the road level; for example, the path width for a highway can correspond to 50m, for a national highway to 30m, and for a provincial highway to 20m. Then, step S3 is executed to calculate the deviation between the current positioning data and the predetermined business path data. This deviation can be calculated as follows: using the path centerline as a reference, calculate the shortest distance from the latitude and longitude coordinates corresponding to the current positioning data to all line segments on the path centerline, and use the ratio of this shortest distance to the path width data as the deviation.

[0026] If the calculated deviation exceeds the second threshold, the location trajectory center determines it as a business-level trajectory anomaly and simultaneously sends a trajectory anomaly notification carrying the waybill identifier to the access terminal corresponding to the identity identifier and other access terminals associated with the waybill identifier. The second threshold is a dynamic distance threshold, with a value greater than the first threshold. For example, when the first threshold is 300m, the second threshold can be set to 1.5km, 2km, or 5km. The second threshold is dynamically configured based on the transportation task type corresponding to the waybill identifier. When the transportation task type is long-distance transportation, the second threshold can be set to 1.5km; when the transportation task type is short-distance delivery, the second threshold can be set to 3km; and when the transportation task type is dangerous goods transportation, the second threshold can be set to 500m. These configuration values ​​are pre-set by administrators on the web management terminal for different transportation task types and stored in the system configuration database. If the deviation is not greater than the second threshold, the location trajectory center marks the current location data as physical fluctuation data and stores it in the trajectory record, without triggering a trajectory anomaly notification. The trajectory records are stored in the system's trajectory database. Each trajectory record contains the latitude and longitude coordinates of the location data, a timestamp, an identity identifier, and a tag type field. When sending trajectory anomaly notifications, the message center can use an SMS gateway to send SMS notifications to the driver's mobile phone, use in-app push services to push notification messages to the App execution terminal, or use WeChat official account template messages to send notifications to the WeChat accounts of customers or managers. The content of the trajectory anomaly notification includes the waybill identifier and a description of the time and location of the anomaly.

[0027] After successful authentication, the account center returns an authentication token to the access point that initiated the authentication request. This token can be generated based on the JSON Web Token format and has a validity period of 2, 4, or 8 hours. The identity identifier carried in the real-time location data is obtained by the access point through parsing this authentication token; that is, the access point extracts the identity identifier from the authentication token and encapsulates it in the location data when reporting it. When the authentication token expires, the location tracking center, upon receiving the location data carrying the expired token, returns a token expiration response to the access point. Upon receiving this response, the access point re-initiates an authentication request to the account center. After re-authentication, the account center returns a new authentication token. Simultaneously, the access point also retrieves the currently bound waybill identifier from the account center and caches it locally. The system also includes an interface center, which serves as a communication interface module for data exchange with external systems. When the positioning and trajectory center determines a business-level trajectory anomaly, it sends trajectory anomaly event data carrying the waybill identifier to the external dispatching system through the interface center. The external dispatching system re-plans the transportation scheduling scheme based on this trajectory anomaly event data and returns updated planned business path data to the positioning and trajectory center through the interface center. The positioning and trajectory center replaces the original planned business path data with the updated planned business path data and continues to perform subsequent deviation assessments according to the updated planned business path data. The interface center can use a RESTful API interface or a message queue-based interface to implement communication with the external dispatching system.

[0028] When the system is in operation, the driver logs in to their account through the App execution terminal. After authentication by the account center, an identity identifier is assigned to the App execution terminal and bound to the current waybill identifier. During vehicle operation, the positioning module of the App execution terminal acquires GPS positioning data at a first sampling frequency and reports it to the positioning trajectory center. After receiving each piece of positioning data, the positioning trajectory center calculates the distance difference with the previous positioning data. Only when this difference exceeds a first threshold is a business context coupling judgment initiated. In the business context coupling judgment, the positioning trajectory center obtains the waybill identifier by querying the mapping table of the account center through the identity identifier, then reads the predetermined path data from the path database and calculates the deviation degree. Based on the comparison result of the deviation degree and a second threshold, it decides whether to trigger a business-level anomaly notification. This technical solution establishes an association index between positioning data and waybill business data, and introduces a secondary judgment based on the business path deviation degree after a physical distance jump is triggered. This enables the system's anomaly detection to distinguish between physical fluctuations and business anomalies. At the same time, by dynamically configuring the second threshold to adapt to the tolerance differences of different transportation task types, it improves the accuracy of operation monitoring, reduces the interference of invalid alarms to management personnel, and ensures that anomaly notifications are accurately delivered to the access terminals of all parties involved in the waybill.

[0029] In another embodiment, after the location trajectory center determines that the business-level trajectory is abnormal, it also queries the current waybill's transportation stage information based on the waybill identifier: If the current waybill is in the loading stage, the message center is invoked to send a loading location anomaly notification to the access terminal corresponding to the customer account associated with the waybill identifier; If the current waybill is in transit, the message center is invoked to send a route deviation alarm to the access terminal corresponding to the administrator's account, and the abnormal start position and abnormal duration are marked in the trajectory record; If the current waybill is in the unloading stage, the message center is invoked to send an unloading location verification prompt to the access terminal corresponding to the identity identifier, and the access terminal is triggered to forcibly collect a return receipt photo of the current geographical location.

[0030] Specifically, when the positioning trajectory center determines that the business-level trajectory is abnormal based on the aforementioned deviation judgment result, the positioning trajectory center further uses the waybill identifier as an index to query the current waybill's transportation stage information from the system's waybill management database.

[0031] The waybill management database stores the current status field for each waybill. This field can be set to loading stage, transit stage, or unloading stage. This status is manually updated by the driver through the App execution terminal or automatically switched by the system based on the geofence of the loading and unloading locations.

[0032] If the query results show that the current waybill is in the loading stage, the location tracking center calls the message center to send a loading location anomaly notification to the access point corresponding to the customer account associated with that waybill. The access point corresponding to the customer account can be a WeChat mini-program used by the customer, which runs on the customer's smartphone. The loading location anomaly notification may include the waybill number, loading address, current actual location, and current time. The notification can be sent via WeChat mini-program subscription messages or SMS.

[0033] If the current waybill is en route, the location tracking center sends a route deviation alarm to the access terminal corresponding to the administrator's account via the message center. This access terminal can be a web management client running on the administrator's computer or a management app running on the administrator's mobile phone. The route deviation alarm may include the waybill identifier, current location coordinates, coordinates of the nearest point on the predetermined path, and the deviation distance. Simultaneously, the location tracking center marks the abnormal start position and abnormal duration in the current waybill's trajectory record. The abnormal start position is the location coordinate when the deviation is first determined to be greater than the second threshold. The abnormal duration is the time from the first abnormal determination to the current time, recorded in seconds in the trajectory record table; for example, the duration can be updated every 10 seconds.

[0034] If the current waybill is in the unloading stage, the location tracking center calls the message center to send an unloading location verification prompt to the access terminal corresponding to the identity identifier, which is the driver's App execution terminal. This unloading location verification prompt appears on the driver's App execution terminal interface as an in-app pop-up or notification message, prompting the driver to confirm whether the current location is the unloading location. Simultaneously, the message center triggers a forced data collection command to the App execution terminal. This command calls the built-in camera module of the smartphone where the App execution terminal is located. This camera module can be a rear-facing camera, located on the back of the smartphone, forcibly opening the camera and taking a photo of the current geographical environment as the return receipt photo. After being taken, this return receipt photo is automatically associated with the waybill identifier and the current location data, and uploaded by the App execution terminal via cellular network to the system's file center for storage. The file center can be a distributed object storage service.

[0035] During the loading and unloading phases, notifications sent by the message center carry the waybill identifier so that the recipient can identify the corresponding waybill. To determine the recording granularity for anomaly duration, the location tracking center has a built-in timer that starts when an anomaly is first detected, incrementing in 1-second increments until the anomaly is resolved or the waybill status changes. For route deviation alarms during transit, the system can set an alarm suppression interval, for example, preventing the same deviation alarm from being sent repeatedly within 10 minutes of the first alarm, to avoid excessive notification frequency. This suppression interval can be adjusted by administrators through the web management interface.

[0036] The processing methods covered in the above embodiments enable differentiated responses to business-level trajectory anomalies based on the specific stage of the waybill. During the loading stage, customers are directly notified to inform them of potential problems with the loading location. During transit, management is notified and the abnormal trajectory is recorded for subsequent tracing and analysis. During the unloading stage, mandatory photo verification of the unloading location is implemented. This tightly integrates anomaly handling with operational processes, improving the targeting and effectiveness of anomaly handling. In another embodiment, after the positioning trajectory center determines that the business-level trajectory is abnormal, it also calls the message center to generate a to-do item creation instruction carrying the waybill identifier and sends it to the to-do center; The to-do center generates a trajectory anomaly handling to-do item associated with the waybill identifier based on the to-do item creation instruction, and simultaneously pushes the trajectory anomaly handling to-do item to the access terminal corresponding to the management personnel account associated with the waybill identifier and the access terminal corresponding to the identity identifier.

[0037] Specifically, after determining a business-level trajectory anomaly based on the aforementioned deviation assessment results, the location trajectory center further invokes the message center to generate a pending task creation instruction. The data structure of this instruction includes the waybill identifier, the timestamp of the anomaly occurrence, the anomaly type flag, and the current location coordinates. The message center can choose a message queue middleware based on RabbitMQ or Kafka to handle the transmission of this instruction. This middleware is deployed on the system's message service node. The location trajectory center serializes the instruction in JSON format and publishes it to a queue topic named "Pending Task Creation."

[0038] The to-do center, acting as the consumer of this queue, pulls and parses the instruction from the message queue. The to-do center can be a standalone task management service module running on the application server and connected to the system's to-do database. This database can be a relational database such as MySQL or PostgreSQL, installed on the database server. Upon receiving the instruction, the to-do center creates a record for handling track anomalies in the to-do database based on the waybill identifier carried in the instruction. This record contains fields: unique to-do number, associated waybill identifier, to-do type (value is track anomaly), to-do status (initially pending), creation time, anomaly description summary, and urgency level.

[0039] The urgency level can be set according to the type of transportation task. For example, dangerous goods transportation can be set to high priority, and general transportation can be set to medium priority. This level is coded as numbers 1 to 3. After generating the to-do item record, the to-do center pushes the to-do item to two targets simultaneously. The first target is the access terminal corresponding to the administrator account associated with the waybill identifier. This access terminal can be a web management terminal running on the administrator's personal computer or a management app running on the administrator's smartphone. The push method can be WebSocket long connection push or mobile message push service. The second target is the access terminal corresponding to the aforementioned identity identifier, i.e., the driver's app execution terminal. The push method can be the app's built-in push service such as JPush or Getui.

[0040] The push notification presents a to-do item card, including the item number, waybill identifier, creation time, and action button. Managers and drivers can click the card to open the to-do item details page on their respective clients. The details page displays a map showing the specific location of the anomaly, a comparison of the scheduled route, and suggested handling methods. The to-do item display interface on the web management terminal can be a list page, arranged in reverse chronological order by creation time, highlighting unprocessed items. Its refresh rate can be set to automatically refresh every 30 seconds.

[0041] On the driver's app, to-do items are presented as notification messages and red dot prompts within the app. Drivers can access the task processing interface by clicking on these notifications. To ensure timely processing, the task center can start a timer after creating a task. If the task is not marked as processed within the set timeout period (e.g., 2 hours, 4 hours, or 8 hours), the task center will again call the message center to send a reminder notification to the two access points mentioned above. The reminder notification includes the original task number and a timeout reminder. This timeout period can be adjusted by administrators on the system configuration page of the web management interface according to the type of transportation task; for example, the timeout period for short-distance delivery can be set to 2 hours, and for long-distance transportation, it can be set to 8 hours. When generating a to-do item record, the task center can also simultaneously write a summary of the record to the system's operation log center for subsequent auditing and traceability.

[0042] Through the mechanism described in the above embodiments, business-level trajectory anomalies are not only notified to relevant parties via messages, but are also transformed into a structured task to be done and incorporated into the system's task management process. This gives the anomaly handling a clear tracking status and responsible person, improving the closed-loop management capability of anomaly handling. At the same time, managers and drivers can receive the task to be done on their respective terminals, facilitating collaborative handling between the two parties.

[0043] In another embodiment, when the task center receives a status change request for the task related to the trajectory anomaly handling, it executes an atomic state synchronization process: The task center extracts the associated waybill identifier based on the task to be handled based on the trajectory anomaly, and sends a lock command to the file center, instructing the file center to lock the abnormal event folder associated with the waybill identifier; After receiving the successful lock response from the file center, the to-do center updates the status of the trajectory anomaly handling to-do item in the to-do database to "processed" and sends an anomaly confirmation mark to the location trajectory center. The location trajectory center stops judging the degree of deviation of subsequent location data for the waybill identifier based on the confirmed anomaly marker.

[0044] Specifically, after creating and pushing the aforementioned to-do items, the to-do center continuously listens for status change requests from various access terminals. When an administrator clicks the "Confirm Processing" button on the to-do item details page via the web management terminal, or a driver clicks the "Verified" button via the app execution terminal, the access terminal sends an HTTP PUT request or WebSocket message to the to-do center. This request contains the unique number of the to-do item and the identity identifier of the requester.

[0045] Upon receiving the status change request, the task center first performs an authorization check to verify whether the requester belongs to the administrator or driver associated with the waybill identifier linked to the task. If the check passes, the atomic status synchronization process begins. The task center retrieves the task record from the task database based on the unique task number in the request and extracts the associated waybill identifier. Subsequently, the task center sends a lock command to the file center. This command can be an HTTP POST request targeting the file center's lock interface, and the request body contains the waybill identifier and the lock operation type (value: write lock).

[0046] The file center can be an independent file management service module running on the application server and connected to the underlying distributed file storage system, which can be MinIO or Ceph, with storage nodes deployed in an intranet storage cluster. Upon receiving a locking command, the file center locates the corresponding abnormal event folder based on the waybill identifier. This folder can be named using the waybill identifier followed by the "_abnormal" suffix, such as "ORD20260628001_abnormal". This folder was created by the trajectory center during the aforementioned trajectory anomaly determination and is used to store evidence files related to the anomaly, such as trajectory screenshots and return receipt photos. The file center invokes the underlying file system's file locking mechanism to set an exclusive lock on the folder. The lock's validity period can be set to 5 minutes, 10 minutes, or 30 minutes. After successful locking, the file center returns a successful lock response to the task center, containing a lock token and a lock expiration timestamp.

[0047] After receiving a successful lock response from the document center, the to-do center executes an update operation on the to-do database, changing the status field of the to-do item record from "Pending" to "Processed," and simultaneously recording the processing time and the processor's identity. This update operation is performed within a database transaction, with the transaction isolation level set to Read Committed. Upon successful update, the to-do center immediately sends an exception confirmation flag to the location tracking center. This flag can be sent via a message queue or by directly calling the location tracking center's RESTful interface, and includes the waybill identifier and confirmation time.

[0048] After the location tracking center receives the confirmed anomaly marker, it stores it in a memory cache. The key of the cache is the waybill identifier, and the value is the confirmation marker and the receiving time. The cache validity period can be set to 24 hours or until the waybill status changes to completed.

[0049] When the location tracking center receives new location data corresponding to the waybill identifier, it first checks whether there is an abnormal confirmation mark for the waybill in the cache before step S1. If there is, it skips the deviation judgment in steps S1 to S3 and directly marks the subsequent location data as normal tracking data after the abnormality is confirmed and stores it in the trajectory record, but no new trajectory abnormality notification is triggered. If there is no mark in the cache, the deviation judgment is performed in the aforementioned manner. If the locking command fails to receive a successful locking response due to the file center being busy or the network timeout, for example, if no response is received within the set timeout period of 3 seconds, 5 seconds, or 10 seconds, the task center can retry the locking request. The number of retries can be set to 3, and the retry interval is 1 second, 2 seconds, or 5 seconds. If all retries fail, the task center returns an operation failure response to the access terminal that initiated the status change request and prompts "File locking failed, please try again later", while not updating the task status or sending a confirmation mark.

[0050] Through the atomic state synchronization process in the above embodiments, a consistent operation sequence is formed between the status change of the to-do item, the locking of the abnormal event folder, and the determination and cessation of the location trajectory center. This avoids data inconsistency, such as preventing the problem that the to-do item status has been updated but the location trajectory center is still triggering abnormal notifications. At the same time, file locking ensures that relevant evidence files will not be concurrently modified or deleted during the abnormal handling process, thereby ensuring the integrity of the abnormal handling operation and data consistency.

[0051] In another embodiment, the first threshold is a fixed distance threshold, and the second threshold is a dynamic distance threshold, the dynamic distance threshold being dynamically configured based on at least one of the following factors: The waybill identifier corresponds to the transportation task type, which includes long-distance transportation, short-distance delivery, and dangerous goods transportation. The road type of the predetermined business path data includes expressways, national highways, and provincial highways; The location trajectory center obtains the current time period weather condition information through an external interface.

[0052] Specifically, the first threshold is a fixed distance threshold that does not change with variations in transportation task type or road conditions. This first threshold is used to detect jumps in physical distance between two adjacent positioning data points, and its value can be set to 200m, 300m, or 500m. This fixed threshold is written to the system's configuration database by administrators via the system configuration page on the web management terminal during system initialization. The positioning trajectory center loads this value from the configuration database and caches it in memory upon startup. Subsequent distance difference comparisons directly use this cached value.

[0053] The second threshold is a dynamic distance threshold, and its value is greater than the first threshold. The second threshold is used to determine whether the deviation between the current location data and the predetermined business path constitutes a business-level anomaly, and its value is calculated in real time based on multiple factors. When dynamically configuring according to the transportation task type, after obtaining the waybill identifier in step S2, the positioning trajectory center uses this waybill identifier as an index to query the transportation task type field in the waybill management database. The value of this field can include three types: long-distance transportation, short-distance delivery, and dangerous goods transportation. For different transportation task types, the second threshold uses different baseline values: when the transportation task type is long-distance transportation, the second threshold can be set to 1.5km; when the transportation task type is short-distance delivery, the second threshold can be set to 3km; when the transportation task type is dangerous goods transportation, the second threshold can be set to 500m. These baseline values ​​are also pre-configured by administrators on the web management terminal and stored in the system configuration database. The configuration table uses the transportation task type code as the key and the corresponding threshold value as the value.

[0054] When dynamically configuring road types based on predetermined business route data, the positioning trajectory center retrieves the predetermined business route data and further extracts road type information from it. The predetermined business route data is drawn by administrators during creation, and each road segment on the route is labeled with a road type attribute, which can be a highway, national highway, or provincial highway. The positioning trajectory center determines the current road segment based on the projection position of the current positioning data on the predetermined route, and then reads the road type of that segment. For different road types, the system sets a correction coefficient for the second threshold: when the road type is a highway, the correction coefficient can be set to 0.8; when the road type is a national highway, the correction coefficient can be set to 1.0; and when the road type is a provincial highway, the correction coefficient can be set to 1.2. The positioning trajectory center multiplies the aforementioned second threshold baseline value obtained based on the transportation task type by the above correction coefficient to obtain the initially adjusted second threshold.

[0055] When dynamically configuring based on current weather conditions, the location tracking center obtains the current weather information through an external interface. This external interface can be a RESTful API from a third-party weather service provider, such as the API of Hefeng Weather or OpenWeatherMap. The interface is accessed by the location tracking center sending an HTTP GET request, with the request parameters including the latitude and longitude coordinates from the current location data. The interface returns weather data for the area at those coordinates, including a weather condition field. This field can take values ​​such as sunny, cloudy, light rain, heavy rain, light snow, heavy snow, or fog / haze. Upon receiving the weather data, the location tracking center maps the weather condition to a weather correction coefficient for a second threshold: 1.0 for sunny or cloudy conditions; 1.2 for light rain or light snow; and 1.5 for heavy fog, heavy rain, or heavy snow. The location tracking center then multiplies the initially adjusted second threshold by the aforementioned weather correction coefficient to obtain the final second threshold.

[0056] Before each execution of step S3, the positioning trajectory center calculates the final value of the second threshold in real time according to the above method. If the external interface call times out or returns an error when obtaining weather information, for example, if no response is received within the set timeout period of 3 seconds, the positioning trajectory center can set the weather correction coefficient to a default of 1.0 and use the initially adjusted second threshold as the final threshold. Simultaneously, this event is recorded in the system log so that administrators can subsequently check the availability of the external interface. The upper limit of the final value of the second threshold can be limited to no more than 10km, and the lower limit can be limited to no less than 300m to prevent extreme values ​​from causing judgment failure.

[0057] Through the dynamic configuration mechanism in the above embodiments, the second threshold can be adaptively adjusted according to different transportation task types, road conditions and real-time weather conditions, making the judgment of business-level trajectory anomalies more adaptable in actual operation scenarios. For example, when short-distance delivery encounters provincial roads and it is raining, the second threshold will be raised accordingly to reduce misjudgments caused by complex road conditions and weather effects. On highways transporting dangerous goods and in sunny weather, the second threshold will be kept at a low level to ensure the strictness of trajectory monitoring for safety-sensitive transportation tasks.

[0058] In another embodiment, before performing step S1, the positioning trajectory center first verifies whether the identity identifier is bound to the currently active waybill identifier: If there is no waybill identifier bound to the identity identifier in the context association mapping table, the current location data is marked as no business context data, and steps S1 to S3 are not executed. If the context association mapping table contains a waybill identifier bound to the identity identifier but the waybill status corresponding to the waybill identifier is completed, then the current location data is marked as redundant data of the completed waybill, and steps S1 to S3 are not executed.

[0059] Specifically, before executing the aforementioned step S1, the location tracking center first queries the context association mapping table from the account center based on the identity identifier carried in the current location data to verify whether the identity identifier is bound to the currently active waybill identifier. The purpose of this verification operation is to confirm whether the vehicle or driver currently reporting the location data is in a valid transportation task.

[0060] After receiving the verification request, the account center performs a lookup operation using the identity identifier as the key in its maintained context association mapping table. This lookup operation is implemented using an in-memory hash table, and the lookup time complexity is constant. The account center returns the found waybill identifier and its corresponding waybill status to the location tracking center. The waybill status is stored in the waybill management database and can take values ​​such as active status, in transit status, and completed status.

[0061] If the account center does not find any waybill identifier bound to the identity identifier in the context association mapping table, that is, if there is no corresponding key-value pair in the mapping table, the location trajectory center marks the current location data as data without business context. After marking, the location trajectory center stores the location data as is in the trajectory record table, and writes the label value "no business context" into the label field of the record table. At the same time, it does not execute subsequent steps S1 to S3, that is, it no longer performs waybill identifier query, scheduled business path retrieval, and deviation calculation. The retention time of this data without business context in the trajectory record table can be set to 30 days, after which it will be automatically cleaned up by the system's data archiving task. The cleanup cycle can be set to be executed once a day at 2:00 AM.

[0062] If the account center finds a waybill identifier bound to the identity in the context association mapping table, but the waybill status corresponding to that waybill identifier is "completed," the location tracking center marks the current location data as redundant data of a completed waybill. A "completed" status indicates that the transportation task for that waybill has been completed and confirmed by the customer, and the system has updated the status field in the waybill management database to "completed." In this case, the location tracking center also does not execute steps S1 to S3, but stores the location data in the tracking record table and writes the tag value "redundant data of completed waybill" in the tag field. The retention time of this redundant data in the tracking record table can be set to 7 days, after which it will be automatically cleared by the system.

[0063] In the two cases mentioned above where no subsequent judgment steps are executed, the location trajectory center will not call the message center to send any notifications or trigger any abnormal alarms after making the mark.

[0064] When the location tracking center performs the above verification operation, if the query response time of the account center exceeds the set timeout threshold, such as exceeding 500ms, 1s, or 2s, the location tracking center can consider the verification operation to have failed. In this case, the location tracking center chooses to temporarily store the current location data in a memory queue and waits for 200ms, 500ms, or 1s before re-initiating the verification request to the account center. If the re-request still times out, the location tracking center normally stores the location data in the tracking record and marks it as "verification timeout unprocessed," and similarly, does not execute subsequent steps S1 to S3. This timeout retry mechanism avoids the interruption of location data processing due to temporary busyness of the account center, and also prevents the erroneous triggering or non-triggering of abnormal judgments when the binding relationship cannot be obtained.

[0065] Through the pre-verification mechanism in the above embodiments, the system divides the processing flow of location data into three paths: location data with valid binding relationships enters the complete business context coupling judgment process, while data without binding relationships and data from completed waybills skips the complex judgment logic and is only used as raw trajectory data storage. This approach reduces the consumption of system computing resources by data without business context and data from completed tasks, and also avoids interference with the judgment of operation and management personnel due to invalid abnormal notifications triggered by this data.

[0066] In another embodiment, in step S3, the degree of deviation is calculated in the following manner: The predetermined business path data includes path centerline and path width data: Using the path centerline as a reference, calculate the ratio of the shortest distance from the current positioning data to the path centerline to the path width data, and use the ratio as the degree of deviation.

[0067] Specifically, the predetermined business path data retrieved from the path database in step S2 by the positioning trajectory center includes two components: the path centerline coordinate sequence and the path width data.

[0068] The path centerline is a broken line formed by connecting a series of ordered latitude and longitude coordinate points. These coordinate points are arranged sequentially according to the vehicle's predetermined driving direction. The interval between two adjacent coordinate points can be set to 50m, 100m, or 200m. This interval is determined by the management personnel when drawing the predetermined path based on the path length and accuracy requirements. Long-distance transportation with longer path lengths can use larger point intervals to reduce the amount of data, while short-distance delivery with shorter path lengths can use smaller point intervals to improve accuracy.

[0069] Path width data is a numerical value representing the maximum permissible deviation of a vehicle from the path centerline. This value is set based on the actual road width of the road segment. For example, the path width data for highways can be set to 50m, for national highways to 30m, for provincial highways to 20m, and for urban roads to 15m. The path width data value can be entered by administrators when configuring pre-defined business path data through the web management interface, or it can be automatically generated by the system based on the road classification of the path centerline.

[0070] In step S3, the positioning trajectory center calculates the deviation between the current positioning data and the predetermined business path data, specifically using the following method. The positioning trajectory center first obtains the latitude and longitude coordinates from the current positioning data, taking these coordinates as point P. Then, using each line segment formed by two adjacent coordinate points on the path centerline as a reference, it sequentially calculates the shortest distance from point P to each line segment. For any line segment on the path centerline, with its two endpoints being points A and B, the shortest distance from point P to this line segment is calculated using the vector projection method. Specifically, it first calculates the projection length ratio t of vector AP along the direction of line segment AB. The value of t is equal to the dot product of vector AP and vector AB divided by the square of the magnitude of vector AB. If t is less than 0, the shortest distance from point P to this line segment is the distance from point P to point A; if t is greater than 1, the shortest distance from point P to this line segment is the distance from point P to point B; if t is between 0 and 1, the shortest distance from point P to this line segment is the perpendicular distance from point P to line AB.

[0071] The positioning trajectory center traverses all line segments along the path centerline, calculates the shortest distance from point P to each line segment, and takes the minimum value as the shortest distance from the current positioning data to the path centerline. This shortest distance is expressed in meters or kilometers, for example, 150m or 0.15km.

[0072] After obtaining the shortest distance, the positioning trajectory center divides this shortest distance by the path width data, and uses the quotient as the deviation degree. This deviation degree is a dimensionless ratio. For example, if the shortest distance from the current positioning data to the path centerline is 150m and the path width data is 30m, then the deviation degree is equal to 5.

[0073] The positioning trajectory center compares the deviation value with a second threshold. If the ratio is greater than the second threshold, it is determined to be a business-level trajectory anomaly; if the ratio is not greater than the second threshold, it is determined to be physical fluctuation data. The second threshold is also a dimensionless ratio, dynamically configured according to the type of transportation task. For example, the second threshold for long-distance transportation can be set to 2, the second threshold for short-distance delivery can be set to 4, and the second threshold for dangerous goods transportation can be set to 1. During the testing and verification process, multiple predetermined routes of different road types can be selected, each route containing at least 20 route coordinate points. Then, multiple simulated positioning points are generated at different distances around these route coordinate points, covering positions at distances of 0, 1, 2, 3, 4, and 5 times the route width from the route centerline, respectively. These simulated positioning data are input into the positioning trajectory center, and the deviation value corresponding to each simulated point is calculated. It is checked whether the deviation increases linearly with distance, and the calculation results are compared with manually measured values ​​to verify the calculation accuracy.

[0074] The path centerline and path width used in this system are stored in a path database. This database can use PostgreSQL in conjunction with PostGIS spatial extensions to store coordinate data, and the path width data is stored as an additional field in the same table.

[0075] The above embodiment uses the ratio of the shortest distance to the path width data as the degree of deviation. This calculation method normalizes the differences in road widths, making the judgment scale of deviation comparable under different road conditions. This avoids too many abnormal judgments due to the small allowable deviation range on narrow roads, and also avoids the omission of abnormal judgments due to the large allowable deviation range on wide roads.

[0076] In another embodiment, the system further includes an interface center. After the positioning trajectory center determines that a business-level trajectory is abnormal, it sends trajectory abnormality event data carrying the waybill identifier to an external scheduling system through the interface center. The external scheduling system re-plans the transportation scheduling scheme based on the trajectory anomaly event data, and returns the updated predetermined business path data to the positioning trajectory center through the interface center. The positioning trajectory center replaces the original predetermined service path data with the updated predetermined service path data, and continues to perform subsequent deviation judgments according to the updated predetermined service path data.

[0077] Specifically, in addition to the location tracking center, account center, message center, to-do center, and file center, the system also has an interface center.

[0078] The Interface Center, as an independent communication gateway service module, runs at the system's edge access layer. Its physical deployment location is in the DMZ zone between the enterprise's internal and external networks, typically mounted on one or more application servers. These servers are equipped with dual network interface cards (NICs), one connecting to the internal LAN and the other to the external internet. The Interface Center can be an API gateway built on Spring Cloud Gateway or Kong, integrating request routing, protocol conversion, circuit breaking and degradation mechanisms, and retry mechanisms.

[0079] Once the positioning trajectory center determines that a business-level trajectory anomaly has been identified based on the aforementioned deviation assessment results, it does not communicate directly with external systems. Instead, it constructs a trajectory anomaly event data and transmits this data to the interface center. This trajectory anomaly event data is encapsulated in JSON format, and its structure includes the following fields: waybill identifier, anomaly occurrence timestamp, latitude and longitude coordinates of the current positioning data, identifier of the planned business path data, deviation degree value, and transportation task type code.

[0080] Upon receiving the event data, the interface center converts it into the interface protocol format required by the pre-configured external dispatch system's access address. The external dispatch system can be a built-in dispatch module within the transportation management system or a separately deployed vehicle dispatch optimization platform. This external dispatch system communicates with the interface center via HTTPS, and the interface address can be configured as https: / / external dispatch system domain name / api / v1 / reroute. The interface center sends an HTTP POST request to this address. The request body contains the aforementioned trajectory anomaly event data, and the request header carries an authentication token for authentication by the external dispatch system. The authentication token's validity period can be set to 24 hours, and the interface center periodically retrieves and caches it from the external dispatch system's authentication interface.

[0081] Upon receiving the request, the external dispatch system analyzes the trajectory anomaly data and queries detailed information such as the loading and unloading locations, cargo type, cargo weight, and agreed delivery time based on the waybill identifier. Simultaneously, it combines the current location coordinates and the planned business route data to initiate a calculation process for replanning the transportation dispatch scheme. This calculation process can employ route replanning based on Dijkstra's algorithm or A algorithm, recalculating the route from the current location coordinates to the unloading location with the shortest time or shortest distance as the objective, while avoiding congested or closed road sections where the anomaly location is located.

[0082] The external dispatch system can also determine whether to dispatch additional backup vehicles based on the real-time location of the vehicles and the urgency of the goods. If additional vehicles are needed, the dispatch plan will include the license plate number of the backup vehicles and their estimated arrival time at the pick-up point.

[0083] After the external scheduling system completes the scheduling plan, it encapsulates the updated scheduled business path data into an HTTP response and returns it to the positioning trajectory center through the interface center. The updated scheduled business path data in the response body also adopts the coordinate point sequence format and includes path width data. It can also include the total mileage of the new path, the estimated remaining travel time, and information on key nodes along the way.

[0084] After receiving a response from the external scheduling system, the interface center extracts the updated business path data from the response body and transmits it back to the positioning trajectory center. Upon obtaining the updated scheduled business path data, the positioning trajectory center replaces the original scheduled business path data corresponding to the current waybill in memory with this data. The replacement operation is atomic; that is, the path data storage area for the waybill is locked first, the new path data is written, and then the lock is released. The write time is typically within 50ms. Simultaneously, the positioning trajectory center writes this update record to the system log, which includes the identifier of the original path data, the identifier of the new path data, and the update time.

[0085] After the replacement is completed, when the location trajectory center receives new location data corresponding to the waybill identifier, it continues to perform deviation judgment based on the updated scheduled business path data, following the steps S1 to S3 described above. In the first deviation calculation after the replacement, if the deviation between the current location data and the updated path is still greater than the second threshold, the location trajectory center will again determine it as a business-level trajectory anomaly and trigger the sending process to the external scheduling system again, forming a loop optimization mechanism. The maximum number of loops can be set to 3 to prevent infinite loops. If the interface center fails to receive a response within the set timeout period after sending a request to the external scheduling system (the timeout period can be set to 5 seconds, 10 seconds, or 15 seconds), the interface center will retry. The retry interval can be set to 2 seconds, with a maximum of 3 retries. If all attempts fail, the interface center will return an error code to the location trajectory center. The location trajectory center will record the error and maintain the original scheduled business path data unchanged. At the same time, it will send a notification "External scheduling system connection failed, please handle manually" to the access terminal corresponding to the administrator account through the message center.

[0086] The above embodiments introduce the linkage between the interface center and the external scheduling system. Business-level trajectory anomalies are no longer limited to the level of anomaly notification, but can drive the external scheduling system to automatically replan the transportation route and feed the updated route back to the positioning trajectory center for subsequent monitoring. This changes the handling of abnormal events from passive alarm to active scheduling, improving the timeliness of transportation scheduling in response to sudden trajectory anomalies.

[0087] In another embodiment, the plurality of access terminals include an App execution terminal operated by the driver, a Web management terminal operated by the manager, a WeChat mini-program terminal operated by the customer, and an official account terminal operated by the franchisee or supplier. The App execution terminal reports real-time location data carrying the identity identifier according to the first sampling frequency; The web management terminal is used to configure the predetermined business path data corresponding to the waybill identifier and the value of the second threshold.

[0088] Specifically, the system includes multiple access terminals covering four different types of terminal applications, each targeting different participants in the transportation business process.

[0089] The driver-operated app is a native application running on the driver's smart mobile device, which can be a smartphone running Android or iOS. It is typically located in the driver's cabin, usually mounted on a phone holder above the dashboard or placed in a storage compartment near the center console, allowing for convenient observation and operation while driving. After the driver completes login authentication, the app obtains the current location information by calling the positioning chip built into the smart mobile device. This positioning chip can be a GPS or BeiDou positioning chip, connected to the device's motherboard via an internal bus. The app periodically acquires location data at a first sampling frequency, which can be set to once every 5 seconds, every 10 seconds, every 15 seconds, or every 30 seconds. This frequency can be remotely adjusted by administrators via a web-based management interface. After acquiring location data each time, the App executes an HTTP POST request, encapsulating the latitude and longitude coordinates from the location data along with the identity identifier obtained from the account center. This request is then sent to the receiving interface of the location tracking center via the cellular network module or WiFi module of the smart mobile device. The URL address of this receiving interface is issued by the system during App initialization and stored in the App's local configuration file. If the location data reporting process fails due to unstable cellular network signal, the App executes a temporary storage of the location data in a local SQLite database. Once the network is restored, the data is retransmitted in a first-in, first-out order. During retransmission, a retransmission flag field is included in the request header so that the location tracking center can identify the data and avoid duplicate counting.

[0090] The web-based management interface, operated by administrators, is a web application running in the browser of an administrator's personal computer. This computer can be a desktop or laptop, located on the administrator's desk in the office or carried by the administrator. It connects to the system's application server via the company's intranet or VPN. The web interface is a single-page application built using the Vue.js or React framework and interacts with the backend service via HTTPS. After logging in through the web interface, administrators can draw or edit pre-booked business route data for specific waybill identifiers on the route planning page. This drawing operation is achieved by generating waypoints by clicking on a map component. The map component can be an interactive map provided by either the Amap JavaScript API or the Baidu Maps JavaScript API. After the route is drawn, the web interface submits the route centerline coordinate sequence and route width data to the route database for storage. Meanwhile, managers can also set the value of the second threshold for different transportation task types on the system configuration page of the web management terminal. The configuration form provides three input boxes for long-distance transportation, short-distance delivery and dangerous goods transportation. Managers can fill in the corresponding values. The values ​​can be set as dimensionless ratios such as 1.5, 2.0, 3.0, 4.0 or 5.0. After submission, these configuration values ​​are saved in the system configuration database. The positioning trajectory center reads these values ​​in real time when performing deviation judgment.

[0091] The WeChat mini-program interface operated by the customer is a mini-program page running within the customer's WeChat application. This mini-program does not require separate installation; the customer can load it by scanning the waybill QR code via WeChat or accessing it through the official account menu. The WeChat mini-program runs on the customer's smartphone, which the customer carries with them. Through the WeChat mini-program, the customer can view real-time trajectory information and anomaly notifications corresponding to the waybill identifier associated with it. When the location trajectory center determines that the business-level trajectory is abnormal and the current waybill is in the loading stage, the message center pushes a loading location anomaly notification to the WeChat mini-program through the WeChat subscription message interface. The notification content is displayed in the WeChat service notification list.

[0092] The WeChat Official Account client operated by franchisees or suppliers is an application based on a WeChat Official Account H5 page. It runs in the smartphone browser environment used by franchisee or supplier personnel and is accessed after following the company's Official Account and binding their account. This client can receive trajectory anomaly notifications sent by the message center through the WeChat Official Account template message interface, allowing franchisees or suppliers to promptly understand changes in the status of their related transportation tasks. During functional testing of the App's reporting frequency, the integrity of location data reception and the processing load of the location trajectory center were tested under different network conditions at reporting intervals of 5 seconds, 10 seconds, 15 seconds, and 30 seconds. The sampling frequency that minimizes the impact on server load while ensuring trajectory smoothness was selected.

[0093] Through the multi-terminal coverage design described above, participants with different roles can obtain information and operation interfaces related to their own responsibilities through their respective suitable access terminals, enabling the system to reach all relevant parties in trajectory monitoring and anomaly handling processes.

[0094] In another embodiment, after successful authentication, the account center returns an authentication token to the access terminal that initiated the authentication request, and the identity identifier carried in the real-time location data is obtained by the access terminal through parsing the authentication token; When the authentication token expires, the location tracking center returns an expired token response to the access terminal, and the access terminal re-initiates an authentication request to the account center to obtain a new authentication token and the currently bound waybill identifier.

[0095] Specifically, after receiving an authentication request from any access point, the account center first verifies the username and password carried in the request. The password is hashed and encrypted using the bcrypt or SHA256 algorithm during transmission to ensure security.

[0096] The sender of the authentication request can be any of the following: the App execution terminal operated by the driver, the Web management terminal operated by the administrator, the WeChat mini-program terminal operated by the customer, or the official account terminal operated by the franchisee or supplier. Each access terminal sends the request to the authentication interface in the account center when the user logs in for the first time. The URL address of the authentication interface is preset in the configuration file of the access terminal, and its format is https: / / system domain name / api / auth / login.

[0097] After the account center verifies the username and password, it generates an authentication token if the verification is successful. This authentication token can be a stateless token based on the JSON Web Token format. The token's payload includes the account's identifier, account type, and token issuance time. The token's signature uses the HMAC-SHA256 algorithm in conjunction with a 256-bit key configured in the account center. The authentication token's validity period can be set to 2 hours, 4 hours, or 8 hours, which is preset by the administrator in the account center's configuration file; for example, it can be set to 4 hours.

[0098] The account center returns the generated authentication token to the requesting access point via the HTTP response body or the Set-Cookie header. Upon receiving the token, the access point persists it locally. For app-based applications and WeChat mini-programs, this can be stored in a secure storage area of ​​the local file system or in SharedPreferences; for web management applications, it can be stored in the browser's localStorage or sessionStorage. Each time the access point subsequently reports real-time location data, it reads the authentication token from local storage and uses the identifier field from the token to populate the identifier field in the location data, or it directly sends the complete authentication token as a Bearer Token in the Authorization field of the HTTP request header to the location tracking center.

[0099] After receiving location data, if the data contains a complete authentication token, the location tracking center will first parse the identity identifier from the token, verify whether the token's signature is valid and whether the token is within its validity period. If the verification is successful, the identity identifier will be extracted for subsequent steps.

[0100] When the authentication token expires and the access terminal reports location data to the location tracking center again, the location tracking center, upon verifying the token's validity, finds that the current time has exceeded the expiration timestamp in the token payload. At this point, the location tracking center does not process the main content of the location data but instead constructs a token expiration response and returns it to the access terminal. This token expiration response can be an HTTP 401 status code response, with the response body containing an error code field and an error description field in JSON format. The error code can be set to TOKEN_EXPIRED, and the error description is that the authentication token has expired; please log in again. Upon receiving this token expiration response, the access terminal stops the periodic reporting task of the current location data and immediately enters the re-authentication process. In the re-authentication process, the access terminal first checks whether the username and password are saved in local storage. If they are saved, it directly sends a re-authentication request to the authentication interface of the account center, with the request body containing the username and password. If they are not saved, it displays a login interface prompting the user to re-enter the username and password, and after the user enters them, it sends an authentication request. If the username and password verification for the re-authentication request passes, the account center generates a new authentication token and returns it to the access point. The validity period of this new token is recalculated, for example, 4 hours from the current time. After receiving the new token, the access point not only replaces the old token in its local storage with the new token, but also actively queries the account center for the waybill identifier currently bound to this identity. After finding the binding relationship, the account center returns it to the access point, which then caches the waybill identifier locally.

[0101] After completing the re-authentication and waybill identifier update, the access terminal resumes periodic reporting of location data, using the identity identifier parsed from the new token in subsequent location data reports. If the access terminal fails to receive a response from the account center during the re-authentication request process due to network issues, such as not receiving a response within the set timeout of 5, 10, or 15 seconds, the access terminal can initiate an exponential backoff retry strategy. The first retry interval is 2 seconds, the second is 4 seconds, the third is 8 seconds, and a maximum of 3 retries are allowed. If all retries fail, the access terminal suspends location data reporting and displays a network error message on the interface, waiting for the user to manually trigger a reconnection.

[0102] When generating a new token, the account center can also choose to set the signing key rotation cycle of the new token to be updated every 24 hours to further improve system security.

[0103] Through the authentication token mechanism in the above embodiments, the system realizes stateless management of access terminal identity authentication. The re-authentication process after the token expires is automatically triggered, ensuring that the system continuously obtains a valid identity identifier for waybill association query. At the same time, the access terminal synchronously obtains the latest bound waybill identifier during re-authentication, avoiding the problem of asynchronous binding relationship caused by token update.

[0104] Although embodiments of the present invention have been disclosed above, they are not limited to the applications listed in the specification and embodiments. They can be applied to various fields suitable for the present invention. For those skilled in the art, other modifications can be easily made. Therefore, without departing from the general concept defined by the claims and their equivalents, the present invention is not limited to the specific details and embodiments shown and described herein.

Claims

1. A smart operation management system for heavy-duty trucks, characterized in that, include: Location tracking center, account center, message center, and multiple access terminals; The account center assigns a unique identity to each account and maintains a context association mapping table. The context association mapping table is used to dynamically bind the identity to the waybill identifier in the current operation task. Each waybill identifier is associated with corresponding predetermined business path data. The positioning trajectory center receives real-time positioning data carrying the identity identifier reported by the access terminal at a first sampling frequency; When the positioning trajectory center detects that the distance difference between the current positioning data and the previous positioning data is greater than a first threshold, the positioning trajectory center performs the following business context coupling judgment steps: S1. Query the context association mapping table in the account center according to the identity identifier to obtain the currently bound waybill identifier; S2. Retrieve the corresponding scheduled business path data according to the waybill identifier; S3. Calculate the degree of deviation between the current location data and the scheduled business path data; If the deviation is greater than the second threshold, the positioning trajectory center determines that it is a business-level trajectory abnormality, and calls the message center to send a trajectory abnormality notification carrying the waybill identifier to the access terminal corresponding to the identity identifier and the access terminals corresponding to other identity identifiers associated with the waybill identifier. If the deviation is not greater than the second threshold, the positioning trajectory center will mark the current positioning data as physical fluctuation data and store it in the trajectory record, without triggering the trajectory abnormality notification; Wherein, the second threshold is greater than the first threshold, and the second threshold is dynamically configured according to the transportation task type corresponding to the waybill identifier.

2. The heavy-duty truck intelligent operation management system as described in claim 1, characterized in that, After the location trajectory center is determined to be an operational-level trajectory anomaly, the current waybill's transportation stage information is also queried based on the waybill identifier: If the current waybill is in the loading stage, the message center is invoked to send a loading location anomaly notification to the access terminal corresponding to the customer account associated with the waybill identifier; If the current waybill is in transit, the message center is invoked to send a route deviation alarm to the access terminal corresponding to the administrator's account, and the abnormal start position and abnormal duration are marked in the trajectory record; If the current waybill is in the unloading stage, the message center is invoked to send an unloading location verification prompt to the access terminal corresponding to the identity identifier, and the access terminal is triggered to forcibly collect a return receipt photo of the current geographical location.

3. The heavy-duty truck intelligent operation management system as described in claim 1, characterized in that, After the location trajectory center determines that the business-level trajectory is abnormal, it also calls the message center to generate a to-do item creation instruction carrying the waybill identifier and sends it to the to-do center. The to-do center generates a trajectory anomaly handling to-do item associated with the waybill identifier based on the to-do item creation instruction, and simultaneously pushes the trajectory anomaly handling to-do item to the access terminal corresponding to the management personnel account associated with the waybill identifier and the access terminal corresponding to the identity identifier.

4. The heavy-duty truck intelligent operation management system as described in claim 3, characterized in that, When the task center receives a status change request for a task related to the trajectory anomaly handling, it executes an atomic state synchronization process: The task center extracts the associated waybill identifier based on the task to be handled based on the trajectory anomaly, and sends a lock command to the file center, instructing the file center to lock the abnormal event folder associated with the waybill identifier; After receiving the successful lock response from the file center, the to-do center updates the status of the trajectory anomaly handling to-do item in the to-do database to "processed" and sends an anomaly confirmation mark to the location trajectory center. The location trajectory center stops judging the degree of deviation of subsequent location data for the waybill identifier based on the confirmed anomaly marker.

5. The heavy-duty truck intelligent operation management system as described in claim 1, characterized in that, The first threshold is a fixed distance threshold, and the second threshold is a dynamic distance threshold, wherein the dynamic distance threshold is dynamically configured based on at least one of the following factors: The waybill identifier corresponds to the transportation task type, which includes long-distance transportation, short-distance delivery, and dangerous goods transportation. The road type of the predetermined business path data includes expressways, national highways, and provincial highways; The location trajectory center obtains the current time period weather condition information through an external interface.

6. The intelligent operation management system for heavy-duty trucks as described in claim 1, characterized in that, Before executing step S1, the location trajectory center first verifies whether the identity identifier is bound to the currently active waybill identifier: If there is no waybill identifier bound to the identity identifier in the context association mapping table, the current location data is marked as no business context data, and steps S1 to S3 are not executed. If the context association mapping table contains a waybill identifier bound to the identity identifier but the waybill status corresponding to the waybill identifier is completed, then the current location data is marked as redundant data of the completed waybill, and steps S1 to S3 are not executed.

7. The heavy-duty truck intelligent operation management system as described in claim 1, characterized in that, In step S3, the degree of deviation is calculated in the following way: The predetermined business path data includes path centerline and path width data: Using the path centerline as a reference, calculate the ratio of the shortest distance from the current positioning data to the path centerline to the path width data, and use the ratio as the degree of deviation.

8. The intelligent operation management system for heavy-duty trucks as described in claim 1, characterized in that, The system also includes an interface center. After the positioning trajectory center determines that a business-level trajectory is abnormal, it sends trajectory abnormality event data carrying the waybill identifier to the external scheduling system through the interface center. The external scheduling system re-plans the transportation scheduling scheme based on the trajectory anomaly event data, and returns the updated predetermined business path data to the positioning trajectory center through the interface center. The positioning trajectory center replaces the original predetermined service path data with the updated predetermined service path data, and continues to perform subsequent deviation judgments according to the updated predetermined service path data.

9. The heavy-duty truck intelligent operation management system as described in claim 1, characterized in that, The multiple access terminals include an App execution terminal operated by drivers, a Web management terminal operated by managers, a WeChat mini-program terminal operated by customers, and an official account terminal operated by franchisees or suppliers. The App execution terminal reports real-time location data carrying the identity identifier according to the first sampling frequency; The web management terminal is used to configure the predetermined business path data corresponding to the waybill identifier and the value of the second threshold.

10. The heavy-duty truck intelligent operation management system as described in claim 1, characterized in that, After successful authentication, the account center returns an authentication token to the access terminal that initiated the authentication request. The identity identifier carried in the real-time location data is obtained by the access terminal through parsing the authentication token. When the authentication token expires, the location tracking center returns an expired token response to the access terminal, and the access terminal re-initiates an authentication request to the account center to obtain a new authentication token and the currently bound waybill identifier.