Predictive modelling

Systems, methods, and non-transitory computer-readable media can be configured to perform receiving a notification of a maintenance event associated with a resource. The method includes retrieving historic maintenance data in relation to the resource with which the fault is associated, the maintenance information originating from a time period preceding the time of the maintenance event. The method includes identifying at least a portion of the retrieved historic maintenance data as being indicative of the maintenance event. The method also includes causing the portion of the retrieved historic maintenance data identified as being indicative of the maintenance event to be stored as a precursor signal of the maintenance event. The method also includes causing future maintenance data received from a plurality of resources related to the resource with which the maintenance event is associated to be monitored to predict a future occurrence of the maintenance event in the plurality of resources.

FIELD OF THE INVENTION

The present technology relates to a method and systems for predicting maintenance events with respect to resources.

BACKGROUND

Machines are increasingly being fitted with sensors to record and control the functions of the machine and subsystems of the machine. For example, a diesel engine for construction machinery such as, for example, a bulldozer, digger and so forth may include sensors which measure, amongst other variables, injected fuel pressure, mass-flow of air into the engine, engine temperature, oxygen concentration in the outlet gases and so forth, to allow precise adjustments of the fuel/air mix. Similarly, a ship typically includes hundreds, thousands or tens of thousands of sensors measuring parameters such as speed, fuel temperature, stresses in the propeller shafts and so forth. Many ships are powered by marine diesel engines, liquefied natural gas (LNG) engines or combi-fuel engines which may be powered using diesel or LNG. Some ships may include gas-turbine engines. Regardless of the particular type of engine, ship engines similarly include large numbers of sensors for operational, monitoring and diagnostic purposes. Quantities of data relating to a machine or other resource may be obtained from data input by users who monitor the maintenance of the machine or other resource.

The information thus gathered can be used in a variety of contexts.

SUMMARY

According to some embodiments of the present specification there is provided a method of predicting maintenance events with respect to resources. The method is performed by one or more processors or special-purpose computing hardware. The method includes receiving a notification of a maintenance event associated with a resource. The method also includes retrieving historic maintenance data in relation to the resource with which the fault is associated, the maintenance information originating from a time period preceding the time of the maintenance event. The method also includes identifying at least a portion of the retrieved historic maintenance data as being indicative of the maintenance event. The method also includes causing the portion of the retrieved historic maintenance data identified as being indicative of the maintenance event to be stored as a precursor signal of the maintenance event. The method also includes causing future maintenance data received from a plurality of resources related to the resource with which the maintenance event is associated to be monitored to predict a future occurrence of the maintenance event in the plurality of resources.

The method may also include providing a database in which is stored historic maintenance data relating to a plurality of resources related to the resource with which the maintenance event is associated. The method may also include comparing the retrieved maintenance data of the resource with which the maintenance event is associated with the stored historic maintenance data of the related resources.

Comparing the retrieved maintenance data with the stored historic maintenance data of the related resources may include performing a dynamic time warping operation with data retrieved from one or more sensor logs.

The notification may contain an indication of a sub-system with which the maintenance event is associated.

Monitoring future maintenance data may include monitoring maintenance data from the sub-system with which the maintenance event is associated.

Monitoring future maintenance data may include monitoring maintenance data from a sub-system related to the sub-system with which the maintenance event is associated.

The maintenance data may be obtained from at least one of: sensor logs, fault logs, or maintenance logs.

Monitoring future maintenance data may include calculating a probability that a maintenance event will occur in a future time period.

Identifying at least a portion of the retrieved historic maintenance data as being indicative of the maintenance event may include identifying a cluster of warning messages associated with the maintenance event.

According to some embodiments of the present specification there is provided a computer program, optionally stored on a non-transitory computer readable medium program, including instructions that, when executed by a computing apparatus, cause the computing apparatus to perform the method of any preceding claim.

According to some embodiments of the present specification there is provided an apparatus for predicting maintenance events with respect to resources. The apparatus includes one or more processors or special-purpose computing hardware configured to receive a notification of a maintenance event associated with a resource. The apparatus is also configured to retrieve historic maintenance data in relation to the resource with which the fault is associated, the maintenance information originating from a time period preceding the time of the maintenance event. The apparatus is also configured to identify at least a portion of the retrieved historic maintenance data as being indicative of the maintenance event. The apparatus is also configured to cause the portion of the retrieved historic maintenance data identified as being indicative of the maintenance event to be stored as a precursor signal of the maintenance event. The apparatus is also configured to cause future maintenance data received from a plurality of resources related to the resource with which the maintenance event is associated to be monitored to predict a future occurrence of the maintenance event in the plurality of resources.

The apparatus may include a resource maintenance server in which is stored historic maintenance data relating to a plurality of resources related to the resource with which the maintenance event is associated. The apparatus may also be configured to compare the retrieved maintenance data of the resource with which the maintenance event is associated with the stored historic maintenance data of the related resources.

The apparatus may also be configured to compare the retrieved maintenance data with the stored historic maintenance data of the related resources by performing a dynamic time warping operation with data retrieved from one or more sensor logs.

The apparatus may also be configured to monitor future maintenance data by calculating a probability that a maintenance event will occur in a future time period.

The apparatus may be configured to identify at least a portion of the retrieved historic maintenance data as being indicative of the maintenance event by identifying a cluster of warning messages associated with the maintenance event.

DETAILED DESCRIPTION

Reference will now be made to certain examples which are illustrated in the accompanying drawings. Whenever possible, the same reference numbers will be used throughout the drawings to refer to the same or like parts.

Embodiments of the technology provide improved methods for predicting maintenance events in resources. Embodiments described herein relate to ships although it should be appreciated that the same principles may be applied to any complex machinery.

Embodiments allow a notification of a maintenance event, for example a fault, an anomaly or other maintenance event, experienced in relation to a first resource to trigger an analysis of the historic maintenance information of that resource. For example, a maintenance event may correspond to a fault such as a machine becoming inoperative. Thus, a maintenance event may correspond in some cases to the need to replace or service one or more parts of a machine. Alternatively, a maintenance event may correspond to unusual or anomalous behaviour such as, for example, measured parameters departing from operational tolerances, or a drop in machine efficiency such as increased power use and/or fuel consumption. A maintenance event may also encompass anomalous external events such as a collision, since some external events may be correlated to a current or developing fault in a machine. For example, a decrease in braking performance of a vehicle may increase the probability of a collision. Firstly, the historic maintenance information of the resource from a time period preceding the time of the maintenance event may be retrieved. This information is then analysed to identify precursor signals of the maintenance event. These precursor signals may then be used to predict maintenance events with respect to other related resources. An example of a related resource may be a ship of the same type as a first ship that experienced a maintenance event.

FIG. 1illustrates, in block diagram form, an exemplary data fusion system1for providing interactive data analysis, consistent with embodiments of the present disclosure. Among other things, data fusion system1facilitates analysis and transformation of one or more data sources2such as, for example, sensors19(FIG. 2), maintenance logs16(FIG. 2), fault logs17(FIG. 2), message logs21(FIG. 2) and so forth, into data models3. Data models3may include one or more object models4whose semantics are defined by an ontology5. Data models3may also include one or more risk models6for calculating a failure probability or risk score for a machine15, or a sub-system18of the machine, during a particular interval. Risk models6may be machine learning models or weighted average models generated in dependence upon data accessed from the data sources2. Alternatively, risk models6may be based on other metrics such as, for example, determining that one or more measured parameters of a machine diverge from corresponding expected values by more than a threshold amount. Divergence from expected values may be transitory, and in some cases a risk model6may keep track of the number of times which a measured parameter exceeds the expected tolerances within a certain period of time. The transformation can be performed for a variety of reasons. For example, an engineer or mechanic may import data from data sources2into a database7for persistently storing object model(s)4. As another example, an engineer or mechanic may import data from data sources2in order to define, refine or apply a risk model6. As another example, a data presentation component can transform input data from data sources2“on the fly” (in substantially real time, as the data is generated) into object model(s)4. The object model(s)4can then be utilized, in conjunction with ontology5, for analysis through graphs and/or other data visualization techniques. Data from data sources2may take the form of numerical data, text information in defined or free-text formats, or a combination of numerical, textual and/or other data types. Data from data sources2may be analysed to extract metrics in the process of transforming the data into object models4and/or risk models6.

Data fusion system1includes a definition component8and a translation component9, both implemented by one or more processors of one or more computing devices or systems executing hardware and/or software-based logic for providing various functionality and features of the present disclosure, as described herein. The data fusion system1can comprise fewer or additional components that provide the various functionalities and features described herein. Moreover, the number and arrangement of the components of data fusion system1which are responsible for providing the various functionalities and features described herein can further vary between different examples of the data fusion system1.

The definition component8generates and/or modifies the ontology5and a schema map10. Examples of defining an ontology (such as ontology5) are described in U.S. Pat. No. 7,962,495 (the '495 patent), issued on Jun. 14, 2011, the entire contents of which are expressly incorporated herein by reference for all purposes. Consistent with certain examples disclosed in the '495 patent, a dynamic ontology may be used to create a database, for example database7. To create a database ontology, one or more object types may be defined, where each object type includes one or more properties. The attributes of object types or property types of the ontology can be edited or modified at any time. At least one parser definition may be created for each property type. The attributes of a parser definition can be edited or modified at any time.

In some examples, each property type is declared to be representative of one or more object types. A property type is representative of an object type when the property type is intuitively associated with the object type. In some embodiments, each property type has one or more components and a base type. In some embodiments, a property type can comprise a string, a date, a number, or a composite type consisting of two or more string, date, or number elements. Thus, property types are extensible and can represent complex data structures. Further, a parser definition can reference a component of a complex property type as a unit or token.

An example of a property having multiple components is an “engine temperatures” property having an “exhaust temperature” component and an “inlet temperature” component. For example, the “inlet temperature” may correspond to the temperature of ambient air drawn into a diesel engine and the “exhaust temperature” may correspond to the temperature of exhaust gasses expelled from the diesel engine. An example of raw input data is “300 K”. An example parser definition specifies an association of imported input data to object property components as follows: {EXHAUST TEMPERATURE}, {INLET TEMPERATURE}→EngineTemperatures:ExhaustTemperature, EngineTemperatures:InletTemperature. In some embodiments, the association {EXHAUST TEMPERATURE}, {INLET TEMPERATURE} is defined in a parser definition using regular expression symbology. The association {EXHAUST TEMPERATURE}, {INLET TEMPERATURE} indicates that an exhaust temperature followed by an inlet temperature, and separated by a comma, comprises valid input data for a property of type “engine temperature”.

According to some embodiments, schema map10can define how various elements of schemas11for data sources2map to various elements of ontology5. Definition component8receives, calculates, extracts, or otherwise identifies schemas11for data sources2. Schemas11define the structure of data sources2; for example, the names and other characteristics of tables, files, columns, fields, properties, and so forth. Furthermore, definition component8optionally identifies sample data12from data sources2. Definition component8can further identify object type, relationship, and property definitions from ontology5, if any already exist. Definition component8can further identify pre-existing mappings from schema map10, if such mappings exist. Some data sources2may be substantially unstructured, for example, in the form of free-text which is analysed for keywords and/or using natural language processing. For substantially unstructured data sources, the schema map10may define how various elements of schemas11map to ontology5for processing free-text, for example parameters or semantic rules.

Based on the identified information, definition component8can generate a graphical user interface13. Graphical user interface13can be presented to users of a computing device via any suitable output mechanism (e.g., a display screen, an image projection, etc.), and can further accept input from users of the computing device via any suitable input mechanism (e.g., a keyboard, a mouse, a touch screen interface, etc.). Graphical user interface13features a visual workspace that visually depicts representations of the elements of ontology5for which mappings are defined in schema map10.

In some embodiments, transformation component9can be invoked after schema map10and ontology5have been defined or redefined. Transformation component9identifies schema map10and ontology5. Transformation component9further reads data sources2and identifies schemas11for data sources2. For each element of ontology5described in schema map10, transformation component9iterates through some or all of the data items of data sources2, generating elements of object model(s)4in the manner specified by schema map10. In some examples, the transformation component9may process data from data sources2to generate statistical or other metrics based on the data. The statistical or other metrics may be stored in the database7. In some examples, the transformation component9may generate one or more risk models6based on the data from data sources2. Risk models6generated by the transformation component9may be stored in the database7. In some examples, the transformation component9may apply risk models6to data from data sources2in order to calculate a failure probability or risk score for a machine within a specified interval. In some examples, transformation component9can store a representation of each generated element of an object model4in the database7. In some examples, transformation component9is further configured to synchronize changes in the object model(s)4back to data sources2.

Data sources2can be one or more sources of data, including, without limitation, spreadsheet files, databases, email folders, document collections, sensor memory storages, and so forth. Documents may include native electronic documents and scanned documents. Scanned documents may be processed using optical character recognition. Data sources2can include data structures stored persistently in non-volatile memory. Data sources2can additionally or alternatively include temporary data structures generated from underlying data sources via data extraction components, such as a result set returned from a database server executing a database query.

Schema map10, ontology5, and schemas11can be stored in any suitable structures, such as XML files, database tables, and so forth. In some embodiments, ontology5is maintained persistently. Schema map10can or cannot be maintained persistently, depending on whether the transformation process is perpetual, or a one-time event. Schemas11need not be maintained in persistent memory, but can be cached for optimization.

The object model(s)4comprise collections of elements such as typed objects, numerical data, properties, and relationships. The collections can be structured in any suitable manner. In some examples, a database7stores the elements of the object model(s)4, or representations thereof. In some examples, the elements of an object model4are stored within database7in a different underlying format, such as in a series of object, property, and relationship tables in a relational database. The risk models6comprise collections of elements such as, for example, weighting tables, decision trees, kernels, Bayesian graphs/networks, artificial neural networks or similar elements of a machine learning model.

According to some embodiments, the functionalities, techniques, and components described herein are implemented by one or more special-purpose computing devices. The special-purpose computing devices can be hard-wired to perform the techniques, or can include digital electronic devices such as one or more application-specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs) that are persistently programmed to perform the techniques, or can include one or more general purpose hardware processors (each including processor circuitry) programmed to perform the techniques pursuant to program instructions in firmware, memory, other storage, or a combination. Such special-purpose computing devices can also combine custom hard-wired logic, ASICs, or FPGAs with custom programming to accomplish the techniques. The special-purpose computing devices can be desktop computer systems, portable computer systems, handheld devices, networking devices, or any other device that incorporates hard-wired and/or program logic to implement the techniques.

In examples described herein, data fusion system1can allow a user, such as an engineer or mechanic, to analyse information and identify underlying trends, patterns, behaviours and/or precursors which allow the engineer or mechanic to make more informed decisions. Such information can allow an engineer or mechanic to determine the most effective maintenance to perform on a machine. Additionally, when a fault or anomaly has developed in a complex machine, an engineer or mechanic may use the data fusion system1to obtain information about a root cause of an anomaly or fault. Other applications of the data fusion system1shall be described hereinafter.

For purposes of illustration, examples are described herein with reference to ships, for example passenger cruise ships, cargo ships, tankers and so forth. However, the examples and techniques described herein may be applied to other types of machines such as, for example, construction machinery in the form of bulldozers, tractors, diggers, any other types of mobile equipment. The examples and techniques described herein may also be applied to further types of machines such as, for example, manufacturing plant, sewage treatment plant, tunnelling/boring equipment and so forth, within the spirit and scope of this disclosure.

FIG. 2shows a block diagram of a first exemplary system14for performing one or more operations for analysing and/or modelling a machine15. In the first system14, the machine15is a ship15aand the first system14can include one or more ships15a. The ships15amay be, for example, passenger cruise ships, car transporter ferries, cargo ships, tanker ships, tugs and so forth. Each ship15ahas a corresponding maintenance log16and fault log17. The maintenance log16for a ship15amay include information such as dates and locations of maintenance, details of replacement parts used, free text notes made by an engineer or mechanic performing a maintenance task and so forth. The fault log17for a ship15amay include information such as dates and locations of faults, the type of fault, the period of time required to rectify the fault and so forth. The maintenance logs16and fault logs17are stored in suitable computer readable formats or structures, such as XML files, database tables, and so forth. The maintenance log16and fault log17corresponding to a ship15amay be stored on one or more servers and/or locally on the ship15a. Maintenance logs16and fault logs17corresponding to a number of different ships15amay be stored in a common database, for example database7.

Each ship15aincludes a number of sub-systems18which may be mechanical systems, electrical systems, computer systems or combinations thereof. For example, sub-systems18for a ship15amay include, but are not limited to, a navigational computer system, a crew area and/or cargo area environmental control and monitoring systems, a fuel management system, engine management systems, a hydraulic system, a fire suppression system, a bilge system and so forth. Each sub-system18may include one or more sensors19which monitor physical parameters of the sub-system. One or more sensors19associated with a sub-system form a sensor group20. Examples of sensors19include a temperature sensor, a pressure sensor, a water level sensor, an electrical current or voltage sensor, a gas concentration sensor, a strain gauge, and so forth. Data from sensors19may be stored on the ship15aand subsequently transmitted or downloaded from the ship15aaccording to a schedule, for example upon arrival at a destination port, daily or weekly. Data from some sensors19may be transmitted to a central operations centre whilst the ship15ais at sea.

The ship15amay also store message logs21, crew logs22, bridge logs23, velocity logs24and global positioning system (GPS) (or other positioning system) logs25. The message log21corresponding to a ship15amay include messages generated by controllers (e.g. an automated bilge pump controller), processors or similar devices which are integrated into the various sub-systems18. The messages may include a date and time, an identifier of an originating sub-system18, and message contents such as, for example, a warning or fault identifier. Crew logs22corresponding to a ship15amay include forms, notes, checklists or other documents which are produced or confirmed by crew responsible for operating the ship15asuch as, for example, the captain, navigator, engineering crew and/or port crew. Crew logs22may include information derived from documents which are native electronic documents and/or scanned documents. Bridge logs23may include, for example, bridge audio recordings, logs detailing button presses, keystrokes and control inputs during a voyage and so forth. Velocity logs24may include a time series of velocities of the ship15a. GPS logs25may include a time series of GPS coordinates for the ship15a. Velocity logs and GPS logs are particular examples of sub-systems18and sensors19. Message logs21, crew logs22, bridge logs23, velocity logs24and global positioning system (GPS) logs25are stored in suitable computer readable formats or structures, such as XML files, database tables and so forth.

The first system14may also include manufacturer information26including, for example, databases providing information about messages and/or faults, suggested maintenance tasks, and manufacturer recommended tolerances for parameters measured by sensors19. The first system14may also include environmental data27such as, for example, information about wind speeds, surface waves, cloud cover, storm systems, currents, tide times as a function of date, time and location. The first system14may also include a route/task log28corresponding to each ship15a. The route/task log for a ship15amay include details of the start and end locations, dates and times of each voyage conducted by the corresponding ship15a. The first system14may also include schedules29for the voyages which a fleet including a number of ships15aneed to be assigned to travel over a forthcoming time period. The first system14may also include facilities information30such as, for example, a type or class of available maintenance and repair facilities at a number of ports between which ships15amay be scheduled to travel, for example, whether a port has maintenance and inspection divers, dry-dock facilities and so forth.

The manufacturer information26, environmental data27, route logs28, schedules29and facilities information30may be stored in suitable computer readable formats or structures, such as XML files, database tables, and so forth. The manufacturer information26, environmental data27, route logs28, schedules29and facilities information30may be stored in one or more servers.

The maintenance logs16, fault logs17, sensors19, message logs21, crew logs22, bridge logs23, altitude and velocity logs25, GPS logs25, manufacturer information26, environmental data27, route logs28, schedules29and facilities information30are examples of data sources2for the data fusion system1.

The first system14includes one or more analysis terminals31in the form of one or more computing devices (e.g., computer or computers, server or servers, etc.), memory storing data and/or software instructions (e.g., database or databases), memory devices, etc.), and other known computing components. In some examples, the one or more computing devices are configured to execute software or a set of programmable instructions stored on one or more memory devices to perform one or more operations, consistent with the examples herein. The data fusion system1may be provided by one or more analysis servers32and one or more analysis terminals31may connect to the analysis server32as clients. Alternatively, each analysis terminal31may provide an example of the data fusion system1. Examples of analysis terminals31may provide the same or different functions. For example, different analysis terminals31may be able to access different types of data or functions of the analysis server32. For example, a maintenance terminal33may be able to access preventative maintenance and troubleshooting functions. As another example, a scheduling terminal34may access data relating to risk model6outputs, schedules29and facilities information30to perform risk based scheduling of ship15aroutes. As another example, a manufacturer terminal35may be given access to a reduced or redacted selection of data from the data sources2, in order to allow monitoring and analysis of technical data whilst preserving the integrity of commercially sensitive information. In some examples, all analysis terminals31may access the same data and functions.

The analysis terminals31and analysis server32communicate with the data sources2over a network36. The network36can be any type of network or combination of networks configured to provide electronic communications between components of the first system14. For example, the network36can be any type of network (including infrastructure) that provides communications, exchanges information, and/or facilitates the exchange of information, such as the Internet, a Local Area Network, or other suitable connection(s) that enables the sending and receiving of information between the components of the first system14. The network36may also comprise any combination of wired and wireless networks. In other embodiments, one or more components of the first system14can communicate directly through a dedicated communication link or communication links, such as links between analysis terminals31, analysis server32, maintenance logs16, fault logs17, sensors19, message logs21, crew logs22, bridge logs23, velocity logs25, GPS logs25, manufacturer information26, environmental data27, route logs28, schedules29and facilities information30.

The first system14may include a number of machines15in the form of ships15a, and all of the ships15aforming part of the first system14are the same or comparable to one another. Two machines15are the same if they include the same components, arranged and configured in the same way. Two machines15may be the same if they are manufactured in the same batch or two machines15may be the same if they are manufactured in different batches. Two machines15which are the same include corresponding sub-systems18which are associated with corresponding sensors19. Two machines15are comparable if they contain one or more corresponding sub-systems18in common. For two comparable machines15, the corresponding common sub-systems18are not substantially interrelated to other sub-systems18which are not common to the machines15. For example, two ships15amay be comparable because they are fitted with the same marine diesel engine. Even when data from other systems is not comparable (or not directly comparable), information from engine sensors may be usefully compared between the two comparable ships15a.

Referring also toFIG. 3, a block diagram of an exemplary computer system37, consistent with examples of the present specification is shown. The components of the first and second exemplary systems14,67(FIG. 11) such as analysis terminals31and analysis server32may include an architecture based on or similar to that of computer system37.

Computer system37includes a bus38or other communication mechanism for communicating information, and a hardware processor39coupled with bus38for processing information. Hardware processor39can be, for example, a general purpose microprocessor. Hardware processor39comprises electrical circuitry.

Computer system37includes a main memory40, such as a random access memory (RAM) or other dynamic storage device, which is coupled to the bus38for storing information and instructions to be executed by processor39. The main memory40can also be used for storing temporary variables or other intermediate information during execution of instructions by the processor39. Such instructions, when stored in non-transitory storage media accessible to the processor39, render the computer system37into a special-purpose machine that is customized to perform the operations specified in the instructions.

Computer system37further includes a read only memory (ROM)41or other static storage device coupled to the bus38for storing static information and instructions for the processor39. A storage device42, such as a magnetic disk or optical disk, is provided and coupled to the bus38for storing information and instructions.

Computer system37can be coupled via the bus38to a display43, such as a cathode ray tube (CRT), liquid crystal display, or touch screen, for displaying information to a user. An input device44, including alphanumeric and other keys, is coupled to the bus38for communicating information and command selections to the processor39. Another type of user input device is cursor control45, for example using a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to the processor39and for controlling cursor movement on the display43. The input device typically has two degrees of freedom in two axes, a first axis (for example, x) and a second axis (for example, y), that allows the device to specify positions in a plane.

Computer system37can implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic which in combination with the computer system causes or programs computer system37to be a special-purpose machine. According to some embodiments, the operations, functionalities, and techniques disclosed herein are performed by computer system37in response to the processor39executing one or more sequences of one or more instructions contained in the main memory40. Such instructions can be read into the main memory40from another storage medium, such as storage device42. Execution of the sequences of instructions contained in main memory40causes the processor39to perform the process steps described herein. In alternative embodiments, hard-wired circuitry can be used in place of or in combination with software instructions.

Various forms of media can be involved in carrying one or more sequences of one or more instructions to processor39for execution. For example, the instructions can initially be carried on a magnetic disk or solid state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line or other transmission medium using a modem. A modem local to computer system37can receive the data on the telephone line or other transmission medium and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus38. Bus38carries the data to the main memory40, from which the processor39retrieves and executes the instructions. The instructions received by the main memory40can optionally be stored on the storage device42either before or after execution by the processor39.

Computer system37also includes a communication interface46coupled to the bus38. The communication interface46provides a two-way data communication coupling to a network link47that is connected to a local network48. For example, the communication interface46can be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, the communication interface46can be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links can also be implemented. In any such implementation, the communication interface46sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.

The network link47typically provides data communication through one or more networks to other data devices. For example, the network link47can provide a connection through the local network48to a host computer49or to data equipment operated by an Internet Service Provider (ISP)50. The ISP50in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet”51. The local network48and internet51both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on the network link47and through the communication interface46, which carry the digital data to and from the computer system37, are example forms of transmission media.

The computer system37can send messages and receive data, including program code, through the network(s), network link47and communication interface46. In the internet example, a server52, for example the analysis server32, can transmit data through the internet51, ISP50, local network48and communication interface46.

Referring also toFIG. 4, an example timeline for a machine15in the form of a ship15awill explained with reference to the corresponding message log21, maintenance log16, fault log17and a number of sensor logs53.

Each sensor log53(e.g.,53a,53b,53c) may include a time series of parameter values measured by one or more sensors19. The sensors19may include all of the sensors19on the ship15a, all the sensors19associated with one or more subsystems18, or any other combination of sensors19. A sensor log53may include parameter values measured by a single sensor19. Parameter values measured by one or more sensors19may be measured at equal intervals, or may be measured in response to triggering messages or events. Each sensor19may measure parameter values at a rate or interval specific to that sensor19, to a type of sensor19or to a sub-system18.

A first voyage commences at time t1and lasts until time t4. The duration of a voyage t4-t1may vary considerably depending upon the type of ship15a. In one example, the ship15amay be a passenger or vehicle ferry which carries out regular, scheduled voyages between a two or more relatively close ports/docks such as, for example, Dover and Calais, Dublin and Liverpool and so forth. In this example, the duration of a voyage t4-t1may range from less than hour up to several days. Scheduled slots for preventative maintenance may be every day, or every week. Scheduled preventative maintenance may be conducted in one or more of the ports, and it may not be necessary to conduct preventative maintenance during the actual voyage.

In other examples, the ship15amay be a long distance cargo ship or tanker, and the duration of a voyage t4-t1may be weeks or months. In this example, preventative maintenance during the voyage cannot be avoided in practice. When the ship15ais a long distance cargo ship or tanker, preventative maintenance may be split into regular maintenance conducted during voyages, and longer and/or more substantial maintenance slots between voyages. The range and type of maintenance tasks which may be conducted during a voyage may be restricted by the available facilities, consumables, spare parts, operational requirements and so forth.

In the example shown inFIG. 4, the ship15ais a passenger and/or vehicle ferry which performs regular crossings of a relatively narrow body of water, for example a voyage may take several hours. In the example shown inFIG. 4, regular maintenance is scheduled to occur between voyages. The corresponding parameter values measured by all or a subset of the sensors19during the first voyage are stored as a first sensor log53a. Alternatively, separate first sensor logs53amay be stored for each sub-system18or separate first sensor logs53amay be stored for each sensor19. During the first voyage, a first message object54ais generated by a sub-system18and stored in the message log21, along with the corresponding time t2and optionally other contextual information such as an identifying number for the voyage. A message object54(e.g.,54a,54b,54c,54d,54e,54f) may include a message identity (ID) code consisting of letters and/or numbers. The message ID code may correspond to an entry in a look-up table providing further details. For example, a message ID code may take the form A-M-001, in which the letter “A” denotes an origin of the corresponding message object54in a first, or “A”, sub-system18, the letter “M” denotes that the message ID code corresponds to a message and should be looked up in a message look-up table, and the numeric code “001” denotes a first entry corresponding to the first sub-system18in the message look-up table. The corresponding entry in the message look-up table provides details of the message. The look-up table may be included in the manufacturer information26, for example in a maintenance manual. Similarly, a message ID code of B-M-023 would identify a message object54originating in a second, or “B”, sub-system18and so forth.

A second message object54bis generated during the first voyage at time t3and stored in the message log21. Message object54contents may correspond to, for example, warnings and/or faults. Message object54contents may be determined by looking up message ID codes in a message look-up table. A message object54may correspond to the illumination of a warning light on the bridge, or illumination of a warning light elsewhere in or on the ship15a, for example in the engine room.

A second voyage starts at time t6and finishes at time t10, and corresponding sensor19measurements are stored in one or more second sensor logs53b, in the same way as the first sensor log(s)53a. Between the first and second voyages, at a time t5, a first maintenance task object55ais recorded in the maintenance log16for the ship15a. The first maintenance task object55ais one example of a maintenance event. The first maintenance task object55amay include information such as the time, t5, and a maintenance task identity (ID) code consisting of letters and/or numbers. The maintenance task ID code may correspond to an entry in a look-up table providing further details. For example, a maintenance task ID code may take the form A-T-003, in which the letter “A” denotes a maintenance task carried out on a first, or “A”, sub-system18, the letter “T” denotes that the maintenance task ID code corresponds to a maintenance task and should be looked up in a maintenance task look-up table, and the numeric code “003” denotes a third entry corresponding to the first sub-system18in the maintenance task look-up table. The corresponding entry in the maintenance task look-up table provides details of the maintenance task which is carried out. The look-up table may be included in the manufacturer information26. The first maintenance task object55amay include further information such as, for example, free-text notes or descriptions of the maintenance task performed, details of any parts replaced, information about the engineer or mechanic responsible for carrying out the maintenance task and so forth. The first maintenance task object55ais not occasioned by a fault, and corresponds to regular, or preventative, maintenance and/or maintenance to address an anomaly.

A third voyage is scheduled to start at a time t13. However, the start time of the third voyage is delayed until t17due to a fault object56which is registered at a time t11, shortly after the end of the second voyage at time t10. The fault object56may correspond to a fault which is discovered following, for example, inspection by the ship crew or port staff, analysis of the second sensor log53b, or the fault may have been indicated by third to fifth message objects54c,54d,54e, which were recorded in a cluster at times t7, t8and t9. The fault object56is recorded in the fault log17. The fault object56includes fault data57indicating the time corresponding to the fault object56, details about the type of fault, the location of the ship15awhen the fault was registered and so forth. The fault data57may also include a fault identity (ID) code consisting of letters and/or numbers. The fault ID code may correspond to an entry in a look-up table providing further details. For example, a fault ID code may take the form C-F-012, in which the letter “C” denotes a fault arising in a third, or “C”, sub-system18, the letter “F” denotes that the fault ID code corresponds to a fault type and should be looked up in a fault type look-up table, and the numeric code “012” denotes a twelfth entry corresponding to the third sub-system18in the fault type look-up table. The corresponding entry in the fault type look-up table provides details of the fault type which has occurred. The fault type look-up table may be included in the manufacturer information26.

Sometimes a fault corresponding to a fault object56may be readily rectified. On other occasions, the root cause of a fault corresponding to a fault object56in a ship15a, or a fault in another machine15, may be difficult to determine. Consequently, an engineer or mechanic may conduct one or more maintenance tasks which fail to resolve the fault. For example, both the second and third maintenance tasks objects55b,55c, started at times t12and t14respectively, both corresponding to maintenance tasks which failed to resolve the fault corresponding to the fault object56. The fourth maintenance task object55d, started at time t15, corresponds to a maintenance task which did resolve the fault corresponding to the fault object56. When the fault corresponding to the fault object56is verified to have been solved, fault resolution data58is added to the fault object56in the fault log17. The fault resolution data58is linked to the fault data57. The fault resolution data58may include information such as the end time of fault, for example t16, and the maintenance task object55dcorresponding to the maintenance task which resolved the fault corresponding to the fault object56. In some examples, the second, third and fourth maintenance task objects55b,55c,55dmay correspond to separate maintenance events. In other examples, the second, third and fourth maintenance task objects55b,55c,55dmay correspond to a single maintenance event.

Once the fault corresponding to the fault object56is resolved, the delayed third voyage starts at a time t17and ends at a time t19. A sixth message object54fis generated during the third voyage, at time t18, but the sixth message object54fdoes not indicate a new fault or a recurrence of the earlier fault corresponding to fault object56. Regular or preventative maintenance, in the form of a maintenance task detailed by a fifth maintenance task object55e, is conducted after the third voyage at a time t20.

It will be appreciated that the sequence of events described in relation toFIG. 4is for illustrative purposes only, and that the contents of the present specification may be applied to other sequences of events. For example, in the case of a ship15awhich a long distance cargo ship or tanker, voyages may last for weeks or even months, and so sensor logs53corresponding to the entire voyage may be inappropriate. Instead, sensor logs53for a ship15awhich a long distance cargo ship or tanker may be analysed according to shorter time periods, for example, daily, hourly or substantially in real time. Furthermore, in the case of a ship15awhich a long distance cargo ship or tanker, maintenance tasks55(e.g.,55a,55b,55c,55d,55e) corresponding to preventative maintenance and/or fault and/or anomaly resolution may also be conducted during a voyage.

Message logs21may be populated in real time, i.e. message objects54generated by a machine15such as a ship15amay be stored to a corresponding message log21at the same time, or shortly after, each message object54is generated. Maintenance logs16and fault logs17may be updated after the relevant events, for example, by filling in an electronic document or by scanning a paper document and so forth.

Referring also toFIG. 5, the values of some parameters measured by sensors19will vary with time, for example, over the course of a voyage when the machine15is a ship15aor throughout a working day of construction machinery15b(FIG. 11). The parameter values may be plotted against time as a parameter curve59. By aggregating a large number of sensor logs53corresponding to a number of different machines15and different operations, a mean value, a standard deviation, a minimum and a maximum value of a the parameter may be determined as a function of time. The averaged parameter values may be plotted against time as an average parameter curve60. Suitable statistical metrics may be calculated such as, for example, the mean and standard deviation of a difference between the parameter curve59and the average parameter curve60. Minimum and maximum differences may also be used as statistical metrics. The same approach may be used to determine statistical metrics based on a difference between first and second parameter curves stored in first and second sensor logs53. Average parameter curves60(and related average statistical metrics) may be updated to take account of new sensor logs53by re-calculating average parameter curves60(and related average statistical metrics) according to a schedule, for example, daily or weekly. Alternatively, if sensor logs53are extracted from the machines15at periodic intervals, then the average parameter curves60(and related average statistical metrics) may be re-calculated immediately after new sensor logs53have been extracted.

Parameter curves59need not be plotted against time. Instead, a parameter curve59corresponding to a first parameter measured by a first sensor19may be plotted against a second parameter measured by a second sensor19. Statistical metrics and average parameter curves60may be calculated in the same way. Analysing a pair of parameters can be useful in diagnosing a developing fault or issue. For example, in a normally functioning diesel engine, the stable operating temperature may vary with the revolutions per minute (RPM) according to a characteristic parameter curve, for example an average parameter curve59. If a parameter curve59significantly deviates from the average parameter curve60, for example, if the parameter curve59shows a faster than expected increase in temperature with RPM, this may indicate a developing fault in coolant levels or in a coolant system.

Referring also toFIG. 6, additional statistical metrics may be derived from the sensor logs53. For example, the number and duration of intervals during which the parameter curve59differs from the average parameter curve60by more than a threshold amount may be calculated and used as a metric. For example, the number and duration of intervals during which the parameter curve59lies below the 25thpercentile61or above the 75thpercentile62may be recorded. In the example shown inFIG. 6, the parameter curve59exceeds the 75thpercentile62for a first interval tb-taand dips below the 25thpercentile61for a second interval td-tc. A Schmidt trigger may be used, for example at the 75thand 80thpercentiles, to determine that the parameter curve59has exceeded a specified tolerance.

For machines15such as ships15aor construction machinery15b(FIG. 11), many parameters will vary with time, but the duration of different sensor logs53need not be the same because each sensor log53corresponds to a different operation of the same machine15or of a different machine15. This can prevent naïve aggregation of corresponding parameter values belonging to first and second sensor logs53a,53b. For example, one working day for construction machinery15b(FIG. 11) will vary dramatically from a subsequent working day because construction machinery15bmay be used to perform slightly different tasks and the duration and loading of each task may also vary from day to day. Sensors19recording parameters of a machine15may record datasets corresponding to two or more tasks or occasions which differ to the extent that direct comparison is difficult or meaningless. Such difficulties may be overcome by applying a dynamic time warping algorithm to the sensor logs53.

Referring also toFIGS. 7 and 8, first and second curves63a,63bof a first parameter are not directly comparable because they have differing lengths. The first and second curves63a,63bcorrespond to first and second sensor logs53a,53brespectively. However, a dynamic time warping algorithm may be used to distort the relative time-bases so that first and second warped curves64a,64bof the first parameter may be compared. The first parameter may be a parameter having a well understood meaning, such as velocity of a ship15a, or the velocity and/or engine revolutions per minute (RPM) of construction machinery15b(FIG. 11). Suitable first parameters may often correspond to the external state of a machine15, for example, to ambient conditions or to a task which the machine15is performing.

Referring also toFIGS. 9 and 10, first and second curves65a,65bof a second parameter may be less well understood or simply less suited to feature extraction. Such second parameters may relate more directly to the internal functioning or internal status of the machine15. For example, when the machine15is a ship15a, the second parameter may be a temperature of part of a gas turbine engine or a marine diesel engine. As another example, when the machine15is construction machinery15b(FIG. 11), the second parameter may be the pressure of a pneumatic or hydraulic actuation system. Parameters relating to the internal functioning or internal status of the machine15may have less predictable or less regular features, which can complicate or prevent the direct application of a dynamic time-warping algorithm, which may lead to erroneous outputs. This issue can be avoided by generating warped curves66a,66bof the second parameter based on a warped time-frame established using the curves63a,63bof the first parameter. For example, if the machine15is a ship15aor construction machinery15b, parameters such as engine temperatures may be warped using a time-frame warping established based on parameters such as velocity or engine RPM of the ship15aor construction machinery15b.

By using an initial parameter curve as a reference, a large number of sensor logs53corresponding to a large number of different machines15and operations may be warped, then aggregated to obtain a mean value, a standard deviation, a minimum and a maximum value of each parameter to be determined for the purpose of calculating statistical metrics. Similarly, a large number of sensor logs53corresponding to a large number of different machines15and operations may be warped, then aggregated to obtain warped average parameter curves.

Log metrics may be determined using the computer readable logs corresponding to each machine15. For example, when the machine15is a ship15a, metrics may be determined based on the maintenance log16, fault log17, message log21, crew log22and bridge log23corresponding to each ship15a, as well as any environmental data27, route logs28and so forth. For example, keyword searching may be used to establish frequencies of occurrence of particular words or phrases during one or more time intervals. Additionally or alternatively, when the message objects54include message ID codes, the maintenance task objects55include maintenance task ID codes and/or the fault objects56include fault ID codes, log metrics may be determined in the form of frequencies of occurrence of each message ID code, maintenance task ID code and/or fault ID code during one or more time intervals.

Additionally, ontology5may include semantic rules allowing natural language processing of computer readable logs, such as the maintenance logs16, fault logs17, message logs21, crew logs22, bridge logs23, environmental data27, route/task logs28and so forth. Natural language processing may enable determination of other log metrics.

It will be appreciated that many different examples of statistical metrics and metrics derived from computer readable logs may be used with the data fusion system1, depending on the data sources1which are used.

Referring also toFIG. 11, a block diagram of a second exemplary system67for performing one or more operations for analysing and/or modelling a machine15is shown. In the second system67, the machine15is construction machinery15band the second system67can include one or more construction machines15b. The second system67may be used to help managing a fleet of construction machines15bwhich are made available for leasing, or to manage all of the construction vehicles associated with a particular construction project. Construction machinery15bmay include be vehicles such as, for example, bulldozers, diggers, cranes, tractors, combine harvesters and so forth. Each construction machine15bhas a corresponding maintenance log16and fault log17. The maintenance log16for a construction machine15bmay include information such as dates and locations of maintenance, details of replacement parts, free text notes made by an engineer or mechanic performing a maintenance task and so forth. The fault log17for a construction machine15bmay include information such as dates and locations of faults, the type of fault, the period of time required to rectify the fault and so forth. The maintenance logs16and fault logs17are stored in suitable computer readable formats or structures, such as XML files, database tables, and so forth. The maintenance log16and fault log17corresponding to a construction machine15bmay be stored on one or more servers and/or locally on the construction machine15bitself. Maintenance logs16and fault logs17corresponding to a number of different construction machines15bmay be stored in a common database, for example database7.

A construction machine15bincludes a number of sub-systems18which may be mechanical systems, electrical systems, computer systems or combinations thereof. Sub-systems18of a construction machine15bmay be controlled by one or more corresponding electronic control units68(ECUs), and the ECUs68of a construction machine15bare interconnected for communications by an on-board network69. Each sub-system18may include one or more sensors19which monitor corresponding physical parameters of the sub-system18. One or more sensors19associated with a sub-system18form a sensor group20. Examples of sensors19include a temperature sensor, a pressure sensor, an electrical current or voltage sensor, a gas concentration sensor, a strain gauge, and so forth. Data from sensors19may be stored on the construction machine15band subsequently transmitted or downloaded from the construction machine15baccording to a schedule, for example, upon arrival to a designated “home” location, daily or weekly. Data from some sensors19may be transmitted to a server via wireless networks operating at a storage location or operational location of a construction machine15b. Data from some sensors19may be transmitted to a server via cellular networks during operation of a construction machine15b. Sub-systems18connected via the on-board network69typically generate message objects54according to protocols which may be proprietary or standardised protocols. Information from a construction machine15bmay be extracted via a wireless connection or using a physical data port provided on the construction machine15b.

Many construction machines15binclude a diesel engine70, which may include a large number of sensors19for use in regular operation, self-diagnostics, maintenance and/or repair. For example, a construction machine15bdiesel engine70may include, amongst other sensors19, a coolant temperature sensor71, an intake air sensor72, one or more oxygen sensors73to monitor combustion efficiency, a fuel rail pressure sensor74, an intake manifold gas pressure sensor75, and engine RPM sensor76, one or more valve timing sensors77, a mass airflow sensor78and so forth.

Construction machines15bmay include an evaporative emissions control system79(EVAP system) including a vapour pressure sensor80. Some construction machines15bmay include a traction control system81including wheel rotation speed sensors82. Some construction machines15bmay include a hydraulic or pneumatic actuation system83including system pressure sensors84, valve status sensors, load sensors and so forth, for controlling and monitoring actuation of tools such as a bull dozer scoop. Construction machines15bmay include a power assist steering system85including steering wheel position sensors86and steering column torque sensors87. Construction machines15bmay include an exhaust system88including, for example, one or more oxygen concentration sensors73and one or more catalyst bed temperature sensors89. Construction machines15bmay include exterior sensing systems90including sensors19such as, for example, ambient temperature sensors91and ambient barometric pressure92for determining the environmental conditions in which the construction machine15bis operating.

The construction machine15bmay also store message logs21and global positioning system (GPS) (or other positioning system) logs25. The message log21corresponding to a construction machine15bmay include message objects54generated by the ECUs68, for example, according to OBD protocols. The message objects54may include a date and time, an identifier of an originating sub-system18, and message contents such as, for example, a warning or fault identifier. Message logs21and global positioning system (GPS) logs25are stored in suitable computer readable formats or structures, such as XML files, database tables and so forth.

The second system67may also include manufacturer information26including, for example, databases providing information about messages and/or faults, suggested maintenance tasks, and manufacturer recommended tolerances for parameters measured by sensors19. The second system67may also include environmental data27such as ambient temperatures, humidity and so forth, as a function of date, time and location. Such information may be relevant to predicting failure of construction machines15bin a variety of ways. For example, a degraded battery system may not become evident to a user until it fails to supply sufficient current for a starter motor in colder ambient conditions. The degradation of the battery system may be detectable in sufficient time to allow replacement, however, whether or not battery replacement is the most critical preventative maintenance task may depend on the expected ambient temperatures. The second system67may also include a route/job log28corresponding to each construction machine15b. The route/task log28for a construction machine15bmay include details of the start and end locations, routes travelled, dates and times of each journey, details of tasks assigned to the corresponding construction machine15band so forth. Route/task logs28may provide important contextual information for interpreting construction machine15bsensor19data, for example, route information may be matched to elevation data to account for variations in engine power output of a tractor driving up or down a field located on an incline. The second system67may also include schedules29for the tasks which a fleet including a number of construction machines15bneed to be assigned to perform over a forthcoming time period. The second system67may also include facilities information30such as, for example, a type or class of available facilities at each location where a fleet of construction machines15boperates or may operate. Examples of facilities information30may include locations of garages providing repair and/or re-fuelling, locations and availability of spare parts and/or geographical coverage and locations of breakdown recovery services.

The manufacturer information26, environmental data27, route/task logs28, schedules29and facilities information30may be stored in suitable computer readable formats or structures, such as XML, files, database tables, and so forth. The manufacturer information26, environmental data27, route logs28, schedules29and facilities information30may be stored in one or more servers.

The second system67includes one or more analysis terminals31in the form of one or more computing systems37.

The data fusion system1may be provided by one or more analysis servers32and one or more analysis terminals31may connect to the analysis server32as clients. Alternatively, each analysis terminal31may provide an example of the data fusion system1. Examples of analysis terminals31may provide the same or different functions. For example, different analysis terminals31may be able to access different types of data or functions of the analysis server32. For example, a scheduling terminal34may access data relating to risk model6outputs, schedules29and facilities information30to perform risk based scheduling of construction machine15btasks. As another example, a manufacturer terminal35may be given access to a reduced or redacted selection of data from the data sources2, in order to allow monitoring and analysis of technical data whilst preserving the integrity of commercially sensitive information. A user device94such as a smartphone or tablet computer operated by the construction machine operator may also provide an analysis terminal31to enable the operator to receive timely and convenient notification of developing problems. In some examples, all analysis terminals31may access the same data and functions.

The analysis terminals31and analysis server32of the second system67communicate with the data sources2over a network36in the same way as the first system14.

The second system14may include a number of machines15in the form of construction machines15b, and all of the construction machines15bforming part of the second exemplary system67are the same or comparable to one another.

The present specification is not limited to machines15in the form of ships15aor construction machines15b. The present specification is equally applicable to machines15in the form of any other type of vehicle such as, for example, trains and so forth.

The present specification is not limited to vehicular machines15, and may instead be applied to any type of machine15which includes sensors19. For example, the present specification may be applied to sewage treatment equipment such as a sewage treatment plant. Unscheduled stoppages of a sewage treatment plant can be very expensive in lost time. A sewage treatment plant is typically extremely complex and tracing and identifying the origin of a fault or anomaly can be difficult and time consuming. Therefore, the teachings of the present specification in relation to data driven identification of precursor signals indicative of a fault developing can provide advantages for a sewage treatment plant.

In a sewage treatment plant operating conditions are intended to be relatively stable. The embodiments of the present specification relating to dynamic time warping and incorporation of computer readable logs to provide contextual information can allow the present specification to be particularly useful for applications in which machines15are operated in variable conditions and/or for variable tasks. For example tunnel boring equipment is complex machinery which is operated in a range of different environments and under a range of mechanical loadings. Each location for tunnel boring will have a different geological constitution, so that loading of a boring bit will vary with depth and distance of the bore hole in a different way at each boring location. Additionally, boring locations can be remote, so that obtaining spare parts may take a long time in the event of an unanticipated failure. Therefore, the teachings of the present specification in relation to data driven identification of precursor signals indicative of a fault developing can provide advantages for tunnel boring equipment.

Predictive Modelling System

FIG. 13is a schematic block diagram of a system500for analysing historic maintenance data to predict future maintenance events such as, for example a fault, an anomaly or other maintenance event. A maintenance event may correspond to a fault, for example that a machine has become inoperative. Thus, a maintenance event may correspond in some cases to the need to replace or service one or more parts of a machine. Alternatively, a maintenance event may correspond to unusual or anomalous behaviour such as, for example, measured parameters departing from operational tolerances, a drop in machine efficiency such as increased power or fuel consumption. A maintenance event may also encompass anomalous external events such as a collision, since some external events may be correlated to a current or developing fault in a machine. For example, a decrease in braking performance of a vehicle may increase the probability of a collision. The system500may be considered a special case of the generic systems shown inFIGS. 1 and 2.

The system500comprises a maintenance terminal33having an analysis module501. The maintenance terminal33is configured to retrieve historic maintenance data relating to a resource, for example a machine15that has experienced a maintenance event. The maintenance terminal33can also retrieve historic maintenance data of other related resources, such as ships15aor construction machines15bof the same type. The historic maintenance data may include data drawn from one of more of the maintenance logs16, fault logs17, sensors19, message logs21, crew logs22, bridge logs23, velocity logs25, GPS logs25, manufacturer information26, environmental data27, route logs28, schedules29, facilities information30and so forth.

The system500comprises a resource maintenance server502. The resource maintenance server502maintains maintenance records503for each resource in the multiple resource environment, for example for each ship15aof the same type. The maintenance records503contain maintenance data. The maintenance data for each resource may be data obtained from one or more of sensor logs53, maintenance logs16or fault logs17for that resource. The maintenance terminal33communicates with the resource maintenance server502via network36.

The system500comprises a resource terminal504. The resource terminal504is associated with the resource that has experienced the maintenance event. The resource terminal504may be an analysis terminal31. The resource terminal504may be integrated within the resource itself, for example integrated within machine15. Alternatively, the resource terminal504may be a separate computer which receives a user input indicating that the resource, such as a ship15aor construction machine15bhas experienced a maintenance event. The maintenance terminal33communicates with the resource terminal504via network36.

The system500comprises a manufacturer terminal35. The maintenance terminal33communicates with the manufacturer terminal35via network36. The manufacturer terminal35may receive the results of the analysis carried out at the maintenance terminal33. The manufacturer terminal35is associated with a manufacturer of the resource and other related resources (i.e. machines15). It may be advantageous for the manufacturer to be alerted to precursor signals indicative of maintenance events in the event that future precursor signals occur during the manufacturing process before the resource is despatched.

The system500may comprise a reference database505located at a remote server. The reference database505may contain any ancillary data that may be useful to the maintenance terminal33as the analysis is performed. For example, the reference database505may contain information instructing the maintenance terminal33to perform specific investigations in response to receiving notifications of a specific type of maintenance event. The maintenance terminal33communicates with the reference database505via network36.

FIG. 14is a flow chart illustrating a process520for predicting maintenance events with respect to resources, for example ships15a, construction machinery15bor other machines15. The process520shown inFIG. 12is carried out by one or more processors. In some embodiments, the processors are provided at a maintenance terminal33. While the steps have been described in a particular order, it should be understood that the steps may be performed in a different order that would be evident to the skilled person.

The process starts at step521. At step522, the maintenance terminal33receives a notification of a maintenance event such as a fault, anomaly or other maintenance event. The notification is received from the resource terminal504. The notification contains data indicating the nature of the maintenance event. Such data may include a resource identifier, an identifier of the sub-system with which the maintenance event is associated and a timestamp. For example, the notification may indicate that a ship15ahaving identifying number 0001 has experienced a maintenance event with respect to its rudder at 15:49 hours on 6 Aug. 2016. In general, the notification may include data drawn from one or more of the maintenance logs16, fault logs17, sensors19, message logs21, crew logs22, bridge logs23, velocity logs25, GPS logs25, manufacturer information26, environmental data27, route logs28, schedules29, facilities information30and so forth.

At step523, the maintenance terminal33retrieves historic maintenance data concerning the resource that experienced the maintenance event. The historic maintenance data is retrieved from the resource maintenance server502. The historic maintenance data contains data from the sources described above and may be limited to data from a predetermined time period preceding the timestamp of the notification. For example, historic maintenance data may be retrieved for the two weeks prior to the timestamp of the notification. The historic maintenance data that is retrieved may be limited to data that relates to the same sub-system that experienced the maintenance event. Historic maintenance data of related sub-systems may also be retrieved. Instructions as to what historic maintenance data should be retrieved may be stored in the reference database505.

At step524, the historic maintenance data is analysed by the analysis module501. As stated above the historic maintenance data may be obtained from sensor logs53, fault logs17, maintenance logs16and so forth. The analysis of the historic maintenance data may be in comparison with historic maintenance data obtained from resources related to the resource that experienced the maintenance event. As such, it is possible to correlate anomalous data from the period before a fault report across all sub-systems related to the sub-system that experienced the maintenance event. For example, sensor information deviating from baseline values may be identified using dynamic time warping. An occurrence of a specific type of warning or a cluster of warnings may also be determined to be indicative of the maintenance event. Based on this correlation, precursor signals may be identified for the maintenance event. In some embodiments, a probability may be calculated indicating the likelihood that a particular maintenance event will occur in a future time period.

At step525, the precursor signals are caused to be stored. The precursor signals may be stored at the maintenance terminal33itself. Alternatively or additionally, the precursor signals may be output to the manufacturer terminal35.

At step526, maintenance data relating to the resource and other related resources is monitored to detect future precursor signals that are indicative of the maintenance event. The monitoring may be performed by the maintenance terminal33and/or by the manufacturer terminal35.

FIG. 15is screenshot of a maintenance graphical user interface (GUI)115for a ship15ahaving identification number 1.

The maintenance GUI115also includes a ship summary pane117. The ship summary pane117presents summary information about the ship15aselected using the selection pane11. The summary information includes the age of the selected ship15a, the total number of operating hours and a current location of the ship15a. The ship summary pane117may be populated with information retrieved from the database7. The maintenance GUI115also includes a fault history pane118. Based on the accessed fault log17, the fault history pane118is populated with a list of a number of faults which have previously occurred for the selected ship15a. For example, the fault history pane118may provide, for each recent fault detailed by a fault object56in the fault log17, a fault ID code which identifies the fault type, the date of the fault and duration before the fault was resolved. In other examples, the fault history pane118may provide any other information associated with a fault object56.

The GUI115contains a Maintenance Options section121. The Maintenance Options section121displays changes in the probability that a maintenance event will occur with respect to respective sub-systems within the next 15 days. These changes are reductions in probabilities that a maintenance event will occur if a particular maintenance task is undertaken. These changes in probability may be derived from a comparison of sensor data for the ship having identification number 1 with stored precursor signals.

It will be appreciated that many modifications may be made to the embodiments hereinbefore described. Such modifications may involve equivalent and other features which are already known in the design, manufacture and use of data processing and analysis systems and which may be used instead of or in addition to features already described herein. Features of one embodiment may be replaced or supplemented by features of another embodiment.

For example, it has been described that the analysis module501determines precursor signals from historic maintenance data leading up to a maintenance event of a particular resource. However, accuracy of determining precursor signal may be improved if the analysis module501determines precursor signals from multiple sets of historic maintenance data leading up to respective multiple maintenance events. The multiple maintenance events may have occurred to different resources, the same resource, or a mixture of different resources and repetitious maintenance events. The multiple maintenance events may be identical, or comparable, for example relating to the same sub-system18.

In other examples, precursor signals may be determined based on a single set of historic maintenance data the first time that a particular maintenance event occurs. If the same or a comparable maintenance event subsequently occurs for the same or a related/comparable resource, then the precursor signals may be recalculated by the analysis module501based on the historic maintenance data for the original maintenance event and also on the historic maintenance data for the new maintenance event. This process may be repeated upon the occurrence of a third maintenance event, a fourth maintenance event and so forth. In this way, precursor signals used to predict the occurrence of future maintenance events may be refined over time.