Development and implementation method of computer interlocking software based on formalized language

Abstract

The invention discloses a formalized language-based computer interlocking software development implementation method, which comprises the following steps of: S1, writing a formalized specification by using a formalized language Z language, defining an abstract state of a system through a mode, defining an initial state, writing a Z mode for each operation, and outputting a Z protocol document; s2, performing formalized verification and theorem certification on the Z protocol document generated in the previous step; s3, if the verification is not passed, redesigning the Z protocol document, and if the verification is passed, refining the Z protocol document for multiple times; and S4, automatically generating a test case, test input and expected output covering all boundary conditions by using a Z auxiliary tool CZT in combination with a user-defined test generator according to the verified and refined Z protocol document. According to the method, the defects that ambiguity and ambiguity are caused by adopting a direct development method based on a natural language, strict logical reasoning and proving cannot be carried out, and automatic verification cannot be carried out can be overcome.

Description

Technical Field

[0001] This invention belongs to the field of rail transit technology, specifically a method for developing and implementing computer interlocking software based on a formal language. Background Technology

[0002] Currently, the computer interlocking system used in urban rail transit signaling systems typically involves functional designers manually writing requirements based on natural language. Software developers then refine these requirements to ensure they conform to the software design architecture. The software is then written and debugged using computer languages ​​such as C and C++, followed by functional and integration testing.

[0003] However, with the continuous increase in interlocking sub-functions and the increasing complexity of functional requirements, the development of interlocking software using traditional methods is becoming increasingly difficult. It is hard to thoroughly inspect the code, and full coverage testing of interlocking functions requires a lot of time. Troubleshooting after problems occur is also very difficult. How to improve the existing interlocking software development methods has become a problem that needs to be studied and solved by those skilled in the art.

[0004] Therefore, a method for developing and implementing computer interlocking software based on a formal language is provided. Summary of the Invention

[0005] To address the aforementioned problems in the existing technology, this invention provides a method for developing and implementing computer interlocking software based on formal languages. By using formal methods to develop interlocking system software, the ambiguity and ambiguity caused by methods based on natural language direct development, as well as the inability to perform rigorous logical reasoning and proof, and the inability to automate verification, can be overcome.

[0006] The technical solution to achieve the above objectives is: A method for developing and implementing computer interlocking software based on a formal language, comprising: Step S1: Using the formal language Z, write a formal specification, define the abstract state of the system through patterns, define the initial state, write a Z pattern for each operation, and output a Z specification document. Step S2: Perform formal verification and theorem proof on the Z-specification document generated in the previous step; Step S3: If the verification fails, redesign the Z specification document; if the verification passes, refine the Z specification document multiple times. Step S4: The verified and refined Z specification document is used to automatically generate test cases, test inputs, and expected outputs that cover all boundary conditions using the Z-assisted tool CZT combined with a custom test generator.

[0007] Preferably, in step S1, the abstract state of the system is defined by the mode definition, including but not limited to the definition of interlocking state, which includes turnout state, route state, and signal state. The initial state includes, but is not limited to, all signals being red and all routes being released; Write a Z-mode for each operation, including but not limited to requesting route establishment and unlocking turnouts. The mode must clearly define the preconditions and postconditions and accurately describe the constraints that the system state must meet before and after the operation is executed.

[0008] Preferably, in step S2, the written Z specification document is checked for syntax and type using an auxiliary tool to check whether all variables and expressions are of the correct type; wherein, the Z tool is used to check whether the syntax and type of the specification are correct.

[0009] Preferably, in step S2, based on security requirements, relevant theorems are defined and expressed as security invariants. For each operation, it must be proven that if the invariant holds before the operation is executed and the preconditions of the operation are met, then the invariant still holds after the operation is executed. This process uses a theorem prover to assist in completing the proof.

[0010] Preferably, in step S2, after formal verification is completed, a verification report is output, which includes all the proven security attributes. If the verification fails, there is a defect or contradiction in the specification, and the process is returned to modify the Z specification.

[0011] Preferably, in step S3, through multiple refinement steps, the highly abstract high-level model in the Z-specification document is gradually transformed into a low-level model that is closer to the actual code and contains specific data structures and algorithms; after completion, the refined low-level Z-specification document is output. in, Each refinement step must be proven to be correct, meaning that the lower-level model strictly follows the behavior of the higher-level model.

[0012] Preferably, in step S4, testing the input and the desired output includes: The refined Z specification document is used in conjunction with the Z auxiliary tool CZT and a custom code rule generator to automatically generate the overall framework of the target code. The variable and function definitions in the framework conform to the refined Z specification. After manual improvement and optimization, the final target code conforming to the Z specification is formed. The interlocking software after code compilation is tested in a simulation environment using instantiated test cases. The actual results monitored are automatically compared with the expected results defined in the test cases to verify whether the final code strictly and accurately implements the behavior required by the formal specification, and a detailed test report is generated. Once the test is passed, it proves that the target code meets the expected values ​​set by all test cases, that is, it conforms to the description of the formal Z specification. Then it can be integrated with other subsystems for testing and deployment.

[0013] Compared with the prior art, the beneficial effects of the present invention are: Each symbol and structure in the formal language of this invention has a strict mathematical definition, which can accurately define different states and their relationships. Among them, the Z language can freely use rich mathematical concepts to describe the state space, with a very high degree of abstraction freedom. Compared with other formal languages, it can write clearer and higher-quality formal requirements documents. Moreover, due to its more powerful and flexible data modeling capabilities, it allows for more free construction of complex data structures (such as interlocking tables), which is very suitable for complex systems such as interlocking systems that require high security and reliability. In this invention, the formal specification can prove that different parts of the specification do not contradict each other, and the design model can be proven to satisfy all the security properties of the specification through theorem proof and model check. This invention uses natural language, which means that errors are usually discovered in the later stages of development (testing phase) or even at runtime, resulting in high repair costs. In contrast, formal methods, using relevant toolchains, can automatically traverse all possible states of the system, discover errors in extreme cases, and perform early repairs before code writing. The test cases automatically generated by this invention (directly derived from the specification) can cover all boundary conditions, abnormal conditions, and normal conditions, with a coverage far exceeding that of manually designed test cases. From generating test cases to executing tests and comparing results, the entire process can be highly automated, significantly improving testing efficiency and allowing for large-scale regression testing. When using natural language processing methods, it is difficult to assess the impact of a change on other parts when the system needs to be upgraded or modified. This requires manual and repeated checks of all relevant documents, which can easily lead to omissions. However, through formal methods, the verification tool can be rerun to automatically check whether the change has violated existing security properties, ensuring that the change does not introduce new risks. Attached Figure Description

[0014] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a flowchart illustrating the development and implementation method of computer interlocking software based on a formal language according to the present invention. Figure 2 This is another flowchart of the development and implementation method of computer interlocking software based on formal language according to the present invention. Detailed Implementation

[0015] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0016] like Figure 1 , 2 As shown, a method for developing and implementing computer interlocking software based on a formal language includes: Step S1: Using the formal language Z, write a formal specification, define the abstract state of the system through patterns, define the initial state, write a Z pattern for each operation, and output a Z specification document.

[0017] In the embodiments, the abstract state of the system is defined by the pattern definition, including but not limited to the definition of interlocking state, which includes turnout state, route state, signal state, etc. The initial state includes, but is not limited to, all signals being red and all routes being released; Write a Z-mode for each operation, including but not limited to requesting route establishment and unlocking turnouts. The mode must clearly define the preconditions and postconditions and accurately describe the constraints that the system state must meet before and after the operation is executed.

[0018] Step S2: Perform formal verification and theorem proof on the Z-specification document generated in the previous step.

[0019] In the embodiment, based on security requirements, relevant theorems are defined and expressed as security invariants. For each operation, it must be proven that if the invariant holds before the operation is executed and the preconditions of the operation are met, then the invariant still holds after the operation is executed. This process uses a theorem prover to assist in completing the proof.

[0020] In this embodiment, after formal verification is completed, a verification report is output, which contains all the proven security attributes. If the verification fails, there is a defect or contradiction in the specification, and the process is returned to modify the Z specification.

[0021] In this embodiment, an auxiliary tool is used to perform syntax and type checks on the written Z specification document to check whether all variables and expressions are of the correct type; specifically, the Z tool is used to check whether the syntax and type of the specification are correct.

[0022] Step S3: If the verification fails, redesign the Z specification document; if the verification passes, refine the Z specification document multiple times.

[0023] In this embodiment, through multiple refinement steps, the highly abstract high-level model in the Z-specification document is gradually transformed into a low-level model that is closer to the actual code and contains specific data structures and algorithms; after completion, the refined low-level Z-specification document is output. in, Each refinement step must be proven to be correct, meaning that the lower-level model strictly follows the behavior of the higher-level model.

[0024] Step S4: The verified and refined Z specification document is used to automatically generate test cases, test inputs, and expected outputs that cover all boundary conditions using the Z-assisted tool CZT combined with a custom test generator.

[0025] In this embodiment, the test input and expected output include: The refined Z specification document is used in conjunction with the Z auxiliary tool CZT and a custom code rule generator to automatically generate the overall framework of the target code. The variable and function definitions in the framework conform to the refined Z specification. After manual improvement and optimization, the final target code conforming to the Z specification is formed. The interlocking software after code compilation is tested in a simulation environment using instantiated test cases. The actual results monitored are automatically compared with the expected results defined in the test cases to verify whether the final code strictly and accurately implements the behavior required by the formal specification, and a detailed test report is generated. Once the test is passed, it proves that the target code meets the expected values ​​set by all test cases, that is, it conforms to the description of the formal Z specification. Then it can be integrated with other subsystems for testing and deployment.

[0026] The following simplified model provides an example illustrating the key steps. Define the permutation path and open signal using formal Z-specification (including explanation).

[0027] Basic type definition: [ROUTE, BLOCK, SWITCH, SIGNAL] ROUTE: The set of all preset routes (e.g., r1, r2, r3).

[0028] BLOCK: The set of all track segments (e.g., t1, t2, t3).

[0029] SWITCH: The set of all turnouts. Turnouts can be in different positions (e.g., right-hand / reverse-hand).

[0030] SIGNAL: A collection of all traffic signals. Traffic signals display different light colors (e.g., red / green).

[0031] State Pattern: -- First, define the types of turnout status and signal status. SwitchStatus ::= normal | reverse SignalAspect ::= red | green InterlockingState == [ -- Check if each track segment is occupied occupied : P BLOCK -- Record the current position of each turnout , switchPosition : SWITCH → SwitchStatus -- Record the current display status of each signal. , signalAspect : SIGNAL → SignalAspect -- A single route consists of multiple track sections.

[0032] , routeDefinition: ROUTE ↔ BLOCK -- Record which routes are currently locked (processed and locked).

[0033] lockedRoutes : P ROUTE -- ### Core Safety Invariants ### | -- 1. A path can only be locked if it is defined. lockedRoutes ⊆ dom routeDefinition -- 2. The most important safety rule: A signal can only be turned on (green light) if the corresponding route is locked and all track sections of that route are clear! ∀ s : SIGNAL; r : ROUTE | -- Map the signal to the path it protects r = routeForSignal(s) ● signalAspect(s) = green ⇒ (r ∈ lockedRoutes ∧ (routeDefinition(r) ∩ occupied= ∅)) -- 3. Another important rule: Once a route is locked, the positions of the switches it contains are fixed and cannot be changed.

[0034] ∀ r : lockedRoutes ● -- `switchsOfRoute(r)` represents the switches that route r depends on. ∀ p : SWITCH | p ∈ switchesOfRoute(r) ● -- `requiredPosition` defines the position of turnout p required for route r. switchPosition(p) = requiredPosition(r, p) -- ... There can also be other invariants, such as path conflict (mutual exclusion) checks, etc. ] Initial state mode: The initial state when the system starts up. InitInterlocking == [InterlockingState' | occupied' = ∅ ∧ switchPosition' = ∅ ∧ -- or all switches are placed in the safe position. signalAspect' = (λ s : SIGNAL @ red) ∧ -- All signals are initially red. lockedRoutes' = ∅ ∧ ] Operation mode: Arrange a path ?r!: ROUTE -- Input: The route to be processed RequestRoute == [ ΔInterlockingState r? : ROUTE -- Prerequisites: r? ∈ dom routeDefinition -- The route must be defined. r? ∉ lockedRoutes -- The route is currently not locked. -- All track sections required for route inspection are free. routeDefinition(r?) ∩ occupied = ∅ -- Check that the required turnout is available and in the correct position (or can be switched to the correct position). (∀ p : SWITCH | p ∈ switchesOfRoute(r?) ● switchPosition(p) = requiredPosition(r?, p) ∨ `switchIsFree(p)` -- `switchIsFree` indicates that the turnout is not locked by other routes. -- Post-condition: Successful processing lockedRoutes' = lockedRoutes ∪ {r?} -- Ensure the switches are switched to the correct positions and locked. switchPosition' = switchPosition ⊕ { p : SWITCH | p ∈ switchesOfRoute(r?) ● p → requiredPosition(r?, p)} -- Other states remain unchanged occupied' = occupied signalAspect = signalAspect -- Signals are not immediately opened when processing a route. ] Operating mode: Open route start signal ?s!: SIGNAL -- Input: The signal that needs to be enabled. ClearSignal == [ ΔInterlockingState s? : SIGNAL | -- Prerequisite: Obtain the route protected by this signal. LET r == routeForSignal(s?) IN r ∈ lockedRoutes -- the route must be locked routeDefinition(r) ∩ occupied = ∅ -- The route is still idle. -- All other safety conditions have been met (switches are in the correct position, etc.) -- Postcondition: Signal turns green signalAspect' = signalAspect ⊕ {s? → green} -- Other states remain unchanged occupied' = occupied switchPosition' = switchPosition lockedRoutes' = lockedRoutes ] The Z specification can be refined, for example as follows: ?r!: ROUTE_INDEX -- Enter: the route number to process !err!: ERROR_CODE -- Output: Operation result code RequestRoute_Final == var temp_switch_fail : SWITCH := null -- Temporary variable for error handling -- Step 1: Validate Input PreCheck: if r? ∉ dom(route_table) then err! := ROUTE_NOT_DEFINED return -- Return early endif if locked_routes_bitset[r?] = TRUE then err! := ROUTE_LOCKED return endif -- Step 2: Check track occupancy CheckTracks: for i in route_table[r?] do if track_occupied[i] = TRUE then err! := TRACK_OCCUPIED return endif endfor -- Step 3: Set and lock the turnout SetSwitchs: for each p in switches_of_route(r?) loop if switch_pos[p] ≠ requiredPosition(r?, p) then -- Attempt to switch switches temp_switch_fail := p switch_pos[p] := requiredPosition(r?, p) -- Call the underlying driver and check the feedback if not check_switch_position(p) then err! := SWITCH_FAILURE -- Error handling process return endif endif endloop temp_switch_fail := null -- All switches were set successfully; clear the failure flag. -- Step 4: Update Status - Lock Path UpdateState: locked_routes_bitset[r?] := TRUE err! := SUCCESS -- Exception handling block ExceptionHandler: -- If the turnout switching fails, the previously set turnout status needs to be returned. if err! ≠ SUCCESS and temp_switch_fail ≠ null then -- Restore the failed switch to a safe position.

[0035] switch_pos[temp_switch_fail] := safe_position(temp_switch_fail) endif Finally, it should be noted that the above are merely preferred embodiments of the present invention and are not intended to limit the present invention. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments or make equivalent substitutions for some of the technical features. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for developing and implementing computer interlocking software based on a formal language, characterized in that, include: Step S1: Using the formal language Z, write a formal specification, define the abstract state of the system through patterns, define the initial state, write a Z pattern for each operation, and output a Z specification document. Step S2: Perform formal verification and theorem proof on the Z-specification document generated in the previous step; Step S3: If the verification fails, redesign the Z specification document; if the verification passes, refine the Z specification document multiple times. Step S4: The verified and refined Z specification document is used to automatically generate test cases, test inputs, and expected outputs that cover all boundary conditions using the Z-assisted tool CZT combined with a custom test generator.

2. The method for developing and implementing computer interlocking software based on a formal language according to claim 1, characterized in that, In step S1, the abstract state of the system is defined by the mode definition, including but not limited to the definition of interlocking state, which includes turnout state, route state, and signal state. The initial state includes, but is not limited to, all signals being red and all routes being released; Write a Z-mode for each operation, including but not limited to requesting route establishment and unlocking turnouts. The mode must clearly define the preconditions and postconditions and accurately describe the constraints that the system state must meet before and after the operation is executed.

3. The method for developing and implementing computer interlocking software based on a formal language according to claim 1, characterized in that, In step S2, the syntax and type of the written Z specification document are checked using an auxiliary tool to check whether all variables and expressions are of the correct type; specifically, the Z tool is used to check whether the syntax and type of the specification are correct.

4. The method for developing and implementing computer interlocking software based on a formal language according to claim 1, characterized in that, In step S2, based on security requirements, relevant theorems are defined and expressed as security invariants. For each operation, it must be proven that if the invariant holds before the operation is executed and the preconditions of the operation are met, then the invariant still holds after the operation is executed. This process uses a theorem prover to assist in completing the proof.

5. The method for developing and implementing computer interlocking software based on a formal language according to claim 1, characterized in that, In step S2, after formal verification is completed, a verification report is output, which contains all the proven security attributes. If the verification fails, there is a defect or contradiction in the specification, and the process is returned to modify the Z specification.

6. The method for developing and implementing computer interlocking software based on a formal language according to claim 1, characterized in that, In step S3, through multiple refinement steps, the highly abstract high-level model in the Z-specification document is gradually transformed into a low-level model that is closer to the actual code and contains specific data structures and algorithms; after completion, the refined low-level Z-specification document is output. in, Each refinement step must be proven to be correct, meaning that the lower-level model strictly follows the behavior of the higher-level model.

7. The method for developing and implementing computer interlocking software based on a formal language according to claim 1, characterized in that, In step S4, testing the input and the expected output includes: The refined Z specification document is used in conjunction with the Z auxiliary tool CZT and a custom code rule generator to automatically generate the overall framework of the target code. The variable and function definitions in the framework conform to the refined Z specification. After manual improvement and optimization, the final target code conforming to the Z specification is formed. The interlocking software after code compilation is tested in a simulation environment using instantiated test cases. The actual results monitored are automatically compared with the expected results defined in the test cases to verify whether the final code strictly and accurately implements the behavior required by the formal specification, and a detailed test report is generated. Once the test is passed, it proves that the target code meets the expected values ​​set by all test cases, that is, it conforms to the description of the formal Z specification. Then it can be integrated with other subsystems for testing and deployment.

Images