Device trajectory backtracking method and device, computer device and storage medium

Abstract

The application relates to a device trajectory backtracking method and device, a computer device and a storage medium, which are applied to the back end of a device management platform, the device management platform comprises a front end, a back end and a time sequence database, the back end comprises a producer and a consumer, the method comprises the following steps: in response to a target query request of the front end, determining a to-be-queried device and a to-be-queried time period according to the target query request; determining a time window size through the producer, and sequentially querying coordinate data of the to-be-queried device in the to-be-queried time period from the time sequence database according to the time window size; when one coordinate data is queried and the consumer meets a first preset condition, the coordinate data is pushed to the consumer; and the coordinate data is pushed to the front end through the consumer, and a trajectory picture of the to-be-queried device is rendered and displayed according to the coordinate data by the front end. According to the application, the occupied memory of the backtracking function can be reduced.

Description

Technical Field

[0001] This application relates to the field of data query technology, and in particular to a method, apparatus, computer device, and storage medium for tracing device trajectories. Background Technology

[0002] In automated storage and retrieval systems (AS / RS), the inbound and outbound operations of goods are completed fully automatically by four-way vehicles, elevators, conveyor lines, and other loading equipment, without human intervention. To facilitate the observation of the equipment's operating status over specific time periods, a backtracking function for the equipment's operating trajectory needs to be implemented on the management platform to support operational monitoring and problem analysis.

[0003] Currently, the implementation of device trajectory backtracking function is generally as follows: after receiving the user's trajectory backtracking request, the system queries all coordinate data of the device within a specified time range at once, and the front end renders the device trajectory in sequence based on the received coordinate data, thereby achieving the trajectory backtracking effect. However, querying all coordinate data at once and loading all of this data into memory will consume system memory resources rapidly, and may even exhaust available memory instantly, which will lead to a decrease in the server's ability to process other business requests, seriously affecting the stability of the entire system.

[0004] Therefore, how to reduce the memory usage of the backtracking function has become an urgent problem to be solved. Summary of the Invention

[0005] Therefore, it is necessary to provide a device trajectory tracing method, apparatus, computer equipment, and storage medium to address the above-mentioned technical problems, which can reduce the memory usage of the tracing function.

[0006] Firstly, this application provides a method for equipment trajectory backtracking, applied to the backend of an equipment management platform. The equipment management platform includes a frontend, a backend, and a time-series database. The backend includes producers and consumers. The method includes:

[0007] In response to the target query request from the front end, determine the device and time period to be queried based on the target query request;

[0008] The producer determines the size of the time window, and queries the coordinate data of the device to be queried in the time period from the time series database according to the size of the time window. Each time a coordinate data is queried, and the consumer meets the first preset condition, the coordinate data is pushed to the consumer.

[0009] Consumers push coordinate data to the front end, which then renders and displays the trajectory of the device being queried based on the coordinate data.

[0010] Secondly, this application provides a device for tracing equipment trajectory, applied to the backend of an equipment management platform. The equipment management platform includes a frontend, a backend, and a time-series database. The backend includes producers and consumers. The device includes:

[0011] The response module is used to respond to the target query request from the front end and determine the device and time period to be queried based on the target query request;

[0012] The push module is used to determine the size of the time window by the producer, and query the coordinate data of the device to be queried in the time period according to the size of the time window. Each time a coordinate data is queried, and the consumer meets the first preset condition, the coordinate data is pushed to the consumer.

[0013] The backtracking module is used to push coordinate data to the front end through consumers, and the front end renders and displays the trajectory of the device to be queried based on the coordinate data.

[0014] Thirdly, this application provides a computer device, which includes a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps in the method described above.

[0015] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps in the above-described method.

[0016] Fifthly, this application provides a computer program product comprising a computer program that, when executed by a processor, implements the steps of the method described above.

[0017] As can be seen, the above-mentioned equipment trajectory backtracking method, by splitting the time period to be queried by the producer according to the size of the time window, and querying the coordinate data within a single window each time, reduces the amount of memory loaded at one time to 1 / N of the original (N is the number of windows obtained by splitting the time period to be queried) compared to the existing technology of querying all data in the time period at once. This avoids the memory peak impact caused by loading the full amount at once, thereby reducing the memory occupied by the backtracking function and improving the efficiency of equipment trajectory backtracking. Attached Figure Description

[0018] Figure 1 A flowchart illustrating a conventional device trajectory tracing method provided in this application embodiment;

[0019] Figure 2 This application provides an illustration of the application environment for a device trajectory backtracking method.

[0020] Figure 3A structural block diagram of a device management platform provided in an embodiment of this application;

[0021] Figure 4 A flowchart illustrating a device trajectory backtracking method provided in this application embodiment;

[0022] Figure 5 A flowchart illustrating the workflow of a device management platform provided in this application embodiment;

[0023] Figure 6 A structural block diagram of a device trajectory tracing device provided in an embodiment of this application;

[0024] Figure 7 An internal structural diagram of a computer device provided in an embodiment of this application;

[0025] Figure 8 An internal structural diagram of another computer device provided in an embodiment of this application;

[0026] Figure 9 This is an internal structural diagram of a computer-readable storage medium provided in an embodiment of this application. Detailed Implementation

[0027] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0028] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0029] In practical applications, please refer to Figure 1 , Figure 1 This application provides a flowchart of a conventional device trajectory backtracking method. The conventional device management platform includes a front-end, a back-end, and a database. The conventional device trajectory backtracking method includes the following steps:

[0030] 1. Select track recording and start playback.

[0031] Users select a device trajectory record on the front-end interface (such as the device management platform page), for example, the running trajectory of device A from 09:00 to 10:00 on 2024-05-20, and click the "Start Playback" button to start the playback function.

[0032] 2. WebSocket connection request

[0033] The front end (e.g., a browser or client) sends a WebSocket connection establishment request to the back end (server-side program). WebSocket is a "two-way real-time communication protocol." Unlike the traditional HTTP "request-response" model, it allows the back end to actively and continuously push data to the front end, providing the communication foundation for subsequent "real-time trajectory animation" (if the HTTP protocol is used, the front end needs to make repeated requests, which cannot achieve smooth animation).

[0034] 3. Parse the start and end times (T_start, T_end)

[0035] After receiving the WebSocket connection request, the backend parses the start time (T_start) and end time (T_end) of the trajectory from the request. For example, from the trajectory record selected by the user, T_start is extracted as 2024-05-20 09:00:00 and T_end is 2024-05-20 10:00:00. In this way, the time range boundary of subsequent database queries can be determined, and it can be determined which time period coordinate data needs to be obtained.

[0036] 4. Full coordinate data query

[0037] The backend sends a query request to the database based on the parsed start and end times, requesting all device-related coordinate data (such as latitude and longitude, timestamps, etc.) within that time period.

[0038] 5. Return all coordinate data [point 1, point 2, ..., point N]

[0039] After executing the query operation in the database, all coordinate data that meet the conditions are returned to the backend in the form of a "data list". For example, 1,000 coordinate point data of device A between 09:00 and 10:00 are returned.

[0040] 6. Load all data into memory (high memory usage)

[0041] The backend loads all the coordinate data returned by the database into the server's memory at once for temporary storage.

[0042] 7. Start the second-level timer

[0043] The backend starts a timer that triggers once per second. This timer controls the timing of the trajectory playback, ensuring that the frontend receives data once per second, simulating the effect of the device moving one position per second, and achieving a smooth trajectory animation. Figure 1In this context, LOOP stands for "loop" step, which means repeatedly executing a certain piece of code or process. Figure 1 Steps 8-12 within the dashed box will continue until specific termination conditions are met (e.g., platform failure, user exit, device trajectory playback completion, etc.).

[0044] 8. Timer Trigger

[0045] The timer can be triggered every second, meaning the timer triggers the preset callback function (i.e., starts executing the subsequent data matching and push logic) at a frequency of "once per second".

[0046] 9. Traverse the entire dataset and match the coordinates at the current time.

[0047] Each time the timer is triggered, the backend filters out the coordinate points whose timestamps match the current system time (or playback progress time) from the full coordinate data in memory. For example, assuming the current time is the 5th second after playback started and the system time is 09:00:05, then the coordinate points with the timestamp of 09:00:05 are filtered out. In this way, the device coordinate points that should be displayed at the current time can be determined, providing accurate coordinate data for frontend rendering.

[0048] 10. WebSocket pushes current time coordinate data

[0049] The backend will actively push the selected current coordinate data to the frontend through the established WebSocket connection to achieve real-time data transmission from the backend to the frontend, allowing the frontend to obtain the coordinates that need to be rendered in a timely manner.

[0050] 11. Rendering device location

[0051] After receiving the coordinate data pushed by WebSocket, the front end uses front-end technologies (such as Canvas, SVG, map API) to draw or update the device's position on the interface. For example, it can move icons on the map or mark the current point on the trajectory line, transforming "data" into "visualized images" and enabling users to directly perceive the core of the trajectory animation.

[0052] 12. Display trajectory animation

[0053] As the front end continuously receives and renders the coordinate data pushed every second, the device position changes continuously on the front end's display interface, forming a "trajectory animation" effect; finally, a smooth device trajectory tracing process is presented to the user, completing the "visual output" of the entire function.

[0054] In summary, the performance bottlenecks of existing device trajectory backtracking methods include: full query blocking, high memory consumption, and long-term traversal matching. It's important to clarify that full query blocking refers to querying all data within a specific timeframe at once (rather than querying in batches), causing the database or network processing to be occupied for an extended period, preventing responses to other requests. High memory consumption refers to the device management platform using excessive memory, exceeding reasonable thresholds, when processing data. Long-term traversal matching refers to the excessive time required to iterate through and match target data (such as matching progress time with coordinate timestamps) within a large dataset, exceeding acceptable response times.

[0055] Therefore, this application provides a device trajectory backtracking method, which reduces the memory usage of the backtracking function and improves the efficiency of device trajectory backtracking.

[0056] Please see Figure 2 , Figure 2 This diagram illustrates the application environment of a device trajectory tracing method provided in this embodiment. Terminal 102 communicates with server 104 via a communication network. A data storage system stores the data that server 104 needs to process. The data storage system can be integrated onto server 104 or located on a cloud or other network server. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can include smart speakers, smart TVs, smart air conditioners, smart vehicle devices, etc. Portable wearable devices can include smartwatches, smart bracelets, head-mounted devices, etc. Server 104 can be implemented using a standalone server or a server cluster consisting of multiple servers.

[0057] It should be noted that terminal 102 or server 104 can execute any of the implementation methods described in the device trajectory backtracking method provided in the embodiments of this application, and will not be repeated here. The computer device described in the embodiments of this application may include at least one of terminal 102 or server 104.

[0058] Please see Figure 3 , Figure 3 This application provides a structural block diagram of a device management platform; as shown, the device management platform includes: a front-end, a back-end, and a time-series database. The back-end includes producers and consumers, wherein:

[0059] The front end is responsible for interacting with the user, receiving user operation commands (such as device trajectory tracing requests), and visualizing the data transmitted from the back end, so that the user can intuitively see device-related information (such as device trajectory animations). In practical applications, the front end can be a terminal device with display and interactive functions, such as a personal computer (accessing the web interface of the device management platform through a browser), tablet computer, or smartphone.

[0060] The backend, as the core processing part of the entire platform, plays a crucial role in connecting the frontend and the backend. On one hand, it receives user requests from the frontend and performs corresponding business logic processing; on the other hand, it interacts with the database to obtain or store data. In practical applications, the backend can be a software program deployed on a server (e.g., a physical server or a cloud server).

[0061] Producers are responsible for retrieving data from time-series databases according to certain rules (such as time windows) in scenarios such as equipment trajectory tracing, preparing the data and delivering it to consumers.

[0062] Consumers are used to receive data from producers, process the data further (such as filtering data based on time matching or other logic), and then transmit the appropriate data to the front end in a way that the front end can recognize. It should be noted that producers and consumers are functional modules within the backend program, not independent physical devices, but software program modules running on the backend server.

[0063] Time-series databases are used to store timestamped data generated during equipment transportation (e.g., coordinate data of equipment at different times). Their characteristics are suitable for efficiently querying and managing data by time dimension, providing data support for functions such as equipment trajectory backtracking. In practical applications, time-series databases can be database systems deployed on servers, such as servers using time-series database software such as InfluxDB and TimescaleDB. These servers can be physical servers maintained by the enterprise itself or cloud database services.

[0064] Please see Figure 4 , Figure 4 A flowchart of a device trajectory backtracking method provided in this application embodiment is shown. This method is applied to the backend of a device management platform, which includes a frontend, a backend, and a time-series database. The backend includes producers and consumers. The method includes the following steps:

[0065] S101. In response to the target query request from the front end, determine the device to be queried and the time period to be queried based on the target query request.

[0066] The backend can be Figure 2 Terminal 102 or server 104 in the middle.

[0067] Specifically, the front-end can provide users with a data query page. Users can set the query period, query conditions, and other details on this page. After completing the settings, users can click the "Query" option to generate a target query request (usually data in JSON format). Then, the back-end can pre-start a WebSocket service (or HTTP service) to continuously listen for network connection requests initiated by the front-end. When a user triggers the "Device Tracking Query" operation on the data query page (e.g., by clicking the "Query" option), the front-end will send a connection request to the back-end according to a preset protocol (such as the WebSocket handshake protocol). The back-end receives and establishes a connection. After the connection is established, the front-end sends the target query request to the back-end through the established connection. Of course, the front-end can also proactively send the target query request to the back-end.

[0068] After receiving the target query request, the backend parses it to obtain the device and time period to be queried. Specifically, the target query request can be JSON formatted data. The backend can use parsing tools (such as JSON parsing libraries in programming languages) to deserialize the target query request, converting the structured string into operable objects (such as Map in Java or Dictionary in Python), and then extracting the raw data according to preset field names. Thus, the device and time period to be queried are obtained. For example, assuming the value of the "deviceId" field corresponds to the device identifier "DEV-20240501" of the device to be queried, the device to be queried can be determined based on this device identifier.

[0069] As can be seen, by identifying the device to be queried, it is possible to accurately filter out trajectory information that is only related to the device to be queried from massive amounts of device data, avoiding invalid operations on other irrelevant device data and greatly improving the targeting of data queries.

[0070] S102. The producer determines the size of the time window, and queries the coordinate data of the device to be queried in the time period from the time series database according to the size of the time window. For each coordinate data queried, and if the consumer meets the first preset condition, the coordinate data is pushed to the consumer.

[0071] The first preset condition can be preset in advance or set by default.

[0072] It is evident that the producer does not query all coordinate data within the query period at once, but rather queries in batches according to a defined time window size. For each coordinate data queried, it checks whether the consumer meets the first preset condition. Only when the first preset condition is met is the data pushed. This avoids loading a large amount of data into memory at once, thereby effectively controlling memory usage and preventing the device management platform's ability to process other business requests from being affected by instantaneous memory exhaustion, thus ensuring the stability of the entire platform.

[0073] In some embodiments, step S102, determining the time window size, may include the following steps:

[0074] A1. Determine the target acquisition period corresponding to the coordinate data of the device to be queried;

[0075] A2. Determine the data processing rate corresponding to the consumer;

[0076] A3. Determine the size of the time window based on the data processing rate and the target acquisition cycle.

[0077] Specifically, the target acquisition period corresponding to the coordinate data of the device to be queried can be determined first. For example, the device basic information can be queried from the backend database based on the device identifier of the device to be queried, and the target acquisition period can be extracted from the device basic information. This is because when the device is connected to the device management platform, it will register its own hardware parameters (including the acquisition period) with the backend database. By querying the corresponding acquisition period in the backend database through the unique identifier (i.e., deviceId) of the device to be queried, the target acquisition period can be obtained. For example, assuming that the field name of the acquisition period is "collection_cycle", if the value of the "collection_cycle" field corresponding to the unique identifier of the device to be queried is 10, then the target acquisition period is 10 seconds.

[0078] It should be explained that the target acquisition period refers to the fixed time interval (e.g., 1 second / time) at which the device to be queried generates coordinate data. That is, the device to be queried will automatically collect and upload coordinate information once every such period. For example, if the device uploads location data once every 10 seconds, then its corresponding target acquisition period is 10 seconds.

[0079] Next, the data processing rate for each consumer can be determined. Specifically, historical work data of the consumer can be obtained, and the data processing rate can be determined based on this historical work data. For example, the maximum number of data items processed by the consumer per unit time (e.g., 1 second) can be extracted from the historical work data, which is the data processing rate. Alternatively, the data processing rate can also be determined through data testing. Specifically, the maximum processing capacity of the consumer under ideal conditions can be tested in a controlled environment (excluding interference from other business operations), as follows:

[0080] Prepare test data: Generate multiple coordinate data samples (containing different timestamps, device identifiers, and latitude and longitude formats), and the data volume needs to cover possible peak values ​​(e.g., 100,000 records).

[0081] Set test parameters: fix system resources (e.g., CPU utilization ≤ 50%, sufficient memory); disable the front-end rendering function and only test the consumer's pure processing capability of "receiving data → processing → pushing to WebSocket buffer" (excluding front-end bottlenecks); push data to the consumer in different batch sizes (e.g., 100 records / batch, 500 records / batch).

[0082] Record processing time: Calculate the maximum amount of data that a consumer can successfully process per unit of time, repeat the test 3-5 times and take the average value to obtain the theoretical maximum processing rate (e.g., "500 data points / second"), which is the data processing rate.

[0083] Finally, the size of the time window can be determined based on the data processing rate and the target acquisition cycle.

[0084] It is evident that determining the time window size based on the data processing rate and the target acquisition period allows the window size to match the acquisition period and the data processing rate, thereby reducing the database overhead of cross-period queries (for example, when a time series database is stored in shards according to the acquisition period, window queries can accurately hit the shards).

[0085] In some embodiments, step A3, determining the time window size based on the data processing rate and the target acquisition cycle, may include the following steps:

[0086] A31. Determine the maximum time window size corresponding to the data processing rate based on the target acquisition cycle;

[0087] A32. Obtain the target time granularity corresponding to the time series database;

[0088] A33. Determine the size of the reference time window based on the target acquisition cycle and the target time granularity;

[0089] A34. When the reference time window size is not greater than the maximum time window size, determine the time window size based on the reference time window size; or, when the reference time window size is greater than the maximum time window size, determine the difference between the reference time window size and the maximum time window size to obtain the first difference; determine the second difference based on the first difference and the target acquisition cycle; determine the time window size based on the second difference and the reference time window size.

[0090] Specifically, the maximum time window size corresponding to the data processing rate can be determined based on the target acquisition cycle. Specifically, the number of data points corresponding to the data processing rate can be determined first. Then, the maximum time window size can be obtained by multiplying the number of data points by the target acquisition cycle. For example, assuming the target acquisition cycle is 10 seconds and the data processing rate is 30 data points / second, the number of data points corresponding to the data processing rate is equal to 30. 30 * 10 = 300, that is, the maximum time window size is equal to 300 seconds.

[0091] Next, the target time granularity corresponding to the time series database can be obtained. Specifically, the preset time granularity configuration of the time series database, i.e. the target time granularity, can be queried through management commands or system tables.

[0092] It's important to explain that the target time granularity refers to the smallest unit of time at which a time-series database "shards" and groups data according to a preset time interval. For example, if the target time granularity is 1 minute, the database will store all data within 1 minute in the same "data shard," and data exceeding 1 minute will be stored in the next shard. This target time granularity is determined by the database initialization configuration or automatic optimization strategy and directly affects the efficiency of time range queries (queries matching the granularity can accurately hit the shards, reducing the scan range).

[0093] Furthermore, the size of the reference time window can be determined based on the target acquisition period and the target time granularity. Specifically, the least common multiple between the target acquisition period and the target time granularity can be determined, and this least common multiple can be used as the size of the reference time window. For example, assuming the target acquisition period is 10 seconds and the target time granularity is 15 seconds, then the least common multiple of these two is 30 seconds, that is, the size of the reference time window is equal to 30 seconds. When the size of the reference time window is not greater than the size of the maximum time window, it means that the size of the reference time window is within the range that consumers can tolerate. At this time, the size of the reference time window can be directly determined as the size of the time window.

[0094] When the reference time window size is larger than the maximum time window size, it indicates that the reference time window size exceeds the range that consumers can tolerate. In this case, the difference between the reference time window size and the maximum time window size is determined to obtain the first difference. Specifically, the first difference can be obtained by subtracting the maximum time window size from the reference time window size. Then, the second difference can be determined based on the first difference and the target acquisition period. Specifically, it can be first determined whether the first difference is a multiple of the target acquisition period. If the first difference is a multiple of the target acquisition period, the second difference can be directly determined. The first difference is set as the second difference. Conversely, if the first difference is not a multiple of the target acquisition period, the first difference can be appropriately increased to make it a multiple of the target acquisition period, thus obtaining the second difference. For example, assuming the target acquisition period is 10, the first difference is 16. Since 16 is not a multiple of 10, 4 can be added to 16 to get 20. Since 20 is a multiple of 10, the second difference is equal to 20. Finally, the size of the time window can be determined based on the second difference and the size of the reference time window. Specifically, the size of the time window can be obtained by subtracting the second difference from the size of the reference time window.

[0095] In some embodiments, when the reference time window size is larger than the maximum time window size, the target deviation between the reference time window size and the maximum time window size can be determined, and the specific calculation formula is as follows:

[0096] Target deviation = |Reference time window size - Maximum time window size| / Maximum time window size * 100%;

[0097] Based on the above formula, the target deviation can be obtained. Next, the target adjustment factor corresponding to the target deviation can be determined. For example, a pre-stored mapping relationship between deviations and adjustment factors can be used to determine the target adjustment factor based on this mapping relationship. The target adjustment factor can range from -0.3 to 0.3. Then, the size of the reference time window can be adjusted according to the target adjustment factor. The specific calculation formula is as follows:

[0098] Target time window size = Reference time window size * (1 + Target adjustment factor);

[0099] Based on the above formula, the target time window size can be obtained. Finally, the target time window size can be adjusted according to the target acquisition period to obtain the time window size. Specifically, it can be first determined whether the target time window size is a multiple of the target acquisition period. If the first difference is a multiple of the target acquisition period, the target time window size can be directly determined as the time window size. Conversely, if the target time window size is not a multiple of the target acquisition period, the target time window size can be appropriately increased to make it a multiple of the target acquisition period, thereby obtaining the time window size.

[0100] As can be seen, determining the maximum window size based on the target acquisition cycle and data processing rate essentially involves inferring the "resource safety boundary" of the window from the premise that "the device generates one data point per cycle" and "the consumer's maximum processing volume per unit time" (e.g., if a consumer can process a maximum of 60 data points per minute, and the acquisition cycle is 10 seconds, then the maximum window size should not exceed 600 seconds to avoid exceeding processing capacity). This step ensures that the window size does not exceed the system's hardware and software capacity limits, preventing risks such as data accumulation and memory overflow at the source.

[0101] In some embodiments, step S102, which involves sequentially querying the coordinate data of the device to be queried within the time period from the time series database according to the time window size, may include the following steps:

[0102] B1. Divide the time period to be queried into N time windows according to the size of the time window; N is an integer greater than 1.

[0103] B2. Arrange the N time windows in chronological order to obtain the target window order;

[0104] B3. Query the coordinate data of the device to be queried in each of the N time windows from the time series database according to the target window order.

[0105] Specifically, the time period to be queried can be segmented according to the size of the time window to obtain N time windows. For example, the start time (T_start) and end time (T_end) of the time period to be queried can be determined first. The first time window is determined according to the time window size and the start time. The start time of the first time window is T_start, and the end time of the first time window is T_start+S, where S represents the size of the time window. According to the rule that "the end time of the previous window is equal to the start time of the next window", the 2nd to N-1th windows are generated in sequence. When generating the Nth window, the remaining time may not be enough for a complete window. Therefore, the end time of the last window (i.e. the Nth window) is T_end (instead of the start time of the window + S) to ensure that it does not exceed the time period to be queried. In this way, N time windows can be obtained.

[0106] Next, the N time windows can be arranged in chronological order to obtain the target window order. Specifically, the N time windows can be assigned numbers (e.g., window 1, window 2, ..., window N) based on their start time. The earlier the start time, the smaller the number. The start time t_i_start and end time t_i_end of each time window are recorded (accurate to seconds or milliseconds, in a unified format of timestamps or sortable strings, e.g., 2024-09-01 08:00:00). These N time windows are then arranged in ascending order of their numbers to obtain the target window order.

[0107] Finally, the coordinate data of the device to be queried within each of the N time windows can be retrieved from the time series database according to the target window order. Specifically, the target window order can be used as a query queue, and the producer processes each window sequentially according to the "first-in, first-out" principle.

[0108] Take the first window (window 1) from the query queue and use it as the current query object;

[0109] The coordinate data of the device to be queried in window 1 is retrieved from the time series database. After the query in window 1 is completed, window 2 is processed, and so on, until all windows have been queried.

[0110] In this way, we can obtain N coordinate data.

[0111] It should be explained that the time range of the queried data usually adopts "left closed, right open" to avoid data duplication caused by the shared end or start time of adjacent windows (because the end time of the previous window = the start time of the next window); in addition, each coordinate data can include at least one coordinate point.

[0112] As can be seen, by splitting the query period into N time windows (e.g., 1 hour into 60 1-minute windows) and querying in batches by window, loading only the data of a single window each time, the memory usage of a single query is significantly reduced, allowing platform resources to be evenly distributed to other services (e.g., processing query requests from multiple users simultaneously), thus improving resource utilization.

[0113] In some embodiments, before pushing the coordinate data to the consumer if the consumer meets the first preset condition, the above method may further include the following steps:

[0114] C1. Obtain the consumer's consumption data rate and the producer's query data rate respectively;

[0115] C2. When the consumption data rate is greater than or equal to the query data rate, determine that the consumer meets the first preset condition; or, when the consumption data rate is less than the query data rate, determine that the consumer does not meet the first preset condition.

[0116] Specifically, we can first obtain the consumer's consumption data rate and the producer's query data rate. The consumer's consumption data rate refers to the amount of coordinate data successfully processed and pushed to the front end per unit time (e.g., "data per second"). We need to track the entire process of data from "receiving" to "pushing". The specific steps are as follows:

[0117] 1. Define the markers for "complete consumption".

[0118] The "end point" for a consumer to process a piece of data is usually when the data, after being filtered and converted in format, is successfully pushed to the front end via WebSocket (or written to the front end's receiving buffer), which is considered "consumption complete".

[0119] 2. Include data logging in the consumer processing logic.

[0120] Record start time: When a consumer receives a piece of data from a producer, record the current timestamp (t1, accurate to milliseconds);

[0121] Record completion time: After the data is successfully pushed to the front end, record the current timestamp (t2);

[0122] Cumulative count: Use a counter (count_consumer) to accumulate the total amount of data consumed in real time.

[0123] 3. Calculate the rate using a fixed time window.

[0124] Set the statistics window (e.g., 1 second, 5 seconds, adjust according to accuracy requirements), and at the end of each window:

[0125] Calculate the total consumption within the window: Δcount = count_consumer at the end of the window - count_consumer at the beginning of the window;

[0126] Consumption rate = Δcount / window duration, which gives the average consumption rate (i.e., the data consumption rate) within the window.

[0127] For example, if a consumer consumes 250 data entries in 5 seconds, then the consumption rate = 250 ÷ 5 = 50 entries / second. In addition, the method for obtaining the producer's query data rate can be the same as the method for obtaining the consumption data rate, which will not be elaborated here.

[0128] When the consumption data rate is greater than or equal to the query data rate, it means that the data pushed by the producer can be "instantly digested" by the consumer and will not accumulate in the consumer's buffer (such as a memory queue). At this time, it can be determined that the consumer meets the first preset condition.

[0129] When the consumption data rate is less than the query data rate, it means that the consumer's processing speed cannot keep up with the supply speed. Data will continue to accumulate in the buffer, causing memory usage to soar and even triggering memory overflow, slowing down the response speed of the entire system. At this time, it can be determined that the consumer does not meet the first preset condition.

[0130] It is evident that when the consumption data rate is less than the query data rate (the consumer's processing speed cannot keep up with the producer's supply speed), it is determined that the first preset condition is not met. At this time, the producer will pause or slow down the data push, thereby avoiding the continuous accumulation of data in the consumer's buffer.

[0131] In some embodiments, after determining that the consumer does not meet the first preset condition, the method may further include the following steps:

[0132] D1. Determine the number of coordinate data that the producer has queried but has not pushed to the consumer, and obtain the first quantity;

[0133] D2. When the first quantity is greater than or equal to the preset quantity, control the producer to stop querying data; or, when the first quantity is less than the preset quantity, control the producer to continue querying data.

[0134] The preset quantity can be preset in advance or set to the default value. For example, the preset quantity can be 3.

[0135] Specifically, the number of coordinate data that the producer has queried but not pushed to the consumer can be determined first to obtain a first quantity. The producer can set a lifecycle status for each batch of queried coordinate data. The lifecycle status of each coordinate data can include one of the following: queried, pushed, or discarded, as detailed below:

[0136] Query results: Data has been successfully read from the time-series database into the producer's local buffer (such as a memory list or queue), but has not yet been pushed to the consumer;

[0137] Pushed: Data has been sent to the consumer via internal communication mechanisms (such as message queues, function calls), or has been written to a buffer that the consumer can read;

[0138] Discarded: Data that was actively discarded by the producer due to anomalies (such as incorrect data format or expiration) (not included in the first quantity);

[0139] It can obtain the number of coordinate data in all lifecycle states of the producer that are queried, and get the first number.

[0140] It is evident that triggering the stop mechanism with the first quantity is equivalent to "applying the brakes" to producers, forcing them to wait for consumers to digest the existing data (the first quantity drops below the preset quantity) before resuming queries, thus ensuring that the production pace matches the consumption capacity.

[0141] S103. The consumer pushes the coordinate data to the front end, and the front end renders and displays the trajectory screen of the device to be queried based on the coordinate data.

[0142] Specifically, consumers can establish a connection with the front-end via the WebSocket protocol. They can then push coordinate data, formatted into a preset format (e.g., JSON), to the front-end. Upon receiving the coordinate data, the front-end can render and display the trajectory of the device being queried. Specifically, the front-end can load a basic map (such as satellite imagery or street view) using a map tool and initialize the map view.

[0143] Center point: can be set to the coordinates of the first trajectory point in the coordinate data, or the center position of all trajectory points can be automatically calculated;

[0144] Zoom level: Adjust according to the coverage of the track (e.g., set to level 13 for tracks within a city and level 8 for tracks across provinces) to ensure that most tracks are visible initially.

[0145] Next, each coordinate point in the coordinate data is represented on the map with a small dot or icon, which can distinguish between the latest point (e.g., red) and historical points (e.g., gray). When a user clicks on a coordinate point, the timestamp of that point can be displayed (e.g., "2024-09-01 08:00:10"), making it easy for the user to see the location at a specific time.

[0146] Furthermore, all trajectory points can be connected by line segments in chronological order to form a continuous path. The color (e.g., blue), width (e.g., 3 pixels), and transparency (e.g., 80%) of the line segments can be set to make the trajectory clearly visible. If the trajectory is long, it can be drawn in segments (e.g., draw the lines of the first 10 points first, and then gradually draw the subsequent parts) to avoid rendering too much at once and causing lag. During the continuous path simulation of device movement (i.e., displaying the trajectory screen), the trajectory is displayed step by step in chronological order. The front end can support speed control, such as displaying the trajectory at 1x speed, 2x speed, etc. (e.g., at 1x speed, one point is displayed every 1 second, consistent with the actual time). During the display, animation effects (e.g., blinking dots, fading lines) can be used to highlight the current playback position, and the current time can be displayed synchronously on the side (e.g., "Now playing: 08:00:10").

[0147] In some embodiments, step S103, pushing coordinate data to the front end, may include the following steps:

[0148] E1. Determine the progress time of the device trajectory backtracking corresponding to the front end at the current moment;

[0149] E2. Determine the coordinate timestamps corresponding to the coordinate data;

[0150] E3. When the progress time and coordinate timestamp match successfully, push the coordinate data to the front end; or, when the progress time and coordinate timestamp fail to match, obtain new coordinate data from the consumer and push the new coordinate data to the front end.

[0151] Specifically, the progress time of the device trajectory backtracking corresponding to the front end at the current moment can be determined. For example, the back end can send a first query request to the front end. The first query request is used to query the progress time of the device trajectory backtracking at the previous moment. After receiving the first query request, the front end sends the progress time to the back end. Then, the coordinate timestamp corresponding to the coordinate data can be determined. Specifically, the coordinate data can include timestamps. The corresponding timestamps can be extracted from the coordinate data to obtain the coordinate timestamps.

[0152] Then, the progress time can be matched with the coordinate timestamp. Specifically, it can be determined whether the coordinate timestamp and the progress time are consistent (or close within the allowable error range). If they are consistent, the match is successful; if they are inconsistent, the match fails. When the progress time and the coordinate timestamp are successfully matched, the backend can push the coordinate data to the frontend.

[0153] When the progress time and coordinate timestamp fail to match, the consumer can obtain new coordinate data from the producer. Then, the consumer pushes the new coordinate data to the front end. Specifically, steps E1-E3 can be executed for the new coordinate data.

[0154] As can be seen, by matching the progress time with the coordinate timestamp, the pushed coordinate data is ensured to be exactly the actual position of the device at the progress time point, avoiding "time misalignment" and thus ensuring the timing accuracy of trajectory playback.

[0155] In some embodiments, the above method may further include the following steps:

[0156] F1, Set the timer;

[0157] F2. The consumer is woken up periodically by a timer, and when the consumer detects that there is processable coordinate data, the processable coordinate data is pushed to the front end.

[0158] Specifically, a timer can be set. For example, a timer can be initialized in the backend system (such as using tools like setInterval or Timer) and a fixed wake-up interval can be set, such as waking up once every 100 milliseconds or 1 second. The wake-up interval can be set according to the frontend rendering accuracy requirements.

[0159] Next, a timer can periodically wake up the consumer, which checks if there is any processable coordinate data. If so, the consumer pushes the processable coordinate data to the front end; otherwise, the consumer enters a sleep state. Specifically, when the timer reaches the set wake-up interval, a wake-up signal (e.g., function call, event notification) is triggered. This wake-up signal activates the consumer in a sleep state, putting it into a working state. The awakened consumer checks its own buffer to determine if there is any coordinate data to be pushed (i.e., "processable coordinate data," usually data that has been queried and meets the push conditions, such as data whose timestamp matches the front end's progress). If there is processable coordinate data in the buffer, it is pushed to the front end; if there is no processable coordinate data in the buffer, the consumer enters a sleep state, releases currently occupied resources (such as CPU threads), and waits for the next timer wake-up. This avoids the consumer "waiting idly" when there is no data to process, reduces ineffective resource occupation, and improves the overall system operating efficiency.

[0160] For example, please refer to [link / reference]. Figure 5 , Figure 5 The present application provides a flowchart of a device management platform. The device management platform includes a front-end, a back-end, and a time-series database. The back-end includes producers and consumers. The workflow of the device management platform is as follows:

[0161] 1. Select track recording and start playback.

[0162] Users can select a historical trajectory record (for example, the movement trajectory of device A throughout the day on September 1, 2024) on the device management platform interface and click the "Start Playback" button.

[0163] 2. WebSocket connection request

[0164] The front-end (such as a webpage or app interface) initiates a WebSocket connection request to the back-end to establish a "long connection" between the front-end and the back-end, ensuring that subsequent trajectory data can be pushed to the front-end in real time.

[0165] 3. Analysis start and end times

[0166] After receiving the request from the frontend, the backend parses out the start and end times of the trajectory playback, thereby defining the time range for subsequent data queries by producers and avoiding the querying of irrelevant data.

[0167] 4. Start production task (start and end time)

[0168] The backend sends instructions to the producer module to start the "production task" and specify the deadline of the task (i.e. the end time of the trajectory); the producer starts to query the coordinate data in the time series database according to the time window to prepare for subsequent push.

[0169] 5. Initiate consumption tasks

[0170] The backend sends a command to the consumer to start the "consumption task". After receiving the command from the backend, the consumer enters the working state, ready to receive the coordinate data queried by the producer and push it to the frontend.

[0171] After the consumption task is initiated in the backend, the device management platform enters the first loop process (i.e. Figure 5 The first loop process (in the producer loop) includes... Figure 5 The steps within the dashed box of the "producer loop," which is the first loop process, include steps 6-9. This indicates that the producer will continuously and cyclically execute steps 6-9 until the "termination condition" is met (such as traversing all time windows or reaching the termination time of the trajectory).

[0172] 6. Dividing the time window

[0173] Producers divide the "start and end time" into multiple time windows. For example, assuming each window is 1 minute long, the first time window can be 08:00-08:01, the second time window can be 08:01-08:02, and so on.

[0174] 7. Query window data

[0175] The producer sends a query request to the time series database for the current time window to obtain all coordinate data within that window.

[0176] 8. Return coordinate data

[0177] After executing the query, the time series database returns the coordinate data (including timestamps, latitude and longitude, etc.) within the time window to the producer.

[0178] 9. Push Data Window

[0179] The producer pushes the retrieved data window (i.e., the coordinate data within the window) to the consumer and follows the caching rules: production continues when the number of windows cached by the consumer is ≤3; production is paused when the cache is full (i.e., production is paused when the number of windows cached by the consumer is >3). This balances the "data supply speed" and the "consumer processing capacity" to avoid the consumer from experiencing memory overflow due to excessive data caching or from having no data to push due to insufficient data.

[0180] After the producer pushes the data window, the device management platform's workflow enters the second loop, which includes... Figure 5 The steps within the dashed box for "trigger every second" indicate that the second loop process means that the front end will continuously and cyclically execute the logic of "receiving coordinate data → rendering trajectory screen", while the consumer will also cyclically execute the logic of "timer wake-up → matching data → push or sleep" until the trajectory playback ends (such as reaching the termination time or the user manually stopping).

[0181] 10. Timer wake-up

[0182] The device management platform can start a timer, which triggers once per second, to wake up consumers in a dormant state. This allows consumers to check their cache for matching data to be pushed to the front end at a fixed rhythm (once per second), ensuring smooth trajectory playback (the screen is updated once per second).

[0183] If the consumer detects (1) [matching data], then sub-steps (11)-(13) are executed. Wherein, Figure 5 The “Alt” in the code represents an alternative condition, used to mark different conditional branches in the process. For example, when determining whether there is matching data, different conditions correspond to different subsequent steps, and “Alt” is used to help explain the alternative execution situation under such conditions.

[0184] (11) Match the current time coordinates

[0185] The consumer obtains the coordinate timestamp of the matching data and matches it with the current time. If the coordinate timestamp matches the current time, the matching is successful and step (12) is executed. If the coordinate timestamp does not match the current time, the matching is failed and the consumer obtains new matching data to match the coordinates of the current time, or enters a sleep state.

[0186] (12) WebSocket pushes current time coordinate data

[0187] Consumers push the successfully matched coordinate data to the front end via the established WebSocket connection, allowing the front end to obtain real-time, accurate coordinate data for rendering the trajectory image.

[0188] (13) Rendering the trajectory screen

[0189] After receiving the coordinate data, the front end renders the trajectory on the front end's display interface (such as dynamically drawing points and lines, and updating the device position) to visualize the data and allow users to see the effect of trajectory tracing.

[0190] If the consumer detects (2) [no matching data], then skip sub-steps (11)-(13) and directly execute sub-step (21).

[0191] (21) Hibernation and waiting

[0192] The consumer enters a sleep state, waiting for the next timer to wake it up.

[0193] The entire workflow, through designs such as "window-based query, cache control, and timed matching," balances data real-time performance with system performance, ensuring that trajectory playback is both smooth and does not consume excessive resources.

[0194] In summary, by splitting the query period into time windows by the producer and querying only the coordinate data within a single window each time, the amount of memory loaded per query is reduced to 1 / N (where N is the number of windows obtained by splitting the query period) compared to querying all data in the query period at once in existing technologies. This avoids the memory spike caused by loading all data at once, thereby reducing the memory usage of the backtracking function and improving the efficiency of device trajectory backtracking.

[0195] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0196] Based on the same inventive concept, this application also provides a device for tracing equipment trajectories. The solution provided by this device is similar to the solution described in the above method. Therefore, the specific limitations of one or more device tracing equipment tracing equipment embodiments provided below can be found in the limitations of the device tracing equipment tracing method described above, and will not be repeated here.

[0197] Please see Figure 6 This application provides a device trajectory tracing device 600, applied to the backend of a device management platform. The device management platform includes a frontend, a backend, and a time-series database. The backend includes producers and consumers. The device trajectory tracing device 600 includes:

[0198] The response module 601 is used to respond to the target query request from the front end and determine the device to be queried and the time period to be queried based on the target query request;

[0199] The push module 602 is used to determine the size of the time window by the producer, and query the coordinate data of the device to be queried in the time period from the time series database according to the size of the time window. Each time a coordinate data is queried, and the consumer meets the first preset condition, the coordinate data is pushed to the consumer.

[0200] The backtracking module 603 is used to push coordinate data to the front end through the consumer, and the front end renders and displays the trajectory screen of the device to be queried based on the coordinate data.

[0201] Each module in the aforementioned device trajectory tracing device 600 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 a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0202] In some embodiments, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 7 As shown, the computer device includes a processor, memory, input / output interfaces (I / O), and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores data related to device trajectory tracing. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements the steps in the device trajectory tracing method described above.

[0203] In some embodiments, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 8As shown, the computer device includes a processor, memory, input / output interface, communication interface, display unit, and input device. The processor, memory, and input / output interface are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interface. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The input / output interface is used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it performs the steps in the device trajectory tracing method described above. The display unit of the computer device forms a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen; the input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs or touchpads set on the casing of the computer device, or external keyboards, touchpads or mice, etc.

[0204] Those skilled in the art will understand that Figure 7 or Figure 8 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specifically, the computer device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.

[0205] In some embodiments, a computer device is provided, the computer device including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the steps in the above method embodiments.

[0206] In some embodiments, such as Figure 9 The diagram shows the internal structure of a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps described in the above-described method embodiments.

[0207] In some embodiments, a computer program product is provided, which includes a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0208] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data shall comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0209] 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 a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0210] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0211] The above embodiments are merely illustrative of several implementation methods of this application, and their descriptions are relatively specific and detailed. However, they should not be construed as limiting the scope of this application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A method for tracing equipment trajectories, characterized in that, The method is applied to the backend of an equipment management platform, which includes a frontend, the backend, and a time-series database. The backend includes producers and consumers. In response to the target query request from the front end, the device to be queried and the time period to be queried are determined based on the target query request; The producer determines the size of the time window, and queries the coordinate data of the device to be queried within the time period in the time series database according to the size of the time window. Each time coordinate data is queried, and the consumer meets the first preset condition, the coordinate data is pushed to the consumer. The consumer pushes the coordinate data to the front end, and the front end renders and displays the trajectory of the device to be queried based on the coordinate data. The determination of the time window size includes: Determine the target acquisition period corresponding to the coordinate data of the device to be queried; Determine the data processing rate corresponding to the consumer; The time window size is determined based on the data processing rate and the target acquisition cycle; The method further includes, before pushing the coordinate data to the consumer when the consumer meets the first preset condition: The consumption data rate of the consumer and the query data rate of the producer are obtained respectively. When the consumption data rate is greater than or equal to the query data rate, the consumer is determined to meet the first preset condition; or, When the consumption data rate is less than the query data rate, it is determined that the consumer does not meet the first preset condition.

2. The method according to claim 1, characterized in that, The step of sequentially querying the coordinate data of the device to be queried within the time period from the time series database according to the time window size includes: The time period to be queried is segmented according to the size of the time window to obtain N time windows; N is an integer greater than 1. Arrange the N time windows in chronological order to obtain the target window order; According to the target window sequence, the coordinate data of the device to be queried is retrieved from the time series database within each of the N time windows.

3. The method according to claim 1, characterized in that, After determining that the consumer does not meet the first preset condition, the method further includes: Determine the number of coordinate data points that the producer has queried but not pushed to the consumer, and obtain a first number; When the first quantity is greater than or equal to a preset quantity, the producer is controlled to stop querying data; or, When the first quantity is less than the preset quantity, the producer is controlled to continue querying data.

4. The method according to claim 1 or 2, characterized in that, The step of pushing the coordinate data to the front end includes: Determine the progress time of the device trajectory backtracking corresponding to the front end at the current moment; Determine the coordinate timestamp corresponding to the coordinate data; When the progress time successfully matches the coordinate timestamp, the coordinate data is pushed to the front end; or, When the progress time fails to match the coordinate timestamp, new coordinate data is obtained through the consumer and pushed to the front end.

5. The method according to claim 1 or 2, characterized in that, The method further includes: Set a timer; The consumer is woken up periodically by the timer, and when the consumer detects that there is processable coordinate data, the processable coordinate data is pushed to the front end.

6. A device for tracing equipment trajectory, characterized in that, The device management platform is used as a backend for an equipment management platform, which includes a frontend, the backend, and a time-series database. The backend includes producers and consumers, and the device includes: The response module is used to respond to the target query request from the front end and determine the device to be queried and the time period to be queried based on the target query request. The push module is used to determine the size of the time window through the producer, and query the coordinate data of the device to be queried in the time period from the time series database according to the size of the time window. Each time a coordinate data is queried, and the consumer meets the first preset condition, the coordinate data is pushed to the consumer. The backtracking module is used to push the coordinate data to the front end through the consumer, and the front end renders and displays the trajectory screen of the device to be queried based on the coordinate data; Specifically, regarding determining the size of the time window, the push module is used for: Determine the target acquisition period corresponding to the coordinate data of the device to be queried; Determine the data processing rate corresponding to the consumer; The time window size is determined based on the data processing rate and the target acquisition cycle; Specifically, before pushing the coordinate data to the consumer when the consumer meets the first preset condition, the device is further configured to: The consumption data rate of the consumer and the query data rate of the producer are obtained respectively. When the consumption data rate is greater than or equal to the query data rate, the consumer is determined to meet the first preset condition; or, When the consumption data rate is less than the query data rate, it is determined that the consumer does not meet the first preset condition.

7. A computer device, the computer device comprising a memory and a processor, the memory storing a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 5.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 5.

Images