A System Model Construction Method for Formal Verification of Interlocking Software

Abstract

The present invention discloses a method for constructing a system model for formal verification of interlocking software, which relates to the technical field of computer interlocking systems. The present invention uses two translators with the same function developed by adopting different programming methods and programming languages to read interlocking input data; and performs consistency verification on the data files in a specific format output by the two translators with the same function through a file comparison tool; develops a system model construction tool by means of programming methods, and uses the system model construction tool to read the specific format files that have been converted by the translator and passed the consistency verification in step S1, and constructs a system model according to the specific format files. The present invention starts from the perspective of signal personnel, focuses on describing the construction of the system model at the interlocking data level and its mapping relationship with the object model. The system model construction method described in the present invention provides an idea for signal personnel on how to construct a system model based on existing interlocking data.

Description

Technical Field

[0001] The present invention relates to the technical field of computer interlocking systems, and more specifically, to a method for constructing a system model for formal verification of interlocking software. Background Art

[0002] The computer interlocking system is a complex safety-critical system for ensuring train operation safety. It is very necessary to effectively analyze, verify, and test the interlocking system. The formal method, with its rigorous mathematical theory and precise semantic definition characteristics, has been favored by many safety-related industries.

[0003] With the application of the formal method in the railway system, the introduction of formal verification in the interlocking system has also become an inevitable trend. Constructing a formal system model of the computer interlocking system is the basis for formal development, verification, and testing of interlocking software. The accuracy of the model will directly affect the results of formal verification and testing. Therefore, how to construct a system model for formal verification of interlocking software becomes particularly important.

[0004] Most of the existing formal modeling methods directly start modeling from the formal field, that is, using formal methods and mathematical theory models. This method starts from basic mathematical theories, which is difficult for railway signal personnel to understand and apply. On the other hand, most of the current modeling systems focus on the object model level and system requirements level, and rarely construct a system model for the interlocking data level. Summary of the Invention

[0005] In order to overcome the defects and deficiencies existing in the above-mentioned prior art, the present invention provides a method for constructing a system model for formal verification of interlocking software. The object of the present invention is to construct a system model from the interlocking data level, and solve the problem that it is difficult for railway signal personnel to understand and apply starting from basic mathematical theories in the prior art. Starting from the perspective of signal personnel, the present invention focuses on describing the construction of the system model at the interlocking data level and its mapping relationship with the object model. The system model construction method described in the present invention provides an idea for signal personnel on how to construct a system model based on existing interlocking data.

[0006] In order to solve the problems existing in the above-mentioned prior art, the present invention is implemented through the following technical solutions.

[0007] The present invention provides a method for constructing a system model for formal verification of interlocking software, and the construction method includes the following steps:

[0008] S1. Two translators with the same function developed using different programming methods and programming languages read the interlocking input data; the interlocking input data includes a station yard topology structure file, a TAB table file, and a Boolean logic file; the two translators with the same function convert the interlocking input data into data files in a specific format, and a file comparison tool performs consistency verification on the data files in the specific format output by the two translators with the same function.

[0009] S2. Develop a system model construction tool using a programming method, and use this system model construction tool to read the specific format files that have been converted by the translator and passed the consistency verification in step S1, and construct a system model based on the specific format files.

[0010] S3. Construct a station yard topology model based on the specific format file converted from the station yard topology structure file:

[0011] S301. Create a directed graph structure composed of nodes and edges. According to the device connection relationship in the specific format file converted from the station yard topology structure file, each device is occupied by a node of the same type, and each node defines its id and node type to form a node module.

[0012] S302. Connect the nodes into a graph structure through edges, and define the connection relationship between nodes in pairs into the edge module.

[0013] S303. Store the station yard device objects in the corresponding nodes to form an object module, and the object module generates the node id of the node where each device object is located.

[0014] S304. Generate a route module according to the route table information in the specific format file converted from the station yard topology structure file.

[0015] S305. Generate a region module according to the device information within the station yard map area.

[0016] The node module, edge module, object module, route module, and region module constitute a complete station yard topology model.

[0017] S4. Construct an object relationship model based on the specific format file converted from the TAB table file:

[0018] S401. Define a first-level table according to the sub-tables in the specific format file converted from the TAB table file. At the same time, define the signal device sub-table and the route table in the specific format file converted from the station yard topology structure file according to the first-level table; the sub-tables defined according to the first-level table include all columns of the corresponding sub-tables in the specific format file.

[0019] S402. Define a secondary table based on the relationships in the object model for formal verification; establish a mapping relationship between the secondary table and the object relationships, and trace the relationships of the object model into the secondary table; generate an object relationship model for formal verification.

[0020] S5. Construct a Boolean variable model based on the specific format file after converting the Boolean logic file. Specifically, based on the object variables in the object model for formal verification, manually configure a variable relationship mapping file to establish a one-to-one mapping between the object variables and the actual Boolean variables in the specific format file after converting the Boolean logic file; generate a Boolean variable model for formal verification.

[0021] Furthermore, in step S1, the station yard topological structure file in the interlocking input data includes the equipment types, equipment names, directions, coordinates, topological connection relationships between equipment in the station yard diagram, and the route information in the station yard diagram; the equipment or objects involved in the station yard topological structure file include signal lights, switches, buttons, indication lights, sections, checkpoints, and route table information.

[0022] Furthermore, in step S1, the TAB table file in the interlocking input data includes a station interlocking information table and an interface information table file; the station interlocking information table is used to define the interlocking relationships between the key signal equipment attributes, route information table, and signal equipment logic attributes within the station; the interface information table defines the interface information between the interlocking and other external systems, including the interlocking and adjacent station interlocking interface information table, the interlocking and train control center interface information table, and the interlocking and radio block center interface information table.

[0023] Furthermore, in step S1, the Boolean logic file in the interlocking input data defines equipment input variables, output variables, general variables, time variables, self-holding variables, and defines the Boolean operation equations of the variables, where the types of the variables are all of BOOL type.

[0024] Furthermore, in step S301, the node module is a container for storing station yard equipment objects. According to the equipment characteristics in the station yard diagram, four types of nodes are defined, namely single-sided nodes, double-sided nodes, three-sided nodes, and four-sided nodes; the node module defines the node identification number and the number of extended edges, and the attributes of its movement path are defined in each type of node.

[0025] Even further, in step S302, the edge module is used to store the connection relationships of the nodes. In each edge module, the numbers of two adjacent nodes are generated, and the id defined on the extended edges where the two nodes are connected is generated. Through the connection of the edges, the nodes are strung together into a graph structure.

[0026] Further, in step S303, the object module is used to define device objects stored in nodes, and these objects are obtained from a specific format file converted from the station yard topology structure file. The object module defines object identification numbers, corresponding user types, node numbers where they are located, and specific attribute information.

[0027] Further, in step S304, the route module stores route information in the station yard diagram. The route module defines route identification numbers, route types, starting nodes, and route paths.

[0028] Further, in step S305, the area in the area module refers to a device set composed of multiple nodes and edges, sections, double - acting turnouts, and crossover switches included in the area in the station yard diagram; the area module defines area identification numbers, area types, and the set of nodes and edges that make up the area.

[0029] Further, in step S4, the tables directly translated from the sub - tables of the interlocking information table and the external system interface table, as well as the device sub - table and the route table in the station yard topology structure file are defined as first - level tables, and the tables generated after calculation according to the table method from the first - level tables are defined as second - level tables.

[0030] Further, in step S5, according to the keywords in the specific format file converted from the Boolean logic file, INPUT, OUTPUT, TIMER timers, and Boolean equations are identified from it. When constructing the Boolean variable model, a mapping relationship between the variable names in the object model and the variable names in this specific format file is established to perform a one - to - one mapping of the attributes of physical devices to the logical variables in the interlocking data.

[0031] Compared with the prior art, the beneficial technical effects brought by the present invention are as follows:

[0032] 1. Relying on the interlocking data output from the project as the input file for constructing the verification system model saves the time cost and labor cost of making additional formalized data; the system model is used to establish the mapping relationship between the object model and the interlocking data, laying a data foundation for the formal verification of safety requirements and ensuring the relative stability of the object model and safety requirements.

[0033] 2. The present invention establishes a system model starting from three aspects: the station yard topology file, the interlocking information table and the interface information table, and the internal Boolean logic file of the interlocking. Each system model has relative independence. When any one of the models changes, it will not affect the other models, which is convenient for upgrading and maintenance during the project application process.

[0034] 3. The system model constructed by the present invention has universality. When meeting the interlocking data and input file format proposed by the present invention, it can be applied to the system model in the present invention, and the system model is not limited by the project scale and the station yard structure of the project.

[0035] 4. In the present invention, the basis for dividing node types is the number of expandable edges of the yard equipment, that is, the number of adjacent nodes that can be traversed outward from this node in the topology. For the signal machines and track sections at the end of the yard, only one end needs to be connected to other equipment, and they are set as single-sided nodes; for the signal machines and track sections in the yard that are not at the boundary, the edges can be expanded bidirectionally and are designed as double-sided nodes; for turnout equipment, three edges can be expanded outward and are designed as three-sided nodes; for crossover turnouts, four turnout points can be expanded outward and are designed as four-sided nodes. Edges in different directions are distinguished by the id defined on the edge. The described nodes and yard equipment objects can have a one-to-one or one-to-many relationship.

[0036] 5. In the present invention, the equipment relationship parameters of the object model are essentially a dictionary structure composed of a set of key-value pairs, and a set of key-value pair relationships corresponds to a secondary table. The key-value pair uses @ to separate the "key" and the "value". Before the @ symbol is considered as the "key", and after the @ is considered as the "value". The object set is stored in the form of keys and values. In the security requirement model, "key.value" is directly used to represent the relationship, such as route.start_signal indicating the start signal of this route. By using the table calculation rules to construct the table model, the conversion from the primary table to the secondary table is realized, and operations such as screening, sorting, merging, and inner product on the primary table are completed. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Figure 1 It is a schematic structural diagram of the formal verification device applied to the present invention;

[0038] Figure 2 It is a schematic diagram of the system model construction process for the formal verification of interlocking software in the present invention;

[0039] Figure 3 It is a diagram of the single-sided node type in the yard topology model of the present invention;

[0040] Figure 4 It is a diagram of the double-sided node type in the yard topology model of the present invention;

[0041] Figure 5 It is a diagram of the three-sided node type in the yard topology model of the present invention;

[0042] Figure 6 It is a diagram of the four-sided node type in the yard topology model of the present invention;

[0043] Figure 7 It is a flow chart of the yard topology model construction of the present invention;

[0044] Figure 8 It is a flow chart of the object relationship model construction of the present invention;

[0045] Figure 9 It is the flowchart for constructing the Boolean variable model of the present invention. Specific embodiments

[0046] The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without making creative efforts shall fall within the protection scope of the present invention.

[0047] Interlocking data is a logical set of interlocking relationships and functional descriptions in the interlocking system. Designers summarize interlocking requirements design according to different usage scenarios to reflect the restrictive relationships between signal devices, forming requirements design. On the basis of the requirements design, using logical operators such as "AND", "OR", "NOT", etc., these restrictive relationships are sorted into Boolean BOOL expressions with interlocking significance, that is, general interlocking rules. In a specific station, data producers combine configuration and interlocking logic generation tools according to the actual signal device names and attributes of the specific station, as well as the positional relationships between devices, etc., to instantiate the general interlocking rules (that is, associate the actual devices with the variables in the general interlocking rules), generating specific interlocking data.

[0048] Formal verification is a method that uses a rigorous mathematical language to define the safety requirements specification of a system, establishes an object model and a safety requirements specification through a formal language, and uses the model checking method to traverse the model to verify that the model fully complies with the safety requirements specification. This verification method has advantages such as high automation degree and complete coverage of scenarios. Therefore, using the formal method to perform safety verification on interlocking data is an effective means to prevent the safety escape of the model corresponding to the interlocking data.

[0049] Verifying specific interlocking data is to verify whether there are any hazards when substituting the specific interlocking data into the actual usage scenario, such as the occurrence of situations like incorrect unlocking of the route and train overrunning the route. Conventional formal verification needs to be carried out on the basis of formal development, that is, formal language development starts in the requirements design stage. However, for the interlocking data that has been used in the field, the cost required for re-formal development is very high, and such extensive changes are likely to introduce unknown design defects, affecting the safety of the system.

[0050] The formal verification device applied in this application is as Figure 1As shown, the system model and the safety requirement model need to be input into the validator for verification. The safety requirement model is created based on the object model, and the system model is constructed relying on the interlocking input data. The essence of the verification is to verify whether the interlocking data meets the safety requirements. Therefore, the processing of the interlocking data is the most critical step for formal verification. The system model constructed in this application is applied to the formal verification device of the computer interlocking software, and the role of this system model is to establish the mapping relationship between the object model and the interlocking data.

[0051] In this embodiment, the interlocking input data for formal verification includes the following three aspects:

[0052] (1) The station yard topology structure file, which is of text type and includes attributes such as the types, names, directions, coordinates, and topological connection relationships between devices in the station yard diagram, as well as the route information in the station yard diagram. The devices or objects involved include: signal machines <signal>, turnout <switch>, Button <button>, indicating lamp <alarm>, section <track> , checkpoint <check>etc., route table information <routetable>;

[0053] (2) The station interlocking information table and interface information table files are table-type files. Among them, the station interlocking information table is used to define the interlocking relationship between the attributes of key signal devices in the station, the route information table, and the logical attributes of signal devices; the interface information table defines the interface information between the interlocking and other external systems.

[0054] (3) The Boolean logic file, in text type, defines device input variables, output variables, general variables, time variables, self-holding variables, and defines the Boolean operation equations of the variables. Among them, the variable types are all of BOOL type. The Boolean logic file is the rule file for the operation of the interlocking system.

[0055] In one implementation manner of this embodiment, a general system model is constructed according to the interlocking input data type. As Figure 2 shown, this embodiment discloses a method for constructing a system model for formal verification of interlocking software. The construction method includes the following steps:

[0056] S1. Two translators with the same function developed using different programming methods and programming languages read the interlocking input data; the interlocking input data includes the station topology structure file, the TAB table file, and the Boolean logic file; the two translators with the same function convert the interlocking input data into data files in a specific format, and a file comparison tool performs consistency verification on the data files in the specific format output by the two translators with the same function.

[0057] In this embodiment, the translator performs data conversion using the conversion method described in the patent with the publication number CN113031934B, the patent number ZL202110368555.1, and the name "An Interlocking Data Security Conversion Method and Translator for Formal Verification". The converted file in a specific format is an LCF format file or an HLL format file.

[0058] Further preferably, a system model construction tool is developed using a programming method. The system model construction tool reads the file in the specific format that has been data-converted by the translator in step S1 and passed the consistency verification, and constructs a system model based on the file in the specific format.

[0059] In this embodiment, the interlocking input data is converted into a file in a specific format, specifically into a data format that can be recognized by the formal verification software, so as to integrate the interlocking data of a specific station into the system model of the formal verification.

[0060] In this embodiment, a system model construction tool is developed by programming methods. The system model construction tool reads a specific format file that has been converted by a translator and passed the consistency check in step S1, and constructs a system model based on the specific format file. It can be developed using the Python programming language or the OCaml programming language.

[0061] As another implementation manner of this embodiment, as Figure 7 shown, a station yard topological model is constructed based on the specific format file converted from the station yard topological structure file. The specific steps are as follows:

[0062] S301. Create a directed graph structure composed of nodes and edges. According to the device connection relationship in the specific format file converted from the station yard topological structure file, each device is occupied by a node of the same type. Each node defines its id and node type to form a node module.

[0063] S302. Connect the nodes into a graph structure through edges, and define the connection relationship between nodes in pairs into the edge module.

[0064] S303. Store the station yard device objects in the corresponding nodes to form an object module, and the object module generates the node id of the node where each device object is located.

[0065] S304. Generate a route module according to the route table information in the specific format file converted from the station yard topological structure file.

[0066] S305. Generate a region module according to the device information in the station yard map area.

[0067] The node module, edge module, object module, route module, and region module constitute a complete station yard topological model.

[0068] In this embodiment, the complete station yard topological model includes the following modules:

[0069] - The node module, which is a container for storing station yard device objects. According to the device characteristics in the station yard map, four types of nodes are defined, namely single-sided nodes (as Figure 3 shown), double-sided nodes (as Figure 4 shown), triple-sided nodes (as Figure 5 shown), and quadruple-sided nodes (as Figure 6 shown); the node module defines the node identification number and the number of extended edges, and the attributes of its movement path are defined in each type of node. For example, a double-sided node defines 0 and 1 respectively to represent the two outward extended sides, so the allowed paths passing through this node are [0,1] and [1,0].

[0070] —— Edge module, used to store the connection relationships of nodes. In each edge module, the numbers of two adjacent nodes are generated, and the id defined on the extended edge connecting the two nodes. Through the connection of edges, nodes are strung together into a graph structure.

[0071] —— Object module, used to define the device objects stored in nodes. These objects are obtained from the specific format file converted from the station yard topology structure file. The object module defines the object identification number, the corresponding user type, the node number where it is located, and specific attribute information. Here, the user type is the connection for mapping between the station yard device objects and the object model of the formalized code layer in the system model. A dedicated configuration file is added to define the mapping relationship, and based on this mapping relationship, the object model of the code layer is instantiated.

[0072] —— The route module stores the route information in the station yard diagram. The route module defines the route identification number (route name), route type, starting node, and route path.

[0073] —— Area module. An area refers to a set of devices composed of multiple nodes and edges. The area module defines the area identification number (device name), area type, and the set of nodes and edges that make up the area.

[0074] In this embodiment, the basis for dividing node types is the number of expandable edges of the station yard devices, that is, the number of adjacent nodes that can be traversed outward from this node in the topology. For the end-type signal machines and track sections in the station yard, only one end needs to be connected to other devices, and they are set as single-sided nodes; for the non-boundary signal machines and track sections in the station yard, the edges can be extended in both directions, and they are designed as double-sided nodes; for turnout devices, three edges can be extended outward, and they are designed as three-sided nodes; for crossover switches, four turnout points can be extended outward, and they are designed as four-sided nodes. Edges in different directions are distinguished by the id defined on the edge. The definition principle is shown in Figures 3 to 6 as shown. The nodes and the station yard device objects can be in a one-to-one or one-to-many relationship.

[0075] As another implementation manner of this embodiment, as shown in Figure 8 as shown, an object relationship model is constructed based on the specific format file converted from the TAB table file. The specific process is as follows:

[0076] S401. Define the first-level table according to the sub-tables in the specific format file converted from the TAB table file. At the same time, define the signal device sub-table and the route table in the specific format file converted from the station yard topology structure file according to the first-level table. The sub-tables defined according to the first-level table include all columns of the corresponding sub-tables in this specific format file;

[0077] S402. Define a secondary table according to the relationships in the object model for formal verification; establish the mapping relationship between the secondary table and the object relationships, and trace the relationships of the object model into the secondary table; generate an object relationship model for formal verification.

[0078] The TAB table class files can be summarized as files that define the relationships or attributes between objects. The tables directly translated from the sub-tables of the interlocking information table and the external system interface table, as well as the device sub-tables and route tables in the station yard topology structure file, are defined as primary tables. The tables generated after calculating the primary tables according to the table method are defined as secondary tables. The secondary tables are usually simple tables consisting of one or two columns. Therefore, the secondary tables define the relationships between devices in a more simplified and straightforward manner, making it easier to search. Usually, we map the device relationships defined in the object model to the secondary tables. For example, for the relationship of the starting signal of a route defined in the object model, a ROUTE@start_signal relationship can be established under the route object, and this relationship can correspond to a secondary table route_start_signal["path","signal"] consisting of two columns: route and signal.

[0079] The device relationship parameters of the object model are essentially a dictionary structure composed of a set of key-value pairs. A set of key-value pair relationships corresponds to a secondary table. The key and value in the key-value pair are separated by @. Before the @ symbol is considered as the "key", and after the @ is considered as the "value". The object set is stored in the form of keys and values. In the security requirements model, "key.value" is directly used to represent the relationship, such as route.start_signal representing the starting signal of the route. By using the table calculation rules to construct the table model, the conversion from the primary table to the secondary table is realized, and operations such as screening, sorting, merging, and inner product on the primary table are completed.

[0080] As another implementation manner of this embodiment, refer to the appended Figure 9 As shown in the drawings, construct a Boolean variable model according to the specific format file after converting the Boolean logic file. Specifically, according to the object variables in the object model for formal verification, manually configure the variable relationship mapping file to establish a one-to-one mapping between the object variables and the actual Boolean variables in the specific format file after converting the Boolean logic file; generate a Boolean variable model for formal verification.

[0081] The translator will implement the translation of the original Boolean file. According to the keywords in the Boolean file, it will identify INPUT, OUTPUT, TIMER timer, and Boolean equations from it. When building the Boolean file model, it is necessary to establish the mapping relationship between the variable names in the object model and the variable names in the input file to achieve a one-to-one mapping of the attributes of the physical device to the logical variables in the interlocking data. The mapping process can be implemented manually through the design of the configuration file. Among them, all timers need to be set as expiration timers. After the timer is triggered, it starts timing. When the delay ends, the value of the time variable changes.

[0082] Note that the above is only the preferred embodiment of the present invention and the applied technical principles. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described here. Various obvious changes, re-adjustments, and substitutions can be made by those skilled in the art without departing from the protection scope of the present invention. Therefore, although the present invention has been described in more detail through the above embodiments, the present invention is not limited to the above embodiments. Without departing from the concept of the present invention, it can also include more other equivalent embodiments, and the scope of the present invention is determined by the scope of the appended claims.< / routetable> < / check> < / alarm> < / button> < / switch> < / signal>

Claims

1. A method for constructing a system model for formal verification of interlocking software, characterized in that The construction method includes the following steps: S1. Two translators developed using different programming methods and programming languages and having the same function read the interlocking input data; the interlocking input data includes a station yard topology structure file, a TAB table file, and a Boolean logic file; the two translators with the same function convert the interlocking input data into data files in a specific format, and a file comparison tool is used to perform consistency verification on the data files in the specific format output by the two translators with the same function; S2. Develop a system model construction tool using a programming method, and use the system model construction tool to read the specific format file that has been data-converted by the translator and passed the consistency verification in step S1, and construct a system model based on the specific format file; S3. Construct a station yard topology model based on the specific format file converted from the station yard topology structure file: S301. Create a directed graph structure composed of nodes and edges. According to the device connection relationship in the specific format file converted from the station yard topology structure file, each device is occupied by a node of the same type, and each node defines its id and node type to form a node module; S302. Connect the nodes into a graph structure through edges, and define the connection relationship between nodes in pairs into the edge module; S303. Store the station yard device objects in the corresponding nodes to form an object module, and the object module generates the node id of the node where each device object is located; S304. Generate a route module according to the route table information in the specific format file converted from the station yard topology structure file; S305. Generate a region module according to the device information in the station yard map area; The node module, edge module, object module, route module, and region module constitute a complete station yard topology model; S4. Construct an object relationship model based on the specific format file converted from the TAB table file: S401. Define a first-level table according to each sub-table in the specific format file converted from the TAB table file. At the same time, define the signal device sub-table and the route table in the specific format file converted from the station yard topology structure file according to the first-level table; the sub-tables defined according to the first-level table include all columns of the corresponding sub-table in the specific format file; S402. Define a second-level table according to the relationships in the object model for formal verification; establish a mapping relationship between the second-level table and the object relationship, and trace the relationships of the object model to the second-level table; generate an object relationship model for formal verification; S5. Construct a Boolean variable model based on the specific format file converted from the Boolean logic file. Specifically, according to the object variables in the object model for formal verification, manually configure a variable relationship mapping file to establish a one-to-one mapping between the object variables and the actual Boolean variables in the specific format file converted from the Boolean logic file; generate a Boolean variable model for formal verification.

2. A method for constructing a system model for formal verification of interlocking software, as described in claim 1, characterized in that: In step S1, the station yard topology structure file in the interlocking input data includes various device types, device names, directions, coordinates, topological connection relationships between devices, and route information in the station yard map; The devices or objects involved in the station yard topology structure file include signal machines, switches, buttons, indication lights, sections, inspection points, and route table information.

3. A method for constructing a system model for formal verification of interlocking software, as described in claim 1, characterized in that: In step S1, the TAB table file in the interlocking input data includes the station interlocking information table and the interface information table file; among them, the station interlocking information table is used to define the interlocking relationship between the attributes of key signal devices in the station, the route information table, and the logical attributes of signal devices; the interface information table defines the interface information between the interlocking and other external systems.

4. A method for constructing a system model for formal verification of interlocking software, as described in claim 1, characterized in that: In step S1, the Boolean logic file in the interlocking input data defines device input variables, output variables, general variables, time variables, self-maintaining variables, and defines the Boolean operation equations of the variables, where the types of the variables are all of the BOOL type.

5. A method for constructing a system model for formal verification of interlocking software according to any one of claims 1-4, characterized in that: In step S301, the node module is a container for storing station yard equipment objects. According to the equipment characteristics in the station yard diagram, four types of nodes are defined, namely single-sided nodes, double-sided nodes, triple-sided nodes, and quadruple-sided nodes; the node module defines the node identification number and the number of extended edges, and defines the attributes of its movement path in each type of node.

6. A method for constructing a system model for formal verification of interlocking software according to any one of claims 1-4, characterized in that: In step S302, the edge module is used to store the connection relationships of the nodes. In each edge module, the numbers of two adjacent nodes are generated, and the id defined on the extended edge connecting the two nodes. Through the connection of the edges, the nodes are strung together into a graph structure.

7. A method for constructing a system model for formal verification of interlocking software according to any one of claims 1-4, characterized in that: In step S303, the object module is used to define the equipment objects stored in the nodes. These objects are obtained from the specific format file converted from the station yard topology structure file. The object module defines the object identification number, the corresponding user type, the node number where it is located, and the specific attribute information.

8. A method for constructing a system model for formal verification of interlocking software according to any one of claims 1-4, characterized in that: In step S304, the route module stores the route information in the station yard diagram. The route module defines the route identification number, the route type, the starting node, and the route path; in step S305, the area in the area module refers to a set of devices composed of multiple nodes and edges. The area module defines the area identification number, the area type, and the set of nodes and edges that make up the area.

9. A method for constructing a system model for formal verification of interlocking software according to any one of claims 1-4, characterized in that: In step S4, the tables directly translated from the sub-tables of the interlocking information table and the external system interface table, as well as the equipment sub-table and the route table in the station yard topology structure file, are defined as first-level tables, and the tables generated after calculating according to the table method of the first-level tables are defined as second-level tables.

10. A method for constructing a system model for formal verification of interlocking software according to any one of claims 1-4, characterized in that: In step S5, according to the keywords in the specific format file converted from the Boolean logic file, INPUT, OUTPUT, TIMER timers, and Boolean equations are identified from it. When constructing the Boolean variable model, the mapping relationship between the variable names in the object model and the variable names in this specific format file is established, and a one-to-one mapping of the attributes of physical devices to logical variables in the interlocking data is performed.

Images