Train state judgment method and system

Abstract

The invention relates to the field of rail transit, in particular to a train state judgment method and system.The judgment method comprises the steps that data analysis is conducted, specifically, return data from a train are received, and state data used for representing train faults and / or early warning are analyzed from the return data; a data storage step: setting a state cache pool, storing the state data in the state cache pool, the state cache pool being used for displaying a fault occurring in the train and / or early warning; a data updating step: updating the data in the state cache pool according to the state data at the current moment and the state data at the previous moment; and a state judgment step: judging the current state of the train according to the updated state buffer pool. According to the method, the state buffer pool is arranged, the state buffer pool is updated according to the train return data, and then the current state of the train is reflected through the updating condition of the state buffer pool, so that the accuracy of train state judgment is improved, and the problem of inaccurate train state judgment is solved.

Description

Technical Field

[0001] This application relates to the field of rail transit, and in particular to a method and system for determining train status. Background Technology

[0002] With the rapid development of the rail transit industry, the traditional operation and maintenance model that relies on manual inspection and post-fault repair is no longer suitable for the high-load and continuous operation requirements of modern trains. Intelligent and digital train operation and maintenance systems are gradually replacing the traditional model and have become the key infrastructure to ensure the safe and stable operation of trains.

[0003] In existing technologies, changes in train malfunctions are typically displayed by updating a linked list containing these malfunctions. A node is added to the list when a malfunction occurs and removed when the malfunction disappears. However, unstable data transmission or packet loss can easily lead to erroneous list updates, resulting in inaccurate train status determination. Summary of the Invention

[0004] This application provides a train status determination method and system to at least solve the problem of inaccurate train operation status determination in related technologies.

[0005] In a first aspect, embodiments of this application provide a train status determination method for determining the current status of a train, including: The data analysis step involves receiving feedback data from the train and parsing the feedback data to extract status data that characterizes train malfunctions and / or warnings. The data storage step involves setting up a status cache pool and storing the status data in the status cache pool, which is used to display the faults and / or warnings that are occurring on the train. The data update step involves updating the data in the state cache pool based on the current state data and the state data from the previous time. The status determination step involves determining the current status of the train based on the updated status cache pool.

[0006] In some embodiments, the returned data is parsed to extract status data characterizing train malfunctions and / or warnings, including: Fault channel data and early warning channel data are extracted from the returned data. The fault channel data is used to characterize faults in various equipment of the train, and the early warning channel data is used to characterize early warnings in various equipment of the train. Both the fault channel data and the early warning channel data are parsed in binary form, and each fault channel data and each early warning channel data generates its own corresponding binary index; wherein, a binary index of 1 indicates that the fault or early warning corresponding to the binary bit at that index is occurring, and a binary index of 0 indicates that the fault or early warning corresponding to the binary bit at that index has not occurred. The status data is generated by merging the binary index of each number with a value of one, the train number, equipment number, and channel number in the corresponding fault channel data or early warning channel data.

[0007] In some embodiments, the data analysis step further includes: Extract the timestamp data from the returned data; Determine whether the timestamp data in the current time-transmitted data is greater than the timestamp data in the previous time-transmitted data. If so, start parsing the data.

[0008] In some embodiments, the data update step includes: The state data from the previous moment is stored in the state cache pool; Each piece of state data at the current moment is compared with the state data at the previous moment to determine whether the state data at the current moment is the same as the state data at the previous moment. If so, then retain the state data from the previous time that is the same as the state data at the current time in the state cache pool; If not, the current state data, which is different from the state data of the previous time step, is added to the state cache pool; Generate the state cache pool with initial updates.

[0009] In some embodiments, each of the status data includes the device number of the device where the fault or warning occurred, and the data update step further includes: According to the device number, all the state data in the initially updated state cache pool are compared one by one with the state data at the current time. If any state data appears in the initially updated state cache pool but does not exist in the current state data, then the state data is deleted from the initially updated state cache pool. Generate the updated state cache pool.

[0010] In some embodiments, determining the current state of the train includes: Determine whether there is fault data in the updated state cache pool. If there is, the train's current state is fault state. If not, determine whether there is warning data in the state cache pool. If there is, the train's current state is warning state. If not, the train's current state is normal state.

[0011] In some embodiments, after the state determination step, the method further includes: Determine whether the data in the state cache pool has changed. If so, send the changed data to the front end of the train.

[0012] In some embodiments, the state determination step includes: During the periodic reception of the returned data, if none of the returned data received within a preset period contains a train number, the current status of the train corresponding to that train number is determined to be offline.

[0013] In some embodiments, the state determination step includes: If no data is received from a train line within a preset time, the current status of all trains on that train line is determined to be offline.

[0014] Secondly, embodiments of this application provide a train status determination system, including: The data analysis module is configured to receive feedback data from the train and parse the feedback data to extract status data that characterizes train malfunctions and / or warnings. The data storage module is configured to set up a status cache pool and store the status data in the status cache pool, which is used to display the faults and / or warnings that are occurring on the train. The data update module is configured to update the data in the state cache pool based on the current state data and the state data from the previous time. The status determination module is configured to determine the current status of the train based on the updated status cache pool.

[0015] Compared to related technologies, the train status judgment method and system provided in this application update the status cache pool to display the current status of the train, solving the problem of inaccurate train operation status judgment, improving the accuracy, real-time performance and reliability of train status monitoring, and providing strong protection for safe train operation.

[0016] Details of one or more embodiments of this application are set forth in the following drawings and description to make other features, objects and advantages of this application more readily apparent. Attached Figure Description

[0017] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments of this application and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings: Figure 1 This is a flowchart of a train status determination method according to an embodiment of this application; Figure 2 This is a structural block diagram of a train status determination system according to an embodiment of this application.

[0018] In the picture: 201. Data Analysis Module; 202. Data Storage Module; 203. Data Update Module; 204. Status Judgment Module. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of this application clearer, the application is described and illustrated below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. All other embodiments obtained by those skilled in the art based on the embodiments provided in this application without inventive effort are within the scope of protection of this application.

[0020] Obviously, the accompanying drawings described below are merely some examples or embodiments of this application. Those skilled in the art can apply this application to other similar scenarios based on these drawings without any inventive effort. Furthermore, it is understood that although the efforts made in this development process may be complex and lengthy, for those skilled in the art related to the content disclosed in this application, any changes to design, manufacturing, or production based on the technical content disclosed in this application are merely conventional technical means and should not be construed as insufficient disclosure of the content of this application.

[0021] In this application, the reference to "embodiment" means that a specific feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment that is mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described in this application may be combined with other embodiments without conflict.

[0022] Unless otherwise defined, the technical or scientific terms used in this application shall have the ordinary meaning understood by one of ordinary skill in the art to which this application pertains. The terms “a,” “an,” “an,” “the,” and similar words used in this application do not indicate quantity limitation and may indicate singular or plural. The terms “comprising,” “including,” “having,” and any variations thereof used in this application are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or device that includes a series of steps or modules (units) is not limited to the listed steps or units, but may also include steps or units not listed, or may include other steps or units inherent to these processes, methods, products, or devices. The terms “connected,” “linked,” “coupled,” and similar words used in this application are not limited to physical or mechanical connections, but may include electrical connections, whether direct or indirect. “Multiple” used in this application refers to two or more. “And / or” describes the relationship between related objects, indicating that three relationships may exist; for example, “A and / or B” can represent: A alone, A and B simultaneously, and B alone. The character " / " generally indicates that the preceding and following objects are in an "or" relationship. The terms "first," "second," and "third" used in this application are merely to distinguish similar objects and do not represent a specific ordering of the objects.

[0023] With the rapid development of the rail transit industry, the operating mileage of trains continues to extend and the operating density continues to increase, which places more stringent demands on the safety, reliability and efficiency of train operation. The traditional operation and maintenance model that relies on manual inspection and repair after failure is no longer suitable for the high-load and continuous operation needs of modern trains. Intelligent and digital train operation and maintenance systems are gradually replacing the traditional model and have become the key infrastructure to ensure the safe and stable operation of trains.

[0024] Current train operation and maintenance systems have formed a relatively complete basic architecture, typically consisting of four core modules: data acquisition, data transmission, data storage and management, and data analysis. These modules work together to achieve comprehensive monitoring and initial control of train operation status.

[0025] Among them, the data acquisition module, as the system's sensing terminal, is responsible for capturing real-time data transmitted by various sensors and monitoring equipment on the train, covering the operating parameters of key components such as train traction, braking, and bogies, as well as relevant information such as the in-vehicle environment and road conditions, providing raw data support for subsequent operation and maintenance work.

[0026] The data transmission module acts as a data bridge, transmitting massive amounts of collected train operation data to the ground control center in real time through various methods such as wireless communication and wired transmission, breaking down information barriers between the train and the ground, and ensuring that the data can be quickly aggregated.

[0027] The data storage and management module serves as the system's data warehouse, classifying, storing, managing, and backing up various types of train data transmitted to the ground. It also organizes data relationships, optimizes data retrieval efficiency, and lays a solid foundation for subsequent data analysis and processing.

[0028] As the core brain of the system, the data analysis module relies on advanced technologies such as big data, artificial intelligence, and machine learning to deeply mine, analyze, and process the massive amounts of stored data, generate detailed train status reports, and attempt to predict the future operating status of trains, providing data references and technical support for operation and maintenance decisions.

[0029] Although existing train operation and maintenance systems have achieved basic functions such as train status monitoring and preliminary analysis, replacing the tedious work of manual operation and maintenance to a certain extent, improving operation and maintenance efficiency, reducing the intensity of manual labor, and have formed a certain scale of application in scenarios such as high-speed rail and subways in first-tier cities, promoting the transformation of rail transit operation and maintenance towards intelligence, they still have many shortcomings in actual operation due to limitations in the level of technological development, system integration capabilities, and the current status of industry applications. They are unable to fully meet the high-end needs of modern rail transit for refined and intelligent operation and maintenance.

[0030] On the one hand, the accuracy and real-time performance of data analysis need to be further improved. Due to the large volume and complex types of data generated by train operation, and the differences in the models and precision of different sensors, there are a lot of noise and outliers in the data. In addition, the computational delay of complex learning models makes it difficult for data analysis results to accurately reflect the actual operating status of the train, and also makes it impossible to respond to sudden train situations in a timely manner, making it difficult to meet the millisecond-level response requirements of train operation control.

[0031] On the other hand, the existing technologies for fault diagnosis and prediction have obvious shortcomings. Current diagnostic models mostly rely on traditional rule bases or models trained on a single line, which have insufficient generalization ability and cannot fully cover all kinds of potential faults of trains. In particular, some early faults that are highly concealed and develop slowly are difficult to identify and warn in advance, and there are still cases of missed or misjudged faults. They cannot effectively support the transformation from fault repair to predictive maintenance.

[0032] Furthermore, data transmission delays and packet loss severely impact the overall system performance. Due to factors such as wireless communication signal interference and bandwidth limitations, some critical operational data experiences delays and loss during train-to-ground transmission. This prevents the ground control center from monitoring train operations in real time, delaying fault response. Simultaneously, the system lacks efficient anomaly detection and early warning mechanisms, failing to establish a closed-loop system of detection-diagnosis-early warning-response. Even when data anomalies or potential faults are detected, early warning signals cannot be issued quickly, and response plans cannot be pushed out. This hinders early fault detection and resolution, potentially escalating minor faults, disrupting normal train operations, and even threatening operational safety.

[0033] To address the aforementioned issues, this application proposes a train status determination method and system, which optimizes the system architecture and improves the accuracy of train status determination.

[0034] like Figure 1 As shown in the figure, this application provides a train status determination method for determining the current status of a train, including a data analysis step S101, a data storage step S102, a data update step S103, and a status determination step S104.

[0035] Data analysis step S101: Receive feedback data from the train and parse the status data from the feedback data to characterize the train malfunction and / or warning.

[0036] By receiving train-transmitted data and parsing out status data representing faults and / or warnings, the system achieves the filtering and structured processing of raw redundant data, avoiding interference from irrelevant data in subsequent status judgments, and laying a data foundation for accurately judging train status.

[0037] Specifically, the system periodically receives data transmitted from the train. The period can be set according to actual needs or the actual transmission speed of the train. For example, the period can be set to 1 second.

[0038] The returned data includes train number, equipment number, timestamp data, station information, kilometer markers, early warning channel data, and fault channel data.

[0039] Among them, the early warning channel data and the fault channel data are several fixed-length unsigned integer data, such as uint16, uint32, etc. Each early warning channel data or each fault channel data occupies one channel. Each bit of its binary data represents an early warning or fault, with 0 indicating no early warning or fault and 1 indicating an early warning or fault.

[0040] Each set of specific early warning information statistics tables corresponding to each early warning channel data is called the early warning dictionary. Each set of specific fault information statistics tables representing each fault channel data is called the fault dictionary. Both the early warning dictionary and the fault dictionary are stored in the database, facilitating the direct retrieval and searching of corresponding early warning or fault information based on the early warning channel data or fault channel data, thus clarifying the train's current specific status.

[0041] Data storage step S102: Set up a status cache pool and store status data in the status cache pool. The status cache pool is used to display the faults and / or warnings that are occurring on the train.

[0042] By setting up a status cache pool to hold the fault and / or warning data that is currently occurring on the train, the scattered status data is centrally managed, avoiding the mixing of historical invalid data with current valid data, ensuring that the benchmark for status judgment is unified and simple, and improving the manageability of status data.

[0043] The status cache pool includes a fault cache pool and an early warning cache pool. The fault cache pool stores fault channel data from the returned data. The early warning cache pool stores early warning channel data from the returned data.

[0044] Data update step S103: Update the data in the state cache pool based on the current state data and the state data from the previous time.

[0045] The update is based on a comparison of the current state data with the previous state data, which abandons the traditional full-coverage update method, reduces the amount of data reading and writing and the consumption of computing resources, while ensuring the real-time and accuracy of the data in the state cache pool.

[0046] Specifically, the status data includes fault data and warning data. Status data that indicates a train malfunction is used as fault data, and status data that indicates a train warning is used as warning data.

[0047] The fault data at the current moment is compared with the fault data at the previous moment stored in the fault cache pool, and the fault data in the fault cache pool is updated. The fault data in the updated fault cache pool is the fault that occurred on the train at the current moment.

[0048] The current warning data is compared with the previous warning data stored in the warning cache pool, and the warning data in the warning cache pool is updated. The updated warning data in the warning cache pool is the warning data for the train at the current moment.

[0049] State determination step S104: Determine the current state of the train based on the updated state cache pool.

[0050] Specifically, based on the data in the fault cache pool and the early warning cache pool, the current faults and early warnings of the train are obtained, which is the current state of the train.

[0051] Furthermore, it determines whether there have been any additions or deletions of data in the fault cache pool and the early warning cache pool. If so, the modified content is pushed to the front end of the train via network protocol.

[0052] Based on the updated state cache pool, a systematic determination of train status was achieved, breaking the limitations of fragmented and inaccurate status determination in existing technologies.

[0053] This application establishes a standardized process to achieve standardized processing of the entire train status chain, from data collection, parsing, storage, and updating to final determination, significantly improving the efficiency and reliability of train status determination and enhancing its accuracy.

[0054] In some embodiments, status data characterizing train malfunctions and / or warnings is parsed from the returned data, including: Fault channel data and early warning channel data are extracted from the returned data. Fault channel data is used to characterize faults in various equipment of the train, and early warning channel data is used to characterize early warnings in various equipment of the train.

[0055] Both fault channel data and early warning channel data are parsed in binary form, and each fault channel data and each early warning channel data generates its own corresponding binary index. A binary index of one indicates that the fault or early warning corresponding to that index is occurring, while a binary index of zero indicates that the fault or early warning corresponding to that index has not occurred.

[0056] Each binary index with a value of one, along with its corresponding train number, equipment number, and channel number from the fault channel data or early warning channel data, is merged to generate status data.

[0057] Specifically, the binary index with a value of one, along with the train number, equipment number, and channel number in the corresponding fault channel data, are merged to generate fault data. Similarly, the binary index with a value of one, along with the train number, equipment number, and channel number in the corresponding early warning channel data, are merged to generate early warning data.

[0058] By specifically extracting fault channel data and early warning channel data, and classifying and processing the two different types of status data, a clear distinction between fault and early warning information is achieved, avoiding the analysis confusion caused by the mixing of the two types of data, and facilitating subsequent hierarchical management and precise handling of faults and early warnings.

[0059] The fault channel data and early warning channel data are parsed in binary form, and corresponding binary indexes are generated. The binary parsing method is compatible with the transmission format of vehicle-mounted embedded devices and industrial-grade data. It has fast parsing speed and high accuracy, and can quickly convert the raw channel data into recognizable and processable status identifiers, overcoming the problem of complex raw feedback data format and improving parsing efficiency.

[0060] By merging binary indexes with a value of 1 with train number, equipment number, and channel number into a single structured status data entry, the standardization and structuring of status data are achieved. This ensures that each status data entry can fully display the train's identity and status, facilitating subsequent data comparison, updates, and storage. It also helps maintenance personnel quickly locate the specific train, equipment, or channel involved in a fault / warning, significantly improving the efficiency and targetedness of fault / warning handling. Furthermore, it provides convenience for subsequent data retrieval and display.

[0061] In some embodiments, the data analysis step S101 further includes: Extract the timestamp data from the returned data.

[0062] Determine if the timestamp data in the current transmitted data is greater than the timestamp data in the previous transmitted data. If so, start parsing the transmitted data.

[0063] Timestamp data accurately reflects the data generation time. By determining whether the timestamp of the data transmitted at the current moment is greater than the timestamp of the data transmitted at the previous moment, it ensures that only the more timely transmitted data enters the parsing process. This effectively filters out out-of-order data and expired data caused by network latency and data retransmission, preventing such invalid data from entering subsequent storage, update, and judgment steps. This reduces invalid calculations, improves the efficiency of data analysis, and enhances the accuracy and reliability of train status judgment.

[0064] In some embodiments, the data update step S103 includes: The state data from the previous moment is stored in the state cache pool.

[0065] Specifically, the fault cache pool stores fault data from the previous moment. The warning cache pool stores warning data from the previous moment.

[0066] Each current state data point is compared with the previous state data point to determine whether the current state data point is the same as the previous state data point.

[0067] If so, then retain the state data from the previous time step that is identical to the current state data in the state cache pool.

[0068] If not, the current state data, which is different from the state data of the previous time step, will be added to the state cache pool.

[0069] Generate an initial updated state cache pool.

[0070] Specifically, the warning data at the current moment is compared with the warning data at the previous moment one by one to determine whether the warning data at the current moment is the same as the warning data at the previous moment. If so, the warning data in the warning cache pool that is the same as the warning data at the current moment remains unchanged. If not, the warning data at the current moment that is different from the warning data at the previous moment is added to the warning cache pool.

[0071] Specifically, the fault data at the current moment is compared with the fault data at the previous moment one by one to determine whether the fault data at the current moment is the same as the fault data at the previous moment. If so, the fault data in the fault cache pool that is the same as the fault data at the current moment remains unchanged. If not, the fault data at the current moment that is different from the fault data at the previous moment is added to the fault cache pool.

[0072] This application provides a clear reference benchmark for comparing current data by storing the state data from the previous moment in a state cache pool, ensuring the targeted nature of data updates. Simultaneously, by employing a line-by-line comparison method, it accurately identifies the differences between the current and previous moment's state data, adding only the different current state data to the state cache pool. This avoids multiple writes of duplicate data, significantly reducing data read / write operations and computational resource consumption, and improving the efficiency of data updates. By generating an initially updated state cache pool, preliminary screening and incremental replenishment of state data are completed, providing an intermediate carrier for subsequent further removal of invalid data and optimization of cache content. This ensures the layered reliability of the data update logic and avoids cache data chaos caused by one-time updates.

[0073] Furthermore, this method enables the state cache pool to keep up with the dynamic changes in the train's state in real time, providing more accurate and efficient data support for the subsequent state judgment step S104, and further improving the real-time performance and accuracy of the train state judgment.

[0074] In some embodiments, each status data includes the device number of the device where the fault or warning occurred, and the data update step S103 further includes: Based on the device number, all state data in the initially updated state cache pool are compared one by one with the state data at the current moment. If any state data appears in the initially updated state cache pool but does not exist in the current state data, then the state data is deleted from the initially updated state cache pool.

[0075] Generate an updated state cache pool.

[0076] Each status data entry contains the device number of the device where the fault or warning occurs. The device number can uniquely identify each device on the train. Therefore, this application uses the device number as the unique matching identifier for status data. By associating status data with the device number and comparing data based on this, the status changes of the same device can be accurately located.

[0077] By comparing all status data in the initially updated status cache pool with the current status data by device number, it is possible to accurately identify status data that exists in the cache pool but does not appear in the current data. This type of data corresponds to faults or warnings that the train equipment has returned to normal and no longer exist. Deleting these from the cache pool ensures that the status cache pool always retains only the faults and / or warnings that are actually occurring on the train, fundamentally avoiding the residue of invalid old data. The final updated status cache pool has higher data purity and stronger targeting, completely solving the problems of status cache data redundancy and invalid data interfering with status judgment. This makes subsequent status judgment results based on the cache pool more accurate, and also facilitates maintenance personnel to quickly locate faulty / warning devices, improving maintenance efficiency.

[0078] Status data includes warning data and fault data.

[0079] In some embodiments, determining the current state of the train includes: Check if there is fault data in the updated status cache pool. If there is, the train's current status is faulty. If not, check if there is warning data in the status cache pool. If there is, the train's current status is warning. If not, the train's current status is normal.

[0080] The system clearly defines the priority of status assessments, placing fault states with the highest priority, followed by warning states, and normal states with the lowest priority. This aligns with the core needs of train safety management, ensuring that train faults are identified and alerted immediately, allowing time for fault handling and maximizing train operational safety. It also facilitates automated processing in the backend system and enables front-end maintenance personnel and drivers to quickly grasp the train's status and take targeted measures. Furthermore, this hierarchical assessment logic is implemented based on an updated status cache pool, ensuring that status assessment results keep pace with the dynamic changes in train status in real time, further improving the accuracy and practicality of train status assessments and providing strong status support for safe train operation.

[0081] In some embodiments, after the state determination step S104, the method further includes: Determine if the data in the state cache pool has changed. If so, send the changed data to the front end of the train.

[0082] By determining whether the data in the state cache pool has changed, accurate identification of state changes is achieved. Only the changed data is pushed, instead of pushing all state data, which greatly reduces the amount of communication data between the front end and the back end, reduces communication bandwidth pressure, reduces the workload of front end devices in receiving and processing data, saves computing resources, and improves the operating efficiency of the front end system.

[0083] The timely push of status change data ensures that the status displayed at the front end of the train is consistent with the status determined by the back end in real time, avoiding the situation where the front end display lags behind the actual status of the train. This enables drivers and maintenance personnel to grasp the dynamic changes in the train status as soon as possible, especially the occurrence and elimination of faults and warning statuses, which facilitates timely response measures and improves the safety and timeliness of train operation and maintenance.

[0084] In some embodiments, the state determination step S104 includes: During the periodic reception of data, if none of the received data within a preset period contains a train number, the current status of the train corresponding to that train number is determined to be offline.

[0085] This application uses the absence of data transmission from a specific train number within a preset period as the criterion for judgment. This aligns with the periodic transmission characteristics of train data transmission, and the judgment logic is scientific, reasonable, and highly operable. This criterion enables accurate identification of a single train's offline status, distinguishing between two scenarios: normal train operation without faults / warnings and train offline with no data transmission, further refining the dimensions for judging train status.

[0086] In actual operation and maintenance, accurate identification of the offline status of a single train makes it easier for maintenance personnel to promptly discover lost trains, quickly troubleshoot communication failures, train malfunctions, and other issues, avoiding safety hazards caused by undetected train offline status. It also provides staff with precise operation and maintenance targets, improves operation and maintenance efficiency, and ensures the safety and controllability of train operation.

[0087] In some embodiments, the state determination step S104 includes: If no data is received from a train line within a preset time, the current status of all trains on that line is determined to be offline.

[0088] This application addresses scenarios involving complete line communication outages by establishing a train-wide offline detection logic. The logic uses the absence of any transmitted data from a specific train line within a preset timeframe as the criterion for judgment. This allows for rapid identification of communication anomalies across the entire line, avoiding the tedious process of checking each individual train and significantly improving the efficiency of offline status determination. Rapid identification of complete line offline status facilitates timely location of line-level communication faults by maintenance personnel, enabling centralized handling measures, shortening fault handling time, reducing safety hazards and operational impacts caused by complete line offline, and further improving the efficiency and overall management level of train maintenance.

[0089] In practical applications, during initialization, the warning dictionary and fault dictionary are read from the database into memory. A warning cache pool and a fault cache pool are set up; the warning cache pool stores warning information, and the fault cache pool stores fault information. The initial state of all trains on the entire line is set to offline.

[0090] Using a ground server algorithm, data transmitted from any train is received. The binary data is parsed into several JSON-formatted data packets according to the protocol, with the push flag set to 0. The train number, device number, and timestamp data are extracted from the JSON data packets, and the train is added to the online train number set. The current timestamp is compared with the previous timestamp of the same train and device. If the current timestamp is greater than the previous timestamp, the transmitted data is analyzed, and the timestamp is updated, using the current timestamp as the latest for the next comparison. Otherwise, the process continues until the next data packet is transmitted.

[0091] Retrieve fault channel data and early warning channel data from the data packet. Since the data is in binary format, if there is a fault or early warning in the fault channel data or early warning channel data, the corresponding data will be displayed as 1. Count the number of non-zero data. If the count is not zero, parse the non-zero fault channel data and early warning channel data into binary numbers of the corresponding length, obtain the index of the binary number containing 1, and store it in an array.

[0092] Set up a cache list. Iterate through the array, and combine each index that is 1 with its corresponding train number, equipment number, and channel number to form a piece of information. The specific format of the information can be a concatenated string, a HashMap, etc., and cache this information in the cache list.

[0093] HashMap is a hash map, a commonly used key-value pair storage structure in programming.

[0094] The cache list is traversed. If the information representing a fault or warning in the cache list does not exist in the corresponding fault cache pool or warning cache pool, the information is added to the corresponding fault cache pool or warning cache pool, and the push flag is set to 1. Then, the traversal continues. After the traversal is completed, a preliminary updated fault cache pool and warning cache pool are formed. After the traversal is completed, or the number of non-zero data in the fault or warning channel data is 0, the warning data or fault data corresponding to the device number is retrieved from the preliminary updated fault cache pool and warning cache pool according to the device number. If the data does not exist in the cache list, the data is deleted from the cache pool, and the push flag is set to 1.

[0095] Once all JSON data packets have been parsed, determine whether the fault cache pool and the warning cache pool have performed any add or delete operations. If so, push the corresponding added and / or deleted content to the front end via WebSocket.

[0096] Traverse the set of online train numbers. If the fault information of a train is found in the fault cache pool, the train's status is set to fault. If the warning information of a train is found in the warning cache pool, but the fault information of the train is not found in the fault cache pool, the train's status is set to warning. If neither is found, the train's status is set to normal.

[0097] If no train number is found in the set of online train numbers for N consecutive cycles, the train's status is set to offline. If the train was not previously offline, the push flag is set to 1. Then, the set of online train numbers is cleared.

[0098] N can be set according to actual needs.

[0099] If the push flag is 1, the updated train status information for the entire line will be pushed to the front end via WebSocket. Then, it will wait for the next data packet to be sent back.

[0100] WebSocket is a network communication protocol that enables full-duplex, long-lived connections over a single Transmission Control Protocol (TCP) connection.

[0101] When determining if the entire line is offline, if no data is received within a preset time, the status of all trains on the line is set to offline, and the offline information is pushed to the front end via WebSocket.

[0102] like Figure 2 As shown in the embodiments of this application, a train status determination system is also provided, including: The data analysis module 201 is configured to receive feedback data from the train and parse the feedback data to extract status data that characterizes train malfunctions and / or warnings.

[0103] The data storage module 202 is configured to set up a status cache pool and store status data in the status cache pool, which is used to display faults and / or warnings that are occurring on the train.

[0104] The data update module 203 is configured to update the data in the state cache pool based on the current state data and the state data from the previous time.

[0105] The status judgment module 204 is configured to determine the current status of the train based on the updated status cache pool.

[0106] This system adopts a modular architecture design, with clearly defined functions and responsibilities for each module. This decoupling of system functions facilitates development, debugging, maintenance, and upgrades, reducing development and operation costs. It ensures the system can stably and efficiently execute train status judgment procedures, significantly improving system reliability and usability. The system solidifies standardized status judgment procedures into modular functions, achieving automated and systematic processing of train status judgments. This greatly improves the efficiency and accuracy of train status monitoring, providing continuous and stable technical support for safe train operation. It also facilitates integration with train operation and maintenance management systems and front-end display systems, enhancing the intelligence level of train operation and maintenance management.

[0107] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0108] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A method for determining train status, characterized in that, Used to determine the current status of the train, including: The data analysis step involves receiving feedback data from the train and parsing the feedback data to extract status data that characterizes train malfunctions and / or warnings. The data storage step involves setting up a status cache pool and storing the status data in the status cache pool, which is used to display the faults and / or warnings that are occurring on the train. The data update step involves updating the data in the state cache pool based on the current state data and the state data from the previous time. The status determination step involves determining the current status of the train based on the updated status cache pool.

2. The train status determination method according to claim 1, characterized in that, The returned data is parsed to extract status data characterizing train malfunctions and / or warnings, including: Fault channel data and early warning channel data are extracted from the returned data. The fault channel data is used to characterize faults in various equipment of the train, and the early warning channel data is used to characterize early warnings in various equipment of the train. Both the fault channel data and the early warning channel data are parsed in binary form, and each fault channel data and each early warning channel data generates its own corresponding binary index; wherein, a binary index of 1 indicates that the fault or early warning corresponding to the binary bit at that index is occurring, and a binary index of 0 indicates that the fault or early warning corresponding to the binary bit at that index has not occurred. The status data is generated by merging the binary index of each number with a value of one, the train number, equipment number, and channel number in the corresponding fault channel data or early warning channel data.

3. The train status determination method according to claim 1, characterized in that, The data analysis steps also include: Extract the timestamp data from the returned data; Determine whether the timestamp data in the current time-transmitted data is greater than the timestamp data in the previous time-transmitted data. If so, start parsing the data.

4. The train status determination method according to claim 1, characterized in that, The data update steps include: The state data from the previous moment is stored in the state cache pool; Each piece of state data at the current moment is compared with the state data at the previous moment to determine whether the state data at the current moment is the same as the state data at the previous moment. If so, then retain the state data from the previous time that is the same as the state data at the current time in the state cache pool; If not, the current state data, which is different from the state data of the previous time step, is added to the state cache pool; Generate the state cache pool with initial updates.

5. The train status determination method according to claim 4, characterized in that, Each piece of status data includes the device number of the device where the fault or warning occurred, and the data update step further includes: According to the device number, all the state data in the initially updated state cache pool are compared one by one with the state data at the current time. If any state data appears in the initially updated state cache pool but does not exist in the current state data, then the state data is deleted from the initially updated state cache pool. Generate the updated state cache pool.

6. The train status determination method according to claim 1, characterized in that, The determination of the train's current status includes: Determine whether there is fault data in the updated state cache pool. If there is, the train's current state is fault state. If not, determine whether there is warning data in the state cache pool. If there is, the train's current state is warning state. If not, the train's current state is normal state.

7. The train status determination method according to claim 1, characterized in that, After the state determination step, the method further includes: Determine whether the data in the state cache pool has changed. If so, send the changed data to the front end of the train.

8. The train status determination method according to claim 1, characterized in that, The state determination step includes: During the periodic reception of the returned data, if none of the returned data received within a preset period contains a train number, the current status of the train corresponding to that train number is determined to be offline.

9. The train status determination method according to claim 1, characterized in that, The state determination step includes: If no data is received from a train line within a preset time, the current status of all trains on that train line is determined to be offline.

10. A train status determination system, characterized in that, The train status determination method according to any one of claims 1-9 includes: The data analysis module is configured to receive feedback data from the train and parse the feedback data to extract status data that characterizes train malfunctions and / or warnings. The data storage module is configured to set up a status cache pool and store the status data in the status cache pool, which is used to display the faults and / or warnings that are occurring on the train. The data update module is configured to update the data in the state cache pool based on the current state data and the state data from the previous time. The status determination module is configured to determine the current status of the train based on the updated status cache pool.

Images