Method for detecting abnormalities in line-side devices, system for detecting abnormalities in line-side devices, and computer program for detecting abnormalities in line-side devices

Abstract

An aspect relates to providing a track-side device anomaly detection technique for detecting an anomaly related to a track-side device and determining an appropriate response action to mitigate an impact of a communication failure resulting from the track-side device anomaly. The track-side device anomaly detection method includes generating a set of error record data indicating presence or absence of a transmission error between a set of railcars and a set of track-side devices, generating a set of error count data indicating a number of detected transmission errors, detecting an anomaly related to a first track-side device based on the set of error count data, determining a priority level of the first set of track-side data configured to be transmitted by the first track-side device, and determining a response action related to the first track-side device based on the priority level of the first set of track-side data.

Description

[Technical Field]

[0001] The present disclosure relates to a line-side device abnormality detection method, a line-side device abnormality detection system, and a line-side device abnormality detection computer program. [Background technology]

[0002] In recent years, as railway systems have become more sophisticated, the importance of reliably monitoring, collecting, and communicating information about the operation of trackside equipment, such as trackside devices, has likewise increased. Analysis of operational information collected from railway systems can provide valuable insights into operational efficiency and safety.

[0003] Previously, techniques have been considered to monitor railroad systems to detect whether a beacon or railcar has malfunctioned. As an example of a monitoring system for a railway network, European Patent Application Publication No. 3988423 (Patent Document 1) discloses "a monitoring system, server, method, and bimodal railway vehicle for a railway network. The monitoring system includes one or more bimodal railway vehicles configured to operate on both electrified and non-electrified sections of the railway network; one or more beacons located at respective trackside points and configured to broadcast beacon signals indicating a transition from an electrified section of the railway network to a non-electrified section of the railway network, or vice versa; and a server configured to receive from a given bimodal railway vehicle one or both of a beacon signal received from a given beacon by the given bimodal railway vehicle and a location signal indicating the location of the given bimodal railway vehicle on the railway network. The server is further configured to determine from the received beacon signal and / or the received location signal whether the given beacon, the given bimodal railway vehicle, or a further bimodal railway vehicle has a fault." [Prior art documents] [Patent documents]

[0004] [Patent Document 1] European Patent Application Publication No. 3988423 Summary of the Invention [Problem to be solved by the invention]

[0005] In modern rail systems, rail vehicles communicate with wayside equipment located along the rail route to obtain data regarding the status of upcoming rail sections, the physical location of the rail vehicle, control actions of the rail vehicle, and the location of subsequent wayside equipment.

[0006] However, in some situations, a rail vehicle may fail to communicate with a particular piece of trackside equipment, for example, due to a failure or interference from the trackside equipment. In such cases, the rail vehicle may not obtain important data used to operate the rail vehicle. As a result, the failure of the trackside equipment may adversely affect the operational efficiency and safety of the rail vehicle.

[0007] While Patent Document 1 discloses a technique for distinguishing whether a communication failure with a trackside device is due to a fault in the railcar or a fault in the trackside device, it does not consider or disclose a technique for determining an appropriate response action to mitigate the impact of the communication failure based on the relative importance of data that failed to be acquired from the trackside device. Thus, while Patent Document 1 provides for identification of a faulty railcar and trackside device, challenges remain related to maintaining the operational efficiency and safety of the railcar when a trackside device fails.

[0008] Therefore, an object of the present disclosure is to provide a line-side device anomaly detection technique for detecting anomalies related to line-side devices and determining appropriate response actions to mitigate the effects of communication failures resulting from the line-side device anomaly. [Means for solving the problem]

[0009] A representative example of the present disclosure is a wayside device anomaly detection method for a railway network, the railway network comprising a set of railway vehicles configured to operate on a set of routes of the railway network, and a set of wayside devices disposed at predetermined locations along the set of routes of the railway network and configured to transmit wayside data to the set of railway vehicles, the wayside device anomaly detection method comprising: generating a set of error recording data indicating presence or absence of a transmission error between a railway vehicle of the set of railway vehicles and a wayside device of the set of wayside devices; a first line-side device of a subset of the set of line-side devices having a number of transmission errors detected therefrom that exceed an error threshold within a time threshold; a first line-side device of a subset of the set of line-side devices having a number of transmission errors detected therefrom that exceed an error threshold within a time threshold based on the set of error count data ... [Effects of the Invention]

[0010] In accordance with the present disclosure, a line-side device anomaly detection technique can be provided for detecting anomalies related to line-side devices and determining appropriate response actions to mitigate the effects of communication failures resulting from the line-side device anomaly.

[0011] Other problems, configurations, and advantages will become apparent from the following description of embodiments of the present invention. [Brief explanation of the drawings]

[0012] [Figure 1] 1 illustrates an exemplary computing architecture for implementing embodiments of the present disclosure. [Figure 2]FIG. 1 illustrates an exemplary hardware configuration of a line-side device anomaly detection system according to an embodiment of the present disclosure. [Figure 3] 1 is a flowchart illustrating a method for detecting an abnormality in a line-side device according to an embodiment of the present disclosure. [Figure 4] FIG. 2 illustrates an error record table for storing a set of error record data according to an embodiment of the present disclosure. [Figure 5] FIG. 2 illustrates an error count table for storing a set of error count data according to an embodiment of the present disclosure. [Figure 6] FIG. 2 illustrates a path management table for storing a set of path management data according to an embodiment of the present disclosure. [Figure 7] FIG. 2 illustrates a trackside data management table for storing a set of trackside data according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0013]

[0023] Herein, embodiments of the present invention will be described with reference to the drawings. It should be noted that the embodiments described herein are not intended to limit the present invention according to the claims, and it should be understood that each element and combination of elements described with respect to the embodiments is not strictly necessary to practice aspects of the present invention.

[0014] Various aspects are disclosed in the following description and related drawings. Alternative aspects may be devised without departing from the scope of the present disclosure. Additionally, well-known elements of the present disclosure will not be described in detail or will be omitted so as not to obscure the relevant details of the present disclosure.

[0015] The words "exemplary" and / or "example" are used herein to mean "serving as an example, instance, or illustrative example." Any aspect described herein as "exemplary" and / or "example" is not necessarily to be construed as preferred or advantageous over other aspects. Likewise, the phrase "aspects of the present disclosure" does not require that all aspects of the present disclosure include the discussed feature, advantage, or characteristic of operation.

[0016] Furthermore, many aspects are described in terms of sequences of actions to be performed by, for example, elements of a computing device. It will be recognized that the various actions described herein can be performed by specific circuitry (e.g., an application-specific integrated circuit (ASIC)), by program instructions executed by one or more processors, or a combination of both. In addition, the sequences of actions described herein can be considered to be embodied as a whole in any form of computer-readable storage medium storing a corresponding set of computer instructions that, when executed, can cause an associated processor to perform the functions described herein. As such, various aspects of the present disclosure may be embodied in many different forms, all of which are contemplated to be within the subject matter of the claims.

[0017] Detailed descriptions of embodiments of the present disclosure are described herein with reference to the drawings.

[0018] Referring now to the drawings, Figure 1 illustrates a schematic block diagram of a computer system 100, according to an embodiment, for implementing various embodiments of the present disclosure. The mechanisms and devices of the various embodiments disclosed herein apply equally to any suitable computing system. The major components of computer system 100 include one or more processors 102, memory 104, terminal interface 112, storage interface 113, I / O (input / output) device interface 114, and network interface 115, all of which are communicatively coupled, directly or indirectly, for inter-component communication via memory bus 106, I / O bus 108, bus interface unit 109, and I / O bus interface unit 110.

[0019] Computer system 100 may include one or more general-purpose programmable central processing units (CPUs) 102A and 102B, generally referred to herein as processors 102. In embodiments, computer system 100 may include multiple processors, although in particular embodiments, computer system 100 may alternatively be a single CPU system. Each processor 102 executes instructions stored in memory 104 and may include one or more levels of on-board cache.

[0020] In embodiments, memory 104 may include random-access semiconductor memory, storage devices, or storage media (either volatile or nonvolatile) for storing or encoding data and programs. In particular embodiments, memory 104 represents the entire virtual memory of computer system 100 and may also include virtual memory of other computer systems coupled to computer system 100 or connected via a network. While memory 104 can be conceptually viewed as a single monolithic entity, in other embodiments, memory 104 is a more complex configuration, such as a hierarchy of caches and other memory elements. For example, memory may exist in multiple levels of caches, which may be further divided by function, whereby one cache holds instructions and another cache holds non-instruction data used by the processor. Memory may also be distributed and associated with different CPUs or sets of CPUs, as is known in any of a variety of so-called non-uniform memory access (NUMA) computer architectures.

[0021] Memory 104 may store all or a portion of the various programs, modules, and data structures for handling data transfers described herein. For example, memory 104 may store lineside equipment anomaly detection application 150. In an embodiment, lineside equipment anomaly detection application 150 may include instructions or statements that execute on processor 102 or that are interpreted by instructions or statements that execute on processor 102 to perform functions as described further below. In particular embodiments, lineside equipment anomaly detection application 150 is implemented in hardware via semiconductor devices, chips, logic gates, circuits, circuit cards, and / or other physical hardware devices instead of or in addition to a processor-based system. In embodiments, lineside equipment anomaly detection application 150 may include data in addition to instructions or statements. In particular embodiments, cameras, sensors, or other data input devices (not shown) may be provided in direct communication with bus interface unit 109, processor 102, or other hardware of computer system 100. In such a configuration, the need for processor 102 to access memory 104 and lineside equipment anomaly detection application 150 may be reduced.

[0022] Computer system 100 may include a bus interface unit 109 that handles communication between processor 102, memory 104, display system 124, and I / O bus interface unit 110. I / O bus interface unit 110 may be coupled to I / O bus 108 to transfer data to and from various I / O units. I / O bus interface unit 110 communicates via I / O bus 108 with multiple I / O interface units 112, 113, 114, and 115, also known as I / O processors (IOPs) or I / O adapters (IOAs). Display system 124 may include a display controller, display memory, or both. The display controller may provide video, audio, or both types of data to display device 126. Additionally, computer system 100 may include one or more sensors or other devices configured to collect and provide data to processor 102. By way of example, computer system 100 may include biometric sensors (e.g., collecting heart rate data, stress level data), environmental sensors (e.g., collecting humidity data, temperature data, pressure data), or motion sensors (e.g., collecting acceleration data, movement data), etc. Other types of sensors are possible. Display memory may be dedicated memory for buffering video data. Display system 124 may be coupled to a display device 126, such as a standalone display screen, a computer monitor, a television, or the display of a tablet or handheld device. In one embodiment, display device 126 may include one or more speakers for rendering audio. Alternatively, one or more speakers for rendering audio may be coupled to the I / O interface unit. In an alternative embodiment, one or more of the functions provided by display system 124 may be incorporated into an integrated circuit that also includes processor 102. Additionally, one or more of the functions provided by bus interface unit 109 may be incorporated into an integrated circuit that also includes processor 102.

[0023] The I / O interface unit supports communication with various storage and I / O devices. For example, the terminal interface unit 112 supports connection of one or more user I / O devices 116, which may include user output devices (such as a video display, speakers, and / or a television receiver) and user input devices (such as a keyboard, mouse, keypad, touchpad, trackball, buttons, light pen, or other pointing device). A user may use a user interface to manipulate the user input devices to provide input data and commands to the user I / O devices 116 and the computer system 100, and may also receive output data via the user output devices. For example, the user interface may be presented via the user I / O devices 116, such as displayed on a display, played through speakers, or printed by a printer.

[0024] Storage interface 113 supports the connection of one or more disk drives or direct access storage devices 117 (typically rotating magnetic disk drive storage devices, but may alternatively be other storage devices, including arrays of disk drives or solid-state drives such as flash memory configured to appear as a single mass storage device to a host computer). In some embodiments, storage device 117 may be implemented by any type of secondary storage device. The contents of memory 104, or any portion thereof, may be stored in storage device 117 and retrieved from storage device 117 as needed. I / O device interface 114 provides an interface to any of a variety of other I / O devices or other types of devices, such as printers or fax machines. Network interface 115 provides one or more communication paths from computer system 100 to other digital devices and computer systems; these communication paths may include, for example, one or more networks 130.

[0025] 1 illustrates a particular bus structure providing direct communication paths between processor 102, memory 104, bus interface 109, display system 124, and I / O bus interface unit 110, in alternative embodiments, computer system 100 may include different buses or communication paths that may be arranged in any of a variety of forms, such as hierarchical, star, or web configurations, multiple hierarchical buses, parallel and redundant paths, or point-to-point links in any other suitable type of configuration. Furthermore, while I / O bus interface unit 110 and I / O bus 108 are shown as single respective units, computer system 100 may actually include multiple I / O bus interface units 110 and / or multiple I / O buses 108. While multiple I / O interface units are shown isolating I / O bus 108 from the various communication paths running to the various I / O devices, in other embodiments, some or all of the I / O devices are directly connected to one or more system I / O buses.

[0026] In various embodiments, computer system 100 is a multi-user mainframe computer system, a single-user system, or a server computer, or similar device with little or no direct user interface, but which receives requests from other computer systems (clients). In other embodiments, computer system 100 may be implemented as a desktop computer, a portable computer, a laptop or notebook computer, a tablet computer, a pocket computer, a telephone, a smartphone, or any other suitable type of electronic device.

[0027] Next, an exemplary hardware configuration of a line-side device abnormality detection system according to an embodiment of the present disclosure will be described with reference to FIG.

[0028] 2 is a diagram illustrating an exemplary hardware configuration of a track-side device anomaly detection system 200 according to an embodiment of the present disclosure. The track-side device anomaly detection system 200 relates to an information processing system configured to detect transmission errors between a rail vehicle and a track-side device, determine an anomaly in the track-side device when the number of transmission errors for the track-side device exceeds an error threshold within a time threshold, determine a priority level of track-side data associated with the track-side device, and determine a response action for the track-side device based on the determined priority level.

[0029] 2 , a track-side device anomaly detection system 200 according to an embodiment of the present disclosure includes a set of railcars 210, a set of track-side devices 215, a user terminal 220, a communication network 230, and a track-side device anomaly detection device 240. In the track-side device anomaly detection system 200, the set of railcars 210, the user terminal 220, and the track-side device anomaly detection device 240 may be communicatively connected via the communication network 230. Furthermore, the set of track-side devices 215 may be configured to communicate with the set of railcars 210 via wireless communication. In a particular embodiment, the set of track-side devices 215 may also be connected to the communication network 230. Here, the communication network 230 may include a local area network (LAN) connection, the Internet, a wide area network (WAN) connection, or a metropolitan area network (MAN) connection, or the like.

[0030] In an embodiment, the set of rail vehicles 210 may include one or more rail cars, such as trains, that are mechanically coupled or connected to travel on tracks extending along a route. Alternatively, the cars may not be mechanically coupled, but may communicate with one another to coordinate their movements and for the fleet of cars to move along a route in a coordinated manner. The set of rail vehicles 210 may be used in operations described as freight rail, passenger rail, high-speed rail, commuter rail, rail transit, subways, light rail, trams, tramways, or rail-tram vehicles. In an embodiment, the set of rail vehicles 210 may be configured to obtain a set of wayside data from each wayside device of the set of wayside devices 215 that it passes. For ease of explanation, FIG. 2 illustrates a configuration including a single railcar, however, it should be noted that the present disclosure is not limited thereto and may also be applied to configurations including multiple railcars.

[0031] The set of wayside equipment 215 refers to equipment located along a rail route and configured to transmit wayside data to rail vehicles 210. In an embodiment, this wayside data may include information regarding the status of upcoming rail sections, the physical locations of rail vehicles, control maneuvers of the rail vehicles (such as speed limits), the geographical conditions of the route (such as curves and grades), and the locations of subsequent wayside equipment. However, wayside data is not particularly limited herein and may include any information to be communicated to the set of rail vehicles 210. It should be noted that, for ease of explanation, FIG. 2 illustrates a configuration including a single trackside device, but in reality, multiple trackside devices will be spaced apart along the route traveled by the set of rail cars 210.

[0032] In an embodiment, the set of wayside devices 215 may include a set of balis. Generally, balis refers to electronic beacons or transponders installed between rails of a railway as part of an automatic train protection (ATP) system. The set of balis is energized by radio frequency energy transmitted by a balis transmission module mounted on the set of railcars 210 and can transmit information to or receive information from the set of railcars 210. The set of balis may include fixed data balis configured to transmit the same data to all passing railcars, or transparent data balis that transmit variable data. The set of balis may be mounted on or between sleepers or ties on the centerline of the railroad track.

[0033] In an embodiment, the set of wayside equipment 215 may include a set of radio block centers (RBCs), which may be configured to receive information from the set of rail cars 210 (via position reports) and use it to generate travel passes that are sent back to the set of rail cars 210 via wireless communication.

[0034] In certain embodiments, a set of trackside devices 215 according to the present disclosure may be dynamically configurable in real time. More specifically, the set of trackside data that a particular trackside device is configured to transmit to a set of rail cars 210 can be dynamically set, updated, or changed in real time. In certain embodiments, programming of a set of trackside devices 215 can be performed via communication with other trackside devices to which the set of trackside devices 215 is connected. In certain embodiments, programming of a set of trackside devices 215 can be performed by a trackside device anomaly detection device 240 via a communication network 230.

[0035] User terminal 220 is a device that can be used by a user (e.g., a client) of line-side device anomaly detection device 240. In an embodiment, user terminal 220 can be used to request anomaly detection of a set of line-side devices 215 by line-side device anomaly detection device 240 and to determine output data generated by line-side device anomaly detection device 240. As an example, user terminal 220 can be implemented using a personal computer, a tablet computer, a smartphone, or other computing device.

[0036] The line-side equipment anomaly detection device 240 is a device configured to detect anomalies related to a set of line-side devices 215 and determine appropriate response actions to mitigate the effects of the line-side equipment anomaly. In an embodiment, the line-side equipment anomaly detection device 240 may be implemented using the computer system 100 shown in FIG. 1 as part of a distributed computing architecture. For example, the functionality of the line-side equipment anomaly detection device 240 may be implemented using one or more computing devices (e.g., the computer system 100) that comprise a cloud infrastructure.

[0037] 2, the line-side equipment anomaly detection device 240 may include a data management unit 242, an anomaly detection unit 244, a priority determination unit 246, and a response action determination unit 248. In an embodiment, the data management unit 242, the anomaly detection unit 244, the priority determination unit 246, and the response action determination unit 248 may be implemented as software modules constituting the line-side equipment anomaly detection application 150 stored in the memory 104 of the computer system 100 shown in FIG. 1. In this manner, the functions of the data management unit 242, the anomaly detection unit 244, the priority determination unit 246, and the response action determination unit 248 may be executed by the processor 102 of the computer system 100 to realize the techniques of the present disclosure.

[0038] The data management unit 242 is a functional unit for generating and managing data related to transmission errors between the set of railcars 210 and the set of wayside devices 215. In an embodiment, the data management unit 242 may generate a set of error record data indicating the presence or absence of transmission errors between a railcar of the set of railcars and a wayside device of the set of wayside devices 215, and may generate a set of error count data indicating the number of transmission errors detected and the error detection time for each transmission error, for each wayside device of the subset of the set of wayside devices 215 in which a transmission error was detected. The operation of the data management unit 242, the setting of the error recording data, and the setting of the error count data will be described in detail later, and therefore will not be described here.

[0039] The anomaly detection unit 244 is a functional unit for detecting an anomaly related to the set of line-side devices 215 based on the set of error count data generated by the data management unit 242. In an embodiment, the anomaly detection unit 244 can detect an anomaly related to a first line-side device when the number of transmission errors detected for a first line-side device of a subset of the set of line-side devices 215 exceeds an error threshold within a time threshold based on the set of error count data. The operation of the abnormality detection unit 244 will be described in detail later, and therefore will not be described here.

[0040] The priority determination unit 246 is a functional unit for determining a priority level of a set of lineside data associated with a lineside device (e.g., a first lineside device) in which an anomaly has been detected. Here, the priority level may be information indicating how important a particular set of lineside data is compared to other sets of lineside data. In an embodiment, the priority level may be represented using categories of "high," "medium," or "low." In a particular embodiment, the priority level may be represented as a numerical value (e.g., between 1 and 10 or 10 and 100), with a higher value indicating a higher priority and a lower value indicating a lower priority. The operation of the priority determination unit 246 will be described in detail later, and therefore will not be described here.

[0041] The response action determination unit 248 is a functional unit that determines a response action for a line-side device in which an anomaly is detected (e.g., a first line-side device). The response action may be determined based on a priority level of a set of line-side data related to the line-side device in which the anomaly is detected. In general, a response action refers to a process, activity, or operation for mitigating the impact of the detected anomaly with respect to the line-side device. The operation of the response action determination unit 248 and the response action will be described in detail later, and therefore will not be described here.

[0042] 2, in addition to the data management unit 242, the anomaly detection unit 244, the priority determination unit 246, and the response action determination unit 248, the track-side equipment anomaly detection device 240 may include one or more databases for storing various information used in performing the functions of the present disclosure. In an embodiment, as shown in FIG. 2, the track-side equipment anomaly detection device 240 may include an error recording database 250, an error count database 252, a railcar route management database 254, and a track-side data management database 256. These databases may be stored, for example, in the storage device 117 of the computer system 100 shown in FIG. 1.

[0043] The error record database 250 is a database for storing an error record table. The error count database 252 is a database for storing an error count table. The railcar route management database 254 is a database for storing a route management table. The track side data management database 256 is a database for storing track side data management tables.

[0044] The line-side device abnormality detection system 200 shown in FIG. 2 can provide a line-side device abnormality detection technology that detects an abnormality in a line-side device and determines an appropriate response action to mitigate the impact of a communication failure caused by the abnormality in the line-side device.

[0045] Next, a method for detecting an abnormality in a line-side device according to an embodiment of the present disclosure will be described with reference to FIG.

[0046] 3 is a flowchart illustrating a line-side device anomaly detection method 300 according to an embodiment of the present disclosure. The line-side device anomaly detection method 300 involves detecting transmission errors between a rail vehicle and a line-side device, determining an anomaly for the line-side device when the number of transmission errors for the line-side device exceeds an error threshold within a time threshold, determining a priority level for line-side data associated with the line-side device, and determining a response action for the line-side device based on the determined priority level. The line-side device anomaly detection method 300 can be implemented by various functional units of the line-side device anomaly detection device 240 shown in FIG. 2.

[0047] First, in step S305, data management unit 242 generates a set of error record data indicating the presence or absence of a transmission error between a rail car of the set of rail cars 210 and a lineside device of the set of wayside devices 215. In an embodiment, data management unit 242 may generate the set of error record data in real time based on operational data received directly from the set of rail cars 210 or indirectly from user terminal 220. In one particular embodiment, data management unit 242 may generate the set of error record data based on operational data collected by the rail cars and stored in local storage (e.g., an SD card) for analysis after operation is completed. The details of the setting of the error recording data will be explained with reference to FIG. 4, and therefore will not be explained here.

[0048] In an embodiment, the data management unit 242 may generate a set of error record data by detecting a transmission error between a railcar and a wayside device when a particular railcar (e.g., a second railcar) of the set of railcars fails to receive a set of wayside data from a particular wayside device (e.g., a second wayside device) at a particular location where the second wayside device is located, and recording the transmission error, along with an associated time of error detection, as a set of error record data for that railcar and wayside vehicle. In a particular embodiment, the data management unit 242 may use a set of railcar path management data (stored in the railcar path management database 254) indicating the location of each wayside device of the set of wayside devices 215 relative to various possible paths to determine when the wayside devices passed. In a particular embodiment, the railcar path management data may be included in the wayside data for each wayside device and used to determine when a subsequent wayside device passed. In this manner, a transmission error that occurs when expected wayside data is not received may be detected and recorded in a set of error record data. The details of the railcar route management data will be explained with reference to FIG. 6, and therefore will not be explained here.

[0049] In an embodiment, when a particular railcar (e.g., a second railcar) of the set of railcars receives a set of wayside data from a particular wayside device (e.g., a second wayside device) that fails to achieve the completeness threshold, the data management unit 242 may detect a transmission error between the railcar and the wayside device and record the transmission error, along with an associated error detection time, as an error record data set for the railcar and the wayside vehicle, thereby generating an error record data set. Here, the completeness threshold may be a criterion for evaluating the comprehensiveness of the set of wayside data. As an example, the data management unit 242 may compare the received set of wayside data with a wayside data template indicating an expected size of the set of wayside data, expected content (e.g., data header) of the set of wayside data, and / or expected transmission time of the set of wayside data, and identify a set of wayside data that does not achieve a predetermined level of similarity to the wayside data template as failing to achieve the completeness threshold. In this way, transmission errors that occur when line-side data is received but not comprehensively can be detected and recorded in the set of error recording data.

[0050] Next, in step S310, the data management unit 242 generates a set of error count data for each lineside device of the subset of the set of lineside devices in which a transmission error was detected. This set of error count data is data indicating the number of transmission errors detected between a particular lineside device and one or more railcars, along with the error detection time of each transmission error. The data management unit 242 may generate the set of error count data by aggregating, for each railcar, the transmission errors detected for each lineside device listed in the set of error recording data. In an embodiment, the set of error count data may be sorted in descending order of error detection time, with more recent errors listed toward the beginning of the set of error count data. Note that, as described above, this set of error count data is generated for each lineside device in which a transmission error was detected. In this manner, the number of transmission errors for each lineside device can be efficiently tracked and managed. The details of the set of error count data will be described with reference to FIG. 5, and therefore will not be described here.

[0051] Next, in step S315, the anomaly detection unit 244 detects an anomaly related to a first line-side device of the subset of the set of line-side devices based on the set of error count data. In an embodiment, the anomaly detection unit can detect an anomaly related to a first line-side device if the number of transmission errors detected for the first line-side device exceeds an error threshold within a time threshold. The error threshold may be a criterion specifying the boundary between the number of transmission errors considered acceptable and the number of transmission errors considered unacceptable. The time threshold may be a criterion specifying a specific time frame for applying the error threshold. Both the error threshold and the time threshold can be freely set based on user expertise or past anomaly detection data. By using the error threshold and the time threshold together, it is possible to identify a line-side device in which the number of transmission errors detected within a predetermined period is sufficient to determine that the line-side device is faulty. As an example, if the error threshold is "3" and the time threshold is "24 hours," an anomaly can be detected in a line-side device in which three transmission errors are detected within a 24-hour period.

[0052] Next, in step S325, the priority determination unit 246 determines a priority level for a first set of trackside data configured to be transmitted to the set of rail vehicles 210 by a first trackside device (e.g., the trackside device for which the anomaly was detected in step S320). As described herein, a priority level may be information indicating the importance of a particular set of trackside data relative to other sets of trackside data. In embodiments, the priority level may be represented using categories of "high," "medium," or "low." In certain embodiments, the priority level may be represented as a numeric value (e.g., between 1 and 10 or 100), with a higher value indicating a higher priority and a lower value indicating a lower priority. In an embodiment, the priority determination unit 246 may use the set of lineside data management data indicating various characteristics of the lineside data for each lineside device (stored in the lineside data management database 256) to assign a priority level to the first set of lineside data management data based on an urgency factor for the first set of lineside data, an impact factor for the first set of lineside data, a redundancy factor for the first set of lineside data, and / or a location factor for the first lineside device. As described below, this priority level may be used to determine an appropriate response action for the first lineside device. The details of the set of trackside data management data will be explained with reference to FIG. 7, and therefore will not be explained here.

[0053] Next, in step S330, the response action determination unit 248 determines a response action for the first lineside device based on the priority level of the first set of lineside data determined in step S325. Generally, a response action refers to a process, activity, or operation to mitigate the effect of the detected anomaly for the lineside device.

[0054] In an embodiment, the response action determination unit 248 may determine to perform a response action with respect to the first lineside device based on a relationship between the priority level of the first set of lineside data and one or more priority thresholds. In an embodiment, at least a first priority threshold and a second priority threshold may be specified for use in determining the response action for the first lineside device. Here, the first and second priority thresholds may include criteria for specifying boundaries between the priority levels of the sets of lineside data. The second priority threshold may specify higher or stricter criteria than the first priority threshold. As an example, if the priority levels of the first lineside device are expressed as categories of “low,” “medium,” and “high,” the first priority threshold may be set to “medium priority” and the second priority threshold may be set to “high priority.” These priority thresholds may be utilized to identify appropriate actions to mitigate the effects of the lineside device anomaly according to the relative priorities of the lineside data transmitted by the lineside device.

[0055] In an embodiment, the response action determination unit 248 may determine to perform a first response action with respect to a first track-side device when the priority level (e.g., medium) of the first set of track-side data achieves a first priority threshold (medium priority level) but fails to achieve a second priority threshold (high priority level). The first response action may include generating a maintenance request requesting maintenance on the first track-side device and sending the maintenance request to a designated maintenance operator. The maintenance request may indicate the location of the first track-side device, the number of transmission errors detected with respect to the first track-side device, the detection time of the transmission errors, etc. In this way, the track-side device in which an abnormality is detected can be designated for maintenance or replacement to promote operational efficiency and safety of the rail vehicle. Furthermore, in certain embodiments, the response action determination unit 248 may be configured to not perform a response action with respect to the first lineside device if the priority level of the first set of lineside data does not reach a first priority threshold. In this manner, financial, computational, and manpower resources used to implement response actions for lineside devices associated with low priorities (e.g., lineside devices with redundant lineside data with other lineside devices, lineside devices for which a response action is already scheduled) can be saved.

[0056] In an embodiment, the response action determination unit 248 may determine to perform a second response action with respect to the first wayside device if the priority level (e.g., “high”) of the first set of wayside data achieves a first priority threshold (priority level “medium”) and a second priority threshold (priority level “high”). The second response action may include identifying a subset of the set of railcars scheduled to operate on a travel route that includes the first wayside device based on a set of railcar route management data for the set of railcars 210 (e.g., stored in railcar route management database 254), identifying content of the first set of wayside data based on a set of wayside data management data (e.g., stored in trackside data management database 256), and transmitting the identified content of the first set of wayside data to the identified subset of the set of railcars. In this manner, the trackside data related to the failed wayside device can be transmitted to other railcars scheduled to travel on the route.

[0057] In an embodiment, the first set of trackside data can be transmitted to a subset of the set of rail vehicles using a wireless communication system. In a particular embodiment, if the rail vehicles are connected to the lineside device anomaly detection device 240 via a communication network 230, the first set of trackside data can be transmitted to the subset of the set of rail vehicles using the communication network 230. In a particular embodiment, the first set of trackside data can be transmitted to the subset of the set of rail vehicles using a text message or an automated telephone call.

[0058] In an embodiment, to transmit the first set of trackside data to the subset of the set of railcars, the response action determination unit 248 may identify another trackside device (e.g., a third trackside device) located on the travel route along which the subset of the set of railcars is scheduled to operate and in which no transmission error has been detected, based on the set of railcar route management data stored in the railcar route management database 254 and the set of error recording data generated in step S305, and transmit the first set of trackside data to the identified trackside device for subsequent transmission to the subset of the set of railcars. In other words, the response action determination unit 248 dynamically updates the operating trackside devices along the travel route traveled by the subset of the set of railcars to include the first set of trackside data associated with the first trackside device in which the abnormality has been detected. This first set of trackside data can be transmitted to the subset of the set of railcars when the railcars pass this trackside device (i.e., the third trackside device). In this case, the response action determination unit 248 preferably identifies a wayside device that is earlier on the travel path than the first wayside device, thereby allowing the first set of wayside data to be communicated to a subset of the set of rail vehicles earlier than it would have been acquired. It should further be noted that this configuration is suitable for situations where the set of wayside devices is dynamically programmable in real time. In this manner, if a set of trackside data associated with the failed trackside has a high priority, it can be transmitted to a subset of the set of rail vehicles via other trackside devices along the same travel route, thereby communicating high-priority information regarding approaching obstacles, deteriorating track conditions, urgent train control commands, or other emergency situations to the rail vehicles to enhance the operational efficiency and safety of the rail vehicles.

[0059] The track-side device anomaly detection method 300 described above not only detects anomalies related to track-side devices, but also determines a response action to mitigate the effects of communication failures caused by the track-side device anomaly. The response action can be determined based on the priority level of the associated track-side data. In this way, by performing a response action according to the track-side priority level, the operating efficiency and safety of the railway vehicle can be improved.

[0060] Referring now to FIG. 4, an error record table for storing a set of error record data according to an embodiment of the present disclosure will be described.

[0061] 4 is a diagram illustrating an error record table 400 for storing a set of error record data according to an embodiment of the present disclosure. The set of error record data may include a collection of data indicating the presence or absence of a transmission error between a set of railcars and a set of track-side devices. As described herein, the set of error record data may be generated by a data management unit and stored in the error record table 400 in the error record database 250 of the track-side device abnormality detection device 240.

[0062] As shown in FIG. 4, the set of error record data in the error record table 400 may include information regarding the railcar number 402, the record time 404, and the number of lineside devices 406, 408, 410.

[0063] The railcar number 402 is a number that uniquely identifies a particular railcar within a set of railcars. As an example, the railcar number 402 may be represented as "Train 1" or "Train 4," etc.

[0064] The recording time 404 indicates the date and time that a particular recording was recorded. In an embodiment, each time a rail vehicle performs communication with a trackside device, the data management unit 242 may generate a record of a set of error recording data that indicates whether there was a transmission error.

[0065] Each of the trackside devices 406, 408, and 410 indicates whether or not a transmission error occurred between the corresponding trackside device and a particular railcar of the set of railcars. In an embodiment, the presence or absence of a transmission error between a particular trackside device and a particular railcar may be represented in binary format in the error record table 400 (e.g., a "1" or "X" indicating a transmission error, or a "0" or blank field indicating no transmission error). As an example, the error record table 400 indicates that a transmission error occurred between trackside device 1 and train 4 at "7 / 11 / 2022 14:00." Similarly, a transmission error occurred between trackside device 2 and train 1 at "7 / 11 / 2022 17:00." Meanwhile, no transmission error occurred between trackside device 1 and train 7 at "7 / 11 / 2022 12:00."

[0066] The error record table 400 may be used to maintain a record of the presence or absence of transmission errors between a set of railcars and a set of lineside equipment. As described herein, the set of error record data in the error record table 400 may be used to facilitate detection of anomalies related to one or more lineside devices of the set of lineside equipment.

[0067] Referring now to FIG. 5, an error count table for storing a set of error count data according to an embodiment of the present disclosure will be described.

[0068] 5 is a diagram illustrating an error count table 500 for storing a set of error count data according to an embodiment of the present disclosure. The set of error count data indicates the number of transmission errors detected between a particular track-side device and one or more railcars, along with the error detection time of each transmission error. As described herein, the set of error count data can be generated by a data management unit and stored in the error count table 500 in the error count database 252 of the track-side device abnormality detection device 240.

[0069] 5, the set of error count data in the error count table 500 includes a railcar number 502, an error detection time 504, a number of errors 506, and a status 508. Further, although not shown in FIG. 5, it should be noted that the set of error count data shown in FIG. 5 corresponds to a particular lineside device. Thus, a set of error count data such as that stored in the error count table 500 can be generated for each lineside device in the set of lineside devices 215 and stored in the error count database 252.

[0070] The railcar number 502 is a number that uniquely identifies a particular railcar among a set of railcars in which a transmission error associated with a particular trackside device has been detected. By way of example, the railcar number 502 may be represented as "Train 1" or "Train 4," etc.

[0071] The error detection time 504 indicates the date and time when the most recent transmission error between a specific trackside device and a specific railcar was detected. As an example, the error detection time can be expressed as "7 / 11 / 2022 15:00".

[0072] The number of errors 506 indicates the total number of errors detected between a specific trackside device and a specific railcar within a 24-hour period. For example, a transmission error detected between the trackside device and Train 7 at 12:00 on July 11, 2022 is the first transmission error detected within a 24-hour period (e.g., approximately 24 hours from 00:00 on July 11, 2022 to 23:59 on July 11, 2022), and is therefore counted as error number "1." A transmission error detected between the trackside device and Train 4 at 14:00 on July 11, 2022 is the second transmission error detected within a 24-hour period, and is therefore counted as error number "2." A transmission error detected between the trackside device and Train 1 at 15:00 on July 11, 2022 is the third transmission error detected within a 24-hour period, and is therefore counted as error number "3."

[0073] Status 508 indicates the status of the track-side device corresponding to error count table 500. As described herein, the status of the track-side device can be determined based on the relationship between the number of errors 506 and the error threshold and the time threshold. As an example, if the error threshold is "2" and the time threshold is "24 hours," the status of the track-side device can be detected as abnormal when a second transmission error is detected in 24 hours for Train 4 at 14:00 on July 11, 2022. Similarly, the status is also abnormal when a third transmission error is detected in 24 hours for Train 1 at 15:00 on July 11, 2022.

[0074] The error count table 500 may be used to maintain a record of the number of transmission errors detected between a particular trackside device and one or more railcars. As described herein, the set of error count data stored in the error count table 500 may be used to detect anomalies with one or more trackside devices of the set of trackside devices 215.

[0075] Referring now to FIG. 6, a railcar route management table for storing a set of route management data according to an embodiment of the present disclosure will be described.

[0076] 6 is a diagram illustrating a railcar route management table 600 for storing a set of route management data according to an embodiment of the present disclosure. The set of route management data is a collection of data characterizing the travel routes used by a set of railcars and the trackside devices located along each route. As described herein, the set of route management data may be generated in advance and stored in the railcar route management database 254 of the trackside device anomaly detection device 240.

[0077] As shown in FIG. 6 , the rail vehicle route management data in the rail vehicle route management table 600 includes a route number 602, a rail vehicle number 604, a departure station ID 606, an intermediate station ID 608, an arrival station ID 610, a trackside device 612, and a trackside device location 614.

[0078] The route number 602 is a number for uniquely identifying a specific travel route within the rail network.

[0079] Car number 604 is a number that uniquely identifies a particular car among the set of cars that use the route specified by route number 602. For example, train 1 is scheduled to use route number "0," and trains 6, 13, and 19 are scheduled to use route number "5."

[0080] The departure station ID 606 is an identifier that uniquely identifies the train station where a particular route begins. Intermediate Station ID 608 indicates a unique identifier for an intermediate train station located between the departure and arrival stations of a particular route. Arrival Station ID 610 is an identifier that uniquely identifies the train station where a particular route terminates.

[0081] The line-side devices 612 indicate identifiers of line-side devices arranged along a specific route. For example, as shown in Fig. 6, line-side devices "2A, 2B, 2C..." are arranged along route number "0".

[0082] The lineside device location 614 is information indicating the geographical location of each lineside device 612. For example, the lineside device location 614 can be expressed by the latitude and longitude of the lineside device.

[0083] Rail vehicle path management table 600 can be used to identify which wayside devices are located along a particular route. Rail vehicle path management data can be used to verify when a particular wayside device is passed to facilitate transmission error detection, and can also be used to identify alternate wayside devices passed by a particular rail vehicle to facilitate transmission of wayside data in the event of an anomaly.

[0084] Next, with reference to FIG. 7, a trackside data management table for storing a set of trackside data according to an embodiment of the present disclosure will be described.

[0085] 7 is a diagram illustrating a lineside data management table 700 for storing a set of lineside data management data according to an embodiment of the present disclosure. The set of lineside data management data is a collection of data indicating various attributes of the lineside data of each lineside device. As described herein, the lineside data management data may be generated in advance and stored in the lineside data management database 256 of the lineside device anomaly detection device 240.

[0086] As shown in FIG. 7 , a set of trackside data management data in the trackside data management table 700 includes a trackside device ID 702, a trackside device location 704, a trackside data ID 706, a content 708, an urgency factor 710, an impact factor 712, and a redundancy factor 714.

[0087] The lineside device ID 702 indicates a unique identifier for identifying a particular lineside device among the set of lineside devices 215 . The lineside device location 704 is information indicating the geographical location of each lineside device. For example, the lineside device location 704 can be expressed by the latitude and longitude of the lineside device.

[0088] The trackside data ID 706 indicates a unique identifier for identifying a particular set of trackside data transmitted from a corresponding trackside device to a passing railcar.

[0089] Content 708 indicates the nature of the data contained in a particular set of trackside data. As shown in Figure 7, content 708 may include information regarding the track status of the next track section, railcar location information, or railcar speed control commands, etc. In an embodiment, one set of trackside data may include one or more of these contents for transmission to a passing railcar.

[0090] The urgency factor 710 is information that indicates the urgency (time-criticality) of a particular set of trackside data. As shown in Figure 7, the urgency factor 710 can be expressed categorically using the categories "low," "medium," and "high." The impact factor 712 is information indicating the degree (scale, influence) of impact that may be exerted on the operation or safety of the rail network if the corresponding trackside data cannot be transmitted to the rail vehicle. As shown in Figure 7, the impact factor 712 can be expressed categorically using the categories of "low", "medium", and "high". Redundancy factor 714 is information that indicates whether a particular set of trackside data is redundant. In an embodiment, redundancy factor 714 may indicate with which trackside devices a particular trackside device has redundancy. As an example, according to FIG. 7, the trackside data associated with trackside data ID "DATA2C" is redundant with a trackside device having trackside device ID "5C."

[0091] In an embodiment, the priority determination unit 246 may be configured to assign different configurations to different lineside devices based on the priorities of the lineside devices. More specifically, the priority determination unit 246 may assign a first configuration to a lineside device having lineside data that achieves a first priority threshold but not a second priority threshold, and assign a second configuration to a lineside device having lineside data that achieves a second priority threshold. Here, the first and second configurations may refer to data specifying the specifications, parameters, and behaviors of a set of lineside devices. For example, the first and second configurations may define error thresholds and time thresholds for the corresponding lineside devices. In this manner, configurations having different error thresholds and time thresholds may be assigned to different lineside devices based on the priority levels of the lineside devices. For example, the second configuration may specify error thresholds and time thresholds that are lower than those specified by the first configuration. In this manner, anomaly detection for high-priority lineside devices may be facilitated.

[0092] Furthermore, the second configuration may specify a condition indicating that past anomaly records for the line-side device should be taken into consideration, and if an anomaly has been detected for the line-side device in the past, the time threshold is removed, and if the number of errors detected for the line-side device exceeds the error threshold, an anomaly is immediately detected without applying the time threshold. In this way, it is possible to easily determine a response action for a line-side device that has a history of anomalous behavior.

[0093] As described herein, the line-side equipment location 704, the urgency factor 710, the impact factor 712, and the redundancy factor 714 can be used to facilitate determining a priority level for a particular line-side equipment. In a particular embodiment, the priority determination unit 246 can determine that a set of line-side data has a priority level of “high” if either the urgency factor 710 or the impact factor 712 is “high” and the redundancy factor 714 indicates no redundancy, can determine that a set of line-side data has a priority level of “medium” if both the urgency factor 710 and the impact factor 712 are “medium” or “low,” and can determine that a set of line-side data has a priority level of “low” if both the urgency factor 710 and the impact factor 712 are “low” or if the set of line-side data has redundancy with another operational line-side equipment. In one particular embodiment, the priority determination unit 246 may calculate the current distance from the rail vehicle to a particular wayside device and assign a higher priority level to a wayside device that is within a threshold distance from the rail vehicle.

[0094] The trackside data management table 700 can be used to determine a priority level for a set of trackside data associated with a trackside device in which an anomaly has been detected, which priority level can be used to determine an appropriate response action for the trackside device, as described herein.

[0095] As described herein, aspects of the present disclosure relate to line-side device anomaly detection techniques for detecting anomalies related to line-side devices and determining appropriate response actions to mitigate the effects of communication failures caused by the line-side device anomalies. However, while conventional techniques for detecting errors in track-side equipment have been proposed, as described herein, challenges remain regarding maintaining the operational efficiency and safety of rail vehicles in the event of a track-side equipment failure.

[0096] In view of the above, therefore, aspects of the present disclosure relate to determining a response action to mitigate the impact of a detected anomaly with respect to a track-side device based on a priority level of a set of track-side data associated with the track-side device in which the anomaly was detected. By determining an appropriate response action according to the relative priority levels of the sets of track-side data, it is possible to increase the operational efficiency and safety of a railway.

[0097] Additionally, aspects of the present disclosure relate to determining a maintenance request requesting maintenance on a first line-side device and transmitting the maintenance request to a designated maintenance operator, so that the failed line-side device can be efficiently addressed and replaced. Aspects of the present disclosure further relate to identifying additional wayside devices located along a travel path along which a subset of the set of rail cars are scheduled to operate and for which no transmission errors have been detected, and transmitting the set of trackside data associated with the failed trackside device to the additional wayside device for subsequent transmission to the subset of the set of rail cars. In this manner, if the set of trackside data associated with the failed trackside device has a high priority level, it may be transmitted to the subset of the set of rail cars via other wayside devices along the same travel path. As a result, high-priority information regarding approaching obstacles, deteriorating track conditions, urgent train control commands, or other emergency situations may be communicated to the rail cars, thereby enhancing the efficiency and safety of rail car operation.

[0098] Additionally, aspects of the present disclosure relate to assigning different configurations to different lineside devices based on their relative priority levels. These configurations can be used to set customized error thresholds, time thresholds, and special conditions for specific lineside devices, providing more granular control over anomaly detection. For example, by assigning lower error and time thresholds to lineside devices with high-priority lineside data, anomalies in these lineside devices can be more easily detected. Response actions can then be taken for these lineside devices to ensure high reliability, operational safety, and efficiency for the lineside devices with high-priority lineside data.

[0099] Thus, according to an embodiment of the present disclosure, it is possible to provide a line-side device anomaly detection technology for detecting an anomaly related to a line-side device and determining an appropriate response action for mitigating the impact of a communication failure resulting from the anomaly in the line-side device.

[0100] As described herein, the present disclosure relates to the following embodiments:

[0101] (Aspect 1) A method for detecting abnormality in track-side devices for a railway network, the railway network comprising: a set of rail vehicles configured to operate on a set of routes of a rail network; a set of wayside devices disposed at predetermined locations along a set of routes in the rail network and configured to transmit wayside data to a set of rail vehicles; The line side device abnormality detection method includes: generating a set of error record data indicating the presence or absence of a transmission error between the set of railcars and the set of trackside equipment; generating, for each lineside device of the subset of the set of lineside devices in which a transmission error was detected, a set of error count data indicating a number of detected transmission errors and an error detection time for each transmission error; detecting an anomaly related to a first line-side device when a number of transmission errors detected for a first line-side device of the subset of the set of line-side devices exceeds an error threshold within a time threshold based on the set of error count data; determining a priority level of a first set of trackside data configured to be transmitted by a first trackside device to a set of rail vehicles; determining a response action for the first lineside device based on a priority level of the first set of lineside data; A line side device abnormality detection method comprising:

[0102] (Aspect 2) Generating a set of error recording data includes: detecting a second transmission error between the second railcar and the second track-side device when a second railcar of the set of railcars fails to receive a set of track-side data from the second track-side device at a particular location where the second track-side device is located; recording a second transmission error with an associated error detection time as a set of error record data for a second rail vehicle and a second line side device; 2. The line-side device abnormality detection method according to claim 1,

[0103] (Aspect 3) Generating a set of error recording data includes: detecting a second transmission error between the second railcar and the second track-side device when a second railcar of the set of railcars receives a set of track-side data from the second track-side device that fails to achieve the integrity threshold; recording a second transmission error with an associated error detection time as a set of error record data for a second rail vehicle and a second line side device; 3. The line-side device abnormality detection method according to claim 1, further comprising:

[0104] (Aspect 4) Determining a priority level of the first set of line-side data includes: assigning a priority level to the first set of lineside data based on one or more factors selected from the group consisting of an urgency factor of the first set of lineside data, an impact factor of the first set of lineside data, and a location factor of the first lineside device; 4. The line-side device abnormality detection method according to any one of aspects 1 to 3, comprising:

[0105] (Aspect 5) defining an error threshold and a time threshold for detecting an anomaly related to the first lineside device based on a priority level of the first set of lineside data; The line-side device abnormality detection method according to any one of aspects 1 to 4, further comprising:

[0106] (Aspect 6) Determining a response action for the first line side device includes: determining to perform a first response action when a priority level of a first set of lineside data achieves a first priority threshold but fails to achieve a second priority threshold; It contains The first response action is generating a maintenance request to request maintenance on the first line side device; Sending a maintenance request to a designated maintenance operator; Including, The line-side device abnormality detection method according to any one of the first to fifth aspects.

[0107] (Aspect 7) Determining a response action for the first line side device includes: determining to perform a first response action and a second response action when a priority level of the first set of lineside data achieves a first priority threshold and a second priority threshold; It contains The second response action is Identifying a subset of the set of rail vehicles that are scheduled to operate on a travel route that includes the first trackside device based on the set of rail vehicle route management data for the set of rail vehicles; transmitting a first set of trackside data to a subset of the set of rail vehicles; Including, A line-side device abnormality detection method according to aspect 6.

[0108] (Aspect 8) A track-side device anomaly detection method as described in aspect 7, wherein transmitting the first set of track-side data to the subset of the set of rail vehicles includes transmitting the first set of track-side data to the subset of the set of rail vehicles using a wireless communication system.

[0109] (Aspect 9) Transmitting the first set of trackside data to a subset of the set of rail vehicles includes: Identifying a third track-side device that is located on a travel route along which the subset of the set of rail vehicles is scheduled to operate, and in which no transmission error has been detected, based on the set of rail vehicle route management data and the set of error recording data; transmitting the first set of line-side data to a third line-side device for subsequent transmission to a subset of the set of rail vehicles; 8. The line-side device abnormality detection method according to claim 7, further comprising:

[0110] (Aspect 10) A track-side device anomaly detection method as described in aspect 9, wherein the third track-side device is dynamically programmable to include additional track-side data and is located at a distance from the subset of the set of rail vehicles that is shorter than a distance from the subset of the set of rail vehicles to the first track-side device.

[0111] The present invention may be a system, a method, and / or a computer program product, which may include a computer-readable storage medium having computer-readable program instructions for causing a processor to implement aspects of the present invention.

[0112] A computer-readable storage medium may be a tangible device capable of holding and storing instructions for use by an instruction execution device. The computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the above. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, mechanical encryption devices such as punch cards or groove ridge structures having instructions recorded thereon, and any suitable combination of the above. As used herein, a computer-readable storage medium should not be construed as being, itself, a primary signal such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., an optical pulse passing through a fiber optic cable), or an electrical signal transmitted by an electrical wire.

[0113] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0114] The computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to manufacture a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for performing the functions / acts specified in the flowchart and / or block diagram blocks. These computer-readable program instructions may also be stored on a computer-readable storage medium that can cause the computer, programmable data processing apparatus, and / or other apparatus to function in a particular way, such that the computer-readable storage medium having the instructions stored thereon comprises an article of manufacture containing instructions that implement aspects of the functions / acts specified in the flowchart and / or block diagram blocks.

[0115] The computer-readable program instructions may further be loaded into a computer, other programmable data processing device, or other device to cause a series of operational steps to be executed on the computer, other programmable device, or other device to create a computer-implemented process, such that the instructions executing on the computer, other programmable device, or other device perform the functions / acts specified in the flowchart and / or block diagram blocks.

[0116] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specialized logical function. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending on the functionality involved. It will also be appreciated that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can be implemented by special-purpose hardware-based systems that perform specialized functions or operations or execute a combination of special-purpose hardware and computer instructions.

[0117] While the foregoing relates to exemplary embodiments of the present invention, other and further embodiments of the present invention may be devised without departing from the basic scope of the invention, which scope is determined by the following claims. The description of various embodiments of the present disclosure has been provided for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein has been chosen to explain the principles of the embodiments, practical applications or technical improvements of existing technology in the market, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

[0118] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of various embodiments. As used herein, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. "Set," "group," "bundle," and the like are intended to include one or more. Furthermore, it will be understood that the terms "comprise" and / or "comprising," as used herein, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. In the foregoing detailed description of exemplary embodiments of various embodiments, reference has been made to the accompanying drawings, which form a part hereof, in which like numerals indicate like elements, and in which certain exemplary embodiments may be practiced. Although the above embodiments have been described in sufficient detail to enable those skilled in the art to practice the embodiments, other embodiments may be used, and logical, mechanical, electrical, and other changes may be made without departing from the scope of the various embodiments. Numerous specific details have been set forth in the above description to provide a thorough understanding of the various embodiments. However, the various embodiments may be practiced without these specific details. In other instances, well-known circuits, structures, and techniques have not been shown in detail so as not to obscure the embodiments. [Explanation of symbols]

[0119] 200 Trackside Equipment Abnormality Detection System 210 Railroad Car Set 215 Trackside equipment set 220 User Terminal 230 Communication Network 240 Lineside equipment abnormality detection device 242 Data Management Unit 244 Anomaly Detection Unit 246 Priority Judgment Unit 248 Response Action Decision Unit 250 Error Record Database 252 Error Count Database 254 Railway Vehicle Route Management Database 256 Trackside Data Management Database

Claims

1. A method for detecting an abnormality in a track-side device for a railway network, the railway network comprising: a set of rail vehicles configured to operate on a set of routes of the rail network; a set of wayside devices located at predetermined locations along the set of routes of the rail network and configured to transmit wayside data to the set of rail vehicles; The line-side device abnormality detection method includes: generating a set of error record data indicating the presence or absence of a transmission error between the set of railcars and the set of trackside devices; generating, for each lineside device of the subset of lineside devices in which a transmission error has been detected, a set of error count data indicating the number of transmission errors detected and the error detection time for each transmission error; detecting an anomaly related to a first line-side device of the subset of the set of line-side devices when a number of transmission errors detected for the first line-side device of the subset of the set of line-side devices exceeds an error threshold within a time threshold based on the set of error count data; determining a first set priority level of line-side data configured to be transmitted by the first line-side device to the set of rail vehicles; determining a response action for the first line-side device based on the priority level of the first set of line-side data; A line side device abnormality detection method comprising:

2. generating the set of error recording data includes: detecting a second transmission error between the second railcar and the second track-side device when a second railcar of the set of railcars fails to receive a set of track-side data from the second track-side device at a particular location where the second track-side device is located; recording the second transmission error with an associated error detection time as the error record data set for the second railcar and the second lineside device; The line-side device abnormality detection method according to claim 1 , further comprising:

3. generating the set of error recording data includes: detecting a second transmission error between the second railcar and the second track-side device when a second railcar of the set of railcars receives a set of track-side data from a second track-side device that fails to achieve an integrity threshold; recording the second transmission error with an associated error detection time as the error recording data set for the second railcar and the second lineside device; The line-side device abnormality detection method according to claim 1 , further comprising:

4. Determining the priority level of the first set of line-side data includes: assigning a priority level to the first set of lineside data based on one or more factors selected from the group consisting of an urgency factor of the first set of lineside data, an impact factor of the first set of lineside data, a redundancy factor of the first set of lineside data, and a location factor of the first lineside device. The line-side device abnormality detection method according to claim 1 , further comprising:

5. defining the error threshold and the time threshold for detecting the anomaly for the first line-side device based on the priority level of the first set of line-side data; The line-side device abnormality detection method according to claim 1 , further comprising:

6. Determining a response action for the first line side device includes: determining to perform a first response action when the priority level of the first set of lineside data achieves a first priority threshold but fails to achieve a second priority threshold; It contains The first response action includes: generating a maintenance request to request maintenance on the first line side device; sending the maintenance request to a designated maintenance operator; Including, The line-side device abnormality detection method according to claim 1 .

7. Determining a response action for the first line side device includes: determining to perform the first and second response actions when the priority level of the first set of lineside data achieves a first and second priority threshold; It contains The second response action is: Identifying a subset of the set of rail vehicles that are scheduled to operate on a travel route that includes the first trackside device based on a set of rail vehicle route management data for the set of rail vehicles; transmitting the first set of trackside data to the subset of the set of rail vehicles; Including, The line-side device abnormality detection method according to claim 6.

8. 8. The track-side device anomaly detection method of claim 7, wherein transmitting the first set of track-side data to the subset of the set of rail cars includes transmitting the first set of track-side data to the subset of the set of rail cars using a wireless communication system.

9. transmitting the first set of trackside data to the subset of the set of rail vehicles; Identifying a third track-side device that is located on a travel route along which the subset of the set of rail vehicles is scheduled to operate, and in which no transmission error has been detected, based on the set of rail vehicle route management data and the set of error recording data; transmitting the first set of line-side data to the third line-side device for subsequent transmission to the subset of the set of rail vehicles; The line-side device abnormality detection method according to claim 7, further comprising:

10. 10. The trackside device anomaly detection method of claim 9, wherein the third trackside device is dynamically programmable to include additional trackside data and is located at a distance from the subset of the set of rail cars that is less than a distance from the subset of the set of rail cars to the first trackside device.

11. A track-side device anomaly detection system for a railway network, the track-side device anomaly detection system comprising: a set of rail vehicles configured to operate on a set of routes of the rail network; a set of wayside devices located at predetermined locations along the set of routes of the rail network and configured to transmit wayside data to the set of rail vehicles; a line-side device abnormality detection device for detecting an abnormality in the set of line-side devices; The line side device abnormality detection device comprises: a data management unit, generating a set of error record data indicating the presence or absence of a transmission error between the set of railcars and the set of trackside devices; generating, for each lineside device of the subset of lineside devices in which a transmission error has been detected, a set of error count data indicating the number of transmission errors detected and the error detection time of each transmission error; a data management unit configured as follows: an anomaly detection unit, Detecting an anomaly related to a first line-side device of the subset of the set of line-side devices when the number of transmission errors detected for the first line-side device of the subset of the set of line-side devices exceeds an error threshold within a time threshold based on the set of error count data. an anomaly detection unit configured as follows: A priority determination unit, determining a priority level of a first set of trackside data configured to be transmitted by the first trackside device to the set of railcars; a priority determination unit configured as follows: a response action decision unit, determining a response action for the first line-side device based on the priority level of the first set of line-side data; and performing the response action for the first line-side device. a response action decision unit configured to A line side device abnormality detection system comprising:

12. A trackside equipment anomaly detection computer program for a railway network, comprising: a set of rail vehicles configured to operate on a set of routes of the rail network; a set of wayside devices located at predetermined locations along the set of routes of the rail network and configured to transmit wayside data to the set of rail vehicles; It is equipped with The line-side device anomaly detection computer program includes a computer-readable storage medium having program instructions embodied therein, the computer-readable storage medium being not itself a primary signal, the program instructions being executable by a processor, and causing the processor to: generating a set of error record data indicating the presence or absence of a transmission error between the set of railcars and the set of trackside devices; generating, for each lineside device of the subset of lineside devices in which a transmission error has been detected, a set of error count data indicating the number of transmission errors detected and the error detection time for each transmission error; detecting an anomaly related to a first line-side device of the subset of the set of line-side devices when a number of transmission errors detected for the first line-side device of the subset of the set of line-side devices exceeds an error threshold within a time threshold based on the set of error count data; determining a priority level for the first set of track-side data configured to be transmitted by the first track-side device to the set of rail vehicles by assigning a priority level to the first set of track-side data based on one or more factors selected from the group consisting of an urgency factor for the first set of track-side data, an impact factor for the first set of track-side data, a redundancy factor for the first set of track-side data, and a location factor of the first track-side device; determining to perform a first response action when the priority level of the first set of lineside data achieves a first priority threshold but fails to achieve a second priority threshold; The first response action is: generating a maintenance request to request maintenance on the first line side device; sending the maintenance request to a designated maintenance operator; Including, determining to perform a first response action; determining to perform the first response action and the second response action when the priority level of the first set of lineside data achieves a first priority threshold and a second priority threshold; The second response action is: Identifying a subset of the set of rail vehicles that are scheduled to operate on a travel route that includes the first trackside device based on a set of rail vehicle route management data for the set of rail vehicles; transmitting the first set of trackside data to the subset of the set of rail vehicles; Including, determining to perform the first response action and the second response action; Including, A computer program for detecting abnormalities in trackside equipment.

Images