Vehicle door and shielding door linkage fault diagnosis and analysis method and system

Abstract

The invention provides a vehicle door and shielding door linkage fault diagnosis and analysis method and system, and belongs to the technical field of urban rail transit, and the method comprises the steps: judging whether the linkage state of a vehicle door and a shielding door has a fault or not based on the vehicle-mounted log data of a vehicle; when the linkage state of the vehicle door and the shielding door has a fault, the fault type is determined; establishing a fault tree model corresponding to the fault type; state confirmation is conducted on top events and sub-events in the fault tree model layer by layer, fault causes are obtained, the top events are linkage faults of the vehicle door and the shielding door, and the sub-events comprise control instruction problems and communication connection problems related to the vehicle door and the shielding door. The linkage state of the vehicle door and the shielding door is monitored in real time through the vehicle-mounted log data, the fault types are automatically classified, and the node state is diagnosed layer by layer based on the fault tree model, so that the linkage fault of the vehicle door and the shielding door is accurately detected and diagnosed, and the fault processing efficiency is improved.

Description

Technical Field

[0001] The present invention relates to the technical field of urban rail transit, and in particular to a method and system for diagnosing and analyzing linkage faults between a vehicle door and a platform shielding door. Background Art

[0002] With the rapid development of urban rail transit, the automation level of public transportation systems such as subways and light rails is increasing, and passenger safety and system operation efficiency have become core concerns. Especially in modern urban rail transit systems, the linkage control of car doors and platform screen doors is directly related to the safe entry and exit of passengers and the normal operation of trains. The linkage between car doors and platform screen doors depends on the complex command transmission and multi-system collaboration in the signal system. Usually, after the train enters the station, the signal system will determine whether the conditions for opening the car doors are met, and send a door opening command to the vehicle control system (such as VOBC), and then synchronously trigger the opening of the platform screen door. Under normal circumstances, the car doors and platform screen doors will move synchronously to ensure passenger safety.

[0003] However, in actual operation, the linkage failure between car doors and platform shielding doors is a common technical problem. This failure may be caused by reasons such as failure to issue control instructions correctly, interruption of communication connection, or inconsistent equipment execution. Existing technical practices mainly rely on on-site observations by drivers or manual analysis of log data by operators to determine faults, and then technicians check the vehicles, signal systems, and platform shielding door equipment one by one. This approach has multiple problems in practice. First, the detection of faults is often delayed, and the troubleshooting process can only be started after the driver or operator discovers the linkage abnormality. Secondly, the fault location process is time-consuming, especially in scenarios where multiple systems collaborate, and the complex communication relationship between systems makes it difficult to quickly determine the source of the fault.

[0004] Therefore, how to accurately detect and diagnose the linkage failure between the vehicle door and the shield door to improve the efficiency of fault handling has become a technical problem that needs to be solved urgently. Summary of the invention

[0005] The present invention provides a method, system, electronic equipment and storage medium for diagnosing and analyzing the linkage fault of a vehicle door and a platform shielding door, which are used to solve the defects in the prior art and realize accurate detection and diagnosis of the linkage fault of the vehicle door and the platform shielding door, so as to improve the efficiency of fault handling.

[0006] The present invention provides a method for diagnosing and analyzing the linkage fault between a vehicle door and a platform shielding door, comprising the following steps: judging whether there is a fault in the linkage state between the vehicle door and the platform shielding door based on the vehicle-mounted log data; When there is a fault in the linkage state between the car door and the shield door, determine the fault type; Establishing a fault tree model corresponding to the fault type; The status of the top event and sub-events in the fault tree model are confirmed layer by layer to obtain the cause of the fault, wherein the top event is the linkage fault of the vehicle door and the platform shielding door, and the sub-events include control instruction problems and communication connection problems related to the vehicle door and the platform shielding door.

[0007] According to a method for diagnosing and analyzing a linkage fault between a vehicle door and a platform shielding door provided by the present invention, the state of the top event and the sub-event in the fault tree model is confirmed layer by layer to obtain the cause of the fault, specifically including: Confirming the status of the top events and sub-events in the fault tree model layer by layer to obtain the status of each node; Based on the status of each of the nodes, the cause of the failure is determined.

[0008] According to a method for diagnosing and analyzing a linkage fault between a vehicle door and a platform shielding door provided by the present invention, the state of the top event and the sub-event in the fault tree model is confirmed layer by layer to obtain the state of each node, specifically including: Confirming the status of the top event, and when it is confirmed that the top event is in an abnormal state, further checking the sub-events; The control instructions, communication connection status and actual actions of the vehicle door and the shielding door included in the sub-events are analyzed layer by layer to obtain the status of each node.

[0009] According to a method for diagnosing and analyzing a linkage fault between a vehicle door and a platform shielding door provided by the present invention, the control instructions, communication connection status and actual actions included in the sub-events are analyzed layer by layer to obtain the status of each node, specifically including: Checking the execution status of the control instruction in the sub-event to obtain a first checking result; When the first inspection result indicates that the control instruction is executed normally, further inspecting the communication connection state included in the sub-event to obtain a second inspection result; When the second inspection result indicates that the communication connection state is normal, checking whether the actual actions of the vehicle door and the platform shield door match the control instruction to obtain a third inspection result; Based on the first inspection result, the second inspection result and the third inspection result, the states of corresponding nodes in the fault tree model are marked layer by layer to obtain the states of each node.

[0010] According to a method for diagnosing and analyzing a linkage fault between a vehicle door and a platform shielding door provided by the present invention, judging whether there is a fault in the linkage state between the vehicle door and the platform shielding door based on the vehicle log data specifically includes: Extracting a door status field and a shield door status field from the vehicle-mounted log data; When the door status field is inconsistent with the platform shielding door status field, and the duration of the inconsistency reaches a preset duration, it is determined that there is a fault in the linkage state of the door and the platform shielding door; When the vehicle door status field is consistent with the platform shielding door status field, it is determined that there is no fault in the linkage status between the vehicle door and the platform shielding door.

[0011] According to a method for diagnosing and analyzing a linkage fault between a vehicle door and a platform shielding door provided by the present invention, the method further comprises: Visually display the process of fault diagnosis for the fault type according to the fault tree troubleshooting process to obtain a visual result of the fault diagnosis; The visualization result of the fault diagnosis and the cause of the fault are sent to the administrator terminal.

[0012] The present invention also provides a vehicle door and screen door linkage fault diagnosis and analysis system, comprising the following modules: a processing module and a fault diagnosis module; The processing module is used to determine whether there is a fault in the linkage state between the vehicle door and the platform shield door based on the vehicle log data; The processing module is further used to determine the fault type when there is a fault in the linkage state between the vehicle door and the shield door; The fault diagnosis module is used to establish a fault tree model corresponding to the fault type; The fault diagnosis module is also used to confirm the status of the top event and sub-events in the fault tree model layer by layer to obtain the cause of the fault, wherein the top event is the linkage failure of the vehicle door and the platform shielding door, and the sub-events include control instruction problems and communication connection problems related to the vehicle door and the platform shielding door.

[0013] The present invention also provides an electronic device, comprising a memory, a processor and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the method for diagnosing and analyzing the linkage faults of vehicle doors and shielding doors as described above is implemented.

[0014] The present invention also provides a non-transitory computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the method for diagnosing and analyzing the linkage faults of a vehicle door and a shielding door as described in any one of the above is implemented.

[0015] The present invention also provides a computer program product, comprising a computer program, wherein when the computer program is executed by a processor, the method for diagnosing and analyzing the linkage faults of a vehicle door and a platform shielding door as described above is implemented.

[0016] In summary, one or more technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages: Through this technical solution, firstly, based on the vehicle's onboard log data, it is determined whether there is a fault in the linkage state between the door and the platform shielding door, and real-time and automatic fault monitoring can be achieved. The onboard log data provides detailed status information during the operation of the train. The system can quickly and accurately detect whether there is an abnormal linkage between the door and the platform shielding door by analyzing these log data. When the system detects that there is a fault in the linkage state between the door and the platform shielding door, the system will determine the type of fault. Through this solution, the system can automatically classify different fault types according to the specific status of the door and the platform shielding door. This automated fault classification can make the fault location more accurate and provide a clear direction for subsequent troubleshooting. Next, the system performs fault diagnosis on the determined fault type according to the fault tree troubleshooting process. The fault tree model can decompose the fault problem in a structured manner and gradually narrow the fault source to a specific subsystem or component. By analyzing the node status in the fault tree layer by layer, the system can effectively identify the cause of the fault, especially when the linkage between the door and the platform shielding door involves multiple systems, the fault tree model can greatly reduce the scope of troubleshooting. In this way, the system can quickly locate problems with control instructions, communication links or actuators in a short period of time, avoiding unnecessary comprehensive inspections, thereby accurately detecting and diagnosing door and shield door linkage failures to improve fault handling efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] In order to more clearly illustrate the technical solutions in the present invention or the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0018] Figure 1 It is one of the flow diagrams of the vehicle door and shield door linkage fault diagnosis and analysis method provided by the present invention.

[0019] Figure 2 This is the second flow chart of the method for diagnosing and analyzing the linkage faults of vehicle doors and platform shielding doors provided by the present invention.

[0020] Figure 3 This is the third flow chart of the method for diagnosing and analyzing the linkage faults of vehicle doors and shield doors provided by the present invention.

[0021] Figure 4 This is the fourth flow chart of the method for diagnosing and analyzing the linkage faults of vehicle doors and shield doors provided by the present invention.

[0022] Figure 5 It is a structural schematic diagram of the vehicle door and shield door linkage fault diagnosis and analysis system provided by the present invention.

[0023] Figure 6 It is a structural schematic diagram of the electronic device provided by the present invention. DETAILED DESCRIPTION

[0024] In order to make the purpose, technical solution and advantages of the present invention clearer, the technical solution of the present invention will be clearly and completely described below in conjunction with the drawings of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0025] It should be noted that, in the description of the present invention, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "include one..." do not exclude the existence of other identical elements in the process, method, article or device including the elements. The orientation or positional relationship indicated by the terms "upper", "lower", etc. is based on the orientation or positional relationship shown in the accompanying drawings, and is only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the system or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore cannot be understood as a limitation on the present invention. For those of ordinary skill in the art, the specific meanings of the above terms in the present invention can be understood according to the specific circumstances.

[0026] The terms "first", "second", etc. in the present invention are used to distinguish similar objects, and are not used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances, so that the embodiments of the present invention can be implemented in an order other than those illustrated or described herein, and the objects distinguished by "first", "second", etc. are generally of the same type, and the number of objects is not limited. For example, the first object can be one or more. In addition, "and / or" means at least one of the connected objects, and the character " / " generally indicates that the objects associated with each other are in an "or" relationship.

[0027] Combine the following Figure 1-Figure 6 The present invention describes a method, system, electronic device and storage medium for diagnosing and analyzing the linkage faults of vehicle doors and platform shield doors.

[0028] Figure 1 FIG. 1 is one of the flow charts of the method for diagnosing and analyzing the linkage faults of vehicle doors and shield doors provided by the present invention, such as Figure 1 As shown, including but not limited to the following steps: Step 101: Based on the vehicle log data, determine whether there is a fault in the linkage state between the vehicle door and the platform shield door.

[0029] In the urban rail transit system, the linkage state between the doors and the platform shielding door directly affects the normal operation of the train and the safety of the passengers. When the doors and the platform shielding door fail to link normally, it will not only delay the departure of the train, but also may cause safety hazards. Therefore, accurately judging whether there is a fault in the linkage state between the doors and the platform shielding door is a key step in the automated diagnosis process. In this embodiment, judging whether there is a fault in the linkage state between the doors and the platform shielding door is based on the vehicle's onboard log data, and the specific implementation is as follows.

[0030] In a possible implementation, step 101 specifically includes the following steps: Extract the door status field and the shield door status field from the vehicle log data; When the door status field is inconsistent with the platform shielding door status field, and the inconsistency duration reaches a preset duration, it is determined that there is a fault in the linkage state of the door and the platform shielding door; When the door status field is consistent with the platform shielding door status field, it is determined that there is no fault in the linkage status of the door and the platform shielding door.

[0031] Specifically, first, the vehicle door status field and the platform shield door status field recorded during the vehicle operation are extracted in real time through the vehicle log system. These two fields reflect the real-time switch status information of the vehicle door and the platform shield door respectively. Under normal circumstances, when the train enters the station, the signal system issues a door opening command, and the vehicle door and the platform shield door should perform the opening action synchronously, and then perform the closing action synchronously after the passengers get on and off the train. Therefore, the status of these two fields should be consistent during the linkage process.

[0032] In order to ensure that the system can respond promptly to possible linkage failures, a preset duration needs to be set. That is, when the time that the door status field and the shield door status field are inconsistent reaches the preset threshold, the system will determine that there is a fault in the linkage status of the door and the shield door. This preset duration is set to avoid the system from misjudging instantaneous inconsistencies (such as short communication delays or device response delays), thereby improving the accuracy of the system's fault detection. In actual operation, the preset duration can be dynamically adjusted according to the specific operating environment of the system and the response time of the device to ensure that both the actual linkage failure can be captured and unnecessary false alarms can be avoided.

[0033] Once the system detects that the door status field and the platform screen door status field remain inconsistent within the preset time, it will immediately determine that there is an abnormality in the linkage between the door and the platform screen door. This judgment mechanism can ensure that the system can detect potential linkage failures in the shortest time, thereby providing a basis for subsequent fault diagnosis. If the system detects that the two status fields are consistent and there is no inconsistency within the preset time, it is judged that the linkage status between the door and the platform screen door is normal, and the train can continue to operate normally.

[0034] Through this linkage fault detection method based on onboard log data, the system can monitor the operating status of the doors and platform screen doors in real time and automatically, effectively reducing the delay and misjudgment of manual troubleshooting. In practical applications, this method not only improves the efficiency of fault detection, but also greatly reduces the downtime caused by linkage faults during train operation, thereby ensuring the safety and reliability of the rail transit system.

[0035] Step 102: When there is a fault in the linkage state between the vehicle door and the shield door, determine the fault type.

[0036] After the linkage status between the car door and the platform shield door is judged to be faulty, the system's first task is to quickly determine the specific type of fault. Since the linkage between the car door and the platform shield door involves the collaborative work of multiple subsystems, such as the sending of control instructions, the transmission of communication links, and the execution feedback of the car door and the platform shield door, if we only know that the linkage is abnormal, but fail to further clarify which link has a problem, the troubleshooting process will be very cumbersome and inefficient. By automatically determining the fault type, more targeted guidance can be provided for subsequent troubleshooting, significantly reducing troubleshooting time and improving diagnostic efficiency.

[0037] The following types of faults are possible: (1) The car door is open, but the shield door is not open: This fault is usually caused by the platform shield door system not receiving the door opening command from the central control system, or due to a problem with the actuator of the platform shield door itself. The system will first confirm that the status field of the car door is displayed as "open", but the status field of the platform shield door has not changed to "open", and the inconsistent state exceeds the preset time. The system will determine that the fault type is "car door open, platform shield door not open".

[0038] (2) The car door is not open, but the shield door is open: This type of fault reflects that the car door failed to respond to the door opening command, but the shield door has already performed the door opening operation. This fault may be caused by the control command of the vehicle system not being correctly sent to the car door execution system, or there is a problem with the door actuator. The system will check the door opening command transmission path in the log, combined with the state that the car door is not open but the shield door is open, and determine the fault type as "car door is not open, shield door is open".

[0039] (3) The car door is closed but the shield door is not closed: Before the train departs, the doors and platform shield doors should be closed at the same time. If the platform shield doors fail to close synchronously after the doors are closed, the system will find that the door status is "closed" in the log data, but the platform shield door status field has not changed, and the preset time has been exceeded. At this time, the system determines the fault type as "door closed, platform shield door not closed".

[0040] (4) The car door is not closed and the shield door is closed: This type of fault reflects that the platform shield door is closed prematurely before the car door is fully closed, which may cause passengers to be trapped or equipment to be damaged. The system determines the fault type as "car door is not closed, platform shield door is closed" by detecting that the car door status field has not changed to "closed" and the platform shield door status has been displayed as "closed".

[0041] Step 103: Establish a fault tree model corresponding to the fault type.

[0042] Specifically, first, the system establishes a corresponding fault tree model based on the determined fault type. The core of the fault tree model is to decompose the top event (i.e., the linkage fault between the door and the shield door) into a series of sub-events, which cover multiple system levels such as the door, shield door, control instructions and communication links. Through this hierarchical progressive analysis, the system can gradually narrow the scope of fault troubleshooting. For example, when the fault type is determined to be "the door is closed, but the shield door is not closed", the fault tree model will start from the top event (i.e., the linkage is not closed fault) and gradually analyze possible sub-events, such as whether the VOBC (Vehicle On-Board Controller) control instruction is sent correctly, whether the CI (Central Interlocking) system receives the instruction, and whether the shield door actuator responds.

[0043] Step 104: Confirm the status of the top event and sub-events in the fault tree model layer by layer to obtain the cause of the fault, wherein the top event is the linkage fault between the vehicle door and the platform shielding door, and the sub-events include control instruction problems and communication connection problems related to the vehicle door and the platform shielding door.

[0044] By confirming the status of the top events and sub-events in the fault tree model layer by layer, the source of the fault can be systematically and structuredly checked, the problem can be quickly identified, unnecessary comprehensive inspections can be avoided, and the troubleshooting time can be shortened.

[0045] The construction of the fault tree model is based on the detected failure of the linkage between the car door and the platform shield door, which is defined as the top event. The top event represents the overall system failure, that is, the car door and the platform shield door cannot be properly linked according to the command. For example, the car door has been opened but the platform shield door has not been opened synchronously, or the car door has been closed but the platform shield door has not been closed. The top event essentially reflects the result of the overall system failure. To solve the problem, it is necessary to go deep into the different sub-event levels of the system to find the specific cause of the top event.

[0046] To diagnose the top event, the system checks each sub-event in the fault tree model layer by layer. These sub-events include control command problems and communication connection problems related to the linkage of doors and platform shielding doors. Control command problems involve whether the doors and platform shielding doors receive the correct opening and closing commands, while communication connection problems involve whether the transmission of these commands between different subsystems is delayed or interrupted.

[0047] In one possible implementation, refer to Figure 2 , Figure 2 This is the second flow chart of the method for diagnosing and analyzing the linkage faults of vehicle doors and shield doors provided by the present invention. Step 104 specifically includes steps 201-202: Step 201: confirm the status of the top event and sub-events in the fault tree model layer by layer to obtain the status of each node.

[0048] Specifically, after establishing the fault tree model, the system will confirm the status of the top event and sub-event layer by layer. This process is achieved by analyzing the on-board log data. For each sub-event, the system will check the relevant status information, such as the sending of control instructions, the status of communication connections, and the actual execution of the equipment. Specifically, the system first confirms the top event, that is, the status of the linkage fault, and then checks each subsystem step by step to see if it is normal. For example, after confirming that the control instruction has been sent correctly, the system will further check whether the communication between the car door and the shield door is normal. If the communication is normal, it will check the feedback of the actuator. Through this layer-by-layer confirmation method, the system can gradually lock the specific node where the fault occurs and mark its status.

[0049] This layer-by-layer troubleshooting can not only determine whether there is a hardware fault in the system (for example, the actuator cannot function normally), but also detect potential soft faults (for example, the control instruction fails to be sent on time or the communication signal is lost). The system confirms the status of each sub-event node and finally obtains a complete fault tree model state diagram, which can intuitively show the health status of each system component and indicate which link has an abnormality.

[0050] Step 202: Determine the cause of the failure based on the status of each node.

[0051] Specifically, once the status of each node is confirmed layer by layer, the system automatically analyzes and derives the final cause of the fault based on this status information. By analyzing the fault tree model, the system can clearly indicate which subsystem or component caused the fault. For example, if the system finds that the communication link is normal but the shield door execution feedback is abnormal, it can be inferred that there is a fault in the shield door actuator; if it is found that the control command is not sent, it indicates that the problem may be in the VOBC system or the central control system. In this way, the system can accurately locate the source of the fault, thereby providing clear instructions to maintenance personnel and guiding them to take targeted maintenance measures.

[0052] Through the fault tree troubleshooting process provided by steps 201-202, the system can significantly shorten the troubleshooting time, reduce the tedious steps of checking the entire system one by one, and improve the accuracy and efficiency of diagnosis. Compared with the traditional manual item-by-item troubleshooting method, the use of the fault tree can make the problem location more systematic and structured, and can handle a variety of complex fault scenarios. The automation and intelligence of this process not only reduces the labor cost of maintenance, but also effectively reduces the risk of misdiagnosis of faults.

[0053] In one possible implementation, refer to Figure 3 , Figure 3 This is the third flow chart of the method for diagnosing and analyzing the linkage faults of vehicle doors and platform shield doors provided by the present invention. Step 201 specifically includes steps 301-302: Step 301: Confirm the status of the top event. When the top event is confirmed to be in an abnormal state, further check the sub-events.

[0054] Specifically, the top event represents the linkage failure of the vehicle door and the platform shielding door in the fault tree model. The top event is based on the fault type determined in step 102, such as "the vehicle door is open, the platform shielding door is not open" or "the vehicle door is not closed, the platform shielding door is closed". In this case, the status confirmation of the top event means that the system needs to cross-check the actual operation of the vehicle door and the platform shielding door to confirm whether the linkage failure has actually occurred.

[0055] The system further confirms whether the linkage fault conditions are met by reading the door status field and the shield door status field in the vehicle log data. For example, when the state of the door being open and the shield door not being open is detected, and this inconsistent state lasts for more than the preset time threshold, the system will confirm the top event as an abnormal state. Confirming this state is crucial because it determines whether further in-depth analysis of the sub-event is required.

[0056] The purpose of this status confirmation is to ensure that the system does not perform redundant analysis during the troubleshooting process. If the top event is not confirmed as an abnormal state, it means that there is no problem with the linkage between the car door and the shield door, and the system can stop the subsequent troubleshooting process to save time and computing resources. However, once the top event is confirmed as an abnormal state, the system immediately starts the analysis process of the sub-events to gradually troubleshoot potential fault sources.

[0057] After the top event is confirmed as an abnormal state, the system will continue to check the sub-events. These sub-events involve multiple system-level factors, such as control instruction problems and communication connection problems. The purpose is to deeply analyze the cause of the fault from multiple dimensions. Through the preliminary confirmation of the top event, the system ensures that the sub-event analysis stage is only entered when the linkage fault actually exists, thereby improving the accuracy of diagnosis and avoiding resource waste and misjudgment.

[0058] Step 302: Analyze the control instructions, communication connection status and actual actions of the vehicle door and the shielding door included in the sub-event layer by layer to obtain the status of each node.

[0059] In step 301, the system has confirmed that the linkage failure between the door and the platform shield door has been confirmed by confirming that the top event is in an abnormal state. In order to locate the cause of the failure more accurately, the system conducts a detailed inspection of the sub-events in step 302. The purpose of this step is to conduct a hierarchical analysis of the sub-events in the fault tree model and gradually troubleshoot each link related to the linkage failure to accurately find the root cause of the problem. Since the linkage between the door and the platform shield door involves multiple subsystems, such as control instructions, communication connections, and equipment execution, the system must analyze the status of these subsystems layer by layer to ensure that the troubleshooting process is comprehensive and targeted.

[0060] The following embodiment will explain the specific implementation method of step 302 in detail.

[0061] In one possible implementation, refer to Figure 4 , Figure 4 This is the fourth flow chart of the method for diagnosing and analyzing the linkage faults of vehicle doors and shield doors provided by the present invention. Step 302 specifically includes steps 401-404: Step 401: Check the execution status of the control instruction in the sub-event to obtain a first check result.

[0062] The reason why we check the control instructions first is that in the urban rail transit system, the linkage process between the car door and the platform shield door first depends on the correct instructions issued by the control system. If the instructions are not sent or received correctly, no matter how normal the subsequent communication or execution links are, the linkage failure cannot be avoided. Therefore, checking the execution of control instructions is the first step in troubleshooting and the basis for ensuring the accuracy and efficiency of troubleshooting.

[0063] In the specific implementation process, the system verifies whether the VOBC subsystem has correctly issued the door opening or closing command to the CI subsystem by reading the command record in the onboard log data. In order to ensure the comprehensiveness of the inspection, the system will compare the time when the command is sent with the actual arrival time of the train, and check whether the content of the command meets the requirements of the current station and train operation status. If the opening and closing command of the door or screen door is not issued within the specified time, or the content of the command does not match the current operation, the system will mark the control command as abnormal.

[0064] For example, when the fault type is "door closed, shield door not closed", the system will first check whether VOBC has issued a command to CI to close the door and shield door. If the system finds that VOBC has not issued a command to close the shield door, or the command fails to reach the CI subsystem in time, this will be regarded as abnormal execution of the control command. At this time, the system will take this result as the first check result and record it as "control command abnormality".

[0065] If the system confirms that the sending and execution of the control instructions are completely normal, the control instruction problem can be ruled out, and this status is recorded as "control instruction normal", and then proceed to the next inspection step.

[0066] Step 402: When the first check result indicates that the control instruction is executed normally, further check the communication connection status included in the sub-event to obtain a second check result.

[0067] In step 401, the system has completed the check on the execution of the control instruction. If the control instruction is confirmed to be executed normally, but the linkage fault still exists, it is likely that the problem occurs in the transmission link of the control instruction, that is, the communication connection status. Therefore, in step 402, the system will further check the communication connection status in the sub-event.

[0068] In the specific implementation process, the system reads the communication status recorded in the vehicle log data, focusing on checking the communication links between the VOBC and CI subsystems, and between the CI and the shielded door system. In this step, the system verifies the connection status of each communication link to ensure that the signal is correctly transmitted and received within the specified time. For example, the system checks the following key indicators: (1) The stability of the communication link, whether there is any interruption or loss of connection; (2) Whether the delay time of signal transmission is within the preset delay range; (3) The packet loss rate, whether there are lost control signals or feedback signals that fail to be successfully transmitted.

[0069] Assuming that in the fault type "car door open, shield door not open", the system finds that the control command has been issued normally, but the shield door fails to open, the system will check whether there is a problem with the communication link from CI to the shield door system. If the communication link is found to be interrupted or the delay exceeds the allowable range, the system will record this problem as "communication connection abnormality". This result will be used as the second inspection result to prompt the system and operation and maintenance personnel that the source of the fault lies in the failure of the communication link, further clarifying the direction of troubleshooting.

[0070] If the communication connection status is checked and confirmed to be normal, the system will mark the sub-event as "communication connection normal" and record the result as the second inspection result. At this time, the system can rule out the possibility of communication link failure and continue to the next step of checking the hardware execution status.

[0071] Step 403: When the second inspection result indicates that the communication connection state is normal, check whether the actual actions of the vehicle door and the platform shield door match the control instruction to obtain a third inspection result.

[0072] In step 402, the system has confirmed that the communication connection is normal. If the control instructions and the communication link are operating normally, but the linkage failure still exists, the problem is likely to occur at the execution level of the device itself. Therefore, in step 403, the system needs to check whether the actual actions of the car door and the shielding door match the control instructions.

[0073] In specific implementation, the system will check the execution of the doors and platform shield doors one by one according to their actual feedback status in the vehicle log data. The system first compares the status fields of the doors and platform shield doors to determine whether they have performed the door opening or door closing operations as expected after receiving the control command. The system compares the state changes of the doors and platform shield doors in the log with the corresponding control command timestamps to ensure that their execution actions meet the command requirements. For example, when the system receives a door opening command, the status fields of the doors and platform shield doors should change from "closed" to "opened" almost at the same time. Any inconsistency or significant time delay will be marked as an abnormality by the system.

[0074] Assume that in the fault type "Car door closed, platform shield door not closed", the system finds that the platform shield door is not closed within the expected time. At this time, the system will check the actual feedback status of the platform shield door. If it is found that the platform shield door actuator fails to respond to the closing command, the system will record the problem as "platform shield door actuator failure". This inspection result will be used as the third inspection result to prompt the system and operation and maintenance personnel that the fault is caused by the hardware execution problem of the platform shield door. At this time, the system will recommend maintenance personnel to further inspect and repair the mechanical part or controller of the platform shield door.

[0075] If the execution of the car door and the shield door completely matches the control instruction, the system will mark the sub-event as "normal execution" and record this result as the third inspection result.

[0076] Step 404: Based on the first inspection result, the second inspection result and the third inspection result, the status of the corresponding nodes in the fault tree model is marked layer by layer to obtain the status of each node.

[0077] In the previous steps, the system has completed the inspection of the control instructions, communication connection status and equipment execution status one by one. Each step produces corresponding inspection results: whether the control instructions are executed correctly, whether the communication link is normal, and whether the equipment acts according to the instructions. In step 404, the system integrates these inspection results and marks the status of the corresponding nodes layer by layer in the fault tree model. The core goal of this step is to systematize and structure the previous analysis results, so as to achieve the final determination of the cause of the fault.

[0078] In specific implementation, the system first marks the status of the control instruction node according to the first check result of step 401. If the system confirms at this stage that the control instruction has not been correctly sent or received, the node will be marked as "abnormal". Next, the system will mark the communication connection status node according to the second check result of step 402. If the communication connection status is judged to be normal, the node will be marked as "normal"; if there is a problem with the communication, the system will mark the communication node as "abnormal". Finally, the system marks the status of the device execution node according to the third check result of step 403. If the device action matches the control instruction, the node is marked as "normal"; if the device fails to act according to the instruction, the system will mark the node as "abnormal".

[0079] This layer-by-layer labeling process helps to establish a clear fault path. For example, in the case of a fault type of "door closed, shield door not closed", if the system marks the control command as normal, the communication connection as normal, but the device execution node as abnormal, the system can quickly determine that the fault is caused by the actuator of the shield door. On the contrary, if the communication connection node is marked as abnormal, the fault may occur in the signal transmission link. This hierarchical labeling method helps to exclude irrelevant system components and quickly locate the problem.

[0080] Through this layer-by-layer labeling method, the system can completely build the diagnostic path of the fault tree model and provide operation and maintenance personnel with a global system status view. This not only makes the cause of the fault clear, but also helps maintenance personnel understand the working status of each system link and guides them to take more accurate maintenance actions. For example, if the fault is ultimately located at a communication connection problem, maintenance personnel can focus on checking the relevant communication modules without having to check the control system or equipment actuators one by one.

[0081] It should be noted that for these four fault types (1) the car door is open, but the shield door is not open; (2) the car door is not open, but the shield door is open; (3) the car door is closed, but the shield door is not closed; (4) the car door is not closed, but the shield door is closed), all execution logic can be performed according to steps 401-404, but each fault type may have different focuses in specific troubleshooting and processing. The following is how each fault type is developed within the framework of steps 401-404: (1) The car door is open, but the shield door is not open

[0082] This failure means that the car door can respond to the door opening command normally, but the shield door does not respond accordingly. According to the logic of steps 401-404: Step 401 (control command check): Check whether the VOBC has correctly sent the door opening command and confirm that the command has been sent to the screen door system. If the command has not been sent, mark the control command as abnormal.

[0083] Step 402 (communication connection check): If the control command is normal, check whether the communication link from VOBC to the screen door system is normal. If the communication is interrupted or delayed, mark the communication abnormality.

[0084] Step 403 (actuator check): If the communication is normal, check whether the feedback of the platform shield door actuator is consistent with the instruction. If the platform shield door does not respond, it may be a problem with the platform shield door actuator.

[0085] Step 404 (Fault Tree Marking): Based on the above inspection results, mark the nodes in the fault tree model layer by layer, and finally confirm the fault location.

[0086] (2) The car door is not open, but the shield door is open

[0087] This type of fault means that the shield door has responded to the door opening command, but the car door fails to open normally. The execution logic is consistent with steps 401-404, but the focus is on the car door control and execution: Step 401 (control command check): First check whether a correct door opening command is sent to the vehicle door. If not, mark the control command abnormal.

[0088] Step 402 (communication connection check): If the control command is normal, check whether the communication link between VOBC and the vehicle door is transmitting normally.

[0089] Step 403 (actuator check): If the communication is normal, check the door actuator. The reason why the door opening action is not performed may be that the door actuator fails.

[0090] Step 404 (Fault Tree Marking): Based on the troubleshooting results, mark the corresponding abnormal nodes to guide maintenance personnel to handle door actuator or communication problems.

[0091] (3) The car door is closed, but the shield door is not closed.

[0092] This type of failure means that the car door can be closed normally, but the shield door fails to respond. The failure of the shield door to close should be checked step by step in the framework of steps 401-404: Step 401 (control command check): Check whether the closing command is correctly sent to the shield door. If the control command is wrong, mark it as abnormal.

[0093] Step 402 (communication connection check): If the control command is normal, check whether there is a problem with the communication link of the shield door, resulting in failure to receive the closing command.

[0094] Step 403 (actuator check): If the communication link is normal, check whether the screen door actuator can correctly complete the closing action. If the actuator fails, it is marked as an execution problem.

[0095] Step 404 (Fault Tree Marking): Mark abnormal nodes based on the inspection results to identify the cause of the fault.

[0096] (4) The car door is not closed and the shield door is closed

[0097] This situation means that the shield door has responded to the closing command, but the car door has failed to close. The execution logic can follow the process of steps 401-404: Step 401 (control command check): Check whether the door receives the correct closing command. If the command is not received or lost, mark it as abnormal.

[0098] Step 402 (communication connection check): If the control instruction is correct, check whether the communication link is transmitting normally and confirm whether there is any signal delay or interruption.

[0099] Step 403 (actuator check): If the communication is normal, check the feedback status of the door actuator to confirm whether the door fails to complete the closing action as instructed.

[0100] Step 404 (Fault Tree Marking): Mark the fault tree layer by layer according to the inspection results, and finally determine the cause of the fault of the door actuator or communication problem.

[0101] In a possible implementation, the steps further include: The process of fault diagnosis for the fault type according to the fault tree troubleshooting process is visualized to obtain a visualized result of the fault diagnosis; the visualized result of the fault diagnosis and the cause of the fault are sent to the management terminal.

[0102] In specific implementation, after the system completes the layer-by-layer marking of the fault tree model, it automatically generates a visual fault diagnosis report. This report graphically displays the status of each node in the fault tree, including the status of control instructions, communication connections, and actuators. Normal nodes and abnormal nodes are distinguished by different colors or icons. Usually green is used to represent normal status and red is used to represent abnormal status. The visual display of the entire fault tree model can clearly show the specific location of the fault and which subsystems or components failed to work as expected. For example, if a communication node is abnormal, the system will mark the node in red, indicating that this is the key link that caused the fault.

[0103] During the visualization generation process, the system automatically summarizes and displays the relevant inspection results next to the visualization chart, allowing managers to quickly view specific inspection data. This data includes the status of each node, execution time, instruction transmission delay, communication connection status, etc. In this way, managers can not only see the location of the fault, but also understand the technical details that caused the fault in detail. This visualization greatly improves the intuitiveness and efficiency of information transmission, allowing managers to understand the fault situation at a glance without having to read a large number of logs or technical reports in depth.

[0104] In addition, the system can also send the generated visual diagnosis results and fault causes to the management terminal synchronously through the network. The management can receive and view the detailed information of the fault diagnosis in real time on their terminal devices. This function can greatly shorten the fault response time, allowing maintenance personnel to immediately take appropriate repair measures based on the diagnosis results, reduce the train downtime, and restore the normal operation of the system.

[0105] Reference Figure 5 , Figure 5 It is a structural schematic diagram of the vehicle door and screen door linkage fault diagnosis and analysis system provided by the present invention, the system comprises: a processing module and a fault diagnosis module; A processing module, used for judging whether there is a fault in the linkage state between the vehicle door and the shield door based on the vehicle log data; The processing module is also used to determine the fault type when there is a fault in the linkage state between the vehicle door and the shield door; A fault diagnosis module is used to establish a fault tree model corresponding to the fault type; The fault diagnosis module is also used to confirm the status of the top event and sub-event in the fault tree model layer by layer to obtain the cause of the fault. Among them, the top event is the linkage failure of the car door and the platform shielding door, and the sub-events include control instruction problems and communication connection problems related to the car door and the platform shielding door.

[0106] In a possible implementation manner, the fault diagnosis module is further used to: Confirm the status of the top events and sub-events in the fault tree model layer by layer to obtain the status of each node; Determine the cause of the failure based on the status of each node.

[0107] In a possible implementation manner, the fault diagnosis module is further used to: Confirm the status of the top event. If the top event is confirmed to be abnormal, further check the sub-events. The control instructions, communication connection status and actual actions of the vehicle doors and shielding doors included in the sub-events are analyzed layer by layer to obtain the status of each node.

[0108] In a possible implementation manner, the fault diagnosis module is further used to: Checking the execution status of the control instruction in the sub-event to obtain a first checking result; When the first check result indicates that the control instruction is executed normally, further checking the communication connection state included in the sub-event to obtain a second check result; When the second inspection result indicates that the communication connection state is normal, check whether the actual actions of the vehicle door and the platform shield door match the control instruction to obtain a third inspection result; Based on the first inspection result, the second inspection result and the third inspection result, the states of corresponding nodes in the fault tree model are marked layer by layer to obtain the states of each node.

[0109] In a possible implementation manner, the processing module is further configured to: Extract the door status field and the shield door status field from the vehicle log data; When the door status field is inconsistent with the platform shielding door status field, and the inconsistency duration reaches a preset duration, it is determined that there is a fault in the linkage state of the door and the platform shielding door; When the door status field is consistent with the platform shielding door status field, it is determined that there is no fault in the linkage status of the door and the platform shielding door.

[0110] In a possible implementation, the system further includes: a management module, configured to: The process of fault diagnosis according to the fault tree troubleshooting process is visualized to obtain the visualization results of fault diagnosis; The visualization results of fault diagnosis and fault causes are sent to the administrator's terminal.

[0111] It should be noted that the vehicle door and platform shield door linkage fault diagnosis and analysis system provided by the present invention can execute the vehicle door and platform shield door linkage fault diagnosis and analysis method of any of the above embodiments during specific operation, which will not be described in detail in this embodiment.

[0112] Figure 6 is a schematic diagram of the structure of the electronic device provided by the present invention, such as Figure 6 As shown, the electronic device may include: a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus. The processor may call the logic instructions in the memory to execute the door and shield door linkage fault diagnosis and analysis method, which includes: judging whether there is a fault in the linkage state of the door and the shield door based on the vehicle log data of the vehicle; when there is a fault in the linkage state of the door and the shield door, determining the fault type; establishing a fault tree model corresponding to the fault type; confirming the state of the top event and the sub-event in the fault tree model layer by layer to obtain the fault cause, wherein the top event is the linkage fault of the door and the shield door, and the sub-event includes the control instruction problem and the communication connection problem related to the door and the shield door.

[0113] In addition, the logic instructions in the above-mentioned memory can be implemented in the form of software functional units and can be stored in a computer-readable storage medium when sold or used as an independent product. Based on this understanding, the technical solution of the present invention is essentially or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including several instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.

[0114] On the other hand, the present invention also provides a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium, and the computer program includes program instructions. When the program instructions are executed by the computer, the computer can execute the vehicle door and shield door linkage fault diagnosis and analysis method provided by the above-mentioned embodiments, and the method includes: based on the vehicle's on-board log data, judging whether there is a fault in the linkage state of the vehicle door and the shield door; when there is a fault in the linkage state of the vehicle door and the shield door, determining the fault type; establishing a fault tree model corresponding to the fault type; confirming the status of the top event and sub-events in the fault tree model layer by layer to obtain the cause of the fault, wherein the top event is the linkage fault of the vehicle door and the shield door, and the sub-events include control instruction problems and communication connection problems related to the vehicle door and the shield door.

[0115] On the other hand, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to execute the vehicle door and shield door linkage fault diagnosis and analysis method provided in the above-mentioned embodiments, the method comprising: judging whether there is a fault in the linkage state of the vehicle door and the shield door based on the vehicle's onboard log data; when there is a fault in the linkage state of the vehicle door and the shield door, determining the fault type; establishing a fault tree model corresponding to the fault type; confirming the status of the top event and sub-events in the fault tree model layer by layer to obtain the cause of the fault, wherein the top event is the linkage fault of the vehicle door and the shield door, and the sub-events include control instruction problems and communication connection problems related to the vehicle door and the shield door.

[0116] The system embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, i.e., they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Those of ordinary skill in the art may understand and implement it without creative effort.

[0117] Through the description of the above implementation modes, those skilled in the art can clearly understand that each implementation mode can be implemented by means of software plus a necessary general hardware platform, or of course by hardware. Based on such an understanding, the above technical solution can essentially or in other words be embodied in the form of a software product that contributes to the prior art. The computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a magnetic disk, an optical disk, etc., and includes a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods of each embodiment or some parts of the embodiment.

[0118] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for diagnosing and analyzing the linkage faults of vehicle doors and platform shield doors, characterized in that: include: Based on the vehicle's onboard log data, determine whether there is a fault in the linkage status between the door and the platform shield door; When there is a fault in the linkage state between the car door and the shield door, determine the fault type; Establishing a fault tree model corresponding to the fault type; The status of the top event and sub-events in the fault tree model are confirmed layer by layer to obtain the cause of the fault, wherein the top event is the linkage fault of the vehicle door and the platform shielding door, and the sub-events include control instruction problems and communication connection problems related to the vehicle door and the platform shielding door.

2. The method for diagnosing and analyzing the linkage faults of vehicle doors and platform shielding doors according to claim 1 is characterized in that: Confirming the status of the top event and the sub-event in the fault tree model layer by layer to obtain the fault cause specifically includes: Confirming the status of the top events and sub-events in the fault tree model layer by layer to obtain the status of each node; Based on the status of each of the nodes, the cause of the failure is determined.

3. The method for diagnosing and analyzing the linkage faults of vehicle doors and platform shielding doors according to claim 2 is characterized in that: The state confirmation of the top event and the sub-event in the fault tree model layer by layer to obtain the state of each node specifically includes: Confirming the status of the top event, and when it is confirmed that the top event is in an abnormal state, further checking the sub-events; The control instructions, communication connection status and actual actions of the vehicle door and the shielding door included in the sub-events are analyzed layer by layer to obtain the status of each node.

4. The method for diagnosing and analyzing the linkage faults of vehicle doors and platform shielding doors according to claim 3 is characterized in that: The control instructions, communication connection status and actual actions included in the sub-events are analyzed layer by layer to obtain the status of each node, specifically including: Checking the execution status of the control instruction in the sub-event to obtain a first checking result; When the first inspection result indicates that the control instruction is executed normally, further inspecting the communication connection state included in the sub-event to obtain a second inspection result; When the second inspection result indicates that the communication connection state is normal, checking whether the actual actions of the vehicle door and the platform shield door match the control instruction to obtain a third inspection result; Based on the first inspection result, the second inspection result and the third inspection result, the states of corresponding nodes in the fault tree model are marked layer by layer to obtain the states of each node.

5. The method for diagnosing and analyzing the linkage faults of vehicle doors and platform shielding doors according to claim 1, characterized in that: The determining, based on the vehicle log data, whether there is a fault in the linkage state between the vehicle door and the platform shield door specifically includes: Extracting a door status field and a shield door status field from the vehicle-mounted log data; When the door status field is inconsistent with the platform shielding door status field, and the duration of the inconsistency reaches a preset duration, it is determined that there is a fault in the linkage state of the door and the platform shielding door; When the vehicle door status field is consistent with the platform shielding door status field, it is determined that there is no fault in the linkage status between the vehicle door and the platform shielding door.

6. The method for diagnosing and analyzing the linkage faults of vehicle doors and platform shielding doors according to claim 1, characterized in that: The method further comprises: Visually display the process of fault diagnosis for the fault type according to the fault tree troubleshooting process to obtain a visual result of the fault diagnosis; The visualization result of the fault diagnosis and the cause of the fault are sent to the administrator terminal.

7. A vehicle door and platform door linkage fault diagnosis and analysis system, characterized in that: include: Processing module and fault diagnosis module; The processing module is used to determine whether there is a fault in the linkage state between the vehicle door and the platform shield door based on the vehicle log data; The processing module is further used to determine the fault type when there is a fault in the linkage state between the vehicle door and the shield door; The fault diagnosis module is used to establish a fault tree model corresponding to the fault type; The fault diagnosis module is also used to confirm the status of the top event and sub-events in the fault tree model layer by layer to obtain the cause of the fault, wherein the top event is the linkage failure of the vehicle door and the platform shielding door, and the sub-events include control instruction problems and communication connection problems related to the vehicle door and the platform shielding door.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein: When the processor executes the computer program, the method for determining the space-time probability envelope of an aircraft as described in any one of claims 1-6 is implemented.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method for determining the space-time probability envelope of an aircraft as described in any one of claims 1 to 6 is implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the method for determining the space-time probability envelope of an aircraft as described in any one of claims 1 to 6 is implemented.

Images