SYSTEM AND METHOD FOR EXTRACTING AND PROCESSING RAILWAY-RELATED DATA

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.

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.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

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

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

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

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

[0181] 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;

[0182] 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

[0183] 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.

[0184] 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.

[0185] 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.

[0186] 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.

[0187] 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.

[0188] 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.

[0189] 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.

[0190] 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.

[0191] The first, second and third sensors 10, 12, 14 measure first, second and third sensor data 20, 22 and 24 respectively.

[0192] 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.

[0193] 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).

[0194] 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.).

[0195] 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.

[0196] 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.

[0197] 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.

[0198] 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.

[0199] 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).

[0200] 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.

[0201] 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.

[0202] 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.

[0203] 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 detectioni.e. patterns which cannot be associated to known patterns), or when an anomaly or fault has been detected to save communication costs.

[0204] 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.

[0205] 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.

[0206] 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.

[0207] Finally, probabilistic inference model can read available data in order to update the health status estimate of the railway.

[0208] 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.

[0209] 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.

[0210] Via an interface 300, users can retrieve arbitrary combinations of reports, all reflecting the up to date situation.

[0211] 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.

[0212] Data stored in the memory component 200 can be retrieved by queries 310. Queries 310 can retrieve data along the following dimensions: [0213] 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.) [0214] 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). [0215] 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. [0216] All associated data from other sources per geo-location (e.g. weather data, temperature, rainfall) [0217] Aggregated statistics of usage for each infrastructure component [0218] All data mentioned so far across user-specified time windows (to track development over time) [0219] 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. [0220] Aggregated statistics along a route leg (multiple switches) [0221] Interpreted information e.g. specifics in electric current patterns [0222] Inferred information, like health status, expected failure probability over the coming 10 days, 20 days, 60 days.

[0223] 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.

[0224] Practically, the sensors 10, 12, 14 can be remotely configured e.g. according to the following parameters:

[0225] 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),

[0226] 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),

[0227] c) selection of traces which should be sent based on configurable criteria (length of trace, RMS of acceleration, etc.).

[0228] 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.

[0229] 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.

[0230] 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.

[0231] 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).

[0232] Anotherapp 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.

[0233] FIG. 3 depicts an embodiment of a method for detecting and analyzing railway data according to one aspect of the invention.

[0234] 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.

[0235] 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.

[0236] The data can be transmitted to the local processing component via a wired connection or via a short range communication protocol such as Bluetooth.

[0237] 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.

[0238] 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.

[0239] 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.

[0240] However, the server can also run certain analyses without prompting from an interface.

[0241] 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.

[0242] In S7, the preprocessed data and/or the analyzed data are stored in a memory component.

[0243] 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).

[0244] 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.

[0245] 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

[0246] 10First sensor [0247] 12Second sensor [0248] 14Third sensor [0249] 20First sensor data [0250] 22Second sensor data [0251] 24Third sensor data [0252] 50Local processing component [0253] 52Preprocessed sensor data [0254] 60Relay station [0255] 100Central server [0256] 110Analyzed sensor data [0257] 120Sensor instructions [0258] 130Local processing component instructions [0259] 200Memory component [0260] 300Interface [0261] 310Query

[0262] 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.

[0263] 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.