Fault processing method and device for control system

Abstract

The embodiment of the invention provides a fault processing method and device for a control system. The method comprises the following steps: determining a current running state of the control system; under the condition that the current running state accords with the target abnormal state, target fault configuration information corresponding to the target abnormal state is obtained, and the target fault configuration information is configured with at least one fault reason in the target abnormal state and fault recovery programs corresponding to the fault reasons respectively; according to the target fault configuration information, a target fault reason of the control system is determined, a target fault recovery program corresponding to the target fault reason is executed, the target fault recovery program is used for enabling the control system to recover the normal state, and the target fault reason of the control system is determined according to the target fault configuration information. And the target fault recovery program corresponding to the target fault reason is executed, so that the system can be helped to perform autonomous recovery, the system is recovered to a normal state, the system reliability is improved, and the train driving safety and the passenger travel safety are guaranteed.

Description

Technical Field

[0001] The embodiments of this specification relate to the field of computer technology, and more particularly to a method and apparatus for troubleshooting a control system. Background Art

[0002] In the field of rail transit, the on-board ATP (Automatic Train Protection) system is the core of the train operation control system. It is used to control the train's operating speed based on ground information and vehicle information, preventing the train from speeding and thus ensuring the train's driving safety.

[0003] Since any minor malfunction in the onboard ATP system can lead to serious consequences and pose a significant safety hazard during actual train operation, improving the safety and reliability of the onboard ATP system is crucial. Currently, this system primarily relies on a dual-system redundant architecture, also known as a "two-by-two-take-two redundant architecture." This architecture employs identical ATP subsystems at the front and rear of the train, operating synchronously. If one subsystem fails, the other can continue to safely control the train. However, if either subsystem fails, or in certain abnormal circumstances, the onboard ATP system cannot continue to operate according to the dual-system redundant architecture, reducing system reliability and thus impacting train safety. Summary of the Invention

[0004] In view of this, embodiments of this specification provide a control system fault handling method. One or more embodiments of this specification also relate to a control system fault handling apparatus, a computing device, a computer-readable storage medium, and a computer program product to address technical deficiencies in the prior art.

[0005] According to a first aspect of an embodiment of this specification, a method for handling a fault of a control system is provided, comprising: Determine the current operating status of the control system; When the current operating state meets the target abnormal state, obtaining target fault configuration information corresponding to the target abnormal state, wherein the target fault configuration information is configured with at least one fault cause in the target abnormal state and a fault recovery program corresponding to each fault cause; According to the target fault configuration information, the target fault cause of the control system is determined, and a target fault recovery program corresponding to the target fault cause is executed, wherein the target fault recovery program is used to restore the control system to a normal state.

[0006] According to a second aspect of the embodiments of this specification, a fault handling device for a control system is provided, comprising: a determination module configured to determine a current operating state of the control system; an acquisition module configured to, when the current operating state meets the target abnormal state, acquire target fault configuration information corresponding to the target abnormal state, wherein the target fault configuration information is configured with at least one fault cause in the target abnormal state and a fault recovery program corresponding to each fault cause; The execution module is configured to determine the target fault cause of the control system according to the target fault configuration information, and execute a target fault recovery program corresponding to the target fault cause, wherein the target fault recovery program is used to restore the control system to a normal state.

[0007] According to a third aspect of an embodiment of this specification, a computing device is provided, including: memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions. When the computer-executable instructions are executed by the processor, the steps of the fault handling method of the control system are implemented.

[0008] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided, which stores computer-executable instructions, which, when executed by a processor, implement the steps of the fault handling method of the control system.

[0009] According to a fifth aspect of the embodiments of this specification, a computer program product is provided, comprising a computer program / instruction, which implements the steps of the fault handling method of the above control system when executed by a processor.

[0010] One embodiment of the present specification implements determining the current operating state of a control system; when the current operating state meets the target abnormal state, obtaining target fault configuration information corresponding to the target abnormal state, wherein the target fault configuration information is configured with at least one fault cause under the target abnormal state and a fault recovery program corresponding to each fault cause; based on the target fault configuration information, determining the target fault cause of the control system, and executing the target fault recovery program corresponding to the target fault cause, wherein the target fault recovery program is used to restore the control system to a normal state.

[0011] In this way, by determining the current operating state of the control system and obtaining the target fault configuration information corresponding to the target abnormal state when the current operating state meets the target abnormal state, the operating state of the control system can be monitored in real time, and in the case of abnormal state, the control system can be fault-handled based on the pre-configured target fault configuration information; by determining the target fault cause of the control system according to the target fault configuration information and executing the target fault recovery program corresponding to the target fault cause, the control system can be helped to perform autonomous recovery according to the pre-configured fault recovery programs corresponding to each fault cause, so that the control system can be restored to a normal state, thereby improving the reliability of the system and ensuring the safety of train operation and passenger travel. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] Figure 1 This is an architectural diagram of a train control management system provided by one embodiment of this specification; Figure 2 This is a flow chart of a control system fault handling method provided by one embodiment of this specification; Figure 3 This is a process flow chart of a control system fault handling method provided by one embodiment of this specification; Figure 4 This is a structural diagram of a fault handling device for a control system provided by one embodiment of this specification; Figure 5 This is a structural block diagram of a computing device provided by one embodiment of this specification. DETAILED DESCRIPTION

[0013] The following description sets forth many specific details to facilitate a thorough understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the scope of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0014] The terms used in one or more embodiments of this specification are for the purpose of describing specific embodiments only and are not intended to limit one or more embodiments of this specification. The singular forms "a," "the," and "the" used in one or more embodiments of this specification and the appended claims are also intended to include plural forms unless the context clearly indicates otherwise. It should also be understood that the term "and / or" used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0015] It should be understood that although the terms first, second, etc. may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish the same type of information from each other. For example, without departing from the scope of one or more embodiments of this specification, the first may also be referred to as the second, and similarly, the second may also be referred to as the first. Depending on the context, the word "if" as used herein may be interpreted as "at the time of" or "when" or "in response to determining".

[0016] In addition, it should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of relevant countries and regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0017] First, the terms involved in one or more embodiments of this specification are explained.

[0018] ATP (Automatic Train Protection): ATP is an onboard subsystem that directly ensures train safety. It achieves autonomous positioning through speed sensors, speed radar, and odometers, and uses transponders to correct the train's position and speed information. It obtains the train's movement authorization (MA) through wireless communication (or variable data transponders), calculates and generates the train's control speed curve, and protects the train's position and speed to ensure driving safety.

[0019] CBTC (Communication Based Train Control System): A continuous train automatic control system built through active train positioning technology that does not rely on trackside train occupancy detection equipment, continuous train-to-ground two-way data communication technology, and on-board and ground processors capable of performing safety functions.

[0020] MMI (Man-Machine Interaction) is a platform for the bidirectional exchange of various symbols and actions between humans and computer systems or machines. Its primary function is to translate human intent into a form that the computer system or machine can understand and process, while also translating feedback from the computer system or machine into a form that humans can perceive and understand. The MMI interface is responsible for converting information into a human-readable form, enabling users to interact with the system conveniently. An MMI interface typically includes components such as a display, buttons, and a touchscreen to provide information display, parameter setting, and control operations.

[0021] In this specification, a control system fault handling method is provided. This specification also involves a control system fault handling device, a computing device, a computer-readable storage medium, and a computer program product, which are described in detail one by one in the following embodiments.

[0022] See also Figure 1 , Figure 1 The following diagram illustrates an architecture of a train control and management system according to one embodiment of this specification. The train control and management system specifically includes a management platform 100 and a control system 200. The control system 200 includes a main system 202 and a backup system 204. The main system 202 includes two identical processing units 2022, and the backup system 204 includes two identical processing units 2042.

[0023] In practical applications, the management platform 100 can be understood as a secure computer platform. The management platform 100 integrates a variety of security-related hardware and software technologies and has functions such as managing the downtime and restart of the control system.

[0024] The control system 200 can be understood as a system based on a "two-by-two redundant architecture" with high reliability and security. The control system includes two subsystems. Under normal system operation, one subsystem operates as the main system 202, primarily responsible for external output, and the other subsystem operates as the backup system 204, primarily responsible for performing redundant operations and maintaining data synchronization with the main system. The system configuration information and operating logic of the main system 202 and the backup system 204 can be consistent. In the event of any failure in the main system, the management platform 100 can control the backup system 204 to upgrade to the main system 202, performing tasks and external output as the new main system 202. In this way, the security and reliability of the system can be guaranteed.

[0025] Specifically, the main system 202 may include two identical processing units 2022. Each processing unit 2022 performs the same computation task and outputs a computation result. The main system 202 votes on the computation results and, if the two results are identical, adopts that result. Accordingly, the backup system 204 may include two identical processing units 2042. Each processing unit 2042 performs the same computation task and outputs a computation result. The backup system 204 votes on the computation results and, if the two results are identical, adopts that result.

[0026] In actual implementation, the main system 202 and the backup system 204 can exchange data through wired or wireless communication methods. Both the main system 202 and the backup system 204 can exchange data with the management platform 100 through a preset communication protocol.

[0027] Optionally, if the primary system 202 or the backup system 204 detects a fault, the fault information can be sent to the management platform 100 via a preset communication protocol. The management platform 100 can then restart the primary system 202 or the backup system 204 via the preset communication protocol, or can control the primary system 202 or the backup system 204 to shut down via the preset communication protocol. The primary system 202 or the backup system 204 can also shut down autonomously if it detects an error in its own business logic and send a shutdown message to the management platform 100.

[0028] In one or more optional embodiments of this specification, the control system 200 may be an ATP system, used to automatically protect the train during operation. The main system 202 and the backup system 204 may be ATP subsystems located at the front or rear of the train, respectively. Under normal operation, the main system 202 and the backup system 204 will each perform real-time calculations of operational information such as the train's position and speed. If the train encounters a roadblock ahead, the system will also execute business logic and output emergency braking signals. Whether the front ATP system or the rear ATP system is used as the main system 202 can be determined based on the specific circumstances of the actual application.

[0029] By applying this embodiment, through the management platform 100 and the control system 200, a safe and reliable control and management system can be implemented based on a two-by-two redundant architecture, thereby improving train driving safety and ensuring passenger travel safety.

[0030] See also Figure 2 , Figure 2 A flow chart of a control system fault handling method provided according to an embodiment of the present specification is shown, which specifically includes the following steps.

[0031] Step 202: Determine the current operating state of the control system.

[0032] The embodiments of this specification are applied to the field of rail transit technology, and can be applied to various specific application scenarios such as railway signal systems, urban rail transit signal systems, etc. For example, a communication-based automatic train control system (CBTC) can be used.

[0033] Specifically, the control system can be an onboard ATP system or other types of control units or equipment on the train that require reliability. The control system consists of two identical subsystems, each of which includes two processing units (such as CPUs). The two processing units operate synchronously and retain the results only when their outputs are consistent. Otherwise, an error is reported or the calculation is recalculated. During normal operation of the control system, one of the two identical subsystems serves as the primary system, and the other as the backup system. Data is synchronized between the primary and backup systems in real time.

[0034] For example, when the control system is an on-board ATP system, the on-board ATP system includes two identical ATP subsystems, one located at the front of the train and the other located at the rear of the train.

[0035] Specifically, the current operating status can be understood as the current operating state of the control system, or the operating state of the control system within the current cycle. The current operating status reflects the working conditions of the primary and backup systems, and can include: primary and backup systems operating normally, primary system operating normally but backup system down, primary system operating normally but backup system asynchronous, primary system down but backup system becoming active normally, and both primary and backup systems down. The latter four states indicate that the control system is in a faulty state, unable to operate according to a two-by-two redundancy architecture, and unable to guarantee the safety and reliability of the control system.

[0036] One or more optional embodiments of this specification apply to the primary system in a control system. Both the primary system and the backup system can be controlled and managed by a secure computer platform. This secure computer platform, also known as a management platform, integrates various security-related hardware and software technologies and provides various functions, such as managing control system downtime and restarts.

[0037] In the above application scenarios, since any failure of the system may lead to serious consequences, it is necessary to ensure the high reliability and security of the system.

[0038] Based on this, the onboard ATP system in the embodiment of this specification adopts a two-by-two redundant architecture, and each train is equipped with two sets of ATP, one at the front and one at the rear.

[0039] According to an optional embodiment of this specification, when a train is traveling in the upward direction, the ATP at the front of the train serves as the control terminal, while the ATP at the rear of the train serves as a redundant standby terminal. The front ATP, acting as the primary ATP, outputs control signals, while the rear ATP, acting as the backup ATP, synchronously performs certain data calculations and processing functions, such as speed calculation and position determination. It should be noted that the backup ATP typically does not output control signals.

[0040] According to another optional embodiment of the present specification, when the train is running in the downward direction, the ATP located at the rear of the train serves as the control end, that is, the main ATP; and the ATP located at the front of the train serves as the redundant waiting end, that is, the backup ATP.

[0041] Specifically, the core of the two-by-two-take-two redundant architecture includes two parts: "two-by-two" and "two-take-two".

[0042] "Dualization" refers to the use of two identical subsystems to form a redundant system. These two subsystems are functionally equivalent and can replace each other, enabling functions such as hot backup or dual-machine operation. For example, an onboard ATP system includes two ATP subsystems: one for front-end ATP and one for rear-end ATP. During actual vehicle operation, the front-end ATP or rear-end ATP can be used as the primary ATP system based on actual conditions.

[0043] "Two-out-of-two" refers to the use of a two-out-of-two redundant design within each subsystem. For example, the front-end ATP system could integrate two CPUs or similar processing units, which operate in strict synchronization and compare their outputs in real time. Only when the outputs of the two processing units are identical will the calculation result be output externally. The same applies to the rear-end ATP system.

[0044] As can be seen above, every train is equipped with an onboard ATP system. Based on their location, onboard ATP systems can be divided into front-end ATP (located at the front of the train) and rear-end ATP (located at the rear of the train). Based on their control logic, onboard ATP systems can be divided into primary ATP (hereafter referred to as the primary system) and backup ATP (hereafter referred to as the backup system). The primary system is typically responsible for outputting control signals, while the backup system typically does not. However, the backup system synchronizes data with the primary system every cycle. The cycle here refers to the ATP's operating period.

[0045] In practical applications, the ATP at one end of the train typically serves as the primary system, while the ATP at the other end serves as the backup system. Together, they control the safe operation of the train through a two-by-two redundant architecture, achieving automatic train protection and ensuring the reliability and safety of the ATP. If the primary system experiences a failure or abnormality and goes down, the backup system can immediately become the primary. Because the backup system synchronizes data with the primary system during each operating cycle, it is guaranteed to operate correctly and output data without errors after becoming the primary system.

[0046] During actual train operation, the onboard ATP system's primary and backup systems may experience the following common states: primary and backup systems operating normally, primary system operating normally with backup system down, primary system operating normally with backup system asynchronous, primary system down with backup system normally becoming primary, and both primary and backup systems down. In the "primary system operating normally with backup system down" state, the backup system ceases calculations, with only the primary system performing calculations. In the "primary system operating normally with backup system asynchronous" state, the backup and primary systems are out of sync. If the primary system fails, the backup system will not take over, effectively acting as an "outsider." In the "primary system down with backup system normally becoming primary" state, the backup system becomes the primary system, and the original primary system, which was down, ceases calculations. All three of these states represent a single-system operation. If faults are not addressed promptly and the system is left asynchronous or down, system reliability will be significantly reduced. If a single system fails during single-system operation, the control system will completely shut down, causing signal and train control issues, disrupting passenger travel, and posing a significant safety hazard. In the state of "all primary and backup systems are down", it can be understood that the control system is completely down, which is a state with a relatively serious problem.

[0047] Therefore, the last four of the five aforementioned states will render the onboard ATP system unable to continue operating in its two-by-two redundant architecture. If the onboard ATP system is in any of the following three states: the primary system is operating normally with the backup system down, the primary system is operating normally with the backup system down, or the primary system is down with the backup system functioning normally, the system will operate as a single system, reducing safety and reliability. If both the primary and backup systems are down, serious problems can easily arise, posing a significant safety hazard. Therefore, an efficient automatic recovery method is urgently needed to enable the ATP system to resume operating in its two-by-two redundant architecture in these four abnormal conditions.

[0048] According to an optional embodiment of the present specification, the control system includes a main system and a backup system; determining the current operating state of the control system may include the following steps: When the primary system operates normally, the current operating status of the control system is determined based on the notification message sent by the backup system to the primary system.

[0049] Specifically, the notification message may include a first message returned by the backup system in response to a synchronization data packet sent by the primary system, or may include a second message actively sent by the backup system to the primary system.

[0050] Specifically, the first message may include a data synchronization message and a data synchronization failure message. A data synchronization message indicates data synchronization between the backup system and the primary system, while a data synchronization failure message indicates data synchronization between the backup system and the primary system. The second message may include a backup system downtime message, indicating that the backup system has encountered an abnormality and is currently down.

[0051] Furthermore, when the main system is operating normally, based on the message sent by the backup system, when the message is a data synchronization message, the main system can determine that the control system is currently in a state of normal operation of the main and backup systems; when the message is a message that data cannot be synchronized, the main system can determine that the control system is currently in a state of normal operation of the main system and asynchronous operation of the backup system; when the message is a message that the backup system is down, the main system can determine that the control system is currently in a state of normal operation of the main system and a downtime of the backup system.

[0052] In actual applications, when the control system is in operation, data synchronization is performed between the primary system and the backup system at a preset time interval. Optionally, the preset time interval can be determined according to actual application requirements, and can be, for example, a cycle of system operation.

[0053] Alternatively, data synchronization may be achieved in a variety of ways, such as through a dedicated synchronization channel, shared memory, or network protocol, etc. The specific synchronization mechanism may depend on the design of the control system and the choice of the manufacturer.

[0054] Optionally, the master system sends the data to be synchronized in the form of synchronization data packets to the backup system. The backup system receives the synchronization data packets and checks the data consistency.

[0055] Specifically, synchronization packets may contain various types of data, including protocol synchronization data and application synchronization data. Synchronized data can include control system configuration information, train configuration information, relevant information during train operation (such as position and speed), main system time information, I / O data, and so on.

[0056] In actual implementation, when the primary and backup systems are operating normally, data synchronization between the primary and backup systems proceeds normally. The backup system, through the redundancy module, also performs the same data processing tasks as the primary system and obtains calculation results. When the backup system receives a synchronization packet from the primary system, it checks whether the data in the synchronization packet is consistent with the data calculated by the redundancy module. If the data is consistent, the backup system may or may not send a data synchronization message to the primary system. Therefore, the primary system can determine that both the backup and primary systems are operating normally based on the data synchronization message returned by the backup system, or if the backup system does not respond to the synchronization packet.

[0057] If the backup system cannot synchronize data with the primary system using synchronization packets, it can send a message to the primary system indicating the data synchronization failure. Based on the message returned by the backup system, the primary system can determine that the backup system is operating asynchronously with the primary system, placing the control system in a single-system state. In this case, if the primary system fails, the backup system cannot take over or become the primary system.

[0058] If the standby system crashes due to an abnormal reason during operation, the standby system can also send a standby system crash message to the main system. Based on the standby system crash message, the main system can determine that the control system is in a state of normal operation of the main system and the standby system is down.

[0059] By applying this embodiment, the current operating status of the control system can be determined based on the notification message sent by the backup system to the main system when the main system is operating normally. This allows the main system to obtain the current operating status of the control system in real time, so that subsequent automatic recovery processing can be performed in a timely manner when the current operating status is abnormal, which is conducive to helping the control system return to normal as soon as possible, realizing the self-recovery function of the control system, and thus improving the safety and reliability of the control system.

[0060] According to another optional embodiment of the present specification, the method may also be applied to a standby system to determine the current operating state of the control system, and may also include the following steps: In the event of a failure in the main system, the system receives an upgrade instruction from the management platform, upgrades the backup system to the main system, and determines the current operating status of the control system.

[0061] Specifically, the upgrade instruction can be understood as an instruction to control the backup system to upgrade to the main system. The failure of the main system can be understood as the main system downtime, or it can be understood as the main system being unable to output correct information.

[0062] In actual applications, when a main system fails and cannot output correct information to the outside world, the main system can send a request message to the management platform through a preset communication protocol. The management platform can control the main system to shut down based on the request message.

[0063] Furthermore, the management platform can issue an upgrade instruction to the standby system while the standby system is operating normally, thereby controlling the standby system to upgrade to the main system.

[0064] When the backup system receives the upgrade instruction and is upgraded to the primary system, it can be determined that the control system is currently in the state of "the primary system is down and the backup system is upgraded to the primary system normally."

[0065] By applying this embodiment, when a main system fails, the backup system is upgraded to the main system by receiving the upgrade instruction issued by the management platform, and the current operating status of the control system is determined. When the backup system receives the upgrade instruction issued by the management platform and is upgraded to the main system, the current operating status of the control system can be determined, and the newly upgraded main system can obtain the current operating status of the control system in real time, so that subsequent automatic recovery processing can be carried out in time when the current operating status is abnormal, which is conducive to helping the control system return to normal as soon as possible, realizing the self-recovery function of the control system, and thus improving the safety and reliability of the control system.

[0066] According to another optional embodiment of the present specification, the method can be applied to both the primary system and the backup system to determine the current operating state of the control system, and can further include the following steps: The current operating status of the control system is received from the management platform during the current operating cycle of the control system.

[0067] In actual applications, the management platform can monitor the operating status of the main system and the backup system in real time, determine the current operating status of the control system, and send the updated current operating status to the control system every cycle.

[0068] Optionally, both the primary and backup systems can send their status to the management platform during operation. Specific statuses may include failure, downtime, or normal operation. Based on the operating status of the primary and backup systems, the management platform can determine the current operating status of the control system and send the current operating status corresponding to the control system's current operating cycle to the control system.

[0069] According to an optional embodiment of the present specification, the target abnormal state may include: the main system operates normally and the backup system is down, the main system operates normally and the backup system is asynchronous, and the main system is down and the backup system is normally promoted to the main system.

[0070] Specifically, in a target abnormal state, the control system can perform fault processing to autonomously recover to a normal state.

[0071] Optionally, the target abnormal state may be specifically determined according to the situation in actual application, and may not be limited to the above three types.

[0072] By applying this embodiment, by setting the target abnormal state, the fault causes can be collected in advance for the abnormal state that the system can recover autonomously and a recovery strategy corresponding to the fault cause can be formulated, so that a fault recovery program can be written based on the recovery strategy, which is conducive to helping the control system to autonomously recover to a normal state based on the fault recovery program corresponding to the fault cause.

[0073] Step 204: When the current operating state meets the target abnormal state, target fault configuration information corresponding to the target abnormal state is obtained, wherein the target fault configuration information is configured with at least one fault cause in the target abnormal state and a fault recovery program corresponding to each fault cause.

[0074] In practical applications, based on determining the current operating state of the control system, the target fault configuration information corresponding to the target abnormal state can be obtained when the current operating state meets the target abnormal state, thereby determining the target fault cause of the control system based on the target fault configuration information, and then executing the corresponding target fault recovery program to help the control system return to normal state.

[0075] Specifically, the target fault configuration information includes at least one fault cause in the target abnormal state and a fault recovery program corresponding to each fault cause. A fault cause can be understood as the reason that caused the control system to be in the target abnormal state. A fault recovery program can be understood as a program that can handle the fault corresponding to the fault cause to restore the control system to a normal state.

[0076] Optionally, the target fault configuration information can be pre-configured for at least one possible fault cause in the target abnormal state. Further, a corresponding recovery strategy can be configured for the fault cause, and a fault recovery program corresponding to the fault cause can be configured based on the recovery strategy.

[0077] Optionally, the target fault configuration information can be implemented as a fault recovery table. The fault recovery table can include multiple rows, each row including a fault cause and a corresponding fault recovery procedure. The fault cause and the corresponding fault recovery procedure can be stored in the primary system and the backup system in the form of key-value pairs.

[0078] Optionally, in addition to storing as a data structure of key-value pairs, storage can also be performed in a variety of ways such as documents, relational databases, and object storage, and the specific storage method can be determined based on the needs of the actual application.

[0079] When stored in the form of key-value pairs (KV), the corresponding target fault recovery program can be quickly obtained based on the determination of the target fault cause, thereby improving the efficiency of obtaining the target fault recovery program and further improving the efficiency of automatic recovery of the control system.

[0080] For example, the following describes optional fault recovery tables for three abnormal states: primary system operating normally with standby system down, primary system operating normally with standby system asynchronous, and primary system down with standby system normally promoted to master. Table 1 is the fault recovery table for primary system operating normally with standby system asynchronous; Table 2 is the fault recovery table for primary system operating normally with standby system down; and Table 3 is the fault recovery table for primary system down with standby system normally promoted to master.

[0081] Table 1. Fault recovery table corresponding to normal operation of the main system and asynchronous standby system

[0082] Table 2. Fault recovery table corresponding to normal operation of the main system and failure of the backup system

[0083] Table 3. Fault recovery table corresponding to the normal promotion of the primary system to the primary system after the primary system fails

[0084] It should be noted that the abnormal states may include not only the three above-mentioned ones, but more abnormal states that can be self-recovered may be determined according to the needs of actual applications, and a corresponding fault recovery table may be pre-configured for the abnormal state.

[0085] Step 206: Determine the target fault cause of the control system according to the target fault configuration information, and execute a target fault recovery program corresponding to the target fault cause, wherein the target fault recovery program is used to restore the control system to a normal state.

[0086] In practical applications, the target fault cause of the control system can be determined according to the target fault configuration information, and the target fault recovery program corresponding to the target fault cause can be executed, so that the control system can be autonomously restored to a normal state.

[0087] Specifically, the target fault cause can be understood as the fault cause that currently causes the control system to be in the target abnormal state. The target fault cause is one of the fault causes in the target fault configuration information.

[0088] According to an optional embodiment of the present specification, determining the target fault cause of the control system according to the target fault configuration information may include the following steps: Traverse each fault cause in the target fault configuration information to determine the target fault cause of the control system.

[0089] In actual applications, when the main system is operating normally, the main system can traverse each fault cause in the target fault configuration information and check one by one which target fault cause or causes correspond to the control system; when the main system fails and the backup system is normally promoted to the main system, the system newly upgraded to the main system can traverse each fault cause in the target fault configuration information and check one by one which target fault cause or causes correspond to the control system.

[0090] In an optional embodiment of this specification, the target abnormal state may be that the primary system is operating normally and the backup system is asynchronous. The target fault recovery table corresponding to the target abnormal state may include the following fault causes: (1) If there is a problem with the speed measurement module of the backup system, the backup system will think that the speed measurement is invalid and will no longer synchronize with the main system.

[0091] (2) The data synchronization package sent by the primary system is incorrect, resulting in the failure of the backup system to parse. The backup system cannot synchronize data normally and will no longer synchronize with the primary system.

[0092] (3) Memory leaks and other issues may cause the backup system to fail to synchronize data. The backup system cannot synchronize data normally and will no longer synchronize with the primary system.

[0093] It should be noted that the above are examples of possible fault causes when the main system is operating normally and the standby system is in asynchronous state. The types and numbers of specific fault causes can be set according to the needs of actual applications, and this manual does not impose any restrictions on this.

[0094] Optionally, the active system ATP may traverse each fault cause in the target fault configuration information, and check each target fault cause causing the standby system ATP to be asynchronous.

[0095] In another optional embodiment of the present specification, the target abnormal state may be that the primary system is operating normally and the backup system is down. The target fault recovery table corresponding to the target abnormal state may include the following fault causes: (1) The IO cable of the backup system is not properly plugged in.

[0096] (2) There is a problem with the backup system configuration file.

[0097] (3) The standby system shuts down due to timeout of emergency braking.

[0098] It should be noted that the above are examples of possible fault causes when the main system is operating normally but the backup system is down. The types and numbers of specific fault causes can be set according to actual application requirements, and this manual does not impose any restrictions on this.

[0099] Optionally, the active system ATP may traverse each fault cause in the target fault configuration information, and check each target fault cause causing the standby system ATP to crash.

[0100] In another optional embodiment of the present specification, the target abnormal state may be that the primary system is down and the backup system is normally promoted to the primary system. The target fault recovery table corresponding to the target abnormal state may include the following fault causes: (1) The IO line of the main system is loose during operation.

[0101] (2) The main system dual CPU voting fails.

[0102] It should be noted that the above are examples of possible fault causes when the primary system is down and the backup system is normally upgraded to the primary state. The types and numbers of specific fault causes can be set according to the needs of actual applications, and this manual does not impose any restrictions on this.

[0103] Optionally, the ATP newly upgraded to the primary system can traverse each fault cause in the target fault configuration information and check the target fault causes that caused the original primary system ATP to go down one by one.

[0104] By applying this embodiment, by traversing each fault cause in the target fault configuration information, the target fault cause that causes the control system to be in the target abnormal state can be checked, so that the corresponding target fault recovery strategy can be further executed based on the target fault cause to help the control system recover autonomously.

[0105] According to an optional embodiment of the present specification, each fault cause includes a first fault type of system operation fault and a second fault type of business logic fault; traversing each fault cause in the target fault configuration information to determine a target fault cause of the control system may include the following steps: At least one fault cause under the first fault type and at least one fault cause under the second fault type are traversed respectively in a preset order to determine a target fault cause of the control system.

[0106] Specifically, the first fault type can be understood as a fault type during the operation of the system, which can be a problem that occurs during the operation of the main system or a problem that occurs during the operation of the backup system. Specifically, it may include: failure of dual CPU voting of the main system or the backup system, problems with the speed measurement module of the main system or the backup system, loose IO lines of the main system or the backup system, problems with the configuration files of the main system or the backup system, problems with the synchronization data packets sent by the main system, or incorrect calculation results of the backup system, etc. In the event of a fault cause under the first fault type, the system can send a request message to the management platform, and the management platform controls the system to perform asynchronous or downtime processing based on the request message.

[0107] Specifically, the configuration file can be understood as the system configuration files for the primary and backup systems. Both systems can be configured with the same system configuration file. The configuration file can specifically configure parameters such as the software's runtime, data exchange protocols between the system and other systems, and I / O interfaces.

[0108] Specifically, the second fault type can be understood as a business logic fault during train operation, which may include an emergency brake application timeout, etc. In the event of a fault of the second fault type, the system may proactively shut down.

[0109] It should be noted that the fault type can be determined according to the needs of actual application, and this manual does not impose any restrictions on this.

[0110] Specifically, the preset sequence can be understood as the sequence of traversing the fault causes under each fault type.

[0111] Optionally, the preset sequence may be determined according to requirements in actual applications. For example, at least one fault cause under the first fault type may be traversed first, and then at least one fault cause under the second fault type may be traversed.

[0112] By applying this embodiment, by traversing at least one fault cause under the first fault type and at least one fault cause under the second fault type respectively in a preset order, the target fault cause of the control system can be detected in sequence according to the preset order between the fault types, and no fault cause is missed, thereby improving the efficiency and accuracy of determining the target fault cause.

[0113] In one or more optional embodiments of this specification, executing a target fault recovery program corresponding to a target fault cause may include the following steps: The target fault recovery program corresponding to the target fault cause is read from the target fault configuration information and executed.

[0114] In practical applications, the target fault recovery program corresponding to the target fault cause can be directly read from the target fault configuration information, and the target fault recovery program can be executed to restore the control system from the target abnormal state to the normal state.

[0115] Optionally, the target fault recovery program may be pre-written based on a recovery policy corresponding to the target fault cause and configured in the primary system and the backup system.

[0116] In actual applications, when the fault causes and corresponding fault recovery programs in the fault recovery table are stored in the primary system and the backup system in the form of key-value pairs, the corresponding target fault recovery program (V) can be read and executed directly based on the target fault cause (K).

[0117] By applying this embodiment, by reading the target fault recovery program corresponding to the target fault cause from the target fault configuration information, the target fault recovery program can be directly executed, thereby restoring the control system to a normal state and realizing autonomous recovery of the control system, thereby greatly improving the reliability of the control system and further ensuring the safety of train operation and passenger travel.

[0118] One embodiment of the present specification implements determining the current operating state of a control system; when the current operating state meets the target abnormal state, obtaining target fault configuration information corresponding to the target abnormal state, wherein the target fault configuration information is configured with at least one fault cause under the target abnormal state and a fault recovery program corresponding to each fault cause; based on the target fault configuration information, determining the target fault cause of the control system, and executing the target fault recovery program corresponding to the target fault cause, wherein the target fault recovery program is used to restore the control system to a normal state.

[0119] In this way, by determining the current operating state of the control system and obtaining the target fault configuration information corresponding to the target abnormal state when the current operating state meets the target abnormal state, the operating state of the control system can be monitored in real time, and in the case of abnormal state, the control system can be fault-handled based on the pre-configured target fault configuration information; by determining the target fault cause of the control system according to the target fault configuration information and executing the target fault recovery program corresponding to the target fault cause, the control system can be helped to perform autonomous recovery according to the pre-configured fault recovery programs corresponding to each fault cause, so that the control system can be restored to a normal state, thereby improving the reliability of the system and ensuring the safety of train operation and passenger travel.

[0120] The following combined Figure 3 , taking the application of the control system fault handling method provided in this specification in the ATP system as an example, the control system fault handling method is further explained. Figure 3 A flowchart of a control system fault handling method provided in an embodiment of the present specification is shown, which specifically includes the following steps.

[0121] Step 302: The management platform issues an upgrade instruction to the backup system, controlling the backup system to upgrade to the primary system.

[0122] Step 304: The master system determines that the current operating state of the control system is "master system down and standby system normal transition to master", and obtains a fault recovery table corresponding to the master system down and standby system normal transition to master.

[0123] Step 306: The main system traverses the fault recovery table to check the fault cause that caused the abnormal state.

[0124] Step 308: Read the corresponding fault recovery program based on the fault recovery table and execute the fault recovery program to restore the original main system to normal operation, thereby restoring the entire ATP system to normal operation.

[0125] In actual applications, when the fault cause is "failure of dual CPU voting in the main system", the newly upgraded main system can execute the corresponding fault recovery program and send an instruction to restart the original main system to the management platform.

[0126] Furthermore, the management platform can automatically restart the original primary system upon receiving a command to restart it. If the original primary system ATP can operate normally within the specified time and the specified number of self-restarts, no further attempts to restart the ATP will be made, and the ATP will be demoted from primary to backup. Otherwise, the system will shut down directly, and the MMI will notify the driver that the ATP is down and cannot be self-recovered.

[0127] Specifically, the prescribed time and the prescribed number of times are both system configuration values ​​and can be determined according to requirements in actual applications.

[0128] In actual applications, when the cause of the fault is "the IO line of the main system is loose during operation", the newly upgraded main system can execute the corresponding fault recovery program and prompt the driver through the MMI system that the IO line is not plugged in properly and needs to be manually plugged in and the equipment restarted.

[0129] By applying this embodiment, by pre-configuring a fault recovery table corresponding to each abnormal state, when a fault occurs in any of the ATP systems during train operation, the cause of the fault can be quickly located and the corresponding fault recovery program can be obtained based on the fault recovery table corresponding to the abnormal state; ATP can directly execute the fault recovery program, so that the system can quickly and automatically recover to a normal state and continue to operate in a "two by two take two" architecture, thereby improving the reliability of the system and ensuring the safety of train operation and passenger travel.

[0130] Corresponding to the above method embodiment, this specification also provides an embodiment of a fault handling device for a control system, Figure 4 FIG1 shows a schematic diagram of a control system fault handling device provided by an embodiment of this specification. Figure 4 As shown, the device includes: Determining module 402: configured to determine the current operating state of the control system.

[0131] Acquisition module 404: is configured to acquire target fault configuration information corresponding to the target abnormal state when the current operating state meets the target abnormal state, wherein the target fault configuration information is configured with at least one fault cause in the target abnormal state and a fault recovery program corresponding to each fault cause.

[0132] Execution module 406 is configured to determine the target fault cause of the control system according to the target fault configuration information, and execute a target fault recovery program corresponding to the target fault cause, wherein the target fault recovery program is used to restore the control system to a normal state.

[0133] Optionally, the control system includes a main system and a backup system, and the determination module 402 is further configured to: When the primary system operates normally, the current operating status of the control system is determined based on the notification message sent by the backup system to the primary system.

[0134] Optionally, the determination module 402 is further configured to: In the event of a failure in the main system, the system receives an upgrade instruction from the management platform, upgrades the backup system to the main system, and determines the current operating status of the control system.

[0135] Optionally, the target abnormal state includes one of: the main system is operating normally and the backup system is down, the main system is operating normally and the backup system is asynchronous, and the main system is down and the backup system is normally promoted to the main system.

[0136] Optionally, the execution module 406 is further configured to: Traverse each fault cause in the target fault configuration information to determine the target fault cause of the control system.

[0137] Optionally, each fault cause includes a first fault type of system operation fault and a second fault type of business logic fault; the execution module 406 is further configured to: At least one fault cause under the first fault type and at least one fault cause under the second fault type are traversed respectively in a preset order to determine a target fault cause of the control system.

[0138] Optionally, the execution module 406 is further configured to: The target fault recovery program corresponding to the target fault cause is read from the target fault configuration information and executed.

[0139] By applying this embodiment, by determining the current operating state of the control system and, when the current operating state meets the target abnormal state, obtaining the target fault configuration information corresponding to the target abnormal state, the operating state of the control system can be monitored in real time, and in the case of an abnormal state, the control system can be fault-handled based on the pre-configured target fault configuration information; by determining the target fault cause of the control system according to the target fault configuration information and executing the target fault recovery program corresponding to the target fault cause, the control system can be assisted to perform autonomous recovery according to the pre-configured fault recovery programs corresponding to each fault cause, so that the control system can be restored to a normal state, thereby improving the reliability of the system and ensuring the safety of train operation and passenger travel.

[0140] The above is a schematic diagram of a control system fault handling device according to this embodiment. It should be noted that the technical solution of the control system fault handling device and the technical solution of the control system fault handling method described above are based on the same concept. For details not described in detail in the technical solution of the control system fault handling device, please refer to the description of the technical solution of the control system fault handling method described above.

[0141] Figure 5 The block diagram of a computing device 500 according to one embodiment of the present disclosure is shown. Components of the computing device 500 include, but are not limited to, a memory 510 and a processor 520. The processor 520 is connected to the memory 510 via a bus 530, and a database 550 is used to store data.

[0142] The computing device 500 also includes an access device 540 that enables the computing device 500 to communicate via one or more networks 560. Examples of such networks include a public switched telephone network (PSTN), a local area network (LAN), a wide area network (WAN), a personal area network (PAN), or a combination of communication networks such as the Internet. The access device 540 may include one or more of any type of network interface (e.g., a network interface card (NIC)) whether wired or wireless, such as an IEEE 802.11 wireless local area network (WLAN) wireless interface, a Worldwide Interoperability for Microwave Access (Wi-MAX) interface, an Ethernet interface, a universal serial bus (USB) interface, a cellular network interface, a Bluetooth interface, or a near field communication (NFC) interface.

[0143] In one embodiment of the present specification, the above components of the computing device 500 and Figure 5 Other components not shown in the figure may also be connected to each other, for example, via a bus. Figure 5 The computing device structure block diagram shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art may add or replace other components as needed.

[0144] Computing device 500 can be any type of stationary or mobile computing device, including a mobile computer or mobile computing device (e.g., a tablet computer, personal digital assistant, laptop computer, notebook computer, netbook computer, etc.), a mobile phone (e.g., a smartphone), a wearable computing device (e.g., a smartwatch, smart glasses, etc.), or other types of mobile devices, or a stationary computing device such as a desktop computer or personal computer (PC). Computing device 500 can also be a mobile or stationary server.

[0145] The processor 520 is configured to execute the following computer-executable instructions, which, when executed by the processor, implement the steps of the fault handling method for the control system.

[0146] The above is a schematic diagram of a computing device according to this embodiment. It should be noted that the technical solution of the computing device and the technical solution of the control system fault handling method described above are based on the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the control system fault handling method described above.

[0147] An embodiment of the present specification further provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the steps of the fault handling method for the control system.

[0148] The above is a schematic diagram of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the control system fault handling method described above are based on the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the control system fault handling method described above.

[0149] An embodiment of the present specification further provides a computer program product, comprising a computer program / instruction, which implements the steps of the fault handling method of the control system when executed by a processor.

[0150] The above is a schematic solution of a computer program product of this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the control system fault handling method described above are based on the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the control system fault handling method described above.

[0151] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0152] The computer instructions include computer program code, which may be in source code form, object code form, executable file, or some intermediate form. The computer-readable medium may include any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard drive, magnetic disk, optical disk, computer memory, read-only memory (ROM), random access memory (RAM), electric carrier signal, telecommunication signal, and software distribution medium. It should be noted that the content of the computer-readable medium may be appropriately increased or decreased based on the requirements of patent practice. For example, in some regions, according to patent practice, computer-readable media does not include electric carrier signals and telecommunication signals.

[0153] It should be noted that for the aforementioned method embodiments, for the sake of simplicity of description, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the embodiments of this specification are not limited by the order of the actions described, because according to the embodiments of this specification, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the embodiments of this specification.

[0154] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described in detail in a certain embodiment, reference can be made to the relevant descriptions of other embodiments.

[0155] The preferred embodiments disclosed above are intended only to help illustrate this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific embodiments described. Obviously, many modifications and variations can be made based on the content of the embodiments of this specification. This specification selects and specifically describes these embodiments in order to better explain the principles and practical applications of the embodiments of this specification, so that those skilled in the art can better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A control system fault handling method, characterized in that: include: Determine the current operating status of the control system; When the current operating state meets the target abnormal state, obtaining target fault configuration information corresponding to the target abnormal state, wherein the target fault configuration information is configured with at least one fault cause in the target abnormal state and a fault recovery program corresponding to each fault cause; According to the target fault configuration information, a target fault cause of the control system is determined, and a target fault recovery program corresponding to the target fault cause is executed, wherein the target fault recovery program is used to restore the control system to a normal state.

2. The method according to claim 1, characterized in that The control system includes a main system and a backup system; Determining the current operating state of the control system includes: In the case that the main system operates normally, the current operating state of the control system is determined based on the notification message sent by the backup system to the main system.

3. The method according to claim 2, characterized in that The determining of the current operating state of the control system further includes: In the event of a failure in the primary system, an upgrade instruction issued by a management platform is received, the backup system is upgraded to the primary system, and the current operating status of the control system is determined.

4. The method according to claim 1, wherein The target abnormal state includes one of: the main system is operating normally and the backup system is down, the main system is operating normally and the backup system is asynchronous, and the main system is down and the backup system is normally promoted to the main system.

5. The method according to claim 1, wherein Determining the target fault cause of the control system according to the target fault configuration information includes: Each fault cause in the target fault configuration information is traversed to determine a target fault cause of the control system.

6. The method according to claim 5, characterized in that The fault causes include a first fault type of system operation fault and a second fault type of business logic fault; The traversing each fault cause in the target fault configuration information to determine the target fault cause of the control system includes: At least one fault cause under the first fault type and at least one fault cause under the second fault type are traversed in a preset order to determine a target fault cause of the control system.

7. The method according to claim 5 or 6, characterized in that The executing the target fault recovery program corresponding to the target fault cause includes: A target fault recovery program corresponding to the target fault cause is read from the target fault configuration information and executed.

8. A fault handling device for a control system, characterized in that: include: a determination module configured to determine a current operating state of the control system; an acquisition module configured to, when the current operating state meets the target abnormal state, acquire target fault configuration information corresponding to the target abnormal state, wherein the target fault configuration information is configured with at least one fault cause in the target abnormal state and a fault recovery program corresponding to each fault cause; An execution module is configured to determine a target fault cause of the control system according to the target fault configuration information, and execute a target fault recovery program corresponding to the target fault cause, wherein the target fault recovery program is used to restore the control system to a normal state.

9. A computing device, characterized in that include: memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions. When the computer programs / instructions are executed by the processor, the steps of the fault handling method of the control system according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium, characterized in that It stores a computer program / instruction, which, when executed by a processor, implements the steps of the fault handling method of the control system according to any one of claims 1 to 7.

11. A computer program product, characterized in that The method comprises a computer program / instruction, which, when executed by a processor, implements the steps of the fault handling method of the control system according to any one of claims 1 to 7.

Images