Same display data link verification method, system, computer device and storage medium

Abstract

The application discloses a same-display data link verification method and system, computer equipment and a storage medium. The method comprises the following steps: obtaining target navigation route data, and extracting a route track point string from the target navigation route data; determining the motion state corresponding to each track point in the route track point string, and generating simulation track data; based on a linkage scheduling strategy of alternately reporting and querying, the simulation track data is reported in batches, and after the completion of single batch reporting, track query is initiated to obtain query track response data corresponding to the batch; and multi-dimensional link verification is performed on the reported simulation track data and the query track response data batch by batch. In the embodiment of the application, the problems of low automation, inability to accurately measure timeliness, lack of authenticity of track simulation, limited verification coverage and the like in the existing same-display function verification are effectively solved, the same-display business full-link verification is realized, and the full-link data stability and reliability of the passenger and freight transport same-display function are ensured.

Description

Technical Field

[0001] This application relates to the field of automated testing technology, and in particular to a method, system, computer device and storage medium for simultaneous display data link verification. Background Technology

[0002] In current passenger and freight transportation platforms, simultaneous display of driver and passenger locations and simultaneous display of driver and freight locations are core functions to ensure service experience and safety monitoring. The data flow chain is usually as follows: the driver's APP collects GPS location data → after encoding and compression, it is reported to the location service backend → the backend stores the trajectory and matches the path → the passenger / freight owner obtains the driver's real-time location and driving trajectory through the query interface → and renders and displays it on the front-end map.

[0003] To ensure the normal operation of the aforementioned simultaneous display function, various methods are typically employed to verify the entire data flow chain, including manual real-device testing, recording and playback, single-interface mock testing, and trajectory management and playback platforms. However, existing verification methods suffer from low automation, relying heavily on manual visual qualitative judgment of display effects. This makes it difficult to achieve procedural and quantitative verification, resulting in low efficiency, strong subjectivity, and unsuitability for routine and large-scale testing. Furthermore, they cannot accurately measure the timeliness of the data link. Traditional trajectory playback uses a separate model of full reporting followed by centralized verification, which cannot immediately verify data visibility after reporting, making it difficult to quantify the end-to-end latency of transmission, storage, writing, and query display. Moreover, conventional simulated trajectories only contain basic coordinate information and lack real kinematic parameters, making it difficult to trigger core algorithms such as backend trajectory matching, smoothing, and anomaly detection. This results in shallow test coverage and insufficient verification. Finally, the existing verification does not fully reproduce the real transmission link of data compression and multi-layer encoding, which is prone to overlooking hidden issues such as encoding and decoding compatibility; at the same time, it lacks navigation route link verification and does not take into account the differentiated needs of customer freight scenarios, resulting in limited verification coverage and failing to guarantee the stability and reliability of the entire link of the same display business.

[0004] In summary, existing verification methods for the same display function suffer from problems such as low automation, inability to accurately measure timeliness, lack of realism in trajectory simulation, and limited verification coverage. They cannot achieve comprehensive, accurate, and automated verification of the end-to-end data path for the same display function between drivers and passengers and between drivers and freight in passenger and freight scenarios. Summary of the Invention

[0005] Therefore, it is necessary to provide a simultaneous display data link verification method, system, computer equipment, and storage medium to address the above-mentioned technical problems and solve at least one of the problems existing in the prior art.

[0006] Firstly, a method for verifying simultaneous data links is provided, including: Acquire target navigation route data, and extract route trajectory point strings from the target navigation route data; Determine the motion state corresponding to each trajectory point in the route trajectory point string, and generate simulation trajectory data; The simulation trajectory data is reported in batches based on a linkage scheduling strategy that alternates between reporting and querying. After a single batch of reporting is completed, a trajectory query is initiated to obtain the corresponding batch of query trajectory response data. Multi-dimensional link verification is performed on the reported simulation trajectory data and the query trajectory response data in batches.

[0007] In one possible implementation, determining the motion state corresponding to each trajectory point in the route trajectory point string and generating simulation trajectory data includes: Based on a pre-defined geographic model, calculate the ground distance between adjacent trajectory points; Based on the ground distance, the speed and heading information of each trajectory point are calculated, and corresponding time information is configured for each trajectory point. The ground distance, speed, heading, and time information are fused to generate simulated trajectory data with multi-dimensional motion states.

[0008] In one possible implementation, calculating the ground distance between adjacent trajectory points based on a preset geographic model includes: Calculate the radius of curvature of the meridian and the radius of curvature of the zonal and tropospheric spheres based on the Earth's equatorial radius and oblateness; Based on the curvature radius of the meridian and the curvature radius of the zonal circle, calculate the eastward and northward distances; The ground distance is calculated based on the eastward distance and the northward data.

[0009] In one possible implementation, the simulation trajectory data is reported in batches based on a coordinated scheduling strategy that alternates between reporting and querying, and trajectory queries are performed after each batch of reporting is completed, including: The simulated trajectory data is divided into multiple batches of simulated trajectory sub-data according to a preset batching rule; After compressing and encoding each batch of simulated trajectory sub-data, it is reported in batches according to the preset reporting time interval. Once a batch of simulation trajectory sub-data has been reported, the trajectory query operation is triggered.

[0010] In one possible implementation, triggering the trajectory query operation includes: Extract the location timestamp corresponding to the last reported data from the simulation trajectory sub-data reported in the current batch; Based on the location timestamp, determine the query start time and query end time; Based on the query start time and query end time, a trajectory query is performed.

[0011] In one possible implementation, acquiring target navigation route data and extracting route trajectory point strings from the target navigation route data includes: According to the nested hierarchical structure of the target navigation route data, extract the coordinate point string level by level; The coordinate point string is concatenated sequentially to obtain the route trajectory point string.

[0012] In one possible implementation, the step of performing multi-dimensional link verification on the reported simulation trajectory data and the queried trajectory response data in batches includes: Determine whether the position offset between the simulated trajectory sub-data reported in each batch and the corresponding query trajectory response data is less than the preset position offset threshold; Determine whether the time offset between the simulated trajectory sub-data reported in each batch and the corresponding query trajectory response data is within the preset time range; Determine whether the trajectory coverage between the simulated trajectory sub-data reported in each batch and the corresponding query trajectory response data is greater than the preset trajectory coverage threshold; Determine whether the time difference between the completion time of each batch's report and the successful return time of the query is less than the preset time limit; Determine whether the target navigation route data is consistent with the route data corresponding to each batch of query trajectory response data; If all of the above conditions are met, the verification passes.

[0013] Secondly, a simultaneous display data link verification system is provided, including: The route trajectory point string extraction unit is used to acquire target navigation route data and extract route trajectory point strings from the target navigation route data; The simulation trajectory data generation unit is used to determine the motion state of each trajectory point in the route trajectory point string and generate simulation trajectory data. The reporting-query alternating execution unit is used to report the simulation trajectory data in batches based on the linkage scheduling strategy of alternating reporting and querying, and to initiate trajectory query after a single batch of reporting is completed to obtain the corresponding batch of query trajectory response data. The multi-dimensional verification unit is used to perform multi-dimensional link verification on the reported simulation trajectory data and the query trajectory response data in batches.

[0014] Thirdly, a computer device is provided, including a memory, a processor, and computer-readable instructions stored in the memory and running on the processor, wherein the processor, when executing the computer-readable instructions, implements the simultaneous display data link verification method as described above.

[0015] Fourthly, a readable storage medium is provided, on which computer-readable instructions are stored, which, when executed by a processor, implement the same-display data link verification method as described above.

[0016] The aforementioned simultaneous display data link verification method, system, computer equipment, and storage medium, the method implementation includes: acquiring target navigation route data and extracting route trajectory point strings from the target navigation route data; determining the motion state corresponding to each trajectory point in the route trajectory point string and generating simulated trajectory data; reporting the simulated trajectory data in batches based on a linkage scheduling strategy that alternates between reporting and querying, and initiating a trajectory query after the completion of a single batch of reporting to obtain the corresponding batch of query trajectory response data; and performing multi-dimensional link verification on the reported simulated trajectory data and the query trajectory response data batch by batch. In this embodiment, the problems of low automation, inaccurate timeliness measurement, lack of realism in trajectory simulation, and limited verification coverage in existing simultaneous display function verification are effectively solved. Trajectory simulation, batch reporting, real-time querying, and multi-dimensional verification are completed through a programmatic process, realizing quantitative output of verification results, improving verification efficiency and meeting the needs of large-scale routine verification. Through a scheduling strategy of alternating reporting and querying, the end-to-end latency is accurately quantified, filling the gap in timeliness measurement. By generating a simulated trajectory containing complete kinematic features, the backend core algorithm is effectively triggered, improving the verification depth and reliability. At the same time, the multi-layer encoding and decoding link is fully reproduced, covering navigation route verification and both customer and freight scenarios, realizing full-link verification of simultaneous display business and ensuring the stability and reliability of the entire link of passenger and freight simultaneous display function. Attached Figure Description

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

[0018] Figure 1 This is a flowchart illustrating a simultaneous data link verification method in one embodiment of this application; Figure 2 This is a schematic diagram of the structure of a simultaneous data link verification system in one embodiment of this application; Figure 3 This is a schematic diagram of a computer device according to one embodiment of this application. Detailed Implementation

[0019] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0020] The simultaneous display data link verification method provided in this embodiment can be applied to a pre-built dual-authentication system cross-system end-to-end data path verification architecture. Specifically, independent business authentication and interface call logic can be constructed for the driver and passenger / freighter ends. The driver end, relying on its driverToken identity credential, calls the location reporting interface and navigation route reporting interface to actively report trajectory and route data; the passenger or freighter end, using its queryToken independent credential, retrieves driver location information in real time through the trajectory query interface. The two authentication and call systems correspond to different business service domains, such as the location service domain and the map path synchronization service domain, respectively, fully replicating multi-role cross-domain interaction scenarios in real-world business scenarios. Meanwhile, based on this dual-authentication cross-system architecture, an automated verification process of alternating reporting and querying can be realized in an orderly manner. The continuous reporting of simulation trajectory data is completed in batches, and after each batch of reporting is completed, the query terminal immediately initiates a data query request, forming a closed-loop verification logic of reporting, writing, querying, and comparison. This fully reproduces the cross-domain interaction behavior of multiple roles under real business, and comprehensively verifies the entire link flow process of data from driver's end collection and reporting, backend reception, storage and processing, to passenger / freighter end query rendering and display. This effectively ensures the data continuity, transmission timeliness and data consistency of the entire process of the same display business.

[0021] In one embodiment, such as Figure 1 As shown, a method for verifying a simultaneous display data link is provided, including the following steps: In step S110, target navigation route data is acquired, and route trajectory point strings are extracted from the target navigation route data; Optionally, the target navigation route data is first loaded from a pre-stored route data resource file. Then, coordinate strings are extracted layer by layer based on the nested hierarchy of the target navigation route data and concatenated into a route trajectory point string. It should be noted that the last coordinate point of the extracted route trajectory point string can be used as the endpoint (nextPoint) for parameter configuration of subsequent query interfaces.

[0022] It should be noted that this route data resource file can be standardized structured route data pre-generated by the navigation route planning service. Specifically, it can be obtained and stored through methods such as pulling from the navigation route planning interface, offline export from the front-end navigation business, or local caching. This resource file internally carries a complete multi-level nested route hierarchy, which may include a set of paths (paths), a set of steps under each path (steps), a set of navigation links under each step (naviLink), and coordinate strings (coords) for each link. The route data can then be encapsulated according to the navigation route reporting data structure. The encapsulated data may include fields such as coordinate type (coord_type), path identifier (path_id), event type (event_type), timestamp (gTime), order identifier (order_ids), and origin latitude and longitude.

[0023] Then, the encapsulated data can undergo multi-layer encoding. Specifically, the JSON data is first serialized into a string, then compressed using the GZIP compression algorithm, the compressed byte stream is Base64 encoded, and finally URL encoded. The encoded data is then reported to the navigation route reporting interface via an HTTP POST request. This request can carry complete driver authentication information (such as a driver-specific authentication token (driverToken) for interface request authentication; a unique device identifier (deviceId) for differentiating access devices; and a platform-assigned driver-specific business number (driverFid) uniquely bound to the driver's business file and order data). This driver authentication information simulates the real driver's reporting request environment and verifies the success of navigation route reporting. If reporting fails, the subsequent process is terminated and the reason for failure is recorded.

[0024] In step S120, the motion state corresponding to each trajectory point in the route trajectory point string is determined, and simulation trajectory data is generated; Optionally, after extracting a continuous and complete string of route trajectory points through step-by-step traversal, the motion state corresponding to each trajectory point is calculated based on the Earth's equatorial radius and oblateness using a preset geographical model, such as the WGS84 ellipsoid model. This motion state may include location information, motion speed, heading angle, timestamp data, etc. Then, the location information, motion speed, heading angle, and timestamp data can be fused and encapsulated to generate simulated trajectory data that fits the real vehicle driving characteristics and has complete motion attributes. This can effectively trigger backend algorithms such as trajectory smoothing, route matching, and abnormal drift detection, achieving in-depth verification of the same display data processing link and ensuring the authenticity and effectiveness of subsequent same display link tests.

[0025] In step S130, the simulation trajectory data is reported in batches based on the linkage scheduling strategy of alternating reporting and querying, and a trajectory query is initiated after a single batch of reporting is completed to obtain the corresponding batch of query trajectory response data. Optionally, based on the linkage scheduling strategy of alternating reporting and querying, reporting and querying operations are alternately executed on the time axis. According to the preset time interval and reporting frequency, the generated simulation trajectory data is reported in batches through the ordered location reporting interface and the navigation route reporting interface to simulate the business behavior of real drivers continuously reporting location data. After each batch of simulation trajectory data is reported and synchronously transmitted to the backend service storage for effectiveness, the query end (such as passenger end / freighter end) is immediately automatically triggered by the callback mechanism to call the trajectory query interface, initiate the corresponding dimension data query request, and pull and obtain the matching query trajectory response data (driver location) of the batch in real time. This forms a closed-loop linkage process of batch reporting and real-time querying, providing complete comparison data for subsequent multi-dimensional data comparison and link timeliness verification.

[0026] In step S140, multi-dimensional link verification is performed on the reported simulation trajectory data and the query trajectory response data in batches.

[0027] Optionally, for each batch of reported simulation trajectory data and retrieved trajectory response data, a full-dimensional link verification is performed batch by batch. This involves sequentially verifying the reported simulation trajectory data and retrieved trajectory response data across multiple dimensions, including location consistency, timestamp consistency, navigation route consistency, data timeliness, and trajectory integrity. Simultaneously, the end-to-end transmission latency of a single batch of data from reporting to normal querying can be measured. Through joint judgment using multiple indicators and preset thresholds, various conditional verifications are completed. When all verification items meet the preset requirements, the current batch of simultaneously displayed data is deemed to have a normal data link flow, thereby achieving multi-dimensional closed-loop verification of the entire process of data transmission, storage parsing, and interface querying.

[0028] It should be noted that the data link verification method for simultaneous display provided in this application can be widely applied to various scenarios involving simultaneous display of driver and passenger information, as well as system iteration and compatibility testing scenarios. Through automated verification, it ensures the accuracy, timeliness, compatibility, and stability of the end-to-end data path across systems in the dual-authentication system. Specifically, it can cover a variety of scenarios, such as verifying the consistency between the driver's location, driving direction, and navigation route obtained by the passenger terminal and the data reported by the driver terminal in passenger simultaneous display scenarios; verifying the correctness and timeliness of the driver and cargo location data obtained by the cargo owner terminal in freight scenarios (including same-city freight, moving, and tail-box hauling with orderType=102); and verifying whether each associated terminal can communicate in multi-order concurrent scenarios (identified by multiple orderId and orderStatus fields in the orderInfo field). Accurately query driver location using its own order identifier; verify the correctness of the same display path at each stage of order pick-up / delivery (orderState=1) and drop-off / delivery (orderState=2); verify the forward and backward compatibility of the encoding and decoding link when the encoding and decoding strategy (GZIP compression, Base64 encoding, URL encoding) of the location service backend changes; verify whether the same display path is affected when the system core modules (location service backend, trajectory storage engine, query interface) are iterated; at the same time, the same display verification of multiple cities and multiple business lines can be performed in batches through parameterized configuration (cityId, serviceId, coordType, etc.); each scenario can be executed individually or in combination, comprehensively covering various applications and abnormal scenarios, and providing a guarantee for the stable operation of the data path.

[0029] In this embodiment of the application, a method for verifying simultaneous data links is provided, comprising: acquiring target navigation route data and extracting route trajectory point strings from the target navigation route data; determining the motion state corresponding to each trajectory point in the route trajectory point string and generating simulated trajectory data; reporting the simulated trajectory data in batches based on a linkage scheduling strategy that alternates between reporting and querying, and initiating a trajectory query after a single batch of reporting is completed to obtain the query trajectory response data of the corresponding batch; and performing multi-dimensional link verification on the reported simulated trajectory data and the query trajectory response data batch by batch. In this embodiment, the problems of low automation, inaccurate timeliness measurement, lack of realism in trajectory simulation, and limited verification coverage in existing simultaneous display function verification are effectively solved. Trajectory simulation, batch reporting, real-time querying, and multi-dimensional verification are completed through a programmatic process, realizing quantitative output of verification results, improving verification efficiency and meeting the needs of large-scale routine verification. Through a scheduling strategy of alternating reporting and querying, the end-to-end latency is accurately quantified, filling the gap in timeliness measurement. By generating a simulated trajectory containing complete kinematic features, the backend core algorithm is effectively triggered, improving the verification depth and reliability. At the same time, the multi-layer encoding and decoding link is fully reproduced, covering navigation route verification and both customer and freight scenarios, realizing full-link verification of simultaneous display business and ensuring the stability and reliability of the entire link of passenger and freight simultaneous display function.

[0030] In one embodiment of this application, determining the motion state corresponding to each trajectory point in the route trajectory point string and generating simulation trajectory data includes: Based on a pre-defined geographic model, calculate the ground distance between adjacent trajectory points; Based on the ground distance, the speed and heading information of each trajectory point are calculated, and corresponding time information is configured for each trajectory point. The ground distance, speed, heading, and time information are fused to generate simulated trajectory data with multi-dimensional motion states.

[0031] Optionally, based on a preset geographic model, such as the WGS84 ellipsoid model, the radius of curvature of the meridian and the radius of curvature of the ramusoidal circle can be calculated using the Earth's equatorial radius and flattening. This allows for the estimation of ground distances, instantaneous speeds, and heading angles between adjacent trajectory points. Then, the ground distances, speeds, heading information, and time information are fused to generate simulated trajectory data with multi-dimensional motion states. The final simulated trajectory data can specifically include a complete list of location reporting data, consisting of fields such as longitude (lon), latitude (lat), speed (speed), heading angle (direction), positioning time (loc_time), device time (g_time), coordinate type (coord_type), event type (eventType), order information (orderInfo), order status (orderState), order type (orderType), and path identifier (path_id).

[0032] Specifically, the instantaneous velocity can be calculated based on the ground data d and the pre-configured sampling time interval (trackIntervalSec, such as 3 seconds), and can be expressed by the following formula: speed = d / nterval; For heading angle, the latitude and longitude of the starting point, the latitude and longitude of the ending point, the Earth's equatorial radius, and the flattening can be combined. By correcting for the influence of the Earth's curvature through the difference in latitude and longitude, the northward and eastward distances of adjacent trajectory points in the plane coordinate system can be accurately calculated. The heading value in radians can be obtained through the arctangent function and converted into an angle value within the range of 0° to 360° to represent the travel direction of the trajectory point. For the last point in the route trajectory point string, since there are no subsequent points to participate in the calculation, its heading angle with the previous trajectory point is directly used as the heading angle of that point, ensuring that the direction data of the entire simulation trajectory is continuous and complete.

[0033] The heading angle can be specifically expressed by the following formula: direction=atan2(de,dn); Where de represents the eastward distance and dn represents the northward distance.

[0034] For timestamps, the temporal information of the simulated trajectory can be distributed at equal intervals. The overall driving time span is determined based on the preset trajectory start timestamp startTs and end timestamp endTs. This time span is then evenly divided according to the total number of trajectory points to obtain the standard time interval between adjacent trajectory points. Based on this time interval, starting from the start timestamp startTs, a corresponding timestamp is sequentially assigned to each trajectory point, so that all trajectory points form a continuous and orderly time sequence according to the uniform speed driving logic. This simulates the uniform time interval characteristics of position reporting during real driving, ensuring the temporal authenticity and rationality of the simulated trajectory data.

[0035] In one embodiment of this application, calculating the ground distance between adjacent trajectory points based on a preset geographic model includes: Calculate the radius of curvature of the meridian and the radius of curvature of the zonal and tropospheric spheres based on the Earth's equatorial radius and oblateness; Based on the curvature radius of the meridian and the curvature radius of the zonal circle, calculate the eastward and northward distances; The ground distance is calculated based on the eastward distance and the northward data.

[0036] Optionally, by combining the latitude and longitude coordinates of adjacent trajectory points and introducing the parameters of the Earth's meridian radius and circumpolar radius, the spherical offset between points is corrected and calculated to accurately calculate the actual ground distance between adjacent trajectory points, avoiding errors caused by planar coordinate conversion and ensuring that the road segment distance calculation results conform to the real road driving scenario.

[0037] For example, suppose the starting point's latitude and longitude are (slon, slat), the ending point's latitude and longitude are (ulon, ulat), the Earth's equatorial radius Re = 6378137.0 m, and the flattening f = 0.00335281317789691, then: The radius of curvature of the meridian circle Rm = Re × (1 - 2f + 3f × sin²(slat)); The radius of curvature of the zonal loop Rn = Re × (1 + f × sin²(slat)); Eastward distance de = (ulon - slon) × Rn / (180 / π) × cos(slat); The northward distance dn = (ulat - slat) × Rm / (180 / π); The ground distance d = √(de² + dn²).

[0038] In one embodiment of this application, the simulation trajectory data is reported in batches based on a coordinated scheduling strategy that alternates between reporting and querying, and trajectory querying is performed after each batch of reporting is completed, including: The simulated trajectory data is divided into multiple batches of simulated trajectory sub-data according to a preset batching rule; After compressing and encoding each batch of simulated trajectory sub-data, it is reported in batches according to the preset reporting time interval. Once a batch of simulation trajectory sub-data has been reported, the trajectory query operation is triggered.

[0039] Optionally, the simulated trajectory data is processed in batches according to a pre-configured batch size (reportBatchSize, such as 2 trajectory points per batch, used to control the data granularity of each verification) to obtain multiple batches of simulated trajectory sub-data. Then, a reporting operation is performed on each batch of simulated trajectory sub-data. Specifically, for the simulated trajectory data to be reported in the current batch, it is first serialized into a standard JSON array format, then compressed using the GZIP compression algorithm, converted from binary compressed data to text format using Base64 encoding, and URL encoded to complete the secure formatting process for transmission. Finally, the encoded data is reported to the preset reporting interface via an HTTP POST request according to a pre-configured reporting interval (reportIntervalMs, such as 3000ms, used to control the reporting frequency to simulate the real rhythm) to simulate the real reporting rhythm. The request includes the parameter `_m=realtime` to identify it as a real-time location report, fully simulating the driver's actual data reporting encoding and transmission process. This ensures the reported message format is completely consistent with real business scenarios. After each batch of data is reported, a query operation is triggered on the passenger / freighter's end. After the reporting interval is reached, the next batch of simulated trajectory sub-data is reported again, and this cycle continues until all data is reported. Simultaneously, the reporting results of each batch and complete information of each trajectory point can be recorded for subsequent multi-dimensional verification operations. Through a coordinated scheduling strategy that alternates between reporting and querying, queries are initiated immediately after each batch of trajectory data is reported. This allows for precise quantification of data transmission latency, storage write latency, and query visibility latency, achieving accurate measurement of the timeliness of the data path.

[0040] In one embodiment of this application, triggering the execution trajectory query operation includes: Extract the location timestamp corresponding to the last reported data from the simulation trajectory sub-data reported in the current batch; Based on the location timestamp, determine the query start time and query end time; Based on the query start time and query end time, a trajectory query is performed.

[0041] Optionally, after completing the full-process encoding, compression, and interface reporting of the current batch of simulation trajectory data, the location timestamp `lastReportedTsSec` corresponding to the last reported data in the current batch of reported simulation trajectory sub-data is extracted. Then, the query end time (`endTimeSec`) and query start time (`startTimeSec`) are calculated respectively. The trajectory query operation can then be performed by initiating an HTTP POST request from the passenger / freighter client to call the trajectory query interface. This request message can carry core business parameters such as passenger / freighter client authentication information (`queryToken`), order identifier (`orderId`), driver identifier (`driverId`), time range [`startTimeSec`, `endTimeSec`]], and destination coordinates (`nextPoint`). The authentication and retrieval conditions for the query request are encapsulated. After the interface response, the returned standard JSON format response message is parsed and processed to extract valid trajectory points, driving status, timestamps, and other target data, forming query trajectory response data that can be used for verification and comparison.

[0042] The query end time can be calculated using the following formula: endTimeSec=lastReportedTsSec+1; The start time can be calculated using the following formula: startTimeSec=max(global reporting start time, endTimeSec) -QUERY_TIME_WINDOW_MAX_SEC); Among them, QUERY_TIME_WINDOW_MAX_SEC represents the maximum query time window duration, which is used to limit the maximum time range that the trajectory query interface can retrieve. It represents the maximum time span of trajectory data that can be retrieved in a single query, ensuring that the query time window covers the time range of the reported trajectory points without excessive backtracking.

[0043] In one embodiment of this application, the step of acquiring target navigation route data and extracting route trajectory point strings from the target navigation route data includes: According to the nested hierarchical structure of the target navigation route data, extract the coordinate point string level by level; The coordinate point string is concatenated sequentially to obtain the route trajectory point string.

[0044] Optionally, the target navigation route data can be the raw structured JSON data received by the navigation route reporting interface. This data can employ a multi-level nested structured design, including a four-level hierarchy of paths, steps, naviLink, and coords. Here, paths is the top-level set of paths for the overall navigation route, steps are the segmented driving sections after route splitting, naviLink is the road link unit within a single road segment, and coords are the discrete latitude and longitude coordinates within the road link unit. Then, according to certain extraction rules, such as from the outside in (paths→steps→naviLink→coords), this four-level structure can be parsed level by level, and the coordinate strings extracted from each level can be concatenated with semicolons in a certain order (such as the actual driving direction of the navigation) to form a complete route trajectory point string.

[0045] In one embodiment of this application, the step of performing multi-dimensional link verification on the reported simulation trajectory data and the queried trajectory response data in batches includes: Determine whether the position offset between the simulated trajectory sub-data reported in each batch and the corresponding query trajectory response data is less than the preset position offset threshold; Determine whether the time offset between the simulated trajectory sub-data reported in each batch and the corresponding query trajectory response data is within the preset time range; Determine whether the trajectory coverage between the simulated trajectory sub-data reported in each batch and the corresponding query trajectory response data is greater than the preset trajectory coverage threshold; Determine whether the time difference between the completion time of each batch's report and the successful return time of the query is less than the preset time limit; Determine whether the target navigation route data is consistent with the route data corresponding to each batch of query trajectory response data; If all of the above conditions are met, the verification passes.

[0046] Optionally, the simulated trajectory sub-data reported in each batch is checked against the trajectory response data queried in that batch from multiple dimensions, including location consistency, timestamp consistency, navigation route consistency, trajectory integrity, and data timeliness. When all verification items meet the preset requirements, the current batch of simultaneous display data link is determined to be in normal operation, thereby achieving multi-dimensional closed-loop verification of the entire process of data transmission, storage parsing, and interface query. By improving the verification coverage of the simultaneous display data link and fully reproducing the multi-layer encoding and decoding link before location data transmission, hidden transmission layer problems such as abnormal compression rate and incompatible encoding formats can be detected in a timely manner. At the same time, it covers the verification of the navigation route reporting interface and takes into account the differentiated needs of customer and freight scenarios, realizing full-link verification of the simultaneous display business from data collection, transmission, storage to query and display, ensuring the stability and reliability of the entire link of passenger and freight simultaneous display function.

[0047] Specifically, the location consistency verification process involves: matching each reported simulation trajectory point and the query response trajectory point within the current batch, and calculating the positional offset between the two sets of corresponding latitude and longitude coordinates; for each set of matched trajectory points, using the WGS84 Earth ellipsoid model distance calculation formula, calculating the actual ground offset distance Δd between the two points. A fixed distance judgment threshold is pre-configured, for example, 50 meters. When the calculated ground offset distance Δd exceeds this threshold range, the positional deviation of the point is deemed excessive, and the set of trajectory points is marked as having an abnormal position.

[0048] The timestamp consistency verification process is as follows: The timestamps of reported simulation trajectory points within the current batch are matched one by one with the timestamps of query response trajectory points. The time difference Δt is calculated, which objectively represents the offset of the entire transmission and processing time from driver reporting, backend reception and storage, data processing, to retrieval and display by the query end. Finally, Δt is compared with a preset legal delay threshold. If the time difference is within the threshold range, the timing verification is considered successful; if it exceeds the threshold, the timestamp is considered abnormal, thus achieving automated verification of trajectory data timing consistency.

[0049] The verification process for navigation route consistency is as follows: The original navigation route data loaded for simulation reporting is compared one by one with the core content of the path structure information returned by the trajectory query interface, including route hierarchy, road link information, coordinate point sequence, and road segment topology. This verifies the integrity and consistency of key route elements throughout the entire process of data reporting, backend reception and parsing, storage and forwarding, and query feedback. Through global route content comparison and verification, it is confirmed that the complete route data has not been lost, tampered with, corrupted, or missing in the overall data transmission path, thus completing the verification of the correctness of navigation route transmission.

[0050] The trajectory integrity verification process is as follows: The total number of simulated reported trajectory points within a batch is counted, along with the total number of trajectory points actually returned by the trajectory query interface. The ratio of these two numbers is calculated to obtain the trajectory coverage rate, which can be expressed as: Trajectory Coverage Rate = (Number of Query Returned Points / Total Number of Reported Points) × 100%. If the trajectory coverage rate is lower than a preset trajectory coverage threshold, such as 95%, it is marked as a point loss anomaly. By comparing this trajectory coverage rate with the preset trajectory coverage threshold, issues such as point loss, data interception, and parsing anomalies during data transmission can be effectively identified, thus completing the integrity verification of trajectory data across the entire link.

[0051] The data timeliness verification process is as follows: Record the end time of all reporting operations for a single batch of simulated trajectory data, and the completion time of calling the trajectory query interface and successfully obtaining the response result. Calculate the time difference between the two times. If the time difference is less than the preset time threshold, it indicates that the overall flow of trajectory data reporting, server-side processing and storage, and interface query feedback is fast, and the data real-time performance meets business requirements, thus determining that the timeliness is qualified. If the time difference exceeds the preset time threshold, it indicates that the link processing is congested, data synchronization is lagging, and there is a significant delay in data display, thus determining that the data timeliness is abnormal, thereby achieving quantitative verification of the timeliness of the trajectory display link.

[0052] In this embodiment, the problems of low automation, inaccurate timeliness measurement, lack of realism in trajectory simulation, and limited verification coverage in existing simultaneous display function verification are effectively solved. Trajectory simulation, batch reporting, real-time querying, and multi-dimensional verification are completed through a programmatic process, realizing quantitative output of verification results, improving verification efficiency and meeting the needs of large-scale routine verification. Through a scheduling strategy of alternating reporting and querying, the end-to-end latency is accurately quantified, filling the gap in timeliness measurement. By generating a simulated trajectory containing complete kinematic features, the backend core algorithm is effectively triggered, improving the verification depth and reliability. At the same time, the multi-layer encoding and decoding link is fully reproduced, covering navigation route verification and both customer and freight scenarios, realizing full-link verification of simultaneous display business and ensuring the stability and reliability of the entire link of passenger and freight simultaneous display function.

[0053] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0054] In one embodiment, a simultaneous display data link verification system is provided, which corresponds one-to-one with the simultaneous display data link verification methods described in the above embodiments. For example... Figure 2 As shown, the simultaneous display data link verification system includes a route trajectory point string extraction unit 10, a simulation trajectory data generation unit 20, a reporting-query alternating execution unit 30, and a multi-dimensional verification unit 40. Detailed descriptions of each functional module are as follows: The route trajectory point string extraction unit 10 is used to acquire target navigation route data and extract route trajectory point strings from the target navigation route data. The simulation trajectory data generation unit 20 is used to determine the motion state corresponding to each trajectory point in the route trajectory point string and generate simulation trajectory data. The reporting-query alternating execution unit 30 is used to report the simulation trajectory data in batches based on the linkage scheduling strategy of alternating reporting and querying, and to initiate trajectory query after a single batch of reporting is completed to obtain the corresponding batch of query trajectory response data. The multidimensional verification unit 40 is used to perform multidimensional link verification on the reported simulation trajectory data and the query trajectory response data in batches.

[0055] In one embodiment of this application, the simulation trajectory data generation unit 20 is further configured to: Based on a pre-defined geographic model, calculate the ground distance between adjacent trajectory points; Based on a pre-defined geographic model, calculate the ground distance between adjacent trajectory points; Based on the ground distance, the speed and heading information of each trajectory point are calculated, and corresponding time information is configured for each trajectory point. The ground distance, speed, heading, and time information are fused to generate simulated trajectory data with multi-dimensional motion states.

[0056] In one embodiment of this application, the simulation trajectory data generation unit 20 is further configured to: Calculate the radius of curvature of the meridian and the radius of curvature of the zonal and tropospheric spheres based on the Earth's equatorial radius and oblateness; Based on the curvature radius of the meridian and the curvature radius of the zonal circle, calculate the eastward and northward distances; The ground distance is calculated based on the eastward distance and the northward data.

[0057] In one embodiment of this application, the reporting-querying alternating execution unit 30 is further configured to: The simulated trajectory data is divided into multiple batches of simulated trajectory sub-data according to a preset batching rule; After compressing and encoding each batch of simulated trajectory sub-data, it is reported in batches according to the preset reporting time interval. Once a batch of simulation trajectory sub-data has been reported, the trajectory query operation is triggered.

[0058] In one embodiment of this application, the reporting-querying alternating execution unit 30 is further configured to: Extract the location timestamp corresponding to the last reported data from the simulation trajectory sub-data reported in the current batch; Based on the location timestamp, determine the query start time and query end time; Based on the query start time and query end time, a trajectory query is performed.

[0059] In one embodiment of this application, the route trajectory point string extraction unit 10 is further configured to: According to the nested hierarchical structure of the target navigation route data, extract the coordinate point string level by level; The coordinate point string is concatenated sequentially to obtain the route trajectory point string.

[0060] In one embodiment of this application, the multidimensional verification unit 40 is further configured to: Determine whether the position offset between the simulated trajectory sub-data reported in each batch and the corresponding query trajectory response data is less than the preset position offset threshold; Determine whether the time offset between the simulated trajectory sub-data reported in each batch and the corresponding query trajectory response data is within the preset time range; Determine whether the trajectory coverage between the simulated trajectory sub-data reported in each batch and the corresponding query trajectory response data is greater than the preset trajectory coverage threshold; Determine whether the time difference between the completion time of each batch's report and the successful return time of the query is less than the preset time limit; Determine whether the target navigation route data is consistent with the route data corresponding to each batch of query trajectory response data; If all of the above conditions are met, the verification passes.

[0061] Specific limitations regarding the simultaneous display data link verification system can be found in the limitations of the simultaneous display data link verification method described above, and will not be repeated here. Each module in the aforementioned simultaneous display data link verification system can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0062] In one embodiment, a computer device is provided, which may be a terminal device, and its internal structure diagram may be as follows: Figure 3 As shown, the computer device includes a processor, memory, and network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a readable storage medium storing computer-readable instructions. The network interface communicates with external terminals via a network connection. When executed by the processor, the computer-readable instructions implement a simultaneous data link verification method. The readable storage medium provided in this embodiment includes both non-volatile and volatile readable storage media.

[0063] In this application embodiment, a computer device is provided, including a memory, a processor, and computer-readable instructions stored in the memory and executable on the processor. When the processor executes the computer-readable instructions, it implements the steps of the above-described simultaneous data link verification method.

[0064] In this embodiment of the application, a readable storage medium is provided, which stores computer-readable instructions. When the computer-readable instructions are executed by a processor, they implement the steps of the above-described simultaneous data link verification method.

[0065] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware with computer-readable instructions. These computer-readable instructions can be stored in a non-volatile readable storage medium or a volatile readable storage medium. When executed, these computer-readable instructions can include the processes of the embodiments of the methods described above. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0066] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

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

Claims

1. A method for verifying simultaneous data links, characterized in that, The method includes: Acquire target navigation route data, and extract route trajectory point strings from the target navigation route data; Determine the motion state corresponding to each trajectory point in the route trajectory point string, and generate simulation trajectory data; The simulation trajectory data is reported in batches based on a linkage scheduling strategy that alternates between reporting and querying. After a single batch of reporting is completed, a trajectory query is initiated to obtain the corresponding batch of query trajectory response data. Multi-dimensional link verification is performed on the reported simulation trajectory data and the query trajectory response data in batches.

2. The simultaneous display data link verification method as described in claim 1, characterized in that, The step of determining the motion state corresponding to each trajectory point in the route trajectory point string and generating simulation trajectory data includes: Based on a pre-defined geographic model, calculate the ground distance between adjacent trajectory points; Based on the ground distance, the speed and heading information of each trajectory point are calculated, and corresponding time information is configured for each trajectory point. The ground distance, speed, heading, and time information are fused to generate simulated trajectory data with multi-dimensional motion states.

3. The simultaneous display data link verification method as described in claim 2, characterized in that, The calculation of ground distances between adjacent trajectory points based on a preset geographic model includes: Calculate the radius of curvature of the meridian and the radius of curvature of the zonal and tropospheric spheres based on the Earth's equatorial radius and oblateness; Based on the curvature radius of the meridian and the curvature radius of the zonal circle, calculate the eastward and northward distances; The ground distance is calculated based on the eastward distance and the northward data.

4. The simultaneous display data link verification method as described in claim 1, characterized in that, The coordinated scheduling strategy based on alternating reporting and querying reports the simulation trajectory data in batches, and performs trajectory querying after each batch of reporting is completed, including: The simulated trajectory data is divided into multiple batches of simulated trajectory sub-data according to a preset batching rule; After compressing and encoding each batch of simulated trajectory sub-data, it is reported in batches according to the preset reporting time interval. Once a batch of simulation trajectory sub-data has been reported, the trajectory query operation is triggered.

5. The simultaneous display data link verification method as described in claim 4, characterized in that, The triggering of the trajectory query operation includes: Extract the location timestamp corresponding to the last reported data from the simulation trajectory sub-data reported in the current batch; Based on the location timestamp, determine the query start time and query end time; Based on the query start time and query end time, a trajectory query is performed.

6. The simultaneous display data link verification method as described in claim 1, characterized in that, The step of acquiring target navigation route data and extracting route trajectory point strings from the target navigation route data includes: According to the nested hierarchical structure of the target navigation route data, extract the coordinate point string level by level; The coordinate point string is concatenated sequentially to obtain the route trajectory point string.

7. The simultaneous display data link verification method as described in any one of claims 1 to 6, characterized in that, The step of performing multi-dimensional link verification on the reported simulation trajectory data and the queried trajectory response data in batches includes: Determine whether the position offset between the simulated trajectory sub-data reported in each batch and the corresponding query trajectory response data is less than the preset position offset threshold; Determine whether the time offset between the simulated trajectory sub-data reported in each batch and the corresponding query trajectory response data is within the preset time range; Determine whether the trajectory coverage between the simulated trajectory sub-data reported in each batch and the corresponding query trajectory response data is greater than the preset trajectory coverage threshold; Determine whether the time difference between the completion time of each batch's report and the successful return time of the query is less than the preset time limit; Determine whether the target navigation route data is consistent with the route data corresponding to each batch of query trajectory response data; If all of the above conditions are met, the verification passes.

8. A simultaneous display data link verification system, characterized in that, The system includes: The route trajectory point string extraction unit is used to acquire target navigation route data and extract route trajectory point strings from the target navigation route data; The simulation trajectory data generation unit is used to determine the motion state of each trajectory point in the route trajectory point string and generate simulation trajectory data. The reporting-query alternating execution unit is used to report the simulation trajectory data in batches based on the linkage scheduling strategy of alternating reporting and querying, and to initiate trajectory query after a single batch of reporting is completed to obtain the corresponding batch of query trajectory response data. The multi-dimensional verification unit is used to perform multi-dimensional link verification on the reported simulation trajectory data and the query trajectory response data in batches.

9. A computer device comprising a memory, a processor, and computer-readable instructions stored in the memory and running on the processor, characterized in that, When the processor executes the computer-readable instructions, it implements the simultaneous data link verification method as described in any one of claims 1 to 7.

10. A readable storage medium having computer-readable instructions stored thereon, characterized in that, When the computer-readable instructions are executed by the processor, they implement the simultaneous data link verification method as described in any one of claims 1 to 7.

Images