US20210009175A1

US20210009175A1 - System and method for extracting and processing railway-related data

Info

Publication number: US20210009175A1
Application number: US17/042,416
Authority: US
Inventors: Vlad Lata; Christian BRANDLHUBER; Thomas Böhm
Original assignee: Konux GmbH
Current assignee: Konux GmbH
Priority date: 2018-03-29
Filing date: 2019-03-29
Publication date: 2021-01-14
Also published as: WO2019185872A1; JP2021516641A; EP3774488A1

Abstract

The invention discloses a system and method for extracting and processing rail data. Disclosed are a first sensor measuring first sensor data, a local processing component preprocessing the first sensor data, a central server analyzing preprocessed data, a memory component storing preprocessed and/or analyzed data, and an interface communicating with the central server.

Description

FIELD

The invention relates to extracting and processing data related to trains and railroad operations. The invention also relates to systems and methods for railway monitoring. The invention further relates to communication in a distributed system comprising railway-related sensors, processing components and servers.

INTRODUCTION

Railroad, railway or rail transport has been developed for transferring goods and passengers on wheeled vehicles on rails, also known as tracks. In contrast to road transport, where vehicles run on a prepared flat surface, rail vehicles (rolling stock) are directionally guided by the tracks on which they run. Tracks commonly consist of steel rails, installed on ties or sleepers and ballast, on which the rolling stock, usually provided with metal wheels, moves.
Other variations are also possible, such as slab track, where the rails are fastened to a concrete foundation resting on a subsurface.
Rolling stock in a rail transport system generally encounters lower frictional resistance than road vehicles, so passenger and freight cars (carriages and wagons) can be coupled into longer trains. Power is provided by locomotives, which either draw electric power from a railway electrification system or produce their own power, usually by diesel engines. Most tracks are accompanied by a signaling system. Railways are a safe land transport system when compared to other forms of transport, and are capable of high levels of passenger and cargo utilization and energy efficiency, but are often less flexible and more capital-intensive than road transport, when lower traffic levels are considered.
The inspection of railway equipment is essential for the safe movement of trains. Many types of defect detectors are in use today. These devices utilize technologies that vary from a simplistic paddle and switch to infrared and laser scanning, and even ultrasonic audio analysis. Their use has avoided many rail accidents over the past decades.
Railways must keep up with periodic inspection and maintenance in order to minimize effect of infrastructure failures that can disrupt freight revenue operations and passenger services.
Because passengers are considered the most crucial cargo and usually operate at higher speeds, steeper grades, and higher capacity/frequency, their lines are especially important. Inspection practices embrace car inspection or walking inspection. Curve maintenance especially for transit services includes gauging, fastener tightening, and rail replacement.
Rail corrugation is a common issue with transit systems due to the high number of light-axle, wheel passages that result in grinding of the wheel/rail interface. Since maintenance may overlap with operations, maintenance windows (nighttime hours, off-peak hours, altering train schedules or routes) must be closely followed. In addition, passenger safety during maintenance work (inter-track fencing, proper storage of materials, track work notices, hazards of equipment near states) must be regarded at all times. Moreover, maintenance access problems can emerge due to tunnels, elevated structures, and congested cityscapes. Here, specialized equipment or smaller versions of conventional maintenance gear are used.
Unlike highways or road networks where capacity is disaggregated into unlinked trips over individual route segments, railway capacity is fundamentally considered a network system. As a result, many components can cause system disruptions. Maintenance must acknowledge the vast array of a route's performance (type of train service, origination/destination, seasonal impacts), line's capacity (length, terrain, number of tracks, types of train control), trains throughput (max speeds, acceleration/deceleration rates), and service features with shared passenger-freight tracks (sidings, terminal capacities, switching routes, and design type).
Railway inspection is used for examining rail tracks for flaws that could lead to catastrophic failures. According to the United States Federal Railroad Administration Office of safety analysis track defects are the second leading cause of accidents on railways in the United States. The leading cause of railway accidents is attributed to human error. Every year, North American railroads spend millions of dollars to inspect the rails for internal and external flaws. Non-destructive testing (NDT) methods are used as a preventative measures against track failures and possible derailment.
With increased rail traffic at higher speeds and with heavier axle loads today, critical crack sizes are shrinking and rail inspection is becoming more important. In 1927, magnetic inductions had been introduced for the first rail inspection cars. This was done by passing large amounts of magnetic field through the rail and detecting flux leakage with search coils. Since then, many other inspection cars have traversed the rails in search of flaws.
There are many effects that influence rail defects and rail failure. These effects include bending and shear stresses, wheel/rail contact stresses, thermal stresses, residual stresses and dynamic effects. Defects due to contact stresses or rolling contact fatigue (RCF) can be tongue-lipping, head-checking (gauge corner cracking) as well as squats (which start as small surface breaking cracks).
Other forms of surface and internal defects can be corrosion, inclusions, seams, shelling, transverse fissures and/or wheel burn.
One effect that can cause crack propagation is the presence of water and other liquids. When a fluid fills a small crack and a train passes over, the water becomes trapped in the void and can expand the crack tip. Also, the trapped fluid can freeze and expand or initiate the corrosion process.
Parts of a rail where defects can be found is the head, the web foot, switchblades, welds, bolt holes etc. A majority of the flaws found in rails are located in the head, however, flaws are also found in the web and foot. This means that the entire rail needs to be inspected.
Methods that are presently used to detect flaws in rails are ultrasound, eddy current inspection, magnetic particle inspection, radiography, magnetic induction, magnetic flux leakage and electric acoustic transducers.
The techniques mentioned above are utilized in a handful of different ways. The probes and transducers can be utilized on a “walking stick”, on a hand pushed trolley, or in a hand held setup. These devices are used when small sections of track are to be inspected or when a precise location is desired. Many times these detail oriented inspection devices follow up on indications made by rail inspection cars or rail trucks. Handheld inspection devices are very useful for this when the track is used heavily, because they can be removed relatively easy. However, they are considered very slow and tedious, when there are thousands of miles of track that need inspection. Moreover, first indications of the defects can be only detected rather late.
There are many approaches of road/rail inspection trucks. Those are almost all-ultrasonic testing exclusively, but there are some with the capability to perform multiple tests. These trucks are loaded with high-speed computers using advanced programs that recognize patterns and contain classification information. The trucks are also equipped with storage space, tool cabinets, and workbenches. A GPS unit is often used with the computer to mark new defects and locate previously marked defects. The GPS system allows a follow up car to find precisely where the lead vehicle detected the flaw. One advantage to such trucks is that they can work around regular rail traffic without shutting down or slowing down entire stretches of track. However, because railroad management frequently orders those trucks to be used to inspect tracks at speeds over 50 mph (80 km/h), tracks reported as having been inspected are, in fact, not inspected. Reference is made to Wikipedia in March 2018 under the keywords “Rail transport” and “Rail inspection”.
With increased rail traffic carrying heavier loads at higher speeds, a quicker more efficient way of inspecting railways is needed. Besides that, also the control of the train-rail interaction would be advantageous; i.e., checking the load, improper loads, load-dependent fees for trains on railroads as high loads increase wear of the railroads, surveillance of the maintenance of trains or future failure thereof etc.
Railway operations require careful monitoring and maintenance to ensure passenger safety and reliable service. Many sensors are used to monitor track structural integrity, train wheels, train or train carriage fissures and other possible sources of malfunction. Such sensors allow for data collection and analysis and ensure safer operation of railways. Various sensors can be placed directly on trains, on tracks or nearby, at train stations and/or on platforms, and generally in the overall vicinity of the railway.
For example, U.S. Pat. No. 8,560,151 B2 discloses a mobile railway car monitoring system. The mobile railway car monitoring system includes a plurality of sensor nodes coupled to an undercarriage portion of a railway car, and a control node coupled to the railway car. Each of the plurality of sensor nodes is configured to monitor the undercarriage portion of the railway car when in motion and transmit information about the undercarriage portion to the control node. The control node is configured to receive the information about the undercarriage portion, process the information to determine a fault condition for the undercarriage portion, and wirelessly report the fault condition to a collection system.
Railroad sensors are generally distributed over a wide area. Such sensors preferably have a means of communication with a remote server, which can store and/or process the data collected by the sensors. For instance, US patent application 2014/0142868 A1 discloses a track inspection platform with a communication interface disposed on it.

SUMMARY

In light of the above, it is the object of the present invention to disclose improved railway analysing and/or monitoring systems and methods. It is also a preferred object of the present invention to disclose a communication and processing architecture for obtaining and processing data related to rail operations.
In a first embodiment, a system for extracting and processing rail data is disclosed. The system comprises at least one first sensor configured to measure first sensor data. The system further comprises at least one local processing component configured to receive first sensor data and preprocess it to obtain preprocessed sensor data. The system also comprises a central server configured to receive preprocessed sensor data and analyze it to produce analyzed sensor data. The system also comprises a memory component configured to store at least one of the preprocessed sensor data and the analyzed sensor data. The system further comprises an interface configured to communicate with the central server.
The first sensor can comprise one or a plurality of sensors forming a sensor device. The sensors can be measuring the same type of data or different. For example, the first sensor can measure vibrations of railways due to trains passing on them.
The local processing component can be integrated with the first sensor in one device, or it can be separate. However, the local processing component is generally placed in the vicinity of the first sensor, such as within 100 or 50 meters for example. The local processing component can comprise a computing device with a CPU and connectivity capabilities via preferably at least two different communication protocols (such as WIFI, WLAN, GSM, LTE, Bluetooth, NFC, LoRa, Narrowband IoT, sub-GHz wireless transmission or others). A skilled person will recognize that various different devices can serve as the local processing component in the present system.
The term “server” can be a computer program and/or a device and/or a plurality of each or both that provides functionality for other programs or devices. Servers can provide various functionalities, often called “services”, such as sharing data or resources among multiple clients, or performing computation and/or storage functions. A single server can serve multiple clients, and a single client can use multiple servers. A client process may run on the same device or may connect over a network to a server on a different device, such as a remote server or the cloud. The server can have rather primitive functions, such as just transmitting rather short information to another level of infrastructure, or can have a more sophisticated structure, such as a storing, processing and transmitting unit.
In the present disclosure, the term central server can indicate a remote server, a collection of servers and/or a cloud server. Generally, the central server indicates computer resources that are generally not in the geographical vicinity of the first sensor and the local processing component.
The memory component can comprise a database located on a storage server and/or a physical storage device. The memory component can be integrated with the central server or it can be a separate component of the system.
The interface can comprise a software program configured to access and/or communicate with the server, including sending instructions and receiving computation results and/or data in various forms (including raw data or processed/analyzed data). The interface can also comprise a dedicated hardware terminal for input/output operations relating to the railway data usage and general system usage. The interface can be accessed, for example, by a user authorized to do so on behalf of the railway operations. The interface can also comprise a remote operator terminal. The interface can comprise a front end of an overarching software running the system operation. That is, it can comprise a presentation layer accessible by a user and comprising various functions/pre-formulated inputs intuitive for a user.
Rail data, which can also be referred to as railway data and/or railroad data can refer to a plurality of different data. That is, data related to trains passing over rails at specific locations is included in the term. Furthermore, data related to various railway components such as switches, frogs, sleepers, rails, trains (including components such as wheels, undercarriage, carriages, locomotive and others) is included in the term. Since the present system is not limited for use with a single type of sensor or rail data, a skilled person will realize that rail data is not limiting other than in regards to limiting the system for use with railway operations.
The present system comprises a plurality of geographically distributed components that communicate with each other and allow for collection and analysis of rail data. Various specific advantages of the system will be listed below, but it generally allows for more accurate tracking of various railway components and status and thereby provides improved safety, reliability and efficiency for the railway operations.
In some embodiments, the interface can be configured to send a query to the central server. The query can comprise a question, instruction, command and/or request. The query can be formulated by a user in a format readable by the server and/or it can be converted to such format by inbuilt interface functions and/or by the central server. The interface and the server can communicate, for example via protocols such as WIFI.
In some such embodiments, the central server can be configured to analyze the preprocessed sensor data to provide the analyzed sensor data corresponding to the query. That is, the query can request analyzed data that the server has already produced (and possibly stored in the memory component). Additionally or alternatively, the query can request data that has not been produced yet. For example, a specific type of analysis can be requested by a user via the interface. This can comprise, for example, an analysis of structural integrity of a railroad switch based on vibration data detected in its vicinity and due to the passing trains.
In some embodiments, the system can further comprise at least one second sensor configured to measure second sensor data. The second sensor can be the same as the first sensor or it can be different from it. The second sensor can be integrated with the first sensor in one sensing device, or it can be physically distinct from the first sensor. The two sensors can be placed in the immediate vicinity of each other or they can be placed in different locations.
In some such embodiments, at least one of the first and second sensors can be an accelerometer configured to measure railway sleeper acceleration. This can advantageously allow to derive a plethora of information relating to railway components from the different accelerations detected.
In some such embodiments, at least one of the first and second sensors can be configured to measure railway sleeper vibration. In some such embodiments, at least one of the first and second sensors can be configured to measure acceleration of up to 500 g. In some such embodiments, each of the first and second sensors can be configured to measure rail track vibrations and wherein the first sensor is configured to measure vibrations up to 40 g and the second sensor is configured to measure vibrations of up to 500 g. In some such embodiments, the precision of the first sensor can exceed that of the second sensor. The two (or more) sensors both measuring the same parameter can be particularly useful for both redundancy and system reliability. Having the sensors with different precision/resolution in different ranges of the parameters allows for a more complete reading of this parameter, and therefore more precise analysis of all of the implications.
In some embodiments, the first sensor can be configured to hibernate until detecting a specific data pattern. The advantage of this feature is that the sensor can use very little or negligible power during the hibernation time. This can prolong the operation time of the sensor until it needs to be replaced entirely or recharged. The sensors described in the present disclosure are generally not connected or wired to grid power and/or a permanent power source. Therefore, energy expenditures need to be carefully managed. The specific data pattern waking the sensor from hibernation can comprise, for example, a typical known pattern associated with a train passing overhead. In this way, the sensor need not be woken when noise or irrelevant signals are detected.
In some embodiments, the second sensor can be configured to hibernate until receiving communication from the first sensor. That is, the first sensor can “wake” the second sensor from hibernation by a specific communication. The advantage of this configuration can be that the second sensor need not “listen” for specific data patterns while hibernating, and an even lower standby energy can be required for its operation. Furthermore, if the first sensor is placed “downstream” of the second sensor, the second sensor can even start measuring the incoming relevant data signal even before it starts, ensuring that no part of the signal is cut off or lost.
In some embodiments, the second sensor can be configured to send second sensor data to the first sensor and the first sensor is configured to send both the first sensor data and the second sensor data to the local processing component. In other words, the sensors can exchange data between each other, with the “point” sensor then forwarding all of the relevant data to the local processing component. This setup can be used, for example when the first and second sensors are spatially displaced from each other and at least one of them is also displaced from the local processing component. The range of communication between the sensors and the local processing component can be low, such as on the order of tens or hundreds of meters. Therefore, if the second sensor is located out of range of the local processing component, but within range of the first sensor, the data can be transferred between the second sensor and the local processing component via the first sensor.
In some embodiments, preprocessing first sensor data comprises removing artifacts. Artifacts can comprise noise due to interference, signal due to unwanted sources, and/or false detections.
In some embodiments, preprocessing first sensor data can comprise applying a low pass filter to the data. That is, for example, (and in the case of the sensor measuring vibration) the signal can be restricted to frequencies of below 100 Hz.
In some embodiments, preprocessing first sensor data can comprise sampling the data. That is, only a limited number of data points can be selected from the whole detected signal.
In some embodiments, preprocessing first sensor data comprises filtering out interference. The interference can be due, for example, to trains passing by on neighboring tracks to the one that the first sensor is monitoring (and therefore the one it is installed on or near). Such interference generally resembles useful signal in shape, but comprises smaller amplitude. Therefore, filtering it out can include scanning the detected signal for known patterns with smaller than expected amplitude.
The different preprocessing measures can all be useful for reducing the size and the amount of data that needs to be forwarded to the central server without significantly affecting useful data.
In some embodiments, the local processing component and the first sensor can be integrated into one device. That is, the two can be integrated into a joint housing and be wired together as one integral device.
In some embodiments, the local processing component and the first sensor can comprise separate devices and communicate via wireless short range communication protocol. That is, the two can be physically distinct devices placed in the general vicinity of each other. This configuration can be particularly advantageous, as the sensors generally need to be placed in the immediate vicinity of the rail tracks, such as on the rail bed. That means that the sensors can require housing configured to withstand the harsh conditions of this placement location. The processing component, on the other hand, can be placed in more favorable conditions nearby. For example, the processing component can be placed indoors in a station, or within a booth housing other railway components. Communication via short range protocol can comprise, for example Bluetooth® and/or Bluetooth® Low Energy (BLE) (other possible short range protocols include, but are not limited to LoRa, Narrowband IoT WLAN, sub-GHz wireless transmission communication). This type of communication can be very energy effective, and therefore optimize energy expenditure of the sensors.
In some embodiments, the local processing component can be integrated in a relay station configured to preprocess first sensor data and forward it to the central server. In some such embodiments, the relay station is configured to receive sensor data from a plurality of sensors and preprocess it separately. The relay station, can be configured to collect data from a plurality of sensors in its vicinity, store it temporarily, and forward it to the central server.
In some embodiments, the central server can be configured to run pattern recognition algorithms of the preprocessed data. The pattern recognition algorithms can be based on various machine-learning techniques. Various types of patterns can be sought for. In some such embodiments, the central server can be configured to identify at least one of train class and train type based on preprocessed data. Additionally or alternatively, patterns reflective of wear and tear can be detected, as well patterns indicating possible sensor or railway component malfunction/failure.
In some such embodiments, the central server can be configured to detect anomalies in the preprocessed data. In some such embodiments, the central server can be configured to evaluate status of railway components based on the detected anomalies. In some such embodiments, the central server can be configured to detect at least one of abrasion and wear of railway infrastructure.
In some embodiments, the central server can be configured to combine preprocessed data relating to a plurality of sensors with a Kalman filter algorithm. The use of the Kalman filter or similar techniques can allow for a quantitative probabilistic combination of data from various sensors to form an adequate combined signal.
In some embodiments, the central server can be configured to send sensor instructions to the first sensor. In some such embodiments, the sensor instructions can comprise measurement parameters adjustment. That is, the sensor parameters such as sensitivity, length of measurement, thresholds, hibernation parameters or others can be adjusted.
In some such embodiments, the sensor instructions can be based on the analyzed sensor data. In other words, if the analyzed sensor data indicates potential problems with any of the railway components or is in other ways differing from normal/expected measurements, the server can instruct the sensor to investigate further by adjusting data collection.
In some embodiments, the central server can be configured to send local processing component instructions to the local processing component. In some such embodiments, local processing component instructions can comprise preprocessing parameters adjustment. Similarly as for the sensor, the amount of preprocessing can be adjusted. That is, any low-pass filter in use can be removed and/or adjusted to include different frequencies of the data, sampling can be done with increased/decreased frequency, and unexpected/anomalous signals that might otherwise be discarded/filtered out may be forwarded to the central server instead.
In some such embodiments, local processing component instructions can be based on analyzed sensor data. This can advantageously be done in real time or close to it. For example, if the central server has detected a potential developing anomaly, it can investigate further by requesting more precise or adjusted data from the local processing component.
Additionally or alternatively, different sensor measurement parameters and/or preprocessing parameters can be used depending on time of day, density of rail operations, weather, and other factors. The central server can instruct the sensors and/or the local processing component to adjust accordingly. Note, this also applies to the second sensor and any further sensors.
In some embodiments, the first sensor can be configured to perform in different modes other than standard operation, and the modes can be optimized for specialized monitoring. That is, different predefined measurement parameters can be associated with different modes. For example, measurement time, type of detected signal required for waking from hibernation, sensitivity, amount of data forwarded to the local processing component and other parameters can be associated with certain different modes of operation. In other words, a mode of operation can comprise a set of specific measurement parameters. In some such embodiments, a first mode comprises sensor diagnostic. That is, this mode can include measurement parameters that are optimized for detecting irregularities in sensor operation. For example, one of the sensors might have become loose in its housing, leading to erroneous measurements. This mode can identify this based on the data measured by this sensor.
In some such embodiments, a second mode comprises railway switch crack monitoring. Developing cracks can produce specific types of signal. The sensor can be configured to monitor the appearance of this type of signal (which can comprise, for example, temporarily high vibration peaks), and alert the local processing component and/or the central server if such patterns are detected. Additionally or alternatively, the measurement parameters may be adjusted to more reliably detect such specific patterns.
In some embodiments, the central server can be configured to transmit at least one of firmware and software updates to at least one of the local processing component and the first sensor. That is, updates of operating software can be installed remotely via data sent from the server to the local processing component and/or to the sensor. Preferably, the server can contact the local processing component, which can then forward the updates to the sensor.
In some embodiments, the local processing component can be configured to determine an optimal time to send the preprocessed sensor data to the central server. In other words, the local processing component can comprise local storage, which can temporarily store the preprocessed data (and/or raw sensor data measured by the sensor) before forwarding it to the central server. In some such embodiments, the optimal time can be determined based on at least one of connection strength, connection availability, weather, incoming sensor data, time of day, schedule of rail operations and predetermined events (which can include, for example, the passage of a specific train). That is, the local processing component can evaluate whether data transmission is possible at a given time and/or whether it is desirable. For example, transferring data over weaker connection can lead to unnecessary delays and/or aborted attempts, which may be undesirable.
In some embodiments, the first sensor can be installed at or near a rail track. As mentioned above, such installation area can be particularly useful for observing and collecting data regarding various railway operations.
In a second embodiment, a method for extracting and processing rail data is disclosed. The method comprises measuring first sensor data via at least one first sensor. The method also comprises preprocessing first sensor data via at least one local processing component to obtain preprocessed sensor data. The method further comprises sending preprocessed sensor data to a central server. The method further comprises analyzing preprocessed sensor data by the server to obtain analyzed sensor data. The method also comprises storing at least one of preprocessed sensor data and analyzed sensor data in a memory component. The method further comprises communicating with the central server via an interface.
A skilled person will realize that the steps of the method according to one aspect of the invention can be performed in a different order without affecting the invention. For example, preprocessed data can be stored before it is analyzed. As another example, communicating with the central server via an interface can be executed at any point.
Embodiments, used terms and specific advantages defined and described with regard to the first embodiment of the invention also apply to the second embodiment.
In some embodiments, the method can further comprise sending a query to the central server via the interface. In some such embodiments, the method further comprises analyzing preprocessed sensor data to provide the analyzed sensor data corresponding to the query. As described above, the query can comprise a request for certain analyzed data. Additionally or alternatively, the query can comprise an instruction to produce additional analyzed data.
In some embodiments, the method can further comprise transmitting analyzed sensor data from the server to the interface.
In some embodiments, the method can further comprise measuring second sensor data via at least one second sensor.
In some embodiments, the method can further comprise measuring railway sleeper vibration via at least one of the first sensor and the second sensor.
In some embodiments, the method can further comprise the first sensor hibernating in the absence of a predetermined data measurement. That is, the first sensor can operate in standby mode until it measures a specific data signal.
In some embodiments, the method can further comprise the second sensor hibernating until receiving a communication from the first sensor. In other words, the first sensor can “wake up” the second sensor if it detected a relevant data signal itself. In this way two hibernation modes are possible: one where a sensor is on standby and listening for a relevant data signal, and one where a sensor is on standby and listening for a relevant communication from another sensor.
In some embodiments, the method can further comprise the first sensor and the local processing component communicating via a short range wireless communication protocol. For example, Bluetooth®, LoRa, Narrowband IoT, WLAN, sub-GHz wireless transmission can be used particularly advantageously, as they can allow for significant energy expenditure optimization, particularly in the case of BLE.
In some embodiments, the local processing component can be integrated into a relay station and the method can further comprise the relay station receiving sensor data from a plurality of sensors, preprocessing it and forwarding it to the central server.
In some embodiments, the method can further comprise the local processing component determining an optimal time to communicate with the central server. In some such embodiments, the optimal time can be determined based on at least one of connection strength, connection availability, weather, incoming sensor data, time of day, schedule of rail operations and predetermined events. Predetermined events can, for example, comprise a detected train passing (any train and/or specific train). In this way, data can be sent in real time to the central server if this is desired (for example, for precise monitoring of a specific train).
In some embodiments, the method can further comprise the second sensor sending second sensor data to the first sensor and the first sensor sending both the first sensor data and the second sensor data to the local processing component. That is, one of the sensors can serve as a temporary aggregation station.
In some embodiments, the method can further comprise applying a low-pass filter to the first sensor data as part of preprocessing.
In some embodiments, the method can further comprise sampling first sensor data as part of preprocessing. In some such embodiments, the frequency of sampling can be adjusted depending on the first sensor data.
In some embodiments, the method can further comprise filtering out interference due to neighboring railway sleeper vibrations as part of preprocessing.
The preprocessing techniques can be applied to both “clean up” data before forwarding it to the server (that is, remove some sources of noise and make sure the relevant signal is being forwarded), as well as significantly reduce the amount of data to be forwarded to the central server.
In some embodiments, the method can further comprise running pattern recognition algorithms on the preprocessed sensor data to obtain analyzed sensor data. In some such embodiments, the method can further comprise identifying at least one of train class and train type based on preprocessed sensor data.
In some embodiments, the method can further comprise evaluating the level of at least one of abrasion and wear of a railway switch based on the analyzed sensor data. This can be done by detecting specific signal patterns that indicate potential problems.
In some embodiments, the method can further comprise combining first sensor data and second sensor data to obtain accurate status of railway components. The status of railway components can refer to their wear and tear, and cracks developing in the components, and further parameters indicative of possible developing problems.
In some embodiments, the method can further comprise the central server sending sensor instructions to the first sensor. In some such embodiments, the sensor instructions can be based on analyzed sensor data.
In some embodiments, the method can further comprise the central server sending local processing component instructions to the local processing component. In some such embodiments, the local processing component instructions can be based on analyzed sensor data.
In some embodiments, the method can further comprise adjusting at least one of first sensor measurement parameters and preprocessing based on analyzed sensor data. As discussed above, measurement parameters can correspond to hibernation time and wake up signal, sensitivity thresholds, length of measurements and various other parameters.
In the system and method according to the present invention the first sensor can be configured to perform in different modes other than standard operation. The modes can be optimized for specialized monitoring and a first mode can comprise sensor diagnostic(s). In a second mode one of the following monitoring an take place alternatively or additionally: railway switch crack or breaking or deformation; blade crack or breaking or deformation; frog crack or breaking or deformation; stretcher bar crack or breaking or deformation; point machine defect or failure; end position detector being out of position; slide chair, roller and/or locking mechanism not having reached end position; non-optimal or intolerable ballast condition.
The invention allows managing and operating a distributed network of sensors which continuously monitors a diverse set of observable physical properties of a railway in order to derive the (non-observable or latent), but most likely health-status of critical parts of the railroad infrastructure (such as switches). The invention thus relates to the general architecture of such a system as required to adapt it to rail infrastructure monitoring.
The objective of the system can be to collect data from the rail infrastructure in real-time, associate the incoming data from multiple sensor posts to actual rail-traffic, aggregate said information into infrastructure usage statistics and usage patterns over time, deduct the dynamics of abrasion and wear process by probabilistic inference and identify emerging safety- and efficiency-(traffic throughput) critical spots in the infrastructure which need maintenance. The architecture includes aspects of distributed data acquisition (including sensors at and in the railbed, their mounting and power supply/power management), data ingestion from non-commensurable sources (e.g. electric current data from switch motor), distributed processing and data relay, as well as central storage and processing for situation analysis.
The use of the system can cover the following areas:
1. Analysis of a railroad infrastructure to detect general sensitivity of certain construction patterns to environmental conditions, detect quality issues in product charges or supplier production methods.
2. Early detection of maintenance need to slow down the abrasion process and prolong lifespan of infrastructure components.
3. Improve efficiency of maintenance operations by focusing maintenance on components that show a fast deterioration and thus have a higher actual probability to fail or cause a risk.
4. Maintenance effects validation: After a maintenance action has been conducted, measured parameters should show normalized values again; the system thus can be used for validation of maintenance effectiveness and quality.
5. Optimize traffic throughput by combining the actual health state of a switch with planned traffic operations to calculate a stochastic optimal sequence of maintenance activities and other measures, such as areas of slow traffic, such that operator selectable metrics are optimized over time (e.g. maximum throughput, minimal delay across all passenger trains)
The present invention is also defined by the following numbered embodiments.
Below is a list of system embodiments. Those will be indicated with a letter “S”. Whenever such embodiments are referred to, this will be done by referring to “S” embodiments.

S1. A system for extracting and processing rail data, the system comprising
- at least one first sensor (10) configured to measure first sensor data (20);
- at least one local processing component (50) configured to receive first sensor data (20) and preprocess it to obtain preprocessed sensor data (52);
- a central server (100) configured to receive preprocessed sensor data (52) and analyze it to produce analyzed sensor data (110);
- a memory component (200) configured to store at least one of the preprocessed sensor data (52) and the analyzed sensor data (110);
- an interface (300) configured to communicate with the central server (100).
S2. The system according to the preceding embodiment wherein the interface (300) is configured to send a query (310) to the central server (100).
S3. The system according to the preceding embodiment wherein the central server (100) is configured to analyze the preprocessed sensor data (52) to provide the analyzed sensor data (110) corresponding to the query (310).
S4. The system according to any of the preceding system embodiments further comprising at least one second sensor (12) configured to measure second sensor data (22).
S5. The system according to the preceding embodiment wherein at least one of the first and second sensors (10, 12) is an accelerometer configured to measure railway sleeper acceleration.
S6. The system according to any of the preceding system embodiments and with the features of embodiment S4 wherein at least one of the first and second sensors (10, 12) is configured to measure railway sleeper vibration.
S7. The system according to the preceding embodiment wherein at least one of the first and second sensors (10, 12) is configured to measure acceleration of up to 500 g.
S8. The system according to any of the preceding two embodiments wherein each of the first and second sensors (10, 12) is configured to measure rail track vibrations and wherein the first sensor (10) is configured to measure vibrations up to 40 g and the second sensor (12) is configured to measure vibrations of up to 500 g.
S9. The system according to the preceding embodiment wherein the precision of the first sensor (10) exceeds that of the second sensor (12).
S10. The system according to any of the preceding system embodiments wherein the first sensor (10) is configured to hibernate until detecting a specific data pattern.
S11. The system according to any of the preceding system embodiments and with the features of embodiment S4 wherein the second sensor (12) is configured to hibernate until receiving communication from the first sensor (10).
S12. The system according to any of the preceding system embodiments and with the features of embodiment S4 wherein the second sensor (12) is configured to send second sensor data (22) to the first sensor (10) and the first sensor (10) is configured to send both the first sensor data (20) and the second sensor data (22) to the local processing component.
S13. The system according to any of the preceding system embodiments wherein preprocessing first sensor data (20) comprises removing artifacts.
S14. The system according to any of the preceding system embodiments wherein preprocessing first sensor data (20) comprises applying a low pass filter to the data.
S15. The system according to any of the preceding system embodiments wherein preprocessing first sensor data (20) comprises sampling the data.
S16. The system according to any of the preceding system embodiments wherein preprocessing first sensor data (20) comprises filtering out interference.
S17. The system according to any of the preceding system embodiments wherein the local processing component (50) and the first sensor (10) are integrated into one device.
S18. The system according to any of the preceding system embodiments wherein the local processing component (50) and the first sensor (10) comprise separate devices and communicate via wireless short range communication protocol.
S19. The system according to the preceding embodiment wherein the local processing component (50) is integrated in a relay station (60) configured to preprocess first sensor data (20) and forward it to the central server (100).
S20. The system according to the preceding embodiment wherein the relay station (60) is configured to receive sensor data (20, 22, 24) from a plurality of sensors (10, 12, 14) and preprocess it separately.
S21. The system according to any of the preceding system embodiments wherein the central server (100) is configured to run pattern recognition algorithms of the preprocessed data (52).
S22. The system according to the preceding embodiment wherein the central server (100) is configured to identify at least one of train class and train type based on preprocessed data (52).
S23. The system according to any of the two preceding embodiments wherein the central server (100) is configured to detect anomalies in the preprocessed data (52).
S24. The system according to the preceding embodiment wherein the central server (100) is configured to evaluate status of railway components based on the detected anomalies.
S25. The system according to the preceding embodiment wherein the central server (100) is configured to detect at least one of abrasion and wear of railway infrastructure.
S26. The system according to any of the preceding claims wherein the central server (100) is configured to combine preprocessed data (52) relating to a plurality of sensors (10, 12, 14) with a Kalman filter algorithm.
S27. The system according to any of the preceding embodiments wherein the central server (100) is configured to send sensor instructions (120) to the first sensor (10).
S28. The system according to the preceding embodiment wherein the sensor instructions (120) comprise measurement parameters adjustment.
S29. The system according to any of the two preceding embodiments wherein the sensor instructions (120) are based on the analyzed sensor data (110).
S30. The system according to any of the preceding system embodiments wherein the central server (100) is configured to send local processing component instructions (130) to the local processing component (50).
S31. The system according to the preceding embodiment wherein local processing component instructions (130) comprise preprocessing parameters adjustment.
S32. The system according to any of the two preceding embodiments wherein local processing component instructions (130) are based on analyzed sensor data (110).
S33. The system according to any of the preceding embodiments wherein the first sensor (10) is configured to perform in different modes other than standard operation, and wherein the modes can be optimized for specialized monitoring.
S34. The system according to the preceding embodiment wherein a first mode comprises sensor diagnostic.
S35. The system according to any of the two preceding embodiments wherein a second mode comprises at least one of the following monitoring: railway switch crack or breaking or deformation; blade crack or breaking or deformation; frog crack or breaking or deformation; stretcher bar crack or breaking or deformation; point machine defect or failure; end position detector being out of position; slide chair, roller and/or locking mechanism not having reached end position; non-optimal or intolerable ballast condition.
S36. The system according to any of the preceding embodiments wherein the central server (100) is configured to transmit at least one of firmware and software updates to at least one of the local processing component (50) and the first sensor (10).
S37. The system according to any of the preceding system embodiments wherein the local processing component (50) is configured to determine an optimal time to send the preprocessed sensor data (52) to the central server (100).
S38. The system according to the preceding embodiment wherein the optimal time is determined based on at least one of connection strength, connection availability, weather, incoming sensor data, time of day and schedule of rail operations.
S39. The system according to any of the preceding system embodiments wherein the first sensor (10) is installed at or near a rail track.

Below is a list of method embodiments. Those will be indicated with a letter “M”. Whenever such embodiments are referred to, this will be done by referring to “M” embodiments.

M1. A method for extracting and processing rail data, the method comprising
- measuring first sensor data (20) via at least one first sensor (10);
- preprocessing first sensor data (20) via at least one local processing component (50) to obtain preprocessed sensor data (52);
- sending preprocessed sensor data (52) to a central server (100);
- analyzing preprocessed sensor data (52) by the server (100) to obtain analyzed sensor data (110);
- storing at least one of preprocessed sensor data (52) and analyzed sensor data (110) in a memory component (300);
- communicating with the central server (100) via an interface (300).
M2. The method according to the preceding embodiment further comprising sending a query (300) to the central server (100) via the interface (300)
M3. The method according to the preceding embodiment further comprising analyzing preprocessed sensor data (52) to provide the analyzed sensor data (110) corresponding to the query (310).
M4. The method according to any of the preceding method embodiments further comprising transmitting analyzed sensor data (110) from the server (100) to the interface (300).
M5. The method according to any of the preceding method embodiments further comprising measuring second sensor data (22) via at least one second sensor (12).
M6. The method according to the preceding method embodiment further comprising measuring railway sleeper vibration via at least one of the first sensor (10) and the second sensor (12).
M7. The method according to any of the preceding method embodiments further comprising the first sensor (10) hibernating in the absence of a predetermined data measurement.
M8. The method according to the preceding embodiment and with the features of embodiment M5 further comprising the second sensor (12) hibernating until receiving a communication from the first sensor (10).
M9. The method according to any of the preceding method embodiments further comprising the first sensor (10) and the local processing component (50) communicating via a short range wireless communication protocol.
M10. The method according to the preceding method embodiment wherein the local processing component (50) is integrated into a relay station (60) and wherein the method further comprises the relay station (60) receiving sensor data (20, 22, 24) from a plurality of sensors (10, 12, 14), preprocessing it and forwarding it to the central server (100).
M11. The method according to any of the preceding method embodiments further comprising the local processing component (50) determining an optimal time to communicate with the central server (100).
M12. The method according to the preceding embodiment wherein the optimal time is determined based on at least one of connection strength, connection availability, weather, incoming sensor data, time of day, schedule of rail operations and predetermined events.
M13. The method according to any of the preceding method embodiments and with the features of embodiment M5 further comprising the second sensor (12) sending second sensor data (22) to the first sensor (10) and the first sensor (10) sending both the first sensor data (10) and the second sensor data (22) to the local processing component (50).
M14. The method according to any of the preceding method embodiments further comprising applying a low-pass filter to the first sensor data (20) as part of preprocessing.
M15. The method according to any of the preceding method embodiments further comprising sampling first sensor data (20) as part of preprocessing.
M16. The method according to the preceding embodiment wherein the frequency of sampling is adjusted depending on the first sensor data (20).
M17. The method according to any of the preceding embodiments further comprising filtering out interference due to neighboring railway sleeper vibrations as part of preprocessing.
M18. The method according to any of the preceding method embodiments further comprising running pattern recognition algorithms on the preprocessed sensor data (52) to obtain analyzed sensor data (110).
M19. The method according to the preceding embodiment further comprising identifying at least one of train class and train type based on preprocessed sensor data (52).
M20. The method according to any of the preceding method embodiments further comprising evaluating the level of at least one of abrasion and wear of a railway switch based on the analyzed sensor data (110).
M21. The method according to any of the preceding method embodiments and with the features of embodiment M5 further comprising combining first sensor data (20) and second sensor data (22) to obtain accurate status of railway components.
M22. The method according to any of the preceding method embodiments further comprising the central server (100) sending sensor instructions (120) to the first sensor (10).
M23. The method according to the preceding embodiment wherein the sensor instructions (120) are based on analyzed sensor data (110).
M24. The method according to any of the preceding method embodiments further comprising the central server (100) sending local processing component instructions (130) to the local processing component (50).
M25. The method according to the preceding embodiment wherein the local processing component instructions are based on analyzed sensor data (110).
M26. The method according to any of the preceding method embodiments further comprising adjusting at least one of first sensor measurement parameters and preprocessing based on analyzed sensor data (110).
M27. The method according to any of the preceding method embodiments with the first sensor being configured to perform in different modes other than standard operation, and wherein the modes can be optimized for specialized monitoring.
M28. The method according to the preceding method embodiment wherein a first mode comprises sensor diagnostic.
M29. The method according to any of the two preceding method embodiments wherein a second mode comprises at least one of the following monitoring: railway switch crack or breaking or deformation; blade crack or breaking or deformation; frog crack or breaking or deformation; stretcher bar crack or breaking or deformation; point machine defect or failure; end position detector being out of position; slide chair, roller and/or locking mechanism not having reached end position; non-optimal or intolerable ballast condition.

The present technology will now be discussed with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a schematic embodiment of a system for extracting and analyzing rail data;

FIG. 2 depicts communication and architecture within a system for extracting and analyzing rail data;

FIG. 3 depicts an embodiment of a method for extracting and analyzing rail data;

FIG. 4 depicts an example of data measured by the first sensor and further processed in accordance with the present invention;

FIG. 5 constitutes an exemplifying data set corresponding to a specific kind of train and being representative for this train in accordance with the present invention;

FIG. 6 is an exemplifying plot of acceleration recorded and caused by a train passing with an overlayed acceleration from another train on a neighboring track.

DESCRIPTION OF EMBODIMENTS

FIG. 1 schematically depicts a system for acquiring and analyzing railway data. The system comprises at least one first sensor 10. The first sensor 10 can comprise a plurality of sensors and/or a sensor system and/or one sensor. The first sensor 10 collects railway related data, such as the vibration due to a train passing on the tracks. The first sensor 10 can be placed on the track bed and/or in its general vicinity.
The system also comprises a local processing component 50. The local processing component 50 can be integrated with the first sensor 10 in one sensor system or it can be a standalone component. The first sensor 10 communicates with the local processing component 50, as indicated by the arrow.
Also depicted is a central server 100. The central server 100 can comprise a cloud server, a remote server, and/or a collection of servers. The central server 100 can be in bidirectional communication with the local processing component 50. Additionally, the central server 100 can be in direct communication with the first sensor 10, particularly if the local processing component 50 comprises a standalone device. However, it is also possible that all communication between the central server 100 and the first sensor 10 is done via the local processing component 50.
A memory component 200 is depicted in bidirectional communication with the central server 100. The memory component 200 can serve to store data sent to the server 100 from the first sensor 10 and/or the local processing component 50. The memory component 200 can also store data generated on the central server 100 and/or by the central server 100 based on the sensor data. The central server 200 can access data stored in the memory component, overwrite it, control the storage logic and generally oversee the distribution of data within the memory component 200.
Also depicted is an interface 300, which can also be in bidirectional communication with the central server 100. The interface 300 can comprise a front end of a dedicated software for running and/or improving railway safety and operations. The interface 300 can also comprise a physical terminal such as a personal computing device, dedicated for communicating with the central server 100. The interface 300 can send queries to the central server 100. For example, a request for a specific computation based on sensor data can be sent to the central server 100 via the interface.
The system can be used in the following exemplary way. The first sensor 10 can collect data, for example vibration data due to trains passing over the rail bed on which it is placed. This data can be sent to the local processing component 50 (either by a wired connection if the first sensor 10 and the processing component 50 comprise one unit, or via wireless connection otherwise). The local processing component 50 preprocesses the collected data, in order to reduce its volume and obtain a cleaner (and therefore more reliable) signal. For example, the data can be passed through a low-pass filter and/or sampled. The preprocessed data is then sent to the central server 100. The server 100 can forward it to be stored to the memory component 200 and/or it can analyze it. The server 100 might do some analysis by default, and some other analyses might be requested as queries via the interface 300. The data stored in the memory component 200 can also be accessed via the interface 300, possibly through the central server 100. The types of analyses that can be performed can include combining data from different sensors via a Kalman filter or a similar analysis, detecting anomalies by comparing with expected data, identifying the types of trains by the detected signal and other analyses. Depending on the result of data analysis and/or of queries sent via the interface 300, the measurement characteristics of the first sensor 10 and/or the preprocessing done by the local processing component 50 can be adjusted. For example, the first sensor 10 might be instructed to adjust sensitivity thresholds to record more or less data, or the local processing component 50 might be instructed to apply a denser sampling procedure.
FIG. 2 depicts a more detailed embodiment of communication and architecture of the system for obtaining and analyzing railway data according to an embodiment of the present invention.
A first sensor 10, a second sensor 12 and a third sensor 14 are shown. Those can all be part of one device, that is, a collection of sensors assembled together. Alternatively, the sensors 10, 12 and 14 can comprise different devices, potentially placed at different locations (but in the general vicinity of each other). The sensors can be identical or different. The sensors can measure the same physical quantities or different. For example, all sensors can measure the acceleration of the railway sleeper, but in different ranges. This can allow for combining the measurements to obtain data over a larger range.
The first, second and third sensors 10, 12, 14 measure first, second and third sensor data 20, 22 and 24 respectively.
The sensor data 20, 22, 24 is then sent to the local processing component 50. As before, the local processing component 50 can be integrated with the sensors, or it can be separate. The local processing component could also be integrated with one or more of the sensors, and not with the others. The local processing component 50 preprocesses sensor data to obtain preprocessed sensor data 52. This can be done for each sensor separately, or for a plurality of sensors together. A skilled person will understand that depending on the precise sensor configuration, preprocessed sensor data 52 can refer to first, second and third sensor data 20, 22, 24 separately or in combination.
Depending on the data aspect requested from the sensor device, data might be converted into frequency domain. Furthermore, depending on the data aspect considered, only the relevant Fourier Coefficients might be sent from which the signal can be reproduced at the server side (compression).
Measured sensor data 20, 22, 24 can be temporarily stored locally on a storage component of the sensors and/or on the storage associated with the local processing component 50. The device can implement a FIFO ring-buffer storage structure to avoid running out of memory (i.e. the buffer can be filled up to its maximum capacity, then, the oldest data or the oldest data file is replaced by the new file. Replacement mechanism can be configured to obey a precedence ordering of attributes “oldest” file”, “oldest file<certain size”, etc.).
One local processing component 50 can preprocess and forward sensor data from a plurality of sensors 10, 12, 14. Additionally or alternatively, each sensor 10, 12, 14 can comprise an individual local processing component 50.
The local processing component 50 can also be integrated with a relay station 60 shown in a dashed line. The relay station 60 can comprise a local “data hub” where a plurality of sensors can send their data using a short range communication protocol.
The sensors 10, 12, 14 can either send data via wide area communication (GSM or similar) directly to the central server 100 or via a relay station 60, which can be located nearby the sensors 10, 12, 14 and usually is used to aggregate and pre-scan information before sending.
Data injection in the simplest case can use a REST interface (restful interface), i.e. be stateless, such that the server 100 does not have to maintain a “session” with the sensors 10, 12, 14, which is important for scaled communication. The REST logic can be implemented on https level.
For standalone devices, the sensors 10, 12, 14 can typically be woken up when trains are approaching. Depending on the sensor configuration, after the train has passed, the device can automatically initiate a connection to the backend server via GSM (and via the local communication component 50) and post its measurements, or its preprocessed measurement data to the backend. A following get request can transfer any new configuration from the server to the device. Such configuration determines when and what to record and according to which criteria data is sent (as sending is the most power consuming phase of operations).
In a cascading setup, i.e. when a nearby relay station 60 is used, the sensors 10, 12, 14 can communicate directly with the relay station 60 using lower power local area connectivity (e.g. Bluetooth® Low Energy). This can be a cost efficient option in situations where there are multiple devices in close proximity or in areas where there is no direct wide area connection possible (such as in tunnels). In such cases, data can be transferred directly to the relay station 60 from the sensors 10, 12, 14.
Operating a relay station 60 can provide multiple advantages, mainly because the relay stations 60 usually are not placed in the railbed, and thus are not exposed to the extreme environmental conditions like the sensor are. Therefore, the relay stations 60 can be produced with known commercial technology, which does not have to be ruggedized. Therefore, relay stations 60 can make use of e.g. permanent power sources or other recharging technologies (such as solar energy) and can use wired data connectivity.
Relay station 60 can perform preprocessing and associate data from multiple sensors 10, 12, 14 in this case. An example is the separation of train induced noise from switch or underground specific resonance signals by statistical signal processing techniques (Independent Component analysis, or ICA) when aligning and associating data from multiple sensor points on the same switch for the same train.
For real-time monitoring, data can be analysed for critical patterns already at the relay station 60. Besides aggregated/statistical information to drive the health models, the relay station 60 can communicate with backend only when interesting new patterns are found (novelty detection—i.e. patterns which cannot be associated to known patterns), or when an anomaly or fault has been detected to save communication costs.
The local processing component 50 can transmit the preprocessed sensor data 52 to the central server 100. The sending process can use a security scheme where data is encrypted on transport layer. The central server 100 can analyze the data based on predetermined algorithms or applications. The central server 100 can also receive direct queries 310 for a specific type of analysis from the interface 300. Analyzed data 110 can be a result of a predetermined algorithm or application and/or of a specific request or query 310.
The preprocessed sensor data 52 can be read by algorithms, which perform transformations (e.g. from acceleration/vibration to displacement). Transformed data can be stored in the memory component 200.
The data can then be read by pattern recognition systems (e.g. to identify train class and train type). Summary statistics can be calculated and precached in the database.
Finally, probabilistic inference model can read available data in order to update the health status estimate of the railway.
The architecture can be generally set up as a non-deterministic reasoning mechanism and communicate asynchronously (that is, event driven). This allows, for example, a probabilistic switch health model to communicate a hypothesis about, for example, a specific switch requiring maintenance, which might not be a dominant hypothesis at that time, but can be picked up by a sensor queuing process to intensify monitoring and data transmission for that particular switch.
Selective data acquisition is an important enabler in the railway use case, because abrasion and wear processes are very long term processes, which would produce a very large amount of data if all data would be recorded and stored for every data aspect and every sensor. Thus, setting the focus on relevant data aspects and selectively intensifying data collection can be an important factor that can make large scale monitoring possible.
Via an interface 300, users can retrieve arbitrary combinations of reports, all reflecting the up to date situation.
The analyzed data 110 can be sent to the interface 300 upon request and/or automatically. Furthermore, both or either of the preprocessed sensor data 52 and the analyzed sensor data 110 can be stored in the memory component 200. The data can then be accessed by the central server 100 for further analysis and/or for retrieval via the interface 300.
Data stored in the memory component 200 can be retrieved by queries 310. Queries 310 can retrieve data along the following dimensions:

- All raw measurement data for a certain railway infrastructure component and/or its parts (there might be multiple sensors 10, 12, 14 at one switch, one at each point machine, one at the frog, etc.)
- All processed measurement data for a certain railway infrastructure component (this includes typically commensurable data and data that can be computed from the raw data by means of mathematical transforms or compensation techniques. E.g. displacement data (in mm) can be calculated from acceleration data in g).
- All associated data for a specific infrastructure component (switch)—this would include non-commensurable data, like electric current of the switch motor, which is not aligned with passage data from a time perspective, but still related to train passages. This also includes maintenance reports and failure messages.
- All associated data from other sources per geo-location (e.g. weather data, temperature, rainfall)
- Aggregated statistics of usage for each infrastructure component
- All data mentioned so far across user-specified time windows (to track development over time)
- Aggregated/comparative statistics over different query groups (e.g. for all switches with fixed frog, for all switches in a certain geographic area, all switches operating high-speed trains, all switches with certain usage characteristics, all switches older than selected ones, all switches with from a certain manufacturer (as per switch dossier) and combinations thereof.
- Aggregated statistics along a route leg (multiple switches)
- Interpreted information e.g. specifics in electric current patterns
- Inferred information, like health status, expected failure probability over the coming 10 days, 20 days, 60 days.

The central server 100 can further send sensor instructions 120 and/or local processing component instructions 130 to the sensors 10, 12, 14 and/or to the local processing component 50 respectively. These instructions can be based on analyzed sensor data 110. For example, if an anomaly is detected in the data indicating possible cracks (such as cracks in railway switches), the central server 100 might instruct the sensors 10, 12, 14 to increase frequency and/or sensitivity of measurement, or the local processing component 50 to increase sampling of the sensor data 20, 22, 24.
Practically, the sensors 10, 12, 14 can be remotely configured e.g. according to the following parameters:
a) time and scheme of recording on train passage (when does the sensor wake up, how long does it record, max. duration, as long as vibration is >threshold; sensor can stay awake through a specifiable time period),
b) when data is to be sent (time point; can be fixed time or related to a wake up e.g. first wake up in a new day),
c) selection of traces which should be sent based on configurable criteria (length of trace, RMS of acceleration, etc.).
Sensors 10, 12, 14 and relay stations 60 (or local processing components 50) can be synchronized either via an own onboard GPS or by the backend to ensure a synchronous time management across the whole system, which is important to align incoming measurement data along the time dimension.
Configuration of the sensors is an important aspect, since sensors 10, 12, 14 are preferably self-sustaining and run on battery life in the field for their intended deployment time of about two years. Given this constraint, the sensor is preferably brought in a very-low-power consuming sleep mode (hibernation) and is only woken up when required. Particularly data transfer (which typically is the most power consuming part for wide-area communication sensors) has to be restricted to relevant and significant information only.
To obtain a clear situational overview, the backend can make use of so called “sensor-queuing”, i.e. the backend (that is, the central server 100) can instruct the individual sensor 10, 12, 14 what to record and what to send based on current situation (communication network coverage and traffic over the switch). A typical pattern might be that the sensor is deployed and instructed to collect in a uniform random sampling pattern over the day. After analysis in the backend, the backend might narrow down the data acquisition to a certain time frame where most relevant load (e.g. high-speed trains) occur over days. If the acquired data shows a “stable situation”, i.e. data is in variance with no changing trend, the backend system might instruct the sensor 10, 12, 14 to reduce sent data volume in favour of prolonging battery lifetime. As soon as first signs of trend changing appear (e.g. starting trend in the data or hypothesis of changing health state becoming more dominant), the backend might instruct the sensor to increase data acquisition and sending volume.
For monitoring and tracking real time events, the system further allows so-called “app injection” on the device. Similar to “apps” on a mobile phone, the sensors 10, 12, 14 can also be loaded with different analysis processes, which search for specific patterns in the data recorded by the sensor elements installed on each sensor. An example is “anomaly detection app”, which searches recorded data for specific data patterns that indicate a potentially loose sensor (cold weather and ice shedding might damage the sensor or its mounting; anomaly detection can be able to find detect when such patterns occur and signal this to the central server 100).
Another“app” can be monitoring for frog (or railway switches) cracks: in the past, it has been repeatedly observed that in case of cracks in the frog, temporarily high vibration peaks were observed. Although the “app” cannot directly detect (or validate) a frog crack, it can inform the central server 100 about such patterns. The central server 100 can then observe the development of occurrences of such patterns and might infer and send an alert about a potential frog material failure using a probabilistic model.
FIG. 3 depicts an embodiment of a method for detecting and analyzing railway data according to one aspect of the invention.
In step S1, first sensor data is measured via at least one first sensor. As discussed above, sensor data can comprise, for example, measurement of the acceleration of a railway sleeper due to a train passing on the track.
The measured data is preprocessed via a local processing component to obtain preprocessed sensor data in S2. Preprocessing can include applying a low-pass to the data, sampling the data, removing artefacts and/or noise from the data. For example, only signals of frequency below 100 Hz can be selected via a low-pass filter to estimate railway sleeper displacement. However, for detection cracks in the structures, signals in the kHz region can be analyzed.
The data can be transmitted to the local processing component via a wired connection or via a short range communication protocol such as Bluetooth®.
In S3, the preprocessed data is sent to a central server. This can be done via cellular communication such as GSM or LTE. Additionally or alternatively, it can also be done via WiFi or WLAN.
In step S4, which is optional, a query relating to rail data is transmitted to the central server via an interface. That is, the query can be input by a user, such as a supervisor or operator or a railway service.
The preprocessed data is then analyzed by the server in S5 to obtain analyzed sensor data. Optionally, this analyzed sensor data can correspond to the requested query from S4.
However, the server can also run certain analyses without prompting from an interface.
In S6, the analyzed sensor data is optionally transmitted from the central server to the interface. In other words, a user can have access to the analyzed data via the interface.
In S7, the preprocessed data and/or the analyzed data are stored in a memory component.
FIG. 4 depicts exemplary sensor data, as well as exemplary preprocessed sensor data. The depicted data is from combined acceleration sensors. The top line shows raw acceleration sensor output (in g). The second line from the top shows a preprosessed acceleration data that has been cleaned by removing artefacts generated by sensor wakeup. The third line from the top shows low pass-filtered acceleration signal. The fourth line from the top shows the absolute mean signal corresponding to signal strength. The sixth line from the top shows twice integrated and noise-corrected signal showing the absolute vertical displacement of a railway sleeper in mm (displaying the typical axle/bogey pattern of a train passage; first bogey particularly shows the impact of the heavy motor car/locomotive).
FIG. 5 shows a schematic typical vibration pattern corresponding to a train passing on a track. These can be used to “wake up” the sensors from hibernation in which they can be kept in the absence of train signals. By identifying the specific patterns associated with a passage of a train, false positives or artefacts can be filtered out from the data.
FIG. 6 depicts another possible preprocessing technique comprising filtering an overlaid signal. The sensors can often detect vibrations or acceleration due to trains passing over neighboring tracks, which can interfere with the data of the sensor's track. To avoid this interference, such data can be filtered out during preprocessing, or directly on the server.

LIST OF REFERENCE NUMERALS

10—First sensor
12—Second sensor
14—Third sensor
20—First sensor data
22—Second sensor data
24—Third sensor data
50—Local processing component
52—Preprocessed sensor data
60—Relay station
100—Central server
110—Analyzed sensor data
120—Sensor instructions
130—Local processing component instructions
200—Memory component
300—Interface
310—Query

Whenever a relative term, such as “about”, “substantially” or “approximately” is used in this specification, such a term should also be construed to also include the exact term. That is, e.g., “substantially straight” should be construed to also include “(exactly) straight”.
Whenever steps were recited in the above or also in the appended claims, it should be noted that the order in which the steps are recited in this text may be the preferred order, but it may not be mandatory to carry out the steps in the recited order. That is, unless otherwise specified or unless clear to the skilled person, the order in which steps are recited may not be mandatory. That is, when the present document states, e.g., that a method comprises steps (A) and (B), this does not necessarily mean that step (A) precedes step (B), but it is also possible that step (A) is performed (at least partly) simultaneously with step (B) or that step (B) precedes step (A). Furthermore, when a step (X) is said to precede another step (Z), this does not imply that there is no step between steps (X) and (Z). That is, step (X) preceding step (Z) encompasses the situation that step (X) is performed directly before step (Z), but also the situation that (X) is performed before one or more steps (Y1), . . . , followed by step (Z). Corresponding considerations apply when terms like “after” or “before” are used.

Claims

1. A system for extracting and processing rail data, the system comprising

at least one first sensor configured to measure first sensor data;

at least one local processing component configured to receive first sensor data and preprocess it to obtain preprocessed sensor data;

a central server configured to receive preprocessed sensor data and analyze it to produce analyzed sensor data;

a memory component configured to store at least one of the preprocessed sensor data and the analyzed sensor data;

an interface configured to communicate with the central server.

2. The system according to claim 1 wherein the interface is configured to send a query to the central server and wherein the central server is configured to analyze the preprocessed sensor data to provide the analyzed sensor data corresponding to the query.

3. The system according to claim 1 further comprising at least one second sensor configured to measure second sensor data.

4. The system according to claim 1 wherein the first sensor is configured to hibernate until detecting a specific data pattern.

5. The system according to claim 3 wherein the second sensor is configured to hibernate until receiving communication from the first sensor.

6. The system according to claim 3, wherein the second sensor is configured to send second sensor data to the first sensor, and the first sensor is configured to send both the first sensor data and the second sensor data to the local processing component.

7. The system according to claim 7 wherein the local processing component and the first sensor comprise separate devices and communicate via wireless short range communication protocol.

8. The system according to claim 7 wherein the local processing component is integrated in a relay station configured to preprocess first sensor data and forward it to the central server and wherein the relay station is configured to receive sensor data from a plurality of sensors and preprocess it separately.

9. The system according to claim 7 wherein the central server is configured to detect anomalies in the preprocessed data and evaluate status of railway components based on the detected anomalies.

10. The system according to claim 1 wherein the central server is configured to send at least one of

sensor instructions comprising measurement parameters adjustment to the first sensor; and

local processing component instructions comprising preprocessing parameters adjustment to the local processing component; and

wherein the at least one of the sensor instructions and the local processing component instructions are based on the analyzed sensor data.

11. The system according to claim 1 wherein the first sensor is configured to perform in different modes other than standard operation, and wherein the modes can be optimized for specialized monitoring.

12. The system according to claim 1 wherein the local processing component is configured to determine an optimal time to send the preprocessed sensor data to the central server and wherein the optimal time is determined based on at least one of connection strength, connection availability, weather, incoming sensor data, time of day and schedule of rail operations.

13. A method for extracting and processing rail data, the method comprising

measuring first sensor data via at least one first sensor;

preprocessing first sensor data via at least one local processing component to obtain preprocessed sensor data;

sending preprocessed sensor data to a central server;

analyzing preprocessed sensor data by the server to obtain analyzed sensor data;

storing at least one of preprocessed sensor data and analyzed sensor data in a memory component;

communicating with the central server via an interface.

14. The method according to claim 13 further comprising

sending a query to the central server via the interface;

analyzing preprocessed sensor data to provide the analyzed sensor data corresponding to the query; and

transmitting analyzed sensor data from the server to the interface.

15. The method according to claim 13 further comprising adjusting at least one of first sensor measurement parameters and preprocessing based on analyzed sensor data.

16. The method according to claim 13 further comprising

measuring second sensor data via at least one second sensor; and

measuring railway sleeper vibration via at least one of the first sensor and the second sensor.

17. The method according to claim 16 further comprising the second sensor sending second sensor data to the first sensor and the first sensor sending both the first sensor data (10) and the second sensor data to the local processing component.

18. The method according to claim 13 further comprising the first sensor and the local processing component communicating via a short range wireless communication protocol and wherein the local processing component is integrated into a relay station and wherein the method further comprises the relay station receiving sensor data from a plurality of sensors, preprocessing it and forwarding it to the central server.

19. The method according to claim 13 further comprising at least one of

applying a low-pass filter to the first sensor data;

sampling first sensor data with the frequency of sampling adjusted based on the first sensor data;

filtering out interference due to neighboring railway sleeper vibrations as part of preprocessing.

20. The method according to claim 16 further comprising evaluating the level of at least one of abrasion and wear of a railway switch based on the analyzed sensor data.