A method and apparatus for storing and replaying historical station map data in a TIAS system.

Abstract

This invention discloses a method and apparatus for storing and replaying historical station map data in a TIAS system, comprising the following steps: subscribing to and receiving trackside location information and train location information from a real-time database; storing the received trackside location information and train location information that meet the conditions into a historical database; when viewing the replay through the front-end interface, the front-end interface sends a data request to the query module; the query module queries data according to the replay time period required by the front-end page; the query module returns the queried data to the front-end interface in the form of sliced ​​packets. By directly storing the required location data in the location format, the data table fields are simplified. The changes in locations are updated by comparing locations in the real-time database with those in the historical database, and location information is requested in the form of time periods for on-demand storage. Excessively large location data packets are sliced ​​and sent up in time periods, significantly reducing interface loading time and interface caching.

Description

Technical Field

[0001] This invention relates to the field of rail transit data processing, and in particular to a method and apparatus for storing and playing back historical station map data in a TIAS system. Background Technology

[0002] Traffic Control Integrated Automation System (TIAS): TIAS is a cross-disciplinary, distributed, integrated data information platform system. Centered on traffic control, it integrates various professional subsystems closely related to traffic control, including ATS, PSCADA, BAS, FAS, UPS, PSD, PIS, PA, ACS, CLK, CCTV, and AFC. This unified platform organically integrates information from each professional subsystem, creating a tightly integrated whole. Through a unified human-machine interface, it provides comprehensive monitoring of the rail transit network's operation and scheduling, unified supervision and management of trains, power supply, and electromechanical systems, and full lifecycle maintenance and management of equipment, thus fully realizing the automation and intelligence of rail transit operations.

[0003] In integrated automated train control systems, station maps are used to display information about trackside equipment and trains. Currently, station map information is primarily stored in traditional relational databases, requiring querying the database to retrieve the corresponding raw data stream, parsing it, and then transmitting it to the interface. However, station maps involve numerous devices and large amounts of data, and different data tables need to be created based on battlefield information. This results in a relatively cumbersome parsing process, consuming significant storage space and time. Therefore, there is an urgent need for a method to simplify the storage and playback of historical station map data, thereby improving data storage and playback efficiency. Summary of the Invention

[0004] This invention addresses the problems of cumbersome and time-consuming storage and retrieval processes for station maps in existing TIAS systems. It provides a method for storing and replaying historical station map data in TIAS systems by directly storing the required point data in point form, thereby reducing the amount of data, accelerating terminal interface loading time, and improving the storage and retrieval efficiency of station maps.

[0005] To achieve the above objectives, the present invention adopts the following technical solution:

[0006] A method for storing and replaying historical station map data in a TIAS system includes the following steps:

[0007] Step S1: Subscribe to receive real-time trackside location information and train location information from the database;

[0008] Step S2: Store the received trackside location information and train location information that meet the conditions into the historical database;

[0009] Step S3: When viewing the replay through the front-end interface, the front-end interface sends a request for data to the query module;

[0010] Step S4: The query module queries data based on the playback time period required by the front-end page;

[0011] Step S5: The query module returns the retrieved data to the front-end interface in sliced ​​and packaged form. By directly storing the required point data in point format, the data table fields are simplified, the data footprint is reduced, and the point information is directly used for interface display without the need for secondary data parsing and uploading, further reducing interface query loading time and minimizing interface caching.

[0012] Preferably, step S2 involves storing the received trackside location information and train location information that meet the conditions into a historical database; specifically, this includes:

[0013] Step S21: Compare the received trackside location information and train location information in the real-time database with the corresponding trackside location information and train location information in the historical database's MAP. If the trackside location information and / or train location information have changed, save the changed trackside location information and / or train location information and update the MAP in the historical database. By comparing the locations in the real-time database with the historical database and updating the changed locations, storage is performed on demand, simplifying data transmission, increasing transmission rate, and improving data update efficiency.

[0014] Furthermore, the change location information is divided into tables according to function, which simplifies the number of columns required for location information and improves the hit rate.

[0015] Preferably, step S2, which involves storing the received trackside location information and train location information that meet the conditions into a historical database, specifically includes:

[0016] Step S22: After receiving the data in step S21, write all the information of the change into the queue and store it in the historical database. At the same time, determine the current heartbeat time. If the current heartbeat time is less than the first preset time, do not do anything. If the current heartbeat time is greater than or equal to the first preset time, write all the current position information stored in the historical database into the queue.

[0017] Step S23: After step S22 is completed, all data that needs to be stored in the historical database is stored in a queue. The data in the queue is retrieved according to type and written into the historical database in ascending order of receiving time.

[0018] Preferably, when viewing the playback through the front-end interface in step S3, the front-end module sends request data to the query module, which includes: the front-end interface sending request data to the query module according to the time period that the user needs to view.

[0019] Preferably, the query module in step S4 queries data based on the playback time period required by the front-end page, specifically including:

[0020] Step S41: The query module receives the query data and determines whether the starting data of the current query time period includes all trackside point data and train point data based on the received time period. If not, the query time period is advanced to the time period of the last saved trackside point data and train point data, and the query data is requested.

[0021] Step S42: After retrieving the required data from the database based on the time index, the data is packaged and returned to the query module. Requesting location information in time period format further improves query speed.

[0022] Preferably, the query module in step S5 returns the queried data to the front-end interface in the form of sliced ​​packages, specifically including:

[0023] Step S51: After receiving the required data, the query module determines the data size. If the data is greater than the preset threshold, it divides the data into packets based on the reception time of the point data in the data packet to form point data packets. Each packet is divided according to the length of the second time period. After being divided, the point data packets are returned to the terminal interface in batches.

[0024] Furthermore, if the data is not greater than a preset threshold, the data is directly packaged and sent to the front end.

[0025] A station map historical data storage and playback device in a TIAS system includes a terminal interface: interacting with the user, generating request data transmission to the query module according to the time period selected by the user, and receiving and parsing the point data packets returned by the query module;

[0026] Historical database: It also stores historical data periodically, determines whether the trackside point information received from the real-time database has changed, and stores the data information of the change in real time;

[0027] The query module receives request data from the terminal interface, parses out the playback time period of the request data, uses a time index to query the required data from the historical database, and packages the data into point data packets to return to the terminal interface.

[0028] As a preferred option, the module includes a judgment and upload module: it judges the size of the data received by the query module. If the data is greater than a preset threshold, it is sliced ​​and uploaded to the front-end interface. If the data is not greater than the preset threshold, it is directly uploaded to the front-end.

[0029] Preferably, a display module is included: used to parse the point data packets received by the front end and display the corresponding point values ​​on the interface.

[0030] Preferably, a comparison module is included: used to compare the trackside location information and train location information received in the real-time database with the corresponding trackside location information and train location information in the MAP of the historical database, and output the locations that have changed.

[0031] Therefore, the present invention has the following beneficial effects: (1) It directly stores the required point data in the form of points, simplifies the data table fields, reduces the data space occupied, and directly uses the point information for interface display without secondary parsing and uploading of data, thus improving the query speed. (2) It updates the changed points by comparing the points in the real-time database with the historical database, and requests the point information in the form of time periods, storing it on demand, occupying little space, and dividing the table by function, requiring fewer columns for point information and having a high hit rate. (3) It slices the excessively large point data packets and uploads the data in the form of packets in time periods, reducing a large amount of interface loading time and reducing interface caching. Attached Figure Description

[0032] Figure 1 This is a flowchart of the method for storing and replaying historical station map data in the TIAS system according to an embodiment of the present invention.

[0033] Figure 2 This is a flowchart of a method for storing historical data of station maps in the TIAS system according to an embodiment of the present invention.

[0034] Figure 3 This is a flowchart of a method for replaying historical data of station maps in the TIAS system according to an embodiment of the present invention.

[0035] Figure 4 This is a flowchart of a method for storing and replaying historical station map data in a train operation automation system according to another embodiment of the present invention. Detailed Implementation

[0036] The present invention will now be further described with reference to the accompanying drawings and specific embodiments.

[0037] Example 1:

[0038] like Figure 1 The method for storing and replaying historical station map data in the TIAS system is shown below, including the following steps:

[0039] Step S1: Subscribe to receive real-time trackside location information and train location information from the database;

[0040] Step S2: Use timed storage combined with change storage. Timed storage stores all point data from the real-time database to the historical database every 300 seconds. Change storage is executed at 500 millisecond intervals. Change storage stores the received trackside point information and train point information that meet the conditions to the historical database.

[0041] Step S21: Compare the received trackside location information and train location information in the real-time database with the corresponding trackside location information and train location information in the historical database's MAP. If the trackside location information and / or train location information has changed, save the changed trackside location information and / or train location information and update the MAP in the historical database. By comparing the locations in the real-time database with the historical database and updating the changed locations, storage is performed on demand, simplifying data transmission, increasing transmission rate, and improving data update efficiency. The changed location information is divided into functional tables, simplifying the number of columns required for location information and improving the hit rate.

[0042] Step S22: After receiving the data in step S21, write all the information of the change into the queue and store it in the historical database. At the same time, determine the current heartbeat time. If the current heartbeat time is less than 300 seconds, do not do anything. If the current heartbeat time is greater than or equal to 300 seconds, write all the current position information stored in the historical database into the queue.

[0043] Step S23: After step S22 is completed, all data that needs to be stored in the historical database is stored in a queue. The data in the queue is retrieved according to type and written into the historical database in ascending order of receiving time.

[0044] Preferably, when viewing the playback through the front-end interface in step S3, the front-end module sends request data to the query module, which includes: the front-end interface sending request data to the query module according to the time period that the user needs to view.

[0045] Step S3: When viewing the replay through the front-end interface, the front-end interface sends a request for data to the query module;

[0046] Step S4: The query module queries data based on the playback time period required by the front-end page;

[0047] Specifically, it includes:

[0048] Step S41: The query module receives the query data and determines whether the starting data of the current query time period includes all trackside point data and train point data based on the received time period. If not, the query time period is advanced to the time period of the last saved trackside point data and train point data, and the query data is requested.

[0049] Step S42: After retrieving the required data from the database based on the time index, the data is packaged and returned to the query module. Requesting location information in time period format further improves query speed.

[0050] Step S5: The query module returns the retrieved data to the front-end interface in the form of sliced ​​packages.

[0051] Specifically, it includes:

[0052] Step S51: After receiving the required data, the query module determines the data size. If the data is greater than the preset threshold, it divides the data into packets based on the reception time of the point data in the data packet to form point data packets. Each packet has a time period of 300 seconds. After packetization, the point data packets are returned to the terminal interface in batches at five-minute intervals.

[0053] By directly storing the required location data in the form of locations, the data table fields are simplified, the data space occupied is reduced, and the location information is directly used for interface display without the need for secondary parsing and uploading of data, further reducing the loading time of interface queries and reducing interface caching.

[0054] This embodiment also discloses a station map historical data storage and playback device in the TIAS system, including a terminal interface: interacting with the user, generating request data transmission to the query module according to the time period selected by the user, and receiving and parsing the point data packets returned by the query module;

[0055] Historical database: It also stores historical data periodically, determines whether the trackside point information received from the real-time database has changed, and stores the data information of the change in real time;

[0056] The query module receives request data from the terminal interface, parses out the playback time period of the request data, uses a time index to query the required data from the historical database, and packages the data into point data packets to return to the terminal interface.

[0057] The upload module determines the size of the data received by the query module. If the data size is greater than a preset threshold, it is sliced ​​and uploaded to the front-end interface. If the data size is not greater than the preset threshold, it is directly uploaded to the front-end.

[0058] Display module: used to parse the point data packets received by the front end and display the corresponding point values ​​on the interface.

[0059] Comparison module: Used to compare the trackside location information and train location information received in the real-time database with the corresponding trackside location information and train location information in the historical database MAP, and output the locations that have changed.

[0060] Example 2:

[0061] like Figure 4 The method for storing and replaying historical station map data in a train automation system, as shown, specifically includes the following steps:

[0062] Step A1: After the user selects the desired playback time on the front-end interface, a corresponding first JSON text is generated and then sent to the server via WEBAPI. In this embodiment, the playback time period can be accurate to the second. The following example illustrates this using a playback time of 12:00 to 14:00 on October 13, 2022. When the user selects the playback time as 12:00 to 14:00 on October 13, 2022, the following JSON text is generated:

[0063] The first JSON text in this article, { "startTime":"1665633600" , "endTime":"1665640800"}, is sent to the server.

[0064] Step A2: After receiving the request from the interface, the server parses the corresponding time period in the request and queries the most recent data storage time of all data. It then sends a request to the database. Upon receiving the first JSON text, the server first queries the corresponding time period, with a start time of 1665633600 and an end time of 1665640800. It also queries the corresponding server for the timestamp of the last time all data was stored, which is 1665633300. Therefore, the request's start time is 1665633300 and the end time is 1665640800. Finally, it queries the database for the data within the corresponding time period using SQL statements.

[0065] Step A3: After the server-side query is completed, the queried data is packaged into a second JSON text. The second JSON text includes the storage point name, point value, and generation time. Then, the data slices are packaged and sent to the front-end interface. In this embodiment, after parsing the point information, the point information is packaged into a third JSON text with a text size of 3M. The slice packets are sent to the front-end interface in 1M packets. In this embodiment, 3 point data packets are sent to the front-end interface.

[0066] Step A4: After receiving the location data packet sent by the server, the front-end interface parses the data and compares the generation time of the location in the packet with the playback time to display the corresponding location information specified by the playback time.

[0067] Furthermore, in this embodiment, after the front-end interface receives the data packet, it first generates and displays all the data points at once, and then displays the corresponding data points according to the playback time.

[0068] The specific embodiments described are merely illustrative of the spirit of the invention. Those skilled in the art to which this invention pertains may make various modifications or additions to the described specific embodiments or use similar methods to substitute them, without departing from the spirit of the invention or exceeding the scope defined by the appended claims.

[0069] Although this paper uses terms such as trackside data, train information, JSON text, queue, and heartbeat time extensively, the possibility of using other terms is not excluded. These terms are used merely for the convenience of describing and explaining the essence of this invention; interpreting them as any additional limitation would contradict the spirit of this invention.

Claims

1. A method for storing and replaying historical station map data in a TIAS system, characterized in that, Includes the following steps: Step S1: Subscribe to receive real-time trackside location information and train location information from the database; Step S2: Store the received trackside location information and train location information that meet the conditions into the historical database; including: updating the changed location information by comparing the location information in the real-time database with the historical database, and deciding whether to write all the current location information stored in the historical database into the queue based on whether the current heartbeat time is greater than or equal to the first preset time. Step S3: When viewing the replay through the front-end interface, the front-end interface sends a request for data to the query module; Step S4: The query module queries data based on the playback time period required by the front-end page; Step S5: The query module returns the queried data to the front-end interface in the form of sliced ​​packets; S5 includes: after receiving the data to be returned, the query module judges the data size. If the data is greater than the preset threshold, it divides the data into packets according to the reception time of the point data in the data packet to form point data packets. Each packet is divided according to the length of the second time period. After being divided, the point data packets are returned to the terminal interface in batches.

2. The method for storing and replaying historical station map data in a TIAS system according to claim 1, characterized in that, Step S2, which involves storing the received trackside location information and train location information that meet the conditions into the historical database, specifically includes: Step S21: Compare the received trackside location information and train location information in the real-time database with the corresponding trackside location information and train location information in the MAP of the historical database; if there are changes in the trackside location information and / or train location information, save the changed trackside location information and / or train location information and update the MAP in the historical database.

3. The method for storing and replaying historical station map data in a TIAS system according to claim 2, characterized in that, Step S2, which involves storing the received trackside location information and train location information that meet the conditions into the historical database, specifically includes: Step S22: After receiving the data in step S21, write all the information of the change into the queue and store it in the historical database. At the same time, determine the current heartbeat time. If the current heartbeat time is less than the first preset time, do not do anything. If the current heartbeat time is greater than or equal to the first preset time, write all the current position information stored in the historical database into the queue. Step S23: After step S22 is completed, all data that needs to be stored in the historical database is stored in a queue. The data in the queue is retrieved according to type and written into the historical database in ascending order of receiving time.

4. The method for storing and replaying historical station map data in a TIAS system according to claim 3, characterized in that, When viewing the playback through the front-end interface as described in step S3, the front-end module sends request data to the query module, which includes: the front-end interface sending request data to the query module according to the time period that the user needs to view.

5. A method for storing and replaying historical station map data in a TIAS system according to claim 4, characterized in that, The query module described in step S4 queries data based on the playback time period required by the front-end page, specifically including: Step S41: The query module receives the query data and determines whether the starting data of the current query time period includes all trackside point data and train point data based on the received time period. If not, the query time period is advanced to the time period of the last saved trackside point data and train point data, and the query data is requested. Step S42: After the database retrieves the required data based on the time index, it packages the data and returns it to the query module.

6. A device for storing and replaying historical station map data in a TIAS system, employing the method for storing and replaying historical station map data in a TIAS system as described in any one of claims 1-5, characterized in that, The terminal interface interacts with the user, generates request data to the query module based on the user's selected time period, and receives and parses the location data packets returned by the query module. Historical database: It also stores historical data periodically, determines whether the trackside point information received from the real-time database has changed, and stores the data information of the change in real time; The query module receives request data from the terminal interface, parses out the playback time period of the request data, uses a time index to query the required data from the historical database, and packages the data into point data packets to return to the terminal interface.

7. A station map historical data storage and playback device in a TIAS system according to claim 6, characterized in that, This includes a data upload / deletion module: it determines the size of the data received by the query module. If the data size exceeds a preset threshold, it is sliced ​​and uploaded to the front-end interface. If the data size does not exceed the preset threshold, it is directly uploaded to the front-end.

8. A station map historical data storage and playback device in a TIAS system according to claim 7, characterized in that, Includes a display module: used to parse the point data packets received by the front end and display the corresponding point values ​​on the interface.

9. A station map historical data storage and playback device in a TIAS system according to claim 8, characterized in that, Includes a comparison module: used to compare the received trackside location information and train location information in the real-time database with the corresponding trackside location information and train location information in the historical database MAP, and output the locations that have changed.

Images