Inter-system data verification method in signal field

Abstract

The invention discloses an inter-system data verification method in the signal field, which aims at Track cross validation of cross-system data on an interface level by ATS and ZC, and comprises the following steps of: S1, extracting and importing source data, namely an electronic map, and carrying out preliminary data analysis and conversion; s2, acquiring and analyzing an interface document, and matching the interface document with source data; s3, acquiring and defining respective Track data rules of the ATS and the ZC, and storing the data rules in a rule base; step S4, executing Track data cross validation; and S5, recording a data verification result, including conditions of successful verification and failed verification, and if verification fails, proposing to a data provider. According to the invention, when the data is transmitted among different systems, real-time verification can be carried out based on the predefined global verification rule.

Description

Technical Field

[0001] The present invention relates to the technical field of urban rail transit, and in particular to a method for verifying data between systems in the signal field. Background Art

[0002] As information systems become more complex and diversified, cross-system data interaction becomes more common. However, differences in rules, inconsistent data formats, and different interface standards between different systems and modules often lead to inconsistencies in data transmission and processing, which can easily lead to data errors, loss, or information tampering. At present, the existing data verification mechanisms are mostly limited to a single system or a single module, and there are obvious deficiencies in cross-system data interaction verification.

[0003] When the electronic map data in the subway signal system needs to be transmitted between different systems (such as ATS, ZC, VOBC, etc.), if there are no unified verification standards and rules, the systems may have inconsistent data, resulting in risks in train operation control.

[0004] For example, Track, as a virtual attribute, is mainly used to set TSR (temporary speed limit) in the signal system, that is, the dispatcher operates the ATS (automatic train protection system) interface to send TSR safety commands to ZC (zone control), and ZC sends TSR information to VOBC (vehicle controller) after the setting is passed. In this way, Track, as an important part of the electronic map, will be saved in ATS, ZC and VOBC respectively. However, due to the different data formats within each system, if the boundary value test of each Track and each Track's TSR is carried out during testing, it will take up a lot of manpower, and even if a certain Track is not tested, it will pose a safety risk to the system operation.

[0005] Therefore, a method for data verification between systems in the signal domain is provided. Summary of the invention

[0006] The purpose of the present invention is to overcome the existing defects and provide a data verification method between systems in the signal field, which ensures that when data is transmitted between different systems, it can be verified in real time based on predefined global verification rules.

[0007] The technical solution to achieve the above purpose is:

[0008] A data verification method between systems in the signal field, for cross-system data, using ATS and ZC to cross-validate Track at the interface level, including:

[0009] Step S1, extracting and importing source data, i.e., electronic maps, and performing preliminary data analysis and conversion;

[0010] Step S2, obtaining and parsing the interface document, and matching it with the source data;

[0011] Step S3, obtaining and defining the Track data rules of ATS and ZC respectively, and storing the data rules in the rule base;

[0012] Step S4, performing Track data cross validation;

[0013] Step S5, recording the results of data verification, including successful verification and failed verification. If the verification fails, it will be reported to the data provider.

[0014] Preferably, it also includes:

[0015] Step S6: regularly update and optimize the data rule base according to actual applications and feedback, and maintain the synchronization between the interface document and the rule base.

[0016] Preferably, the step S1 comprises:

[0017] Step S11, extracting source data from ATS and ZC, wherein the data content includes all key elements;

[0018] Step S12, importing the source data into the data verification system for preliminary data analysis and conversion.

[0019] Preferably, the step S2 comprises:

[0020] Step S21, obtaining and parsing the interface document between ATS and ZC;

[0021] Step S22, extracting key interface data requirements from the interface document;

[0022] Step S23, matching the extracted interface data requirements with the imported source data.

[0023] Preferably, in step S21, the interface document includes the Track data format, field requirements and data transmission rules required by the interface.

[0024] Preferably, in step S22, the interface data requirements include but are not limited to data format and valid value range.

[0025] Preferably, in step S3, the data rules include but are not limited to data format rules, logical consistency rules and data integrity rules.

[0026] Preferably, step S4 comprises:

[0027] Step S41, format verification of the interface data, including but not limited to checking whether a certain Track exists and whether the data type is correct;

[0028] Step S42, testing and verifying the integrity of the data interface to verify whether each Track of the electronic map is completely consistent in the ATS and ZC;

[0029] Step S43, verify whether the data in ATS and ZC are consistent in Track during interface transmission.

[0030] Preferably, in step S42, the original electronic map is imported, and the data type is matched according to the interface document to make Track match the internal data format of ATS and ZC respectively, so as to verify whether each Track of the electronic map is completely consistent in ATS and ZC; the verification content includes but is not limited to the range of ID and TSR.

[0031] Preferably, in step S43, the verification process is:

[0032] Traverse the data tracks of the ATS and the data tracks of the ZC and verify that each track has the same configuration in the ZC and the location information is consistent;

[0033] Similarly, traverse the ZC data Track and ATS data one by one to verify that each Track has the same configuration and the same position in ATS;

[0034] Then verify whether the data in ATS and ZC are consistent in the track during interface transmission.

[0035] The beneficial effects of the present invention are:

[0036] The present invention uses a unified verification engine and rule base to avoid verification difficulties caused by inconsistent rules between systems and modules in traditional methods.

[0037] The verification process of the present invention can realize automatic and real-time verification, reduce the need for manual intervention, and improve verification efficiency and accuracy;

[0038] By combining the data rules and interface documents of the two systems, the present invention can ensure that data follows consistent rules during cross-system and cross-module interactions, thereby ensuring data consistency and integrity;

[0039] The present invention can dynamically adjust and expand the verification rule base to adapt to changes in the system and data mode. The dynamic update of the rule base ensures the flexibility and adaptability of the verification mechanism.

[0040] The present invention can handle data formats and interface standards between different systems, so that the data verification process is not limited to specific formats and interface specifications;

[0041] The present invention can realize global verification at the system level, ensure the consistency of data between different systems, and avoid systemic problems that may be caused by omissions in local verification;

[0042] In summary, the present invention has obvious advantages in improving the consistency, real-time performance, automation and flexibility of data verification, can effectively solve the problems in cross-system data verification, and improve the overall efficiency of data processing and system integration. BRIEF DESCRIPTION OF THE DRAWINGS

[0043] Figure 1 It is a flow chart of a method for data verification between systems in the signal field of the present invention;

[0044] Figure 2 It is a specific flow chart of extracting and importing source data, i.e., electronic maps, and performing preliminary data analysis and conversion in the present invention;

[0045] Figure 3 It is a specific flow chart of acquiring and parsing the interface document and matching it with the source data in the present invention;

[0046] Figure 4 It is a specific flow chart of executing Track data cross-validation in the present invention. DETAILED DESCRIPTION

[0047] The technical solution of the present invention will be described clearly and completely below in conjunction with the accompanying drawings. In the description of the present invention, it should be noted that the terms "center", "up", "down", "left", "right", "vertical", "horizontal", "inside", "outside" and the like indicate directions or positional relationships based on the directions or positional relationships shown in the accompanying drawings, which are only for the convenience of describing the present invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific direction, be constructed and operated in a specific direction, and therefore cannot be understood as a limitation on the present invention. In addition, the terms "first", "second", and "third" are used for descriptive purposes only and cannot be understood as indicating or implying relative importance.

[0048] The present invention will be further described below in conjunction with the accompanying drawings.

[0049] The data source across systems is the same electronic map, but each system uses a different data format. Data transmission is achieved between systems through interfaces. Taking ATS and trackside ZC as an example, TRACK is used to set temporary speed limits between ATS and ZC. Although ATS and ZC are from the same electronic map, the definition formats between the two systems are different. The traditional test method is to test TRACK in an interface manner through system integration testing. In this solution, the interface document is used as the middle layer, combined with the different internal data formats of ATS and ZC. The specific steps are as follows:

[0050] like Figure 1 As shown, a data verification method between systems in the signal field includes:

[0051] Step S1, extract and import source data, namely electronic map, and perform preliminary data analysis and conversion.

[0052] like Figure 2 As shown, step S1 includes:

[0053] Step S11, extracting source data from ATS and ZC, wherein the data content includes all key elements, such as Track, station, traffic light, etc.

[0054] Step S12, importing the source data into the data verification system for preliminary data analysis and conversion to ensure the integrity and consistency of the data.

[0055] Step S2, obtain and parse the interface document, and match it with the source data.

[0056] like Figure 3 As shown, step S2 includes:

[0057] Step S21, obtaining and parsing the interface document between ATS and ZC.

[0058] In the embodiment, the interface document includes the Track data format, field requirements, and data transmission rules required by the interface.

[0059] Step S22, extracting key interface data requirements from the interface document.

[0060] In the embodiment, the interface data requirements include but are not limited to data format and valid value range.

[0061] Step S23, matching the extracted interface data requirements with the imported source data to ensure that the data complies with the standards of the interface document.

[0062] Step S3, obtain and define the Track data rules of ATS and ZC respectively, and store the data rules in the rule library to provide a basis for subsequent data verification.

[0063] In the embodiment, the data rules include but are not limited to data format rules, logical consistency rules and data integrity rules.

[0064] Step S4, performing Track data cross-validation.

[0065] like Figure 4 As shown, step S4 includes:

[0066] Step S41, performing format verification on the interface data, including but not limited to checking whether a certain Track exists and whether the data type is correct.

[0067] Step S42, testing and verifying the integrity of the data interface to verify whether each Track of the electronic map is completely consistent in the ATS and ZC.

[0068] In the embodiment, the original electronic map is imported, and the data type is matched according to the interface document to make Track match the internal data format of ATS and ZC respectively, so as to verify whether each Track of the electronic map is completely consistent in ATS and ZC; the verification content includes but is not limited to the range of ID and TSR.

[0069] Step S43, verify whether the data in ATS and ZC are consistent in Track during interface transmission.

[0070] In the embodiment, the verification process is:

[0071] Traverse the data tracks of the ATS and the data tracks of the ZC and verify that each track has the same configuration in the ZC and the location information is consistent;

[0072] Similarly, traverse the ZC data Track and ATS data one by one to verify that each Track has the same configuration and the same position in ATS;

[0073] Then verify whether the data in ATS and ZC are consistent in the track during interface transmission.

[0074] Step S5, recording the results of data verification, including successful verification and failed verification. If the verification fails, it will be reported to the data provider.

[0075] Step S6, based on actual applications and feedback, regularly update and optimize the data rule library to ensure that the validation rules can adapt to system changes and new data requirements, such as updates to electronic maps, new fields added to the interface, etc., and maintain the synchronization of the interface documents and the rule library to ensure that changes in the interface documents can be reflected in the validation rules in a timely manner.

[0076] The present invention includes the whole process from source data import, interface document parsing, data rule definition, data verification execution to processing verification results, updating rules and system optimization. Through these steps, it can ensure that the data remains consistent and correct during the interaction between different systems, reducing the risk of data errors.

[0077] The above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit the same. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that the technical solutions described in the above embodiments may still be modified, or some or all of the technical features may be replaced by equivalents. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for data verification between systems in the signal field, characterized in that: Cross-system data is cross-validated with ATS and ZC at the interface level, including: Step S1, extracting and importing source data, i.e., electronic maps, and performing preliminary data analysis and conversion; Step S2, obtaining and parsing the interface document, and matching it with the source data; Step S3, obtaining and defining the Track data rules of ATS and ZC respectively, and storing the data rules in the rule base; Step S4, performing Track data cross validation; Step S5, recording the results of data verification, including successful verification and failed verification. If the verification fails, it will be reported to the data provider.

2. A method for data verification between systems in the signal field according to claim 1, characterized in that: Also includes: Step S6: regularly update and optimize the data rule base according to actual applications and feedback, and maintain the synchronization between the interface document and the rule base.

3. A method for data verification between systems in the signal field according to claim 1, characterized in that: The step S1 comprises: Step S11, extracting source data from ATS and ZC, wherein the data content includes all key elements; Step S12, importing the source data into the data verification system for preliminary data analysis and conversion.

4. A method for data verification between systems in the signal field according to claim 1, characterized in that: The step S2 comprises: Step S21, obtaining and parsing the interface document between ATS and ZC; Step S22, extracting key interface data requirements from the interface document; Step S23, matching the extracted interface data requirements with the imported source data.

5. A method for data verification between systems in the signal field according to claim 4, characterized in that: In step S21, the interface document includes the Track data format, field requirements and data transmission rules required by the interface.

6. A method for data verification between systems in the signal field according to claim 4, characterized in that: In step S22, the interface data requirements include but are not limited to data format and valid value range.

7. A method for data verification between systems in the signal field according to claim 1, characterized in that: In step S3, the data rules include but are not limited to data format rules, logical consistency rules and data integrity rules.

8. A method for data verification between systems in the signal field according to claim 1, characterized in that: The step S4 comprises: Step S41, format verification of the interface data, including but not limited to checking whether a certain Track exists and whether the data type is correct; Step S42, testing and verifying the integrity of the data interface to verify whether each Track of the electronic map is completely consistent in the ATS and ZC; Step S43, verify whether the data in ATS and ZC are consistent in Track during interface transmission.

9. A method for data verification between systems in the signal field according to claim 8, characterized in that: In step S42, the original electronic map is imported, and the data type is matched according to the interface document to make Track match the internal data format of ATS and ZC respectively, so as to verify whether each Track of the electronic map is completely consistent in ATS and ZC; the verification content includes but is not limited to the range of ID and TSR.

10. A method for data verification between systems in the signal field according to claim 8, characterized in that: In step S43, the verification process is: Traverse the data tracks of the ATS and the data tracks of the ZC and verify that each track has the same configuration in the ZC and the location information is consistent; Similarly, traverse the ZC data Track and ATS data one by one to verify that each Track has the same configuration and the same position in ATS; Then verify whether the data in ATS and ZC are consistent in the track during interface transmission.

Images