CN117725030A - Verification method, device and medium for XML data of TACS system - Google Patents

Abstract

The invention relates to a verification method, equipment and medium of XML data of a TACS system, wherein the method comprises the following steps: compiling a parameter architecture file XSD; loading a parameter architecture file XSD into a tool, and reading the XSD information and checking with checked TACS system XML data by the tool; configuring a verification rule of the TACS system XML data in a configuration folder of the tool; using a tool to load a configured check rule document, and after the tool reads the check rule, executing compliance check on the XML data of the TACS system: and generating a verification result report. Compared with the prior art, the invention has the advantages of improving the data verification efficiency, high verification accuracy and the like.

Description

Verification method, device and medium for XML data of TACS system

Technical Field

The invention relates to a train signal control system, in particular to a verification method, equipment and medium of XML data of a TACS system.

Background

TACS system, full name Train Autonomous Circumambulate System, chinese name train autonomous operation system based on train-to-train communication. The system achieves the aims of safer, more efficient and more economical in a mode of interlocking vehicles and ground and cooperative vehicles.

Compared with the existing CBTC system data, the TACS system data XML has the following characteristics:

1. the data size is larger: one database of CBTC system data becomes four packets of TACS system data, and each packet may contain one or more databases. The addition of the database causes the system data producer to process more data, thereby increasing the workload;

2. the relevance of the data is stronger: in TACS system data, parameters have strong correlation with each other, and the correlated parameters are embodied in the form of id. Because id does not have good readability, data producer can't be fast and accurately positioned to the equipment that id is associated with, has increased the data preparation degree of difficulty. And once the association error occurs, the subsequent data compiling is failed;

3. the fault tolerance of the data is lower: the system data needs to ensure that the production of each piece of data is completely accurate, any error is not allowed to occur, and even if a space exists in the data, the subsequent data compiling can fail, and reworking is caused.

CN116303231a discloses a method, device and medium for verifying data of TACS system of urban rail transit, the method comprises the following steps: step S101, a system database is exported, and the system database in an XML format is converted into an Excel table; step S102, editing the header of an Excel table; step S103, verifying the consistency of the system data value and the design value; step S104, verifying whether the system data format meets the system data rule requirement; step S105, verifying whether the data content is consistent with the change requirement; step S106, checking whether the verification report content is missing, and signing the verification report after confirming that the verification report content is not wrong. However, the method is to convert XML data into an Excel table for verification, and not directly verify the XML data.

Disclosure of Invention

The invention aims to overcome the defects of the prior art and provide a verification method, equipment and medium for XML data of a TACS system, which realize automatic verification of errors, inconsistencies and the like in the system data by a tool, provide a difference report for system data producer, reduce the workload of manually checking the data, save the time of checking and verifying, and improve the accuracy of the data.

The aim of the invention can be achieved by the following technical scheme:

according to a first aspect of the present invention, there is provided a method for verifying XML data of a TACS system by a tool, wherein the accuracy, consistency and compliance of the XML data of the TACS system are verified based on a parameter architecture file, and the compliance is verified based on a verification rule configured in the tool.

As a preferred technical solution, the method comprises the following steps:

s1, compiling a parameter architecture file XSD;

s2, loading the parameter architecture file XSD into a tool, and reading the XSD information and checking with checked TACS system XML data by the tool;

s3, configuring a verification rule of the XML data of the TACS system in a configuration folder of the tool;

s4, loading the configured check rule document by using a tool, and executing compliance check on the XML data of the TACS system after the tool reads the check rule:

s5, generating a verification result report.

As an preferable technical scheme, the TACS system XML data includes physical element nodes and logical element nodes, wherein parameters related to the trackside equipment are included under the physical element nodes, parameters of the virtual equipment or the virtual area are included under the logical element nodes, and data producer configures required parameter values under two types of nodes according to the requirement of the project.

As an preferable technical scheme, the parameters under the physical element nodes comprise topological structure parameters of stations, platforms and tracks.

As an optimal technical scheme, the parameters under the logic element nodes comprise parameters of a speed limit area, a train stopping point and a protection area.

As an optimal technical scheme, the parameter architecture file XSD comprises parameter names, parameter value ranges, parameter descriptions, parameter paths and data versions which are required to be used for manufacturing the XML data of the TACS system.

In the step S2, the tool reads XSD information and checks the XSD information with the checked TACS system XML data specifically: the tool checks XML data according to the information in the XSD, checks whether the parameter has error definition or missing definition, and whether the parameter value meets the value range requirement, so that the parameter accuracy and consistency check is realized.

As a preferred technical solution, the verification rule includes:

checking and verifying whether illegal characters exist in the XML data;

checking the uniqueness of the id and name in the verification data for the same data table;

checking that all ids containing parameter reference value association in the verification data are defined in the XML data;

checking and verifying whether all the starting end kilometer post values defined by parameters including the kilometer post are smaller than the terminal end kilometer post value;

checking and verifying whether kilometer post values of related parameters are in a track range;

checking and verifying whether each parking point is associated with a relevant parameter;

checking and verifying whether the kilometer post of the parking spot is in a platform or a parking line;

only one piece of WTC data is defined in the checking and verifying database;

checking that at least one piece of curvature data is defined in the verification database;

checking the WRC area full coverage defined in the verification data table;

the check verifies that the area range defined by the unprotected supervisor area data table does not exist in the WRC area range.

In the step S4, as an preferable technical solution, the compliance verification is specifically performed on the XML data of the TACS system:

traversing physical element nodes in XML by a tool, checking all parameter values and rules under the nodes, and checking whether the parameter values meet the requirements of the check rules;

and then, traversing logical element nodes in the XML by the tool, checking all parameter values and rules in the nodes, and checking whether the parameter values meet the requirements of the checking rules.

As a preferable technical solution, the step S5 specifically includes: automatically generating a verification result report according to the verification results of the step S2 and the step S4, and listing all the verification results one by one in the report, wherein if the verification results are consistent with the XSD and the verification rules, the verification passing information is output in the report; otherwise, error information is detailed in the report.

According to a second aspect of the present invention there is provided an electronic device comprising a memory and a processor, the memory having stored thereon a computer program, the processor implementing the method when executing the program.

According to a third aspect of the present invention, there is provided a computer readable storage medium having stored thereon a computer program which when executed by a processor implements the method.

Compared with the prior art, the invention has the following beneficial effects:

1. the invention can automatically check the XML data by setting the XSD and the check rule, can reduce the labor expenditure of the XML check of the system data, reduce the data check time and improve the XML check efficiency of the system data.

2. The invention can generate a detailed check result report, and is convenient for data producer to check the data production result.

3. The invention improves the accuracy of the system data XML verification and eliminates the condition of missed detection and false detection existing in the manual verification.

Drawings

FIG. 1 is a flow chart of the method of the present invention;

FIG. 2 is a schematic diagram of the physical element node parameters of the XML data of the TACS system in one embodiment;

FIG. 3 is a schematic diagram of node parameters of XML data logical elements of a TACS system in one embodiment.

Detailed Description

The following description of the embodiments of the present invention will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are some, but not all embodiments of the invention. All other embodiments, which can be made by those skilled in the art based on the embodiments of the present invention without making any inventive effort, shall fall within the scope of the present invention.

The embodiment provides a verification method for XML data of a TACS system, wherein a data producer can verify the accuracy, consistency and compliance of the XML data of the TACS system through a tool, the accuracy and the consistency of the XML data are verified based on a parameter architecture file, and the compliance is verified based on a verification rule configured in the tool.

Specifically, as shown in fig. 1, the method comprises the following steps:

s1, compiling a detailed parameter architecture file XSD, namely a TACS system data parameter specification, wherein the XSD file contains information such as parameter names, parameter value ranges, parameter descriptions, parameter paths, data versions and the like required for manufacturing system data XML.

S2, after S1 is completed, loading the XSD into the tool, and after loading is completed, using a checking function of the tool, the tool performs mutual checking by reading the XSD information and the checked XML database, and the tool can check that the parameter information defined by the XML database and the XSD is inconsistent and inaccurate, for example, whether the parameter has incorrect definition or missing definition, whether the parameter value meets the value range requirement, and the like.

S3, configuring a verification rule of the system data in a configuration folder of the tool, and defining association relations, limits and the like of the system data parameters in the verification rule file.

The validation rules may be configured according to the form of the XML data and the stored content.

S4, loading a configuration rule document by using a tool after the configuration work of S3 is completed, and executing data compliance verification on the system data XML database after the tool reads the configuration rule:

s5, generating a verification result report. After completing S1 through S4, the tool may automatically generate a verification result report. All check results are listed one by one in the report. If the verification result is consistent with the XSD and the configuration rule, outputting verification passing information in a report; if the verification result has problems, error information is detailed in the report, so that a user can conveniently check the data verification result and modify the system data.

Before the data verification is performed by using the method, there is first a system data XML to be verified. Referring to fig. 2 and 3, the system data XML configured parameter node information is shown in one embodiment. Physical elements (physical elements) nodes contain parameters related to trackside equipment, such as stations, platforms, topology structures of tracks, and the like. The logical element (logicalElements) node contains parameters of virtual equipment or virtual area, such as speed limit area, train stopping point, protection area, etc. And the system data producer configures the required parameter values under the physical element and the logicalElement nodes according to the requirements of the project.

According to fig. 2, three tables are contained under the physical elements (physical elements) node: track groups, track, equipmentElements.

The track combination table includes a station data table (station), and the station data table stores station id (serial number), name, shortName, assocityplatformref (station associated station) information.

Track data table stores track id (serial number), name (name), main dir (track direction), track topology (track topology), ocsElements (controller), track elements (track civil engineering) information.

The equality elements data table includes MSSServer (MSS server) data table, atsep (ATS server) data table, WTC (trackside train controller) data table, WRC (trackside resource controller) data table, smioculicles (input output matrix) data table, OMAP (maintenance tool) data table, localPointController) data table.

MSSServer data table stores id (sequence number), name, WRCRefs (managed trackside resource controller) information;

the ATSFEP data table stores id (sequence number), name (name), WRCRefs (managed trackside resource controller), notProtectedSupervisodZoneRefs (managed non-protected supervision region) information;

the WTC data table stores id (sequence number), name (name), WRCRefs (managed trackside resource manager), notprotected supervisedzonerefs (managed non-protected supervision area) information;

the WRC data table stores id (sequence number), name (name), WRC overlay Zones (area covered by the trackside resource manager), associtySMITsRefs (associated input/output) information;

SMIOCUBICICs data sheet stores id (sequence number), name (name), SMIO information;

OMAP data table stores id (serial number), name (name) information;

the localPointController data table stores id (serial number), name, managedSwitchRefs (managed switch) information.

According to fig. 3, the logicalelements node includes a protectionZones data table, a clearingzones data table, a PSRZone data table, a stoppoint data table, a tsrstatiiczones data table, a consignable zones data table, a WTOZs data table, an automatic sweepzones data table, a notprotectedsupervisetrefs data table.

The protectionZones data table stores id (serial number), name (name), type (type), actuatorRefs (associated buttons), zones (area scope) information;

clearblezones data table stores id (sequence number), name (name), type (type), WRCRef (WRC area where it is located), actuatorRefs (associated buttons), zones (area scope) information;

the PSRZones data table stores id (serial number), name (name), PSRValue (speed limit value), orintedZones (speed limit area direction), type (type), and train Format Characies Refs (associated train type) information;

the stopingpoints data table stores id (serial number), name (name), direction (direction), position (location), tralnformationchacterics refs (associated train type), platformRef (station in which the station is located), stablingRef (line of storage in which the station is located) information;

TSRStaticZones data table stores id (sequence number), name, zones (area range) information;

ConsignableZones data sheet stores id (sequence number), name, zones (area scope) information;

the WTOZs data table stores id (serial number), name (name), zones (regional scope) information;

automation switches data table stores id (sequence number), name (name), boundaryswitch refs (associated boundary switch) information;

the notProtectedSupervisedZones data table stores id (sequence number), name, zones information.

After the system data XML parameters are configured, a data producer loads the completed XML database by using a tool, and the tool automatically checks the consistency between XML and XSD by reading the database. As in fig. 3, assume that a data node is configured: the system data producer configures the lower-case 'S' into the upper-case 'S' by mistake in the process of data production according to the defined data specification, and the tool can recognize the error through the verification of XML and XSD after reading the system data XML and outputs the error result to the verification log. And the data personnel quickly locate to the error point according to the error description in the check log, and then carry out XML modification on the system data. And after the modification is completed, the tool is reused to check the consistency of the XML and the XSD until all check results are completely consistent.

And then, checking the consistency of the system data XML and the configured check rule, namely, performing compliance check. In the configuration rule file, data verification rules are predefined.

Specifically, according to the parameter definitions of fig. 2 and 3, the verification rule configured in the present embodiment includes:

1) Checking and verifying whether illegal characters such as space, punctuation marks and the like exist in the XML database;

2) Checking the uniqueness of the id and name in the verification data for the same data table;

3) Checking that all ids containing the association of the parameter Ref in the verification data are defined in an XML database;

4) Checking and verifying whether all the starting end kilometer post values defined by parameters including the kilometer post are smaller than the terminal end kilometer post value;

5) A check verifies whether kilometer post values for the following parameters are in track range: switch, annunciator, button, beacon, grade range, curvature range, platform, storage line, "boundary" (boundary point);

6) Checking verifies that "ids" (ids of connections of current tracks) and "ref ids" (ids of connections of tracks associated with the current tracks) of "connections" (data defining inter-track interconnections) in a "track" table (track data table) are mutually referenced;

7) Checking verifies that each parking spot has associated with it the parameter "stabingRef" (stock line reference id) or "platformRef" (station reference id) or "boundaryRef" (boundary reference id);

8) Checking and verifying whether the kilometer post of the parking spot is in a platform or a parking line;

9) Only one piece of WTC (trackside train controller) data is defined in the checking and verifying database;

10 Checking that at least one piece of curvature data is defined in the verification database;

11 Checking and verifying the complete coverage of the WRC area defined by the data tables MSSServer, WTC and ATSFEP, wherein the MSSServer data table defines the information of the maintenance server, and comprises the id, the name and the managed WRC area of the server; the WTC data table defines the data of the trackside train controller, and comprises the id, the name, the managed WRC area and the managed train number of the WTC; the ATSFEP data table defines ATS server data, including the id, name and managed WRC area of the server;

12 Checking that the area range defined by the verification data table "notprotected supervisedzone" does not exist in the WRC area range, wherein the notprotected supervisedzone represents a non-protected supervision area, the data table being used to define a non-system-managed area;

when the tool performs compliance verification, firstly, traversing the physical elements data nodes in XML by the tool, verifying all parameter values and rules under the nodes, and checking whether the parameter values meet the requirements of configuration rules; then, the tool traverses the logicalElements data node in XML, checks all parameter values and rules in the node, and checks whether the parameter values meet the requirements of configuration rules.

In one embodiment, assume that a data producer configures a plurality of region parameter information under logicalElements according to the system data structures of fig. 2 and 3: protective zones, clearblezones, PSRZones, etc. Among these area parameters, each area parameter contains area start and end information, and the area start and end information is composed of a track id and a kilometer post. After the tool acquires the track id and kilometer post information of the area, the tool performs checking and checking with a trackBegin and a trackEnd in the physical elements. And if the checked area is in the range between the beginning end and the end of the track, checking. If the verified area range is not between the beginning and the end of the track, the tool outputs an error to the verification log. The data producer modifies the system data according to the log description. After the modification is completed, the database and the configuration rule are checked again until all check results meet the rule requirements.

The electronic device of the present invention includes a Central Processing Unit (CPU) that can perform various appropriate actions and processes according to computer program instructions stored in a Read Only Memory (ROM) or computer program instructions loaded from a storage unit into a Random Access Memory (RAM). In the RAM, various programs and data required for the operation of the device can also be stored. The CPU, ROM and RAM are connected to each other by a bus. An input/output (I/O) interface is also connected to the bus.

A plurality of components in a device are connected to an I/O interface, comprising: an input unit such as a keyboard, a mouse, etc.; an output unit such as various types of displays, speakers, and the like; a storage unit such as a magnetic disk, an optical disk, or the like; and communication units such as network cards, modems, wireless communication transceivers, and the like. The communication unit allows the device to exchange information/data with other devices via a computer network, such as the internet, and/or various telecommunication networks.

The processing unit performs the respective methods and processes described above, for example, the methods S1 to S5. For example, in some embodiments, methods S1-S5 may be implemented as a computer software program tangibly embodied on a machine-readable medium, such as a storage unit. In some embodiments, part or all of the computer program may be loaded and/or installed onto the device via the ROM and/or the communication unit. When the computer program is loaded into RAM and executed by the CPU, one or more steps of the methods S1 to S5 described above may be performed. Alternatively, in other embodiments, the CPU may be configured to perform methods S1-S5 in any other suitable manner (e.g., by means of firmware).

The functions described above herein may be performed, at least in part, by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: a Field Programmable Gate Array (FPGA), an Application Specific Integrated Circuit (ASIC), an Application Specific Standard Product (ASSP), a system on a chip (SOC), a Complex Programmable Logic Device (CPLD), and the like.

Program code for carrying out methods of the present invention may be written in any combination of one or more programming languages. These program code may be provided to a processor or controller of a general purpose computer, special purpose computer, or other programmable data processing apparatus such that the program code, when executed by the processor or controller, causes the functions/operations specified in the flowchart and/or block diagram to be implemented. The program code may execute entirely on the machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of the present invention, a machine-readable medium may be a tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. The machine-readable medium may be a machine-readable signal medium or a machine-readable storage medium. The machine-readable medium may include, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a machine-readable storage medium would include an electrical connection based on one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

While the invention has been described with reference to certain preferred embodiments, it will be understood by those skilled in the art that various changes and substitutions of equivalents may be made and equivalents will be apparent to those skilled in the art without departing from the scope of the invention. Therefore, the protection scope of the invention is subject to the protection scope of the claims.

Claims (12)

1. The method is characterized in that the accuracy, the consistency and the compliance of the XML data of the TACS system are checked through a tool, wherein the accuracy and the consistency of the XML data are checked based on a parameter architecture file, and the compliance is checked based on a check rule configured in the tool.

2. The method for verifying XML data of TACS system according to claim 1, wherein said method comprises the steps of:

s1, compiling a parameter architecture file XSD;

s2, loading the parameter architecture file XSD into a tool, and reading the XSD information and checking with checked TACS system XML data by the tool;

s3, configuring a verification rule of the XML data of the TACS system in a configuration folder of the tool;

s4, loading the configured check rule document by using a tool, and executing compliance check on the XML data of the TACS system after the tool reads the check rule:

s5, generating a verification result report.

3. The method for verifying the TACS system XML data according to claim 2, wherein the TACS system XML data includes physical element nodes and logical element nodes, parameters related to the trackside equipment are included under the physical element nodes, parameters of the virtual equipment or the virtual area are included under the logical element nodes, and data producer configures required parameter values under the two types of nodes according to the requirement of the project.

4. A method for verifying XML data of TACS system according to claim 3, wherein said parameters under physical element nodes include topology parameters of stations, platforms and tracks.

5. A method for verifying XML data of TACS system according to claim 3, wherein said parameters under the nodes of the logic element include parameters of speed limit area, train stop point, and protection area.

6. The method for verifying the XML data of the TACS system according to claim 2, wherein said parameter architecture file XSD includes a parameter name, a parameter value range, a parameter description, a parameter path and a data version which are required for producing the XML data of the TACS system.

7. The method for verifying TACS system XML data according to claim 2, wherein in step S2, the tool reads XSD information and verifies the XSD information with the verified TACS system XML data specifically: the tool checks XML data according to the information in the XSD, checks whether the parameter has error definition or missing definition, and whether the parameter value meets the value range requirement, so that the parameter accuracy and consistency check is realized.

8. The method for verifying XML data of TACS system according to claim 2, wherein said verification rule comprises:

checking and verifying whether illegal characters exist in the XML data;

checking the uniqueness of the id and name in the verification data for the same data table;

checking that all ids containing parameter reference value association in the verification data are defined in the XML data;

checking and verifying whether all the starting end kilometer post values defined by parameters including the kilometer post are smaller than the terminal end kilometer post value;

checking and verifying whether kilometer post values of related parameters are in a track range;

checking and verifying whether each parking point is associated with a relevant parameter;

checking and verifying whether the kilometer post of the parking spot is in a platform or a parking line;

only one piece of WTC data is defined in the checking and verifying database;

checking that at least one piece of curvature data is defined in the verification database;

checking the WRC area full coverage defined in the verification data table;

the check verifies that the area range defined by the unprotected supervisor area data table does not exist in the WRC area range.

9. A method for verifying XML data of TACS system according to claim 3, wherein in step S4, the compliance verification is performed on the XML data of TACS system specifically:

traversing physical element nodes in XML by a tool, checking all parameter values and rules under the nodes, and checking whether the parameter values meet the requirements of the check rules;

and then, traversing logical element nodes in the XML by the tool, checking all parameter values and rules in the nodes, and checking whether the parameter values meet the requirements of the checking rules.

10. The method for verifying XML data of TACS system according to claim 1, wherein said step S5 is specifically: automatically generating a verification result report according to the verification results of the step S2 and the step S4, and listing all the verification results one by one in the report, wherein if the verification results are consistent with the XSD and the verification rules, the verification passing information is output in the report; otherwise, error information is detailed in the report.

11. An electronic device comprising a memory and a processor, the memory having stored thereon a computer program, characterized in that the processor, when executing the program, implements the method of any of claims 1-10.

12. A computer readable storage medium, on which a computer program is stored, characterized in that the program, when being executed by a processor, implements the method according to any one of claims 1-10.