Patent Description:
Rail systems are highly complex systems comprising rolling stock and infrastructure that are subject to harsh operating and environmental conditions. The rolling stock includes trainsets, shunting locomotives, and railcars, for example. The infrastructure includes the physical rail track, switches, overhead lines, as well as the power electronics (e.g., transformers and back-up generators). Each of the aforementioned examples of rolling stock and infrastructure include various sub-systems, devices, and components thereof.

To ensure safe and efficient operation, regular inspections and maintenance of devices of the rail systems is required. Additionally, any malfunctioning or improperly functioning device of the rail system that is noticed by rail personnel is reported. On the basis of such reports alone, however, it can be difficult to ascertain the correct manner of proceeding, in particular because it may be unclear, due to the highly complex nature of rail systems and their components, what the underlying cause of the malfunctioning or improperly functioning device is. Additionally, it can be difficult to correctly plan and/or prioritize maintenance of the device because it may be unclear what effect the malfunctioning or improperly functioning part has on the safe and reliable execution of rail services. For example, a safety-critical device which does not function properly may have to undergo maintenance immediately, while another non-safety-critical device may have maintenance planned for a next routine stop at a rail maintenance facility.

<CIT> discloses a system and method for training and validating models in a machine learning pipeline for failure mode analytics. The machine learning pipeline may include an unsupervised training phase, a validation phase and a supervised training and scoring phase. In one example, the method may include receiving a request to create a machine learning model for failure mode detection associated with an asset, retrieving historical notification data of the asset, generating an unsupervised machine learning model via unsupervised learning on the historical notification data, wherein the unsupervised learning comprises identifying failure topics from text included in the historical notification data and mapping the identified failure topics to a plurality of predefined failure modes for the asset, and storing the generated unsupervised machine learning model via a storage device.

<NPL>), is a study concerned with the improvement of the efficiency, reliability and safety related to railroad maintenance tasks through an evaluation of the consequences of failures. The brake system was selected based on the failure data obtained from railroad vehicles in operation as one of the safety systems in railroad vehicles.

It is an object of the invention and embodiments disclosed herein to provide a method for maintenance planning of a rail system device and computer for maintenance planning of a rail system device.

In particular, it is an object of the invention and embodiments disclosed herein to provide a method for maintenance planning of a rail system device, in particular a rolling stock device or a railway infrastructure device, and computer for maintenance planning of a rail system device which does not have at least some of the disadvantages of the prior art.

The present disclosure relates to a method for maintenance planning of a rail system device, in particular a rolling stock device or a railway infrastructure device. The method comprises receiving, in a processor, a fault report message relating to a malfunctioning rail system device. The method comprises analyzing, in the processor, the fault report message using natural language processing. The method comprises mapping, in the processor, the analyzed fault report message to a particular failure mode type of a plurality of failure mode types associated with the rail system device, the particular failure mode type identifying at least one probable cause of malfunction of the rail system device related to the fault report message. The method comprises determining, in the processor, using the particular failure mode type, a failure effect associated with the particular failure mode type, wherein the failure effect identifies one or more operational consequences of the failure mode type. The method comprises determining, in the processor, a time and/or a distance until maintenance of the rail system device, using the failure effect.

The term rail system device is not to be understood as a device limited to the railway line system (such as tracks and switches) but to be understood as any device used in direct relation with rail transportation, including rolling stock or railway infrastructure. The term rail system device can therefore be a rail traffic system device, a rail transport system device, or component thereof.

In an embodiment, the method further comprises generating, in the processor, a maintenance planning message indicating the time and/or the distance until maintenance.

In an embodiment, the method further comprises performing maintenance of the rail system device according to maintenance measures, wherein the maintenance measures are determined using the fault report message, the failure mode type, and/or the failure effect. The maintenance measures can include repair or replacement of the rail system device or a component thereof.

In an embodiment, determining the failure effect using the particular failure mode type comprises using a failure-mode-and-effects model which associates the particular failure mode type with the failure effect.

In an embodiment, the failure-mode-and-effects model for the rail system device is established using a historical dataset comprising the plurality of failure mode types of the rail system device and therewith associated failure effects, and/or by processing technical device information related to the rail system device from external information sources.

In an embodiment, processing the technical device information from external information sources comprises aggregating, in the processor, from a plurality of external information sources, the technical device information related to the rail system device, wherein the external information sources including scientific literature, patent publications, and/or technical manuals. Processing the technical information comprises extracting, in the processor, from the plurality of external information sources, functional elements and/or structural elements of the rail system device. Processing the technical information comprises determining, in the processor, using the functional elements and/or structural elements, one or more failure mode types and one or more failure effects of the rail system device.

In an embodiment, mapping the analyzed fault report message to one of a plurality of failure mode types uses a statistical topic model trained using a topic model training dataset and an unsupervised machine learning technique, wherein the topic model training dataset comprises a plurality of historical fault report messages.

In an embodiment, the natural language processing for analyzing the fault report message uses Named Entity Recognition.

In addition to a method for maintenance planning of a rail system device, the present disclosure also relates to a rail system maintenance planning device for maintenance planning of a rail system device, in particular a rolling stock device or an infrastructure device, comprising a processor configured to receive a fault report message relating to a malfunctioning rail system device. The processor is configured to analyze the fault report message using natural language processing. The processor is configured to map the analyzed fault report message to a particular failure mode type of a plurality of failure mode types associated with the rail system device. The particular failure mode type identifies at least one probable cause of malfunction of the rail system device related to the fault report message. The processor is configured to determine, using the particular failure mode type, a failure effect associated with the particular failure mode type, using the particular failure mode types, wherein the failure effect identifies one or more operational consequences of the particular failure mode type. The processor is configured to determine a time and/or a distance until maintenance of the rail system device, using the failure effect.

In an embodiment, the processor of the rail system maintenance planning device is further configured to generate a maintenance planning message indicating the time and/or the distance until maintenance.

In an embodiment, the processor of the rail system maintenance planning device is configured to determine the failure effect using a failure-mode-and-effects model which associates the particular failure mode type with the failure effect.

In an embodiment, the failure-mode-and-effects model used by the processor for the rail system device is established using a historical dataset comprising the plurality of failure mode types of the rail system device and therewith associated failure effects, and/or by processing technical device information related to the rail system device from external information sources.

In an embodiment, the processor is configured to process the technical device information from external information sources by aggregating, from a plurality of external information sources the technical device information related to the rail system device. The external information sources include scientific literature, patent publications, and/or technical manuals. The processor is configured to extract, from the plurality of external information sources, functional elements and/or structural elements of the rail system device. The processor is configured to determine, using the functional elements and/or structural elements, one or more failure mode types and one or more failure effects of the rail system device.

In an embodiment, the processor is configured to map the analyzed fault report message to one of a plurality of failure mode types using a statistical topic model trained using a topic model training dataset and an unsupervised machine learning technique, wherein the topic model training dataset comprises a plurality of historical fault report messages.

In addition to a method for maintenance planning of a rail system device and a rail system maintenance planning device, the present disclosure also relates to a computer program product comprising a non-transitory computer-readable medium having stored thereon computer program code configured to control a processor, in particular of a rail system maintenance planning device, such that the processor performs the step of receiving a fault report message relating to a malfunctioning rail system device. The computer program code is configured to control the processor to perform the step of analyzing the fault report message using natural language processing. The computer program code is configured to control the processor to perform the step of mapping the analyzed fault report message to a particular failure mode type of a plurality of failure mode types associated with the rail system device, the particular failure mode type identifying at least one probable cause of malfunction of the rail system device related to the fault report message. The computer program code is configured to control the processor to perform the step of determining, using the particular failure mode type, a failure effect associated with the particular failure mode type, wherein the failure effect identifies one or more operational consequences of the particular failure mode type. The computer program code is configured to control the processor to perform the step of determining one or more of: a time or a distance until maintenance of the rail system device, using the failure effect.

In addition to the method for maintenance planning of a rail system device, a rail system maintenance planning device, and a computer program product, the present disclosure also relates to a maintenance system comprising the rail system maintenance planning device as described herein and a maintenance facility, wherein the maintenance facility is configured to perform maintenance on the rail system device according to determined maintenance measures. In particular, the maintenance facility comprises a computing device configured to receive a maintenance planning message comprising the maintenance measures.

The present disclosure relates in particular to maintenance planning of a rail system device, however maintenance planning of other types of devices is also foreseen. In particular, maintenance planning of a tram system device (e.g., a tram), trolley-bus system device (e.g., a trolley bus) shall be included, as well, and be covered by the appended claims.

Furthermore, the present disclosure also relates to a method or device or computer program product for maintenance planning of other vehicles, in particular a bus or industrial vehicles, such as logistics machinery (e.g., a truck, a forklift), construction machinery (e.g., cranes, diggers, cement mixers), agricultural machinery (e.g., tractors, harvesters), or mining machinery, is foreseen. Additionally, maintenance planning of other types of vehicles, including boats, can be included. Such applications are herewith disclosed, and they can profit from the embodiments disclosed herein in the context of rail traffic systems.

The herein described disclosure will be more fully understood from the detailed description given herein below and the accompanying drawings which should not be considered limiting to the invention described in the appended claims. The drawings in which:.

<FIG> shows a block diagram illustrating schematically a rail system maintenance planning device <NUM> for maintenance planning of a rail system device. The rail system maintenance planning device <NUM> comprises an electronic circuit, including a processor <NUM>, a memory <NUM>, and a communication interface <NUM>. Depending on the embodiment, the rail system maintenance planning device <NUM> can have a human-machine interface (HMI), comprising output means and/or input means. The output means can comprise a display (touch or non-touch) and/or a loudspeaker. The input means can comprise a touch interface, keyboard, mouse, pen, etc. The rail system maintenance planning device <NUM> can be embodied as a laptop computer, a desktop computer, a server computer, and/or a computer system comprising several connected computers. In an embodiment, the rail system maintenance planning device <NUM> is connected to a cloud-based computing system <NUM> which provides computing resources, including processing and storage capabilities, to the rail system maintenance planning device <NUM>. In an embodiment, the rail system maintenance planning device <NUM> is itself implemented on a cloud-based computing system.

The person skilled in the art is aware that some or all of the functionality described in relation to the rail system maintenance planning device <NUM> can be, depending on the embodiment, provided by the cloud-based computing system <NUM>. The cloud-based computing system <NUM> is particularly well suited for providing a large memory for storing data, for example in a database.

The processor <NUM> comprises a central processing unit (CPU) for executing computer program code stored in the memory. The processor <NUM>, in an example, can include more specific processing units such as application specific integrated circuits (ASICs), reprogrammable processing units such as field programmable gate arrays (FPGAs), or processing units specifically configured to accelerate certain applications. The memory <NUM> can comprise one or more volatile (transitory) and or non-volatile (non-transitory) storage components. The storage components can be removable and/or non-removable, and can also be integrated, in whole or in part with the rail system maintenance planning device <NUM>. Examples of storage components include RAM (Random Access Memory), flash memory, hard disks, data memory, and/or other data stores. Depending on the embodiment, the memory <NUM> comprises a database, which database may be implemented locally on the rail system maintenance planning device <NUM> itself or remotely, for example on the cloud-based computer system <NUM>. The memory <NUM> has stored thereon computer program code configured to control the processor <NUM> of the rail system maintenance planning device <NUM>, such that the rail system maintenance planning device <NUM>, performs one or more method steps and/or functions as described herein. Depending on the embodiment, the computer program code is compiled or non-compiled program logic and/or machine code. As such, the rail system maintenance planning device <NUM> is configured to perform one or more method steps and/or functions. The computer program code defines and/or is part of a discrete software application. One skilled in the art will understand, that the computer program code can also be distributed across a plurality of software applications, which software applications can be distributed and executed on a plurality of devices which together form the rail system maintenance planning device <NUM>. The software application is installed in the rail system maintenance planning device <NUM>. Alternatively, the computer program code can also be retrieved and executed by the rail system maintenance planning device <NUM> on demand. In an embodiment, the computer program code further provides interfaces, such as APIs (Application Programming Interfaces), such that functionality and/or data of the rail system maintenance planning device <NUM> can be accessed remotely, such as via a client application or via a web browser. In an embodiment, the computer program code is configured such that one or more method steps and/or functions are not performed in the rail system maintenance planning device <NUM>, but in an external computing system or computing device, for example a mobile phone, and/or a remote server at a different location to the computer <NUM>, such as in the cloud-based computing system <NUM>.

The various components of the rail system maintenance planning device <NUM> are interconnected using connection lines. The term connection line relates to means which facilitate power transmission and/or data communication between two or more modules, devices, systems, sub-systems, or other entities. A given connection line can comprise a wired connection, for example using a cable or system bus, or comprise a wireless connection using direct or indirect wireless transmissions.

Furthermore, the rail system maintenance planning device <NUM> is connected to one or more networks, including local networks such as a local area network, and other networks, such as the Internet, using a communication interface <NUM>. The communication interface <NUM> is configured to facilitate wired and/or wireless data transmission between the rail system maintenance planning device <NUM> and one or more further devices and/or computer systems, in particular the cloud-based computing system <NUM>, either directly or via an intermediary network. In particular, the communication interface <NUM> is configured to receive a fault report message.

<FIG> shows a flow diagram illustrating an exemplary sequence of steps for maintenance planning of a rail system device. The steps are described as being performed by the processor <NUM> of the rail system maintenance planning device <NUM>, however at least some of the steps can be carried out on other devices, for example the cloud-based computing system <NUM>.

In a step S1, a fault report message is received in the processor <NUM> via the communication interface <NUM>. The fault report message relates to a malfunctioning rail system device (examples of such rail system devices are described with reference to <FIG>).

In an embodiment, the fault report message comprises a human-written text describing a fault of the rail system device. The fault report message, in particular the human-written text, or recorded human speech, is preferably entered into a mobile communication device used by the railway technician and transmitted by the mobile communication device to the rail system maintenance planning device <NUM>.

In an example, a railway technician, noting that a door of a train car does not open anymore, submits a fault report message indicating that the door does not close properly. In another example, a railway technician, noting that the sliding door step does not retract fully anymore, submits a fault report message indicating that the sliding door step does not retract fully anymore. Additionally, the railway technician may note suspected causes of the malfunction and/or efforts to remedy the malfunction, for example by noting that the sliding door step was jammed by a rock and noting that the rock was successfully removed.

In an embodiment, the fault report message is generated by a monitoring system configured to monitor the rail system device. The monitoring system transmits the fault report message to the rail system maintenance planning device <NUM>.

The fault report message may further comprise information identifying the particular rail system device (e.g., an identifier of the door and/or the particular train car), circumstances relating to the malfunction, conjectures about causes of the malfunction, and/or indications that the malfunction has been fixed. Additionally, the fault report message can comprise a time-stamp and/or location information related to the timepoint and/or the geographic location, respectively, when the fault report message was created.

In a step S2, the processor <NUM> analyzes the fault report message. The fault report message is analyzed using natural language processing. Natural language processing comprises, for example, morphological analysis, syntactic analysis, relational semantics, and lexical semantics. In particular, Named Entity Recognition is used to identify the rail system device, a super-system comprising the rail system device, and/or components of the rail system device. The natural language processing is implemented, for example, as a recurrent neural network (RNN) configured to take as an input the fault report message.

The fault report message is analyzed and results in an analyzed fault report message. The analyzed fault report message comprises an output of the natural language processing (e.g., an output of the neural network), and may take a number of forms, including a list of keywords extracted from the fault report message, an identified rail system device, etc. Depending on the embodiment, the analyzed fault report message comprises vectors, matrices, or other data types not directly relating to text.

Step S2 may be adapted or be integrated in Step S1, in some embodiments, in particular when the fault report message is generated automatically by the monitoring system and not by the railway technician and is thus present in an already analyzed form. This variant shall be covered by the appended claims.

In a step S3, the processor <NUM> maps the analyzed fault report message to a particular failure mode type <NUM> of a plurality of failure mode types <NUM> associated with the rail system device. The particular failure mode type <NUM> identifies at least one probable cause of malfunction of the rail system device. For example, the failure mode type <NUM> related to the malfunction of a door of a train car can be that a door sensor, which senses whether or not the door is closed, has malfunctioned. In another example, the failure mode type <NUM> may relate to the presence of a rock interfering with the retraction of the sliding door step.

The mapping S3 can take place, for example, by using a distance function to generate a distance between the analyzed fault report message and each of the plurality of failure mode types <NUM>, and then to identify a closest failure mode type <NUM>. The distance function may generate the distance in a number of ways, for example by considering a number of matching keywords (or abstractions thereof) between the analyzed fault report message and one or more keywords associated with the failure mode type <NUM>.

In an embodiment, the mapping S3 is performed in a more abstract manner, wherein the analyzed fault report message is represented as a vector in a vector space and compared with a plurality of failure mode type vectors each associated with a particular failure mode type <NUM>, selecting the failure mode type <NUM> having a most similar vector. In this embodiment, similarity may be expressed by providing scalar products of normalized vectors, and the most similar vector can be identified as the one having the largest scalar product with a given failure mode type vector.

In an embodiment, mapping S3 the analyzed fault report message to one of a plurality of failure mode types <NUM> uses a statistical topic model trained using a topic model training dataset and machine learning (e.g., unsupervised machine learning), wherein the topic model training dataset comprises a plurality of historical fault report messages. The machine learning technique uses, for example, latent dirichlet allocation (LDA). The topic model training dataset can also comprise external data sources as explained herein. The statistical topic model training can further comprise preprocessing the topic model training dataset, in particular by cleaning the data and vectorising the data in order to filter common and/or rare words.

In a step S4, the processor <NUM> is configured to determine a failure effect <NUM> associated with the particular failure mode type <NUM>, using the particular failure mode type <NUM>. The failure effect <NUM> identifies one or more operational consequences of the particular failure mode type <NUM>. For example, an operational consequence of the door failing to open is that passengers can no longer enter or exit the train car using that particular door, and that longer allowances must be made for passengers to enter and/or exit the train during stops. In another example, an operational consequence of the sliding door step failing to retract fully may be relatively minor, and depending on whether the railway technician was able to remedy the malfunction, there may be no immediate operational consequences. The operational consequences, in case of more severe malfunction of a critical rail system device, may result in the rail system device having to undergo immediate maintenance (e.g., repair or replacement).

Determining the failure effect <NUM> may further comprise using the analyzed fault report message. In particular, the analyzed fault report message may comprise an indication as to whether the malfunction was able to be fixed.

In a step S5, the processor <NUM> determines a time and/or a distance until maintenance of the rail system device. The time and/or distance until maintenance can be determined using the failure effect determined in step S4, and can also be determined using the failure report message and/or the failure mode type <NUM>. More severe failure effects typically result in a shorter time and/or distance until maintenance. For example, a train car door that does not close has the failure effect of (relating to the operational consequence of the train door not closing) that the train cannot continue its course until the malfunctioning train car door has been fixed, or at least closed and locked such as to ensure passenger safety. Therefore, immediate maintenance is necessary and the time and/or distance until maintenance indicate this. If the failure effect is very minor, or if the malfunction of the rail system device has already been remedied by the railway technician, then the time and/or distance until maintenance reflect this, for example by indicating a time and/or distance until a regular, previously scheduled maintenance, when the fix of the railway technician can be inspected. In another example, for example relating to a malfunctioning toilet, the time and/or distance until maintenance may be determined to reflect the end of an operational shift or an otherwise previously scheduled maintenance.

<FIG> shows a flow diagram illustrating an exemplary sequence of steps for carrying out the invention, steps S1 to S5 having been described above with reference to <FIG>. In a step S6, the processor <NUM> generates a maintenance planning message indicating the time and/or distance until maintenance. The maintenance planning message is preferably transmitted, using the communication interface <NUM>, to a maintenance scheduling system, in particular a maintenance scheduling database.

The maintenance planning message further comprises, depending on the embodiment, an identifier of the rail system device, the fault report message, the failure effect, and/or maintenance measures indicating how the malfunction of the rail system device is to be remedied. For example, the maintenance measures indicate replacement parts, maintenance procedures, equipment, and/or technical expertise required to perform the maintenance of the rail system device.

The maintenance measures can further indicate a time required to perform the maintenance. The maintenance measures thereby indicate precisely how the maintenance is to be undertaken for the rail system device, greatly increasing the efficiency of maintenance.

In a step S7, maintenance is performed according to the maintenance measures. In particular, maintenance is performed on the malfunctioning rail system device at a maintenance facility <NUM> (described in more detail with reference to <FIG>), according to the maintenance measures received as part of the maintenance planning message.

<FIG> shows a block diagram illustrating a failure-mode-and-effects (FME) model <NUM>. The FME model <NUM> is a computerized model implemented on the rail system maintenance device <NUM>. The FME model <NUM> can alternatively be implemented on the cloud-based server computer <NUM>, with appropriate requests and responses between the rail system maintenance device <NUM> and the cloud-based server computer <NUM> facilitating use of the FME model for the rail system maintenance device. The FME model <NUM> can be implemented, for example, as one or more databases.

The FME model <NUM> associates, for a plurality of different rail system devices, failure mode types <NUM> with failure effects <NUM> associated with each particular rail system device. A given failure mode type <NUM> of a particular rail system device may be associated with one or more failure effects <NUM>. As explained above, the failure mode type <NUM> relates to a cause of malfunction of the rail system device and the failure effect <NUM> relates to an operational consequence of the malfunction of the rail system device.

The FME model <NUM> can be established in a number of ways, for example using failure mode and effects analysis (FMEA).

In an embodiment, the FME model <NUM> further comprises a plurality of maintenance measures associated with the failure mode types <NUM> and the failure effects <NUM>. In particular, each maintenance measure is associated with one or more failure mode types <NUM> and/or one or more failure effects <NUM>.

<FIG> shows a flow diagram illustrating schematically how the FME model <NUM> is established, according to an embodiment of the invention. The FME model is established using a historical dataset <NUM> of failure mode types <NUM> and failure effects <NUM>. Depending on the embodiment, the historical dataset <NUM> was compiled on the basis of a FMEA, in which a group of technical experts recorded, for a plurality of rail system devices, a number of failure mode types <NUM> and therewith associated failure effects <NUM>. In an embodiment, at least some parts of the historical dataset <NUM> of the failure mode types <NUM> of the historical dataset <NUM> are established using an automated process.

In an embodiment, the statistical topic model, as described herein, is used to establish at least part of the historical dataset <NUM>. The topic model takes as an input a large number of historical fault report messages and, using machine learning (e.g., unsupervised learning), groups these historical fault report messages into a plurality of groups, each with a common failure mode type <NUM>. The topic model therefore automatically provides the failure mode types <NUM> of a particular rail system device, taking as an input only historical fault report messages associated with that particular rail system device. Further, the topic model can additionally assign each historical fault report message to a particular rail system device, such that an explicit identification of the rail system device in the historical fault report messages is not necessary to successfully employ the topic model. Additionally, depending on the embodiment, the topic model further establishes failure effects <NUM> by extracting, from the historical fault report messages or additional informational sources, failure effects <NUM> associated with each fault report message.

In addition to the historical dataset <NUM>, the FME model <NUM> is also established by extracting (e.g., by using a data source crawler) technical device information <NUM> related to rail system devices from external sources. These external sources comprise scientific literature, patent publication, and/or technical manuals. In particular, failure mode types <NUM> and failure effects <NUM> are determined from these external sources (for further details, see the description with reference to <FIG> herein).

In an embodiment, the maintenance measures associated with the failure mode types <NUM> and/or failure effects <NUM> are also determined during establishing of the FME model <NUM>. As described for the establishment of failure mode types <NUM> and failure effects <NUM> herein, the maintenance measures can be compiled by a group of experts, historical fault report messages and/or external data sources. As described above, the FME model <NUM> can thereby make use of natural language processing and extracting maintenance measures by the use of a statistical topic model.

After establishing the FME model <NUM>, the model is implemented as described herein, in particular such that the processor <NUM> uses the FME model <NUM> for maintenance planning of the rail system device.

In an embodiment, the FME model <NUM> aggregates incoming fault report messages. Thereby, failure mode types are linked to a specific rail system device. Depending on the frequency and nature of particular failure mode types <NUM> relating to the specific rail system, further steps may be taken. These steps include, for example, the revision or replacement of the specific rail system device or a component thereof, with another specific rail system device of the same or similar functionality. In particular, the replacement rail system device is configured such that the particular failure mode types <NUM> occur less frequently. In this manner, prescriptive solutions can be identified.

<FIG> shows a flow diagram illustrating an exemplary sequence of steps for determining failure mode types <NUM> and failure effects <NUM> of rail system devices from external sources.

In a step S20, technical device information is aggregated from a plurality of sources, including scientific literature, patent publication, and/or technical manuals.

In a step S21, functional and/or structural elements of the rail system device are extracted from the external sources and analyzed to determine, in a step S22, one or more failure mode types <NUM> and one or more failure effects <NUM> of the rail system device. Extracting the functional elements and/or structural elements from the external sources can comprise using natural language processing, in particular classification, Named Entity Recognition (NER), and/or semantic association. The natural language processing can further comprise using a machine reading comprehension model including span extraction and free-answering.

The individual functional and/or structural components of the rail system device can each have associated failure mode types <NUM> and one or more failure effects <NUM>. Further, if the functional and/or structural components can be arranged in a hierarchical model, the failure mode types <NUM> and the one or more therewith associated failure effects <NUM> can also be arranged in an analogous hierarchical model.

<FIG> shows a block diagram illustrating schematically a maintenance facility <NUM> for performing maintenance of the rail system device, in particular according to maintenance measures as indicated in a received maintenance planning message. The maintenance facility <NUM> comprises a workshop <NUM>, the workshop <NUM> having means for maintaining the rail system device. The workshop <NUM> may further comprise an inventory of replacement parts for replacing the rail system device or parts thereof. The maintenance facility <NUM> further comprises a computing device <NUM> having a display <NUM>. The computing device <NUM> can be, for example, a smart phone, laptop computer, or tablet computer. The maintenance facility <NUM> can further comprise an RFID reader configured to read an RFID tag attached to the rail system device.

<FIG> shows a flow diagram illustrating an exemplary sequence of method steps for maintenance of the rail system device.

In a step S30, the computing device <NUM> receives, from the rail system maintenance planning device <NUM>, a maintenance request comprising the maintenance planning message. The maintenance planning message includes maintenance measures.

In a step S31, the maintenance request is displayed on the display <NUM> of the computing device <NUM>. A service technician then performs maintenance of the rail system device according to the maintenance measures.

In a step S32, the maintenance is performed and a maintenance confirmation message is transmitted, from the computing device <NUM> to the rail system device.

<FIG> show block diagrams illustrating schematically examples of different types of rail system devices, in particular rolling stock devices and infrastructure devices. The rolling stock devices including electrical locomotives and train cars, and the infrastructure devices include the rail track system (e.g., railway track and railroad switches) and the power electrical systems (e.g., a traction substation and an overhead electrical line).

As depicted in <FIG>, the electrical locomotive comprises a pantograph, a transformer, traction power control, an electrical motor, and a wheel. An auxiliary power system powers auxiliary systems including a battery, lights HVAC, and a compressor. These auxiliary systems can be connected to further train cars attached to the electrical locomotive.

Claim 1:
A method for maintenance planning of a rail system device, in particular a rolling stock device or a railway infrastructure device, the method comprising:
receiving (S1), in a processor (<NUM>), a fault report message relating to a malfunctioning rail system device;
analyzing (S2), in the processor (<NUM>), the fault report message using natural language processing;
mapping (S3), in the processor (<NUM>), the analyzed fault report message to a particular failure mode type (<NUM>) of a plurality of failure mode types (<NUM>) associated with the rail system device, the particular failure mode type (<NUM>) identifying at least one probable cause of malfunction of the rail system device related to the fault report message;
determining (S4), in the processor (<NUM>), using the particular failure mode type (<NUM>), a failure effect (<NUM>) associated with the particular failure mode type (<NUM>), wherein the failure effect (<NUM>) identifies one or more operational consequences of the particular failure mode type (<NUM>); and
determining (S5), in the processor (<NUM>), one or more of: a time or a distance until maintenance of the rail system device, using the failure effect (<NUM>).