Train fault monitoring method, device, equipment, train and storage medium

Abstract

The present application discloses a train fault monitoring method, device, equipment, train and storage medium, which relates to the field of fault monitoring. The method includes: locating the fault bit corresponding to the current train fault from the communication data; querying the fault protocol file corresponding to the current communication protocol according to the fault bit to determine the fault information of the current fault; the fault protocol file is pre-constructed, and the fault protocol file includes a fault frame file and a fault data file; the fault frame file includes a fault frame number and a fault frame length representing the communication data transmission port; the fault data file includes a fault frame number, a fault protocol bit, and fault information, and the fault information includes any one or more of the fault name, fault cause, solution and fault level; generating a fault prompt based on the fault information and sending it to the terminal. It can realize the decoupling of fault data and fault logic, improve the flexibility and reusability of fault data configuration, be compatible with multiple communication protocols, and improve the train fault monitoring capability.

Description

Technical Field

[0001] The present invention relates to the field of fault monitoring, and in particular to a train fault monitoring method, device, equipment, train and storage medium. Background Art

[0002] Train fault monitoring can promptly detect train faults during operation and alert train crews to address them promptly. Therefore, train fault monitoring is crucial. Related technologies implement train fault monitoring through programming. However, due to differences in fault protocols between trains and the frequent updates to these protocols, professionals must frequently write and modify these programs, increasing complexity and potentially delaying train operations. Summary of the Invention

[0003] In view of this, the purpose of the present invention is to provide a train fault monitoring method, apparatus, device, train, and storage medium that can decouple fault data from fault logic, improve the flexibility and reusability of fault data configuration, and be compatible with multiple communication protocols, thereby improving train fault monitoring capabilities. The specific solution is as follows:

[0004] In a first aspect, the present application discloses a train fault monitoring method, comprising:

[0005] Locate the fault bit corresponding to the current train fault from the communication data;

[0006] Querying the fault protocol file corresponding to the current communication protocol according to the fault bit to determine the fault information of the current fault; the fault protocol file is pre-constructed and includes a fault frame file and a fault data file; the fault frame file includes a fault frame number and a fault frame length representing a communication data transmission port; the fault data file includes a fault frame number, a fault protocol bit, and fault information, wherein the fault information includes any one or more of a fault name, a fault cause, a solution, and a fault level;

[0007] Generate a fault prompt based on the fault information and send it to the terminal.

[0008] Optionally, before locating the fault bit corresponding to the current train fault from the communication data, the method further includes:

[0009] Collect statistics on the data corresponding to different faults under different communication protocols, and model the corresponding fault frame files and fault data files for different communication protocols in character-separated value format;

[0010] Establishing an association relationship between the fault frame file and the fault data file of the same communication protocol;

[0011] Based on the fault frame files of the same communication protocol, the fault frame files, and the association relationship between the fault frame files and the fault data files, a fault protocol file corresponding to the communication protocol is generated.

[0012] Optionally, the generating of the fault protocol file corresponding to the communication protocol based on the fault frame file of the same communication protocol, the fault frame file, and the association relationship between the fault frame file and the fault data file includes:

[0013] Registering the fault frame file of the same communication protocol, the association relationship between the fault frame file and the fault data file in a fault registration table;

[0014] According to the fault registration table, hashing the fault frame files corresponding to the communication protocols, the fault frame files, and the association relationship between the fault frame files and the fault data files to obtain a hash table corresponding to each communication protocol;

[0015] The hash table is used as a fault protocol file of the communication protocol.

[0016] Optionally, locating a fault bit corresponding to the current train fault from the communication data includes:

[0017] storing the continuous communication data in the same memory area;

[0018] The communication data in the memory area is segmented and searched using a binary search method, and the changed bits are located as the fault bits corresponding to the current fault.

[0019] Optionally, the fault information includes a fault logic script;

[0020] After determining the fault information of the current fault, the method further includes:

[0021] Execute the fault logic script and determine whether other faults exist through logical operations.

[0022] Optionally, the train fault monitoring method further includes:

[0023] Generate a fault list based on the faults that have occurred, save the fault list to the memory, and transfer the data corresponding to the fault flow table in the memory to the data model;

[0024] The fault list is displayed on the train terminal using the data model.

[0025] Optionally, the train fault monitoring method further includes:

[0026] The train terminal device obtains a fault acquisition request sent by the mobile terminal;

[0027] According to the fault acquisition request, the fault list is sent to the mobile terminal in accordance with a pre-configured internal communication protocol between the train terminal device and the mobile terminal.

[0028] In a second aspect, the present application discloses a train fault monitoring device, comprising:

[0029] The fault capture module is used to locate the fault bit corresponding to the current train fault from the communication data;

[0030] a fault information determination module, configured to query a fault protocol file corresponding to the current communication protocol according to the fault bit to determine fault information of the current fault; the fault protocol file is pre-constructed and includes a fault frame file and a fault data file; the fault frame file includes a fault frame number and a fault frame length representing a communication data transmission port; the fault data file includes a fault frame number, a fault protocol bit, and fault information; the fault information includes any one or more of a fault name, a fault cause, a solution, and a fault level;

[0031] The fault prompt module is used to generate a fault prompt according to the fault information and send it to the terminal.

[0032] In a third aspect, the present application discloses an electronic device, comprising:

[0033] Memory, used to store computer programs;

[0034] The processor is used to execute the computer program to implement the aforementioned train fault monitoring method.

[0035] In a fourth aspect, the present application discloses a train comprising the aforementioned electronic equipment.

[0036] In a fifth aspect, the present application discloses a computer-readable storage medium for storing a computer program; wherein the computer program implements the aforementioned train fault monitoring method when executed by a processor.

[0037] In this application, the fault bit corresponding to the current train fault is located from the communication data; the fault protocol file corresponding to the current communication protocol is queried based on the fault bit to determine the fault information of the current fault; the fault protocol file is pre-constructed and includes a fault frame file and a fault data file; the fault frame file includes a fault frame number and a fault frame length representing the communication data transmission port; the fault data file includes a fault frame number, a fault protocol bit, and fault information, and the fault information includes any one or more of the fault name, fault cause, solution, and fault level; a fault prompt is generated based on the fault information and sent to the terminal. It can be seen that by pre-constructing a fault frame file including a fault frame number and a fault frame length representing the communication data transmission port, and a fault data file including a fault frame number, a fault protocol bit, and a fault information, fault protocol files corresponding to different communication protocols are obtained. After capturing the fault bit, the fault protocol file corresponding to the current communication protocol can be used to determine the relevant fault information, which includes the fault name, fault cause, solution, and fault level, so that the train crew can understand the train status in a timely manner. By modeling, a fault protocol file is obtained, and the fault data is decoupled from the fault logic. When the fault data is updated, only the fault protocol file needs to be updated without modifying the program and fault logic. This improves the flexibility and reusability of the configuration, and is compatible with multiple communication protocols, improving the ability to monitor train faults. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0039] Figure 1 A flow chart of a train fault monitoring method provided in this application;

[0040] Figure 2 A flow chart of a specific train fault locating method provided in this application;

[0041] Figure 3 A flow chart of a specific train fault update method provided in this application;

[0042] Figure 4 A flow chart of a specific train fault filtering method provided in this application;

[0043] Figure 5 A flow chart of a specific train fault linkage method provided in this application;

[0044] Figure 6 A flow chart of a specific train fault monitoring method provided in this application;

[0045] Figure 7 A schematic diagram of the structure of a train fault monitoring device provided in this application;

[0046] Figure 8 This is a structural diagram of an electronic device provided in this application. DETAILED DESCRIPTION

[0047] To make the objectives, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only 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 making creative efforts shall fall within the scope of protection of the present invention.

[0048] In the existing technology, train fault monitoring is achieved by writing programs. However, due to the differences in fault protocols between different trains and the frequent updates of train fault protocols, professionals are required to frequently write and modify programs, which increases complexity and delays train operations. To overcome the above technical problems, this application proposes a train fault monitoring method that can decouple fault data from fault logic, improve the flexibility and reusability of fault data configuration, and is compatible with multiple communication protocols, thereby improving train fault monitoring capabilities.

[0049] The present application discloses a train fault monitoring method. Figure 1 As shown, the method may include the following steps:

[0050] Step S11: Locate the fault bit corresponding to the current train fault from the communication data.

[0051] When a train fault occurs, a bit in the communication protocol data is flipped. Therefore, the fault bit corresponding to the current train fault is first located from the communication data. The reversal of different bits represents different faults. After determining the fault bit, the specific fault information can be determined by querying the fault protocol file. It can be understood that when a train fault occurs, a bit in the communication protocol data is flipped. For example, a change from 1 to 0 indicates that the fault disappears, and a change from 0 to 1 indicates that a fault occurs. Fault capture is to trigger the fault processing by detecting the change of this bit. Fault capture needs to consider accuracy and efficiency. Accuracy requires that when a fault occurs, a bit in the port where the data bit is located needs to be located. Efficiency requires that the bit be quickly found in all ports. The data communication frequency in the train is very high, and the fault bit changes are also very fast. Therefore, how to efficiently detect fault changes is very important.

[0052] In this embodiment, locating the fault bit corresponding to the current train fault from the communication data may include: storing the continuous communication data in the same memory area; using a binary search method to segment and search the communication data in the memory area, and locating the changed bit as the fault bit corresponding to the current fault. This embodiment combines the binary search idea to unify the data on the occurrence of the fault in a whole memory area, for example Figure 2 As shown, when the communication data is transmitted to the display screen, these continuous memory blocks are first unified in a memory area, and the memory area is continuously divided and searched through the binary search algorithm through the binary search idea until the position where the fault protocol bit changes, that is, the bit that has changed, is found. Compared with the overall traversal of the entire original fault memory area, the advantage in algorithm complexity is obvious, especially when the fault bit occurs at the end of the memory area. In the above method, when a new fault occurs on the train, the fault capture algorithm is used to quickly locate the fault protocol bit that has changed, and then the modeling data file is combined to match the corresponding fault, thereby improving the fault capture efficiency and thus improving the fault detection efficiency.

[0053] Step S12: query the fault protocol file corresponding to the current communication protocol according to the fault bit to determine the fault information of the current fault; the fault protocol file is pre-constructed, and the fault protocol file includes a fault frame file and a fault data file; the fault frame file includes a fault frame number and a fault frame length representing the communication data transmission port; the fault data file includes a fault frame number, a fault protocol bit, and fault information, and the fault information includes any one or more of the fault name, fault cause, solution, and fault level.

[0054] In this embodiment, a snapshot is created in the memory by describing the fault data through a modeling file. By corresponding to this snapshot information, all information about the fault associated with the fault bit can be found.

[0055] Specifically, before monitoring a train fault, data corresponding to different faults under different communication protocols are collected, and corresponding fault frame files and fault data files are modeled for each communication protocol in character-separated value format. An association is established between the fault frame files and the fault data files for the same communication protocol. Based on the fault frame files, the fault frame files, and the association between the fault frame files and the fault data files for the same communication protocol, a fault protocol file corresponding to the communication protocol is generated. The fault data file includes, but is not limited to, a fault flag, a fault frame number, a fault protocol bit, and fault information.

[0056] This involves fault modeling. The fault protocol bits and fault information are categorized and counted based on the original train fault protocol. Fault information includes, but is not limited to, fault name, cause, solution, and description. Based on the protocol, an Excel spreadsheet tool is used to model fault frame information and fault data information separately, while also establishing a fault registry. Modeling files are divided into fault data frame files and fault data files. The data frame describes the location of the data in the protocol, including the frame number and frame length (bytes).

[0057] Taking Ethernet as an example, a frame represents a port on the Ethernet. The following Table 1 shows two Ethernet ports: 1301 and 1302, each with a length of 1400 bytes. These 1400 bytes contain the required fault protocol bits, i.e., the fault bits.

[0058] Table 1: Eth protocol fault frame table (Eth_Fault_Frames.csv)

[0059]

[0060] The fault protocol bits in the fault data file are modeled sequentially according to the position of a fault in the frame. This is because the fault protocol bits are distinguished by bit, either occurring or not occurring, that is, 1 bit is used to represent two states: occurring or not occurring. Taking the communication protocol bit Ethernet as an example, different fault examples are described:

[0061] Table 2: Eth protocol fault data table (Eth_Fault_Data.csv)

[0062]

[0063] After modeling the fault frame and data files, these two types of files for the same protocol need to be associated. This means that to accommodate faults occurring under different communication protocols, a fault frame table and a fault data table must be created for each protocol, and each protocol must be registered in a fault registry. The registry maintains data frames and data tables for each protocol and establishes corresponding dependencies. For example, Table 3 below describes the fault registry for both MVB (Multifunction Vehicle Bus) and Ethernet protocols:

[0064] Table name 3: Fault Registry (Fault_Protocl.csv)

[0065]

[0066] Based on the existing train fault protocol, the fault is abstracted through modeling, the fault content that needs to be displayed for train fault monitoring is extracted, and a fault data file is generated. This file can be updated synchronously according to changes in the protocol.

[0067] Further, a modeling memory data structure is generated. Specifically, the fault frame file, the fault frame file, and the association relationship between the fault frame file and the fault data file based on the same communication protocol are used to generate a fault protocol file corresponding to the communication protocol, including: registering the fault frame file, the fault frame file, and the association relationship between the fault frame file and the fault data file of the same communication protocol to a fault registration table; hashing the fault frame file, the fault frame file, and the association relationship between the fault frame file and the fault data file corresponding to the communication protocol according to the fault registration table to obtain a hash table corresponding to each communication protocol; and using the hash table as the fault protocol file of the communication protocol.

[0068] The modeling file is described by a character-separated value format (CSV) file. First, the fault registry is read. According to the protocol, fault table, and dependency relationships described in the registry, the corresponding fault frame table and fault data table are read according to the protocol. Then, the corresponding data is initialized into a hash table. The hash table is differentiated by protocol, and each protocol corresponds to a hash table. The fault ID is the primary key in the hash table, and each primary key is associated with a MAP structure. The MAP is filled with each data item in the fault data. The fault protocol file structure corresponding to the ETH protocol is described in the following table:

[0069] Table 4: Fault protocol file

[0070]

[0071] After constructing fault protocol files for different protocols, the corresponding protocol hash table is loaded based on the train's current protocol. When a fault occurs, the corresponding fault information is retrieved by searching the fault ID in the MAP in the hash table. The fault protocol registry manages fault tables and dependencies for multiple communication protocols and supports dynamic switching of communication protocols to different fault data tables.

[0072] Step S13: Generate a fault prompt according to the fault information and send it to the terminal.

[0073] In this embodiment, after the fault is captured, the fault information is located by searching the fault protocol file, and then the train fault information is fed back to the display screen in the machinery room or the driver's cab; specifically, it can be presented to the train crew through a list, prompt or other visual elements, so train fault processing is a repackaging of the fault data.

[0074] That is, when a fault occurs, the fault information is immediately sent to the display screen or other terminals, and the concerned terminals are notified in the form of reminders. The reminder content includes but is not limited to the fault ID, fault name, fault cause, existing solutions, etc., to help train crew members understand and handle the fault in a timely manner. Fault reminders can be used to remind train crew members of certain levels of faults as required. For example, only level 1 and level 2 faults or faults within any level are reminded, and other levels of faults do not require reminders. The reminder algorithm can be flexibly customized according to specific needs. In addition, to ensure that the fault is notified to the train crew in a timely manner, the train crew can be set to feedback to the back end after confirming the fault, and notify the back end to modify the fault status and record the handling process. In this way, if the train crew does not confirm the fault, the fault reminder will continue to be triggered until the train crew confirms and handles the fault.

[0075] In some embodiments, the fault information may include a fault logic script. After determining the fault information for the current fault, the process may further include executing the fault logic script and determining whether other faults exist through logical operations. This means that logical operations for the fault, such as AND, OR, NOT, addition, subtraction, multiplication, and division, are added to the modeling data to comprehensively determine whether other faults exist. This allows simple fault logic to be configured through modeling files, rather than implemented in code.

[0076] In some embodiments, the method may further include: generating a fault list based on the faults that have occurred, saving the fault list to memory, transferring the data corresponding to the fault flow table in memory to a data model; and displaying the fault list on a train terminal device via the data model. Specifically, the faults are presented to the train attendant via a list in a fixed format. In this embodiment, the fault list may include a real-time fault list, a historical fault list, and a filtered fault list. The real-time fault list compiles all currently occurring faults into a single list, sorted by occurrence time, with the most recent fault displayed at the beginning. The historical fault list compiles faults that have occurred and resolved into a single list, sorted by resolution time, and stored. Using binary data improves storage and access efficiency. The filtered fault list can filter both real-time and historical faults separately, filtering by time or level. Specifically, this can be accomplished by obtaining a fault query instruction that includes time and level conditions; filtering the target faults based on the fault query instruction; and displaying the target faults on the human-computer interaction interface via the data model. The real-time fault list is stored in memory, while the historical fault list is stored on disk. When the device is restarted, the historical faults must be read and a list generated. At the same time, it is necessary to check whether new real-time faults have been resolved and adjust the fault elimination time. The total number of fault entries in the fault list can be limited as needed.

[0077] In addition, due to the frequent occurrence of faults and the large amount of data, a data model is used to manage the list in this embodiment, that is, the list is established in the memory, and then the memory data is aggregated into a special data model, and then the data model is presented to the display screen or terminal interface. The terminal directly binds the interface with the data model to view the list data.

[0078] In some embodiments, the above method may further include: obtaining a fault update instruction; the fault update instruction includes a fault adding instruction, a fault deleting instruction, and a fault modifying instruction; modifying the data corresponding to the fault flow table in the memory according to the fault update instruction, and refining the data model through incremental updating. Figure 3 As shown, through the add, delete, and modify interface and the quick query interface, the structure in the memory is added, deleted, and modified, and the data model is republished through incremental updates. Therefore, the entire data model is not sent repeatedly, but only the updated part of the data is sent. The query interface of the interactive interface can adopt a sliding window query mechanism. When the display screen quickly views multiple pages of data or multiple data items, the list only receives the data segments at the start and end positions and feeds them back to the display screen to ensure the efficiency of the query; for example Figure 4As shown, list filtering retrieves a new data model by filtering the data model, and then rebinds it to the interface elements to obtain the filtered list data. This improves fault list operation efficiency by supporting the generation of different types of fault lists and the addition, deletion, modification, and querying of fault lists.

[0079] In some embodiments, the above train fault monitoring method may further include: the train terminal device obtains a fault acquisition request sent by the mobile terminal; according to the fault acquisition request, the fault list is sent to the mobile terminal in accordance with the pre-configured internal communication protocol between the train terminal device and the mobile terminal. That is, this application supports fault terminal linkage, for example Figure 5 As shown, the mobile terminal connects to the train terminal display screen via a wireless network and sends fault requests in a formatted format using an internally defined communication protocol. Upon receiving the fault request, the display screen pushes the entire current fault list to the mobile terminal, which then presents the fault list according to its view. When the number of faults on the display screen increases or decreases, instructions to add, delete, or modify the fault list are also sent to the mobile terminal, which then updates the data according to the protocol. To view or filter data, the mobile terminal must issue a corresponding request to the display screen and retrieve the data. When the mobile terminal is powered off or restarted, the fault list must be re-requested according to the protocol, and the faults on the display screen are then synchronized according to the interaction strategy.

[0080] In some embodiments, video fault linkage between mobile terminals and train terminal equipment can also be supported: video faults are modeled and associated with the fault ID and the fault modeling data table, meaning that the fault information includes the fault video. When a fault occurs, if video data exists for the fault, the video data corresponding to the fault is found in the video fault data table, and then the corresponding fault video is viewed through the video playback interface. By extending and expanding the fault data, a method is provided for presenting faults in various formats.

[0081] For example Figure 6As shown, the fault monitoring and processing method proposed in this application can be applied to intelligent trains, including fault data modeling, fault capture, fault processing, fault reminder, fault list, fault confirmation, fault filtering and fault notification extension, etc., which can timely discover faults, identify faults and display fault monitoring results. Specifically, in view of the frequent occurrence of faults on trains, low latency and frequent updates of different train fault protocols, as well as the synchronization of train faults with mobile terminals, a fault monitoring and processing mechanism is proposed. A fault reminder is issued immediately for train faults and inserted into the fault list. If the fault is not confirmed, the reminder state needs to be maintained until the fault is confirmed and resolved, and the fault is added to the historical fault list and written to the disk. The fault list maintains the data of the fault in the memory. The list supports addition, deletion, modification and query, provides an efficient filtering algorithm and the ability to synchronize to the display screen, and supports quick viewing and filtering on the display screen or terminal. At the same time, through the network interconnection protocol of the display screen and the terminal, the fault of the display screen is synchronized to the terminal to realize the expansion of train faults.

[0082] Fault data modeling uses Excel to model the protocol for train faults. Modeled data includes fault ID, fault content, fault level, fault protocol bits, fault cause, fault resolution, and fault logic script. The fault capture algorithm utilizes a split-half search algorithm to compare the memory location of the fault data to capture the memory block sent by the fault. By comparing bytes within the memory block, double-byte data is located. Within the double-byte data, single-byte data is located, and protocol bit changes are located within the single-byte data. Fault processing locates the fault protocol bits after a fault occurs. By reviewing the fault modeling data file, matching the protocol bits to extract fault information, the system then performs fault insertion, fault deletion, and fault logic operations, such as AND, OR, and NOT operations on multiple fault protocols. The fault list supports addition, deletion, modification, and querying, using a customized hash structure to store fault data. A current fault list is maintained in memory, specifically storing all currently unconfirmed faults. A historical fault list stores confirmed faults, and a linked fault list stores fault details linked to video faults. Correspondingly, during the fault confirmation phase, the system traverses the current fault list for each confirmed fault ID, removes the fault from the current list, adds it to the historical fault list, modifies the fault confirmation time, and stores the fault list for easy access the next time the system is powered on. Fault filtering uses regular expressions to implement a filtering algorithm, supporting various filtering criteria within the fault list, such as level and type. Fault notifications are performed by traversing the current fault list according to the maximum alert level, searching for faults below the maximum level and notifying the display screen or mobile terminal of any faults found. Furthermore, system faults and faults that support video viewing are linked through modeling files. When a system fault occurs, the corresponding video ID is quickly found in the video fault table using the fault ID. Once the video ID is found, both general faults and video viewing faults are reported simultaneously. Fault notification extensions are also supported, synchronizing data with the mobile terminal through a network interconnection protocol. The mobile terminal then monitors the display screen's synchronized data in real time to update its own data.

[0083] As can be seen from the above, in this embodiment, the fault bit corresponding to the current train fault is located from the communication data; the fault protocol file corresponding to the current communication protocol is queried based on the fault bit to determine the fault information of the current fault; the fault protocol file is pre-constructed and includes a fault frame file and a fault data file; the fault frame file includes the fault frame number and fault frame length representing the communication data transmission port; the fault data file includes the fault frame number, fault protocol bit, and fault information, and the fault information includes any one or more of the fault name, fault cause, solution, and fault level; and a fault prompt is generated based on the fault information and sent to the terminal. As can be seen, by pre-constructing a fault frame file including the fault frame number and fault frame length representing the communication data transmission port, and a fault data file including the fault frame number, fault protocol bit, and fault information, fault protocol files corresponding to different communication protocols are obtained. After capturing the fault bit, the fault protocol file corresponding to the current communication protocol can be used to determine the relevant fault information, including the fault name, fault cause, solution, and fault level, so that the train crew can promptly understand the train status. By modeling, a fault protocol file is obtained, and the fault data is decoupled from the fault logic. When the fault data is updated, only the fault protocol file needs to be updated without modifying the program and fault logic. This improves the flexibility and reusability of the configuration, and is compatible with multiple communication protocols, improving the ability to monitor train faults.

[0084] Correspondingly, the present application also discloses a train fault monitoring device, see Figure 7 As shown, the device includes:

[0085] The fault capture module 11 is used to locate the fault bit corresponding to the current train fault from the communication data;

[0086] a fault information determination module 12, configured to query a fault protocol file corresponding to the current communication protocol according to the fault bit to determine fault information of the current fault; the fault protocol file is pre-constructed and includes a fault frame file and a fault data file; the fault frame file includes a fault frame number and a fault frame length representing a communication data transmission port; the fault data file includes a fault frame number, a fault protocol bit, and fault information; the fault information includes any one or more of a fault name, a fault cause, a solution, and a fault level;

[0087] The fault prompt module 13 is configured to generate a fault prompt according to the fault information and send the generated fault prompt to the terminal.

[0088] As can be seen from the above, in this embodiment, the fault bit corresponding to the current train fault is located from the communication data; the fault protocol file corresponding to the current communication protocol is queried based on the fault bit to determine the fault information of the current fault; the fault protocol file is pre-constructed and includes a fault frame file and a fault data file; the fault frame file includes the fault frame number and fault frame length representing the communication data transmission port; the fault data file includes the fault frame number, fault protocol bit, and fault information, and the fault information includes any one or more of the fault name, fault cause, solution, and fault level; and a fault prompt is generated based on the fault information and sent to the terminal. As can be seen, by pre-constructing a fault frame file including the fault frame number and fault frame length representing the communication data transmission port, and a fault data file including the fault frame number, fault protocol bit, and fault information, fault protocol files corresponding to different communication protocols are obtained. After capturing the fault bit, the fault protocol file corresponding to the current communication protocol can be used to determine the relevant fault information, including the fault name, fault cause, solution, and fault level, so that the train crew can promptly understand the train status. By modeling, a fault protocol file is obtained, and the fault data is decoupled from the fault logic. When the fault data is updated, only the fault protocol file needs to be updated without modifying the program and fault logic. This improves the flexibility and reusability of the configuration, and is compatible with multiple communication protocols, improving the ability to monitor train faults.

[0089] In some specific embodiments, the train fault monitoring device may specifically include:

[0090] A modeling unit is used to count data corresponding to different faults under different communication protocols before locating the fault bit corresponding to the current train fault from the communication data, and to model corresponding fault frame files and fault data files for different communication protocols in a character separated value format;

[0091] an associating unit, configured to establish an associative relationship between the fault frame file and the fault data file of the same communication protocol;

[0092] The fault protocol file generating unit is configured to generate a fault protocol file corresponding to the communication protocol based on the fault frame file of the same communication protocol, the fault frame file, and the association relationship between the fault frame file and the fault data file.

[0093] In some specific embodiments, generating the fault protocol file may specifically include:

[0094] A registration unit, configured to register the fault frame file of the same communication protocol, the fault frame file, and the association relationship between the fault frame file and the fault data file in a fault registration table;

[0095] The hash unit is used to hash the fault frame file corresponding to the communication protocol, the fault frame file, and the association relationship between the fault frame file and the fault data file according to the fault registration table to obtain a hash table corresponding to each communication protocol, and use the hash table as the fault protocol file of the communication protocol.

[0096] In some specific embodiments, the fault capture module 11 may specifically include:

[0097] A storage unit, configured to store the continuous communication data into a same memory area;

[0098] The transformed bit search unit is used to divide and search the communication data in the memory area using a binary search method, and locate the transformed bit as the fault bit corresponding to the current fault.

[0099] In some specific embodiments, the fault information includes a fault logic script; the train fault monitoring device may specifically include:

[0100] The logic operation unit is used to execute the fault logic script after determining the fault information of the current fault, and determine whether there are other faults through logic operations.

[0101] In some specific embodiments, the train fault monitoring device may further include:

[0102] A fault list generating unit is configured to generate a fault list according to the faults that have occurred, save the fault list to a memory, and transfer the data corresponding to the fault flow table in the memory to a data model;

[0103] A fault list display unit is used to display the fault list on a train terminal device using the data model.

[0104] In some specific embodiments, the train fault monitoring device may further include:

[0105] a fault acquisition request acquiring unit, configured for the train terminal device to acquire a fault acquisition request sent by the mobile terminal;

[0106] The fault list synchronization unit is used to send the fault list to the mobile terminal according to the fault acquisition request and the pre-configured internal communication protocol between the train terminal equipment and the mobile terminal.

[0107] Furthermore, the present application also discloses an electronic device, see Figure 8 The contents in the drawings should not be considered as any limitation on the scope of use of the present application.

[0108] Figure 8This is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of the present application. The electronic device 20 may include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 is used to store a computer program, which is loaded and executed by the processor 21 to implement the relevant steps of the train fault monitoring method disclosed in any of the aforementioned embodiments.

[0109] In this embodiment, the power supply 23 is used to provide operating voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and the external device. The communication protocol it follows is any communication protocol that can be applied to the technical solution of this application and is not specifically limited here; the input and output interface 25 is used to obtain external input data or output data to the outside world. Its specific interface type can be selected according to specific application needs and is not specifically limited here.

[0110] In addition, the memory 22, as a carrier for resource storage, can be a read-only memory, random access memory, disk or CD, etc. The resources stored thereon include an operating system 221, a computer program 222 and data 223 including fault protocol files, etc. The storage method can be temporary storage or permanent storage.

[0111] The operating system 221 is used to manage and control the hardware devices and computer program 222 on the electronic device 20, so as to enable the processor 21 to calculate and process the massive data 223 in the memory 22. The operating system 221 can be Windows Server, NetWare, Unix, Linux, etc. In addition to including computer programs capable of implementing the train fault monitoring method disclosed in any of the aforementioned embodiments and executed by the electronic device 20, the computer program 222 can further include computer programs capable of performing other specific tasks.

[0112] Furthermore, an embodiment of the present application also discloses a train, which includes the aforementioned electronic equipment and is capable of implementing the steps of the train fault monitoring method disclosed in any of the aforementioned embodiments.

[0113] Furthermore, an embodiment of the present application also discloses a computer storage medium, in which computer executable instructions are stored. When the computer executable instructions are loaded and executed by a processor, the steps of the train fault monitoring method disclosed in any of the aforementioned embodiments are implemented.

[0114] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from the other embodiments. Reference can be made to the descriptions of the identical or similar parts between the various embodiments. For the devices disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and the relevant parts can be referred to the descriptions of the methods.

[0115] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein may be implemented directly using hardware, a software module executed by a processor, or a combination of the two. The software module may be placed in random access memory (RAM), internal memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, a hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art.

[0116] Finally, it should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of additional identical elements in the process, method, article, or device comprising the element.

[0117] The above is a detailed introduction to the train fault monitoring method, device, equipment, train and storage medium provided by the present invention. Specific examples are used in this article to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core ideas. At the same time, for those skilled in the art, according to the ideas of the present invention, there will be changes in the specific implementation methods and application scope. In summary, the content of this specification should not be understood as limiting the present invention.

Claims

1. A train fault monitoring method, characterized in that: include: Locate the fault bit corresponding to the current train fault from the communication data; Querying a fault protocol file corresponding to the current communication protocol according to the fault bit to determine fault information of the current fault; The fault protocol file is pre-built and includes a fault frame file and a fault data file; The fault frame file includes a fault frame number and a fault frame length representing a communication data transmission port; The fault data file includes a fault frame number, a fault protocol bit, and fault information, wherein the fault information includes any one or more of a fault name, a fault cause, a solution, and a fault level; Generate a fault prompt based on the fault information and send it to the terminal; Before locating the fault bit corresponding to the current train fault from the communication data, the following steps are also included: Collect statistics on the data corresponding to different faults under different communication protocols, and model the corresponding fault frame files and fault data files for different communication protocols in character-separated value format; Establishing an association relationship between the fault frame file and the fault data file of the same communication protocol; Generate a fault protocol file corresponding to the communication protocol based on the fault frame file, the fault data file, and the association relationship between the fault frame file and the fault data file of the same communication protocol; The generating of the fault protocol file corresponding to the communication protocol based on the fault frame file, the fault data file, and the association relationship between the fault frame file and the fault data file of the same communication protocol includes: Registering the fault frame file, the fault data file, and the association relationship between the fault frame file and the fault data file of the same communication protocol in a fault registration table; According to the fault registration table, hashing the fault frame file, the fault data file, and the association relationship between the fault frame file and the fault data file corresponding to the communication protocol to obtain a hash table corresponding to each communication protocol; The hash table is used as a fault protocol file of the communication protocol.

2. The train fault monitoring method according to claim 1, characterized in that: The step of locating the fault bit corresponding to the current train fault from the communication data includes: storing the continuous communication data in the same memory area; The communication data in the memory area is segmented and searched using a binary search method, and the changed bits are located as the fault bits corresponding to the current fault.

3. The train fault monitoring method according to claim 1, characterized in that: The fault information includes a fault logic script; After determining the fault information of the current fault, the method further includes: Execute the fault logic script and determine whether other faults exist through logical operations.

4. The train fault monitoring method according to any one of claims 1 to 3, characterized in that: Also includes: Generate a fault list based on the faults that have occurred, save the fault list to a memory, and transfer the data corresponding to the fault list in the memory to a data model; The fault list is displayed on the train terminal using the data model.

5. The train fault monitoring method according to claim 4, characterized in that: Also includes: The train terminal device obtains a fault acquisition request sent by the mobile terminal; According to the fault acquisition request, the fault list is sent to the mobile terminal in accordance with a pre-configured internal communication protocol between the train terminal device and the mobile terminal.

6. A train fault monitoring device, characterized in that: include: The fault capture module is used to locate the fault bit corresponding to the current train fault from the communication data; A fault information determination module is used to query the fault protocol file corresponding to the current communication protocol according to the fault bit to determine the fault information of the current fault; The fault protocol file is pre-built and includes a fault frame file and a fault data file; The fault frame file includes a fault frame number and a fault frame length representing a communication data transmission port; The fault data file includes a fault frame number, a fault protocol bit, and fault information, wherein the fault information includes any one or more of a fault name, a fault cause, a solution, and a fault level; A fault prompt module is used to generate a fault prompt according to the fault information and send it to the terminal; The train fault monitoring device is configured to, before locating the fault bit corresponding to the current train fault from the communication data, count the data corresponding to different faults under different communication protocols, model corresponding fault frame files and fault data files for different communication protocols in character-separated value format; establish an association relationship between the fault frame files and the fault data files of the same communication protocol; and generate a fault protocol file corresponding to the communication protocol based on the fault frame files, the fault data files, and the association relationship between the fault frame files and the fault data files of the same communication protocol; Among them, the train fault monitoring device is used to register the fault frame file, the fault data file and the association relationship between the fault frame file and the fault data file of the same communication protocol into a fault registration table; according to the fault registration table, the fault frame file, the fault data file and the association relationship between the fault frame file and the fault data file corresponding to the communication protocol are hashed to obtain a hash table corresponding to each communication protocol; and the hash table is used as the fault protocol file of the communication protocol.

7. An electronic device, characterized in that: include: Memory, used to store computer programs; A processor, configured to execute the computer program to implement the train fault monitoring method according to any one of claims 1 to 5.

8. A train, characterized in that: The electronic device comprising the electronic device according to claim 7.

9. A computer-readable storage medium, characterized in that Used to store computer programs; wherein when the computer program is executed by a processor, the train fault monitoring method according to any one of claims 1 to 5 is implemented.

Images