GB2563971A - Machine monitoring - Google Patents

Abstract

A method of monitoring the operation of a machine 20 to provide prognostic and/or diagnostic information. Method including a data processor (3) receiving operational data over a communications network (4) from at least one sensor (20a) connected to the machine; contextualising the machine in an at least semi-automated manner, which comprises use of the sensor data and use of metadata, and generating prognostic and/or diagnostic contextual information; and the method also includes applying said prognostic and/or diagnostic contextual information to operational data received from the sensor. The contextualising may include sensor similarity processing, and may include separate data feed in addition to the data from the sensor. Determination of the contextual data may comprise comparing data to previous known data and/or signatures. Contextualising may include determining characteristics of the machine which may be: machine type, function, properties, component type, potential failure modes/events previously reported, and prognostic and/or diagnostic data signatures.

Description

MACHINE MONITORING

Technical Field

The present invention relates generally to an apparatus and method for monitoring operation of a machine, and determining prognostic and/or diagnostic information relating to the machine.

Background

In manufacturing and production industries, it is key that operational downtime is minimised or avoided. However should a piece of equipment develop a fault or fail, then remedial action needs to be taken as soon as possible. Certain types of predictive tools are known which seek to provide information ahead of time, so that suitable action can be taken in a timely manner, such as just-in-time, or before any fault condition occurs.

The application of the Internet of things (IoT) to industrial machinery, in the guise of the so-called Industrial Internet of Things (IIoT), presents many opportunities which can increase both productivity and product quality. The (Internet of Things) IoT can be viewed as a construct of objects or environments informing and being informed about other objects systematically, via connection and exchange of information over the internet, by use of sensors. Sensors can measure temperature, torque, current, vibration, speed, lubrication contamination, acoustic emissions, motion and direction, magnetic fields, sound and light, and many other things including chemicals and pollutants. Broadly, the IoT system structure or architecture requirements include appropriate sensors to provide their location and status, a connection to the internet, appropriate software between the object, the internet and other objects and operator interfaces.

Traditional approaches to machine diagnostics and prognostics are labour intensive as models have to be developed per machine. They require extensive manual intervention by highly experienced and qualified individuals.

We have devised a novel way in which this data which is available from sensors can be utilised to provide prognostic/diagnostic information in a highly accurate and efficient manner.

Summary

According to the first aspect of the invention there is provided a method defined in claim 1.

Contextual information may include machine type, component type, sub-assembly type, product type, potential failure modes previously seen and characteristic diagnostic signatures. Put another way, these may be viewed as descriptors of different attributes and characteristics of the machine. Use of ‘contextual information’ and ontology/ontologies may be used interchangeably.

The method may comprise generating/compiling an ontology, fn the present context, an ontology may be thought of as a definition of the type, properties, behaviours and interrelationships of a machine, which can be used in determining prognostics and diagnostics. The ontology of the machine may collectively define the contextual information of the machine. The method may comprise compiling or populating a template or fields related to the relevant contextual information.

The method may include determining machine contextual information including the step of use of pre-determined or known metadata from data sources (external of the machine), sensor similarity determination and (prompted) user input.

The method may include determining machine contextual information using data received from the at least sensor of the machine and analysing the same, and comparing the data to historical operational data, and comparing the data to predetermined data signatures. A machine’s ontology/contextual information may be thought of as comprising relevant metadata.

The method may include storing the contextual information, or at least linking or mapping the contextual information to an identifier which identifies the machine. The method may include maintaining and updating a repository of contextual information.

One aspect of the invention may broadly be described as capturing various data to generate and store contextual information, in particular, ontologies of machines, which is then used to monitor the operational behaviour of machines, by applying the stored contextual data received from sensors connected to the machine. The ontology information may be stored in a database or repository. Over time, an increasing amount of data (or put differently knowledge) is accumulated. Initially, the data (which may be termed seeding data) may comprise data input from a connected data source (such as an IoT middleware hub) of pre-stored data (such as the contextual which is already available about a particular machine or a sensor), or as input by a user. The pre-stored data may conveniently already be stored in the system (such as when a machine and/or sensor of the same or similar type is added to the system, and its ontology can at least in part be populated), and the relevant data can be located by the way in which the stored data is referenced or identified. Alternatively, the prestored data may come from an external source (such as a data resource available over a network, or from other sensors (external to the monitoring system)). The intelligent learning capability of the system advantageously supplements, updates and enriches the stored contextual data over time. This increases the accuracy and depth of knowledge about a particular machine, as well as potentially increasing coverage for an increasing number of machines. For example, a failure event learned from one machine can be learned by the system, the contextual data updated accordingly for that machine. Therefore, the ontologies of all other machines of the same or similar type will be updated, and so their monitoring will benefit from the increased knowledge. This can conveniently be achieved by using a common data structure (such as format/terminology/syntax) across machine ontologies, to facilitate cross-referencing across machines.

An alternative, or supplemental, way to define an aspect of the invention is that of a machine monitoring system which is arranged to perform a number of processing phases which include: a registration phase in which a machine and a connected sensor is added to the monitoring system, the registration phase includes a data capture which includes populating a machine’s ontology from one or more data sources, a monitoring phase in which data from the machine’s sensor is applied to the machine’s ontology to determine a prognostic and/or diagnostic condition of the machine, and an updating/optimising phase in which a body of stored machine ontologies is updated based on additional data and/or on insights derived from existing or additional data.

The invention preferably comprises a number of processing steps which are substantially fully automated in their execution.

The prognostic information for a machine may include a measure of Remaining Useful Life, or RUL.

In at least one overarching aspect, the invention may be viewed as a method of monitoring the operation or operational condition of a machine.

The method may be arranged to determine a predicted/forecasted failure, or in more general terms, a condition which requires or is likely to require suitable attention/action/manual intervention. ‘Metadata’ may include, in general terms, information or data which describes other information or data. ‘Prognostic’ may include any information which relates to a predicted or likely, outcome or event in relation to a machine. Prognostics generally may be thought of as an engineering discipline which includes predicting the time at which a system or a component will no longer perform its intended function.

The method may also provide/output ‘Diagnostics’ and/or ‘Prognostic’ information which relates to an actual or prevailing or real-time operational condition. The method may include one or more processing steps to determine the operational condition of the machine at a given instance. ‘Machine’ is intended to be used broadly to include manufacturing machinery, or more generally any operative device or assembly. Even more generally, machine could be defined as an asset which is intended to perform a particular function, and includes not only industrial machinery, but also vehicles and building structures (to each of which one or more sensors are connected or associated with).

The one or more sensors are preferably connected to the machine to measure (chemical or physical) phenomena, or environment, associated with the machine (preferably directly, but could be indirectly connected). The phenomena include, but are not limited to: temperature position mechanical properties including: vibration, torque, speed (linear or rotational), pressure, stress, strain optical properties magnetic properties number of operational events (for example number of actuations) electrical properties such as voltage, current, resistance, capacitance and impedance moisture levels rate of product input and/or output of material to/from, or throughput of, machine.

The one or more sensors may be arranged to measure characteristics (e.g. physical or chemical) of materials input and product output by the machine

The method may include determining information relating to a particular remedial/pre-emptive action required.

Operational status information may be provided either on-demand, at the request of a user, and/or automatically to a user.

Data sources (other than data from the sensor(s) of the machine) may be used in determining prognostic and/or diagnostic information. The data sources may include at least one of the following: third party or external data (feed), machine specification data, and meta data, historical operational data, of the same or other related machine(s) (either real-time/live or historical).

In determining which of the external data is relevant to use, the method may comprise determining how similar an entity which generated the data is to the machine which is being monitored.

The method may include use of at least one of the following types of processing: semantic annotation predictive analytics machine learning artificial intelligence language processing.

One, some or all of the above processing types may be employed in analytical processing to determine a prognostic/diagnostic condition of machine, and/or may be employed in analysing new and/or existing contextual data so as to enable the contextual data to be updated and optimised (and thereby enable the system to perform intelligent processing to be self-training).

The invention may be viewed as including the processing of data received from one or more sensors connected to a machine, which communicate operational data to a remotely located data processor, such as a server, over the internet.

The invention may be viewed as including prediction of machine failure.

The method may include determining a risk of failure. The method may determine a risk of failure in terms of percentage likelihood.

The method may include sending a message or a report to a user terminal or user interface to inform of a prognosis, diagnosis or machine condition or status. The message may comprise an operational condition status (update).

The method may include determining when received operational data falls outside a band or bounds, or beyond a threshold, of normal operation. The method may include determining a trajectory of instances which occur outside the normal operational band. The method may include use signatures or characteristics of previous instances of failure to forecast a future failure.

The method may include determining a machine’s operational performance. Determination of machine performance may include use of operational status and data from the machine.

The method may include diagnosing actual or predicted failures/anomalies.

The machine, and its associated at least one sensor, may be part of the Internet of Things (IoT), or the Industrial Internet of Things (IIoT). The communications network may include the Internet. By the term 'Internet' we include a global system of interconnected computer networks that use a protocol suite (such as TCP/IP) to link devices worldwide. It may be viewed as a network of networks that consists of many private and public networks which are linked by a broad array of electronic, wireless, and optical networking technologies. We also include communications networks more generally.

The one or more sensors of the machine are preferably arranged to communicate data with the internet by way of a suitable connection or interface.

The method may comprise removing or reducing noise in the data received from the at least one sensor.

The method may comprise substantially automatically classifying the at least one sensor of the machine. The classification may include use of predetermined data such as ontologies of sensors’ measures and units, preferably in combination with metadata of the at least one sensor of the machine.

The method may include identifying other sensors connected to a communications network, obtaining current or historical sensed data from the sensors, and/or attributes of the sensor(s), and determining whether any of the located sensors are sufficiently similar to the sensor connected to the machine or to each other based on sensed sensor data and/or sensor attributes. Once determined as being similar, their data can be used in connection with classifying the sensor connected to the machine and/or in a contextualisation phase.

In determining similarity between sensors, use may be made of actual or (substantially) raw data which is sensed/measured/recorded by the sensor(s). A second aspect of the invention relates to a data processing apparatus for providing diagnostic/prognostic information relating to the machine, which apparatus is arranged to implement the method of the first aspect of the invention, which is arranged to receive data from the at least one sensor connected to the machine, and is arranged contextualise the machine in an at least semi-automated manner by way of use of data from the sensor and use of metadata.

Another aspect of the invention may include a computer software application, comprising machine-readable instructions, which when executed by a data processor of a computer, implement the method of the first aspect of the invention. A further aspect of the invention may include a data processor device which executes the instructions of the computer software application.

The apparatus and/or the application may implement a number of functional logical processing blocks. These may include: a raw data cleaning/noise reduction block, a sensor classification block, a machine contextualisation block, a failure mode identification block a feature extraction block a prognostic/diagnostic analysis block, an ontology optimisation block, and a user feedback/input block.

Some or all of the blocks may be executed in sequence. The apparatus and/or the application may additionally or alternatively implement a data capture block, a machine/sensor registration block and a machine monitoring block.

The invention may comprise one or more features described in the description and/or as shown in the drawings.

Brief Description of the Drawings

Various examples of the invention will now be described by way of example only, with reference to the following drawings in which:

Figure 1 is a schematic representation of a network which includes a machine whose operational performance is monitored remotely, and

Figure 2 is a flow diagram which illustrates the principal operational phases involved in determining prognostic and/or diagnostic information, and

Figures 3 to 8 are examples of various failure modes and detection modes for different elements/sub-assemblies of industrial machinery.

Detailed Description

There will now be described an apparatus and method for determining prognostic information in relation to the operation of a machine. As will be described in detail below, use is made of one or more sensors connected to the machine, which sense/measure operational data, which is then sent to a server by way of an Internet interface connection.

Figure 1 shows a network which comprises a plurality 10 of nodes 9, the internet, or other communications network 4 to which the sensors are connected, a server 3, a user computer terminal 2 and an industrial machine or equipment 20, which is provided with a sensor 20a, and which sensor 20a and machine 20 are connected to the network 4. The server 3 is loaded with machine-readable instructions in the form of a software application which implements a number of functional data processing blocks, which, when executed by the processor of the server, are, inter alia, configured to perform prognostic/diagnostic analytics based on data received from the sensor, 20a, which is connected to the machine 20.

The user computer 2 may communicate with the server 3 by way of a cloud-based solution (requiring the user computer to have internet browser software) or may do so by way of being loaded with a bespoke software application arranged to communicate with the server 3.

Similarly, the server 3 may be viewed as providing a cloud solution to the machine 20, in which the processing is effected remotely from machine.

The method and operation of the apparatus can be viewed as including a number of phases: i) A set-up procedure in which sensors/machines are registered and/or classified, ii) A contextualisation procedure in which the machine is associated with relevant contextual information, iii) Identification of potential failure modes and detection methods, iv) A feature extraction process, v) An analytics procedure in which data from the sensors is processed, vi) A reporting procedure in which any determined instances (such as anomalies, failures) are sent to a user, or made available to a user, and vii) A feedback, optimisation and training procedure.

Figure 2 is a flow chart 100 which outlines each of the above steps, and the sequence in which they are executed. Each step will now be described in more detail. It will be appreciated that prior to commencing use, the sensor 20a is first registered with the application run by the server 3. For registration of each sensor its unique identifier (such as an IP or MAC address) and its address is stored in an IoT (or similar) middleware hub. The format of its data exchange protocol is known so it can be accurately parsed. Additional metadata associated with the sensor can be helpful but is not necessarily essential.

The process commences at step 101 with the receipt of raw data from the sensor 20a connected to the machine 20. The data is sent to the server 3 using an interface which connects to the internet 4.

At step 102 the raw data is filtered by signal processing at the server 3 to remove noise from the data and perform basic mathematical analysis of the raw data. This is done in an automated way and uses knowledge accumulated and stored in the contextual ontology from past data streams (such as from other machines and sensors, which are sufficiently similar in one or more aspects) to configure the processing that is performed. Noise reduction is used to maximise the effectiveness of subsequent processing and analyses steps. Standard techniques are supplemented with in-built knowledge of the most appropriate noise reduction techniques and filters to apply - as learned from previous data sources or accumulated knowledge, and (the determined appropriate noise reduction techniques/filters) recorded in the contextual model (for the machine in question) which is then beneficially available for subsequent use. Here, a specific contextual model includes the specific instance of a sensor and the machine to which it is connected.

Contextual information about machines also assists to guide this data cleaning process. For example, vibration data from a shaft will be processed differently than temperature data from a gearbox, based on use of available contextual information. Once this step has been performed, cleaned raw data is produced. There then follows the step of automated classification of the sensor by the server, at step 103, which acts on the cleaned raw data from the sensor 20a. This utilises available sensor metadata in combination with classification and similarity techniques to relate or associate the received sensor feed(s) to predefined (stored) ontologies of sensors, measures and units. Machines or middleware platforms may provide additional meta-data along with the sensor data. This additional meta-data is communicated through similar channels as the sensor data is received.

Further details of examples as how the use of similarity criteria and techniques are used in the sensor classification process are described below. Automating the task of understanding the data feeds connected to the application executed by the server advantageously enables the sharing of knowledge between sensors including for use in diagnostic techniques, determining failure modes, and using/generating prognostic models. If similar sensors (i.e. which collect the same or substantially the same sensor data) are attached to the same machine type (such as a particular brand of pump) then the diagnostic and prognostic information derived is relevant to both machines, and can determined as such by the application. This means, for example, if a failure mode is observed on one machine, then the learning behind that failure mode is automatically relevant to the other machine. This learning can then be used to update the stored contextual information/ontologies so that monitoring on other identical or similar machines can benefit from this.

The automated classification phase may be supplemented with user feedback input, such as by way of being prompted to confirm similarities between sensors, and other aspects of sensor classification, and contextualisation of machines. For example, for a user to confirm a measure that a sensor is providing, such as temperature, or providing confirmation that a machine is of a particular type.

Having classified the sensor(s) of the machine, the machine 20 is now contextualised, as shown at step 104. The result of this aspect of the process is prognostic and diagnostic contextual information for use during monitored operation of the machine 20 to provide prognostic and diagnostic reports to a user. Using ontology information of general machine behaviour, physical characteristics of failure modes, degradation patterns and stored past experience of machine failure, all of which information is stored or available for use, prognostic and diagnostic contextual information can automatically be added to the derived features. The derived features may be considered as any features which have been created from the cleaned sensor data. The process of contextualisation is performed in a way where, highly advantageously, detailed knowledge of individual machines is not required. Metadata from data sources, in combination sensor similarity modelling and user input (directly and prompted) provide inputs to the process of automatically relating the machine 20 to the most relevant ontologies, and thereby generating contextual information related to that individual machine.

Contextual information of a machine can include aspects such as:

Sector (for example, automotive, pharmaceutical)

Sensor measure types (for example, temperature, current)

Measure units (for example, Celsius, amps)

Measure periodicity (for example, stream or sampled)

Measure precision (for example, resolution of values)

Machine usage pattern (for example, batch or continuous)

Hierarchy of Machines (for example, locality to other similar machines)

Machine Manufacturer

Machine Model (for example, Manufacturers model number)

Machine type (e.g. conveyor system)

Component type being monitored (e.g. driveshaft)

Potential failure modes/events previously reported (e.g. shaft imbalance)

Detection methods (e.g. abnormal vibration).

In relation to machine types mentioned above, a machine classed as a conveyor, for example, could fall into sub-classes depending on the machine system design. Classes of machine could be determined by factors such as; the carrier system (e.g. belt, or pallet), the drive system (e.g. electrical or hydraulic), and the transmission system (e.g. chain, pulley).

In relation to component types mentioned above, components relate to the detailed part of the machine system design, but are defined at a level that is generic enough to be applicable to many machine types. For example, a conveyor with a belt carrying system that is driven electrically via a chain transmission system has a known set of major components being; conveyer belt, electric motor and a sprocket/chain configured transmission. Component definitions are advantageously shared between very different machine types. Electric motors and sprocket/chain transmission relate to failure modes and detection methods that are charted across machine types over many sectors. Additionally, components may have their own respective ontologies which splits them in to sub-classes such as; electrical, mechanical, hydraulic and pneumatic.

Further in relation to potential failure modes, these are preferably related to component types and linked to their dependency on sensor measure types to enable them to be detectable. Failure modes may be populated in two ways; 1) as seeded knowledge and 2) as accumulated knowledge. Seeded knowledge comes from the generation of ontology information populated manually into the system, or from available pre-stored data. However, an enabler to scalability is the accumulation of knowledge through use and evidence gathering from the end user. Feedback in the form of maintenance event information with classification of maintenance type and failure mode being addressed, is used to extend the component failure mode ontology for a machine of a class of machines. Thus new failure modes that occur within the population of machines being monitored are captured and proliferated as applicable across machine components.

As new failure modes enter the purview of the system, this knowledge can readily be shared with machines having the same or similar ontologies (or their components). Any new failure modes can be stored in a database, available for use in the diagnostic/prognostic monitoring. For example, during an automated periodic (or on-demand) updating/optimisation process, the application executed by the server 3, can associate a new failure mode with a particular machine’s ontology being monitored, or can update relevant machines’ ontologies accordingly. This additional information can then be employed in the prognostic/diagnostic process subsequently.

Further in relation to detection methods, these depend on the condition indicators and data features used in identifying the presence of a failure mode. An example would be the ‘spikiness’ in the maximum current values for a motor which could be due to an electrical overload due to damaged rotor bars. Similarly to the immediately preceding paragraph, as new detection methods are recorded or come to light (either by manual input and/or by intelligent determination), these can advantageously be shared across the relevant sub-group of machines to which this is applicable, and the prognostic/diagnostic processing modified accordingly.

The application executed by the server 3 may include a template or a number of fields relating to all some or other aspects above which are to be populated in order to compile the relevant contextual information for the machine. This preferably includes use of a common syntax or terminology or identifiers, so as to facilitate machine contextualisation, as well as updating of ontologies. An ontology of a contextualised machine may be realised as a look-up table, in which some or all of the above categories/aspects are populated according to the characteristics of the machine. This provides a common framework for the stored contextual data which allows the information to be updated and referenced, as required.

The contextual information can be determined by the server by analysing data received from the machine sensor(s) 20a, and comparing it to previously stored/reported data (either from the machine itself, or derived from other (similar) machines or sensors (such as sensors 9). The metadata already stored against or associated with the sensors provides the means to map through to machine types, which in turn identifies applicable machine components (such as motors, gearboxes). Each machine type and component type contains a link to the failure modes defined, which have associated detection methods. The detection methods have dependencies on sensor characteristics (for example, measure type and periodicity), which are identified in the sensor metadata. This enables the system to know which of the detection methods to utilise and, as a result, the failure modes that can be identified, and stored in association with the machine for use in the diagnostic/prognostic analytics processing.

Through the (intelligent) sensor similarity processing the cross population of metadata is achieved. Utilising the level of similarity between sensors, and therefore machines, it is possible to identify sensors with metadata that is applicable to other sensors with little or no metadata associated with them. The process of cross population of metadata can either be fully automated, or initiated following user confirmation/input. User confirmation can be used to increase certainty to the process of applying the metadata, however with larger populations of sensors the confidence in the similarity can be increased to levels where the system automatically copies metadata between sensors (which can be thought of as automated population of contextualised machine information).

As stated above, detection methods have associated with them dependencies on sensor measures that they require as inputs, which can be mapped back through the ontology of detection methods, failure modes to the machine and sensor metadata. This enables an output to the user of the expected failure modes that are detectable from the available sensor sources. In addition, the user can be informed of missing sensor measures that relate to (currently) non-detectable failure modes. This provides the user with the choice of enhancing the sensor measure feeds provided to the system to increase the coverage of the detectable failure modes.

The advantage of this, and subsequent steps described below, is that contextual information (i.e. metadata) is combined with raw data. The metadata, raw (cleansed) data and derived features are all held together in a structured form to represent the behaviour and characteristics of a machine. This can be considered as being stored in an ontology structure, with one such structure per machine instance.

This, in turn, enables subsequent processing to be automatically targeted and fine-tuned (substantially) without manual intervention. Machines and their degradations/failures are typically highly unique and complex. With this technique, data scientists and diagnostics engineers are not required to manually interpret data and manually select and configure which type of algorithm/processing is appropriate, which is the known process currently employed.

This advantageously significantly affects the scalability and deployability of the process, since by removing (substantially all or a significant extent of) manual intervention out of the equation, and being able to entirely/largely automate the process, it becomes scalable and deployment costs are dramatically reduced.

The contextual prognostic and diagnostic data generated by the previous step, together with the sensor classification information, is used in combination at step 105 to identify and store the potential failure modes, as well as the degradation patterns and general behavioural characteristics that can be identified with the source data for the machine type. A failure mode ontology is populated initially and then enhanced with knowledge from user activity in the system (for example by feedback of events and failures, described below). The initial population is based on information obtained based on industrial standards and is constructed in a manner to ensure that the machine and sub-assembly failure modes are transferable across machines types and industrial sectors.

Taking the contextualised data, the application automatically adds failure mode and failure detection method data. Further reference is made to Figures 3 to 8, which show tabulated representations of examples of failure modes and associated detection modes. For each failure mode that is identifiable with the scope of the source data there is an associated detection method, which directed the extraction of features. The failure mode data and the detection method data are used to automatically fine tune the analytical processing. Fine tuning the analysis process can be considered as being split into two main areas, 1) enriching sensor data provided to expose failure modes, and 2) providing configuration input to the analysis in the form of algorithm selection, thresholding and/or models defining acceptable operational bounds.

It will be appreciated that advantageously, the combined use of sensor classification and machine context enables potential failure modes to be identified at step 105. These failure modes then in turn inform the feature extraction (at step 106 described below) to make the failure detectable. The detection methods drive the extraction of the most appropriate features to enable the prognostics and diagnostics to identify the failure modes.

Based on the detection methods, source sensor data is processed and converted into features or condition indicators (Cis) that relate specifically to the detection method that exposes the failure mode identified as being relevant to the machine being monitored. The Cis are used as the source for the analysis and form a new derived stream of data that can be viewed as an additional sensor feed.

The detection methods also contain relationships to applicable algorithms for diagnostics and prognostics within the system. To minimise false outputs from the system the use of the correct algorithms is important, as the system contains or has access to a library of algorithms, which can be specific to a type of diagnostic detection or prognostic forecast.

An example of generation of a CI would be the transformation of discrete events related to debris monitoring in lubrication systems to features describing the rate of events in terms of number of metallic particles identified per period of operation (for example, ten or one hundred hours). There could be more than one detection method using this rate feature, one related to specific thresholds such as no more than three particles in ten hours, the other related to the rate of change in particles over longer periods.

Turning now to step 106, this relates to extracting features related to detection methods from sensor data using known mathematical and diagnostic approaches in addition to proprietary techniques. This has the effect of extracting information from the data and reducing the data to new time series of features and condition indicators. Using contextual data from the previous step, only the features necessary to enable subsequent steps are extracted from the received sensor data. Known patterns and signatures from past data are used to assist in configuring the feature extraction algorithm. Some influence on the feature calculation could be taken from the statistical properties of the sensor data. This could be especially useful where the detection method is new and has limited features defined. The feature extraction algorithm processes over historic sensor data and establishes characteristics of the data that can be used to drive the most appropriate methods of feature extraction from the sensor data. Identifying if the sensor data is highly state based as opposed to having readings that are evenly distributed through a range, will influence the type of feature extraction to perform.

This is supplemented with additional statistical features of the data, which is intended to provide the basis for the identification of previously unforeseen failure modes. In addition to the specifics of the failure modes and detection methods employed through the seeded and accumulated knowledge held in the system, generalised processing is conducted on a range of statistical features generated over the sensor data. This provides the scope to detect, through intelligent processing/machine learning, failure modes that either have been unforeseen in the initial population of the system or not encountered for an asset type while the system has been used. The identification of unforeseen failures is a prime source to supplement the failure and detection ontologies. The system advantageously has a more generalised approach to diagnostic event detection, since limiting the system to only known failure modes can overly constrain the machine learning engine and may negate many of the benefits. Experience from other sectors has shown that significant unavailability of a machine or asset results from failure modes that were never conceived in the machine design process of the design of traditional condition monitoring systems. This determination of unforeseen failure modes can be considered as supplemental to step 105 (in which known failure modes are determined).

The monitoring of the statistical features of sensors’ measures either individually or in combination, is achieved through the use of one or a combination anomaly detection processing, output evaluation, optimisation of processing constrains and triaging of output to minimise false positives. The evaluation and optimisation also considers non-sensor inputs, such as user feedback and operational events entered in to the system. A significant advantage of the feature extraction step 106 is reducing the dimensionality/bandwidth/size of the data which needs to be processed at the analytics step 107, and makes subsequent processing both more accurate and more relevant.

With the previous steps having been completed, the analytics of monitoring the operation of the machine can commence, using the data feed from the machine’s sensor. This is shown as the analytics step 107. Implementations of machine learning process steps or algorithms are applied to process the derived information (i.e. features and condition indicators) determined from previous steps described above. The algorithms are data-driven and split into instance based and/or single pass techniques. The instance based techniques learn failure modes from past observations, where the single pass techniques forecast using constraining models. The ability to perform this is greatly enhanced with the ability to act on contextualised feature data rather than raw data directly as machine learning algorithms are highly reliant on good quality input. High quality contextual input increases the accuracy and the prediction horizon of the analytics and algorithms employed at step 107. Also, by adding contextual information, the trendability of the data/information becomes more apparent. Specific classes of machine learning algorithms may be configured during this process.

In relation to the steps described above, the relevant contextual information is stored by the sever 3 in a memory (not illustrated) of or connected to the server, and made available for subsequent use during monitoring of the machine 20.

In use, with the machine 20 operational, the server 3 receives raw data from the sensor 20a connected to the machine. This data is then subjected to the condition monitoring, prognosis and diagnosis analytics described above, in particular steps 107 and 108. In the event that an abnormal event is determined, or at least which has been predetermined as requiring to be reported, the relevant user is then notified accordingly. The reporting message may be sent directly to a user interface of a user terminal 2 (such as a PC) or user communications device (such as a portable phone or a tablet computer device), which is in communication with the internet. The relevant user is then alerted to the event, and can bring about any required action.

The following provides some examples of the reporting messages which may be generated, and sent to or made available to a user: 'The electrical actuator ACT023 has entered a failure pattern and now has 8 days of Remaining Useful Life'. 'Bearing on the main hydraulic pump will exceed design limits in 32 days, due to excessive vibration levels'. 'The motor ES2 on production line AC6 will fail in 40 days. Trends in vibration condition indicators have been detected'. 'Performance of pump 28 indicates damage to the impellor. Rectification action is recommended to avoid any secondary damage'. 'Analysis shows that the conveyor on production line H has 72 hours of operation remaining'. Ά misalignment of the input shaft to gearbox MPC2 has been identified'. 'Check transmission'. 'Belt is about to fail'. 'Abnormal use of pressing machine'. 'Bearing failure in 200 hours'.

All of the above examples provide a very clear indication of what any predicted or actual issue is, together with any associated details (such as relevant timescale to take remedial action, and a likely cause). These provide valuable operational insights to industrial machine assets.

Being a data drive processes that uses substantially unsupervised techniques, inputs other than source data assist to enhance the classification processed and the inputs to the analytic processes. This splits into the areas of optimisation and feedback at step 108. Optimisation uses methods of measuring the accuracy of the analysis retrospectively and captures metrics, then performs automated optimisation to improve feature extraction and model definition (defensive analytics to prevent overfitting are included). Feedback is captured in the form of discrete and evidence based information. Discrete feedback provides metrics of the user’s perception of the system output (positive/negative). Evidence feedback is typically in the form of capturing actions and events that are applied to the machine, either resulting from system insights or other operational events. Optimisation and feedback are used in many of the preceding stages (e.g. event feedback will extend the known failure modes for a machine type), through intelligent machine learning, updating different aspects of stored ontologies as appropriate.

As mentioned above, the application run by the server 3 uses a method for discovering network or internet connected sensors which measure the same, similar or related phenomenon or environment, for example to contextualise a machine and to classify sensors. Identified similar sensors can be grouped, and then their respective data beneficially exploited, and in particular making use of publically or commercially available data. This use may include increasing discoverability, providing additional information for use in data analytic algorithms, and aid in tuning algorithms. The sensors are (pre-)registered with a software application, which then allows their data and characteristics to be analysed for similar sensors to be discovered therefrom and associations created. The group of sensors which is registered can be increased (or decreased) over time. The registered group of sensors could be supplemented by way of manual input and/or internet/external database searching for other sensors.

In the exemplary embodiment described here, each of the nodes 9 may comprise an object or device which is provided with one or more sensors, or the node may itself be a sensor. Use of data from or relating to those nodes is beneficial in (a) classifying a sensor of the machine, (b) contextualising the machine and (c) in performing the prognostic analytics. The application of the server 3 is configured to identify one or more sensors which are determined to be characteristically similar to the sensor 20a. In broad terms, the characteristics of the first sensor of the sensors 10 are known, as are the data and metadata of the entire group of sensors registered. However, the links or associations between them, as to which ones are similar, are not. This characterising data of the first sensor is then processed and used to determine whether the registered sensors have characteristics which are sufficiently similar to those of the first sensor to qualify as being considered as a similar sensor. A link or association with that or those located similar sensors and the first sensor can then be stored in a memory (for example, such as a hard drive), and data from the former can be beneficially exploited in relation to the latter (or vice versa). Whilst it may be that the similarity between all (possible) pairs is tested, in many cases, a subset of the group of sensors is likely to be considered at any one time. In determining similarity between sensors, multidimensional models of sensor features could be used on how a distance measure is used to determine similarity, with the result being that similar sensors on similar machines will cluster, whereas and unique sensors will be some distance away in the model from other sensor types. This takes due account of the sensor data stream, as well as machine types and differences in the operating mode of machines.

The method of identifying similar sensors may comprise using at least one of the following criteria, which is indicative of a dependence between at least two sensors: (i) a similarity in a physical property (e.g. type, make, units or property measured) or environment measured by a sensor (ii) a similarity in the statistical characteristics of measured physical properties/environments, and (iii) a dependency between physical properties/environments measured.

The above described method and apparatus provides many important advantages.

Principally, these include automatic diagnostics as well as foresight into failures on all types of machinery, to support a Predictive Maintenance (PdM) regime. By having this information ahead of time eliminates costly downtime and improves OEE.

Accurate indications of RUL can be determined, without the need for detailed knowledge of the physics and dynamics of individual machines.

The automatic monitoring of equipment and machines inform a user what is happening in real-time and what is likely to happen in the future.

Manual inspections and spares inventory can be reduced.

Abnormalities and incorrect usage can be detected.

There is generally no requirement to add any hardware or install any software.

Greater process visibility and increased product quality.

Further advantageously, the analytics which underpins the diagnostics and prognostics, and more generally, the condition monitoring, can be fine-tuned automatically (i.e. in an unsupervised way) through suitable machine learning processing implemented by the application. Therefore, not only is the process itself largely automated, but the refinement of the same are also automatic. This does away with the need for large numbers of data scientists and diagnostic engineers to analyse data and improve the accuracy of the analytics and is therefore capable of readily scaling with the prospective increases to be witnessed by the maturing IoT.

The method and apparatus can be applied to any industrial machine, and can be said to be machine agnostic. The enrichment of the sensor data can advantageously be progressed to a point that enables the prognostics and diagnostics analytics to be generic in its implementation meaning that it is not linked to specific physical machine models or even an understanding of machines.

Claims (21)

1. A method of monitoring the operation of a machine to provide prognostic and/or diagnostic information, comprising receiving operational data over a communications network by a data processor from at least one sensor connected to the machine, and the method further comprises the data processor performing processing to contextualise the machine in an at least semi-automated manner, which comprises use of data received from or relating to the at least one sensor and use of metadata, and wherein contextualising the machine further comprises generating prognostic and/or diagnostic contextual information, and the method comprises applying said prognostic and/or diagnostic contextual information to operational data received from the at least one sensor operatively connected to the machine.

2. A method as claimed in claim 1 which comprises use of sensor similarity processing in contextualising the machine.

3. A method as claimed in claim 1 or claim 2 which comprises use of data from one or more data sources in contextualising the machine.

4. A method as claimed in claim 3 which the at least one data source is provided by a separate data feed which is additional to the data received from the sensor of the machine.

5. A method as claimed in any of claims 1 to 4 in which determination of contextual data comprises analysing data from the machine sensor, comparing the data to previous known data and/or comparing it to known data signatures.

6. The method as claimed in any preceding claim in contextualising the machine comprises determining one or more characteristics of the machine.

7. The method of claim 6 in which the characteristics of the machine include at least one of: machine type, function, properties, component type being monitored, potential failure modes/events previously reported and diagnostic and/or prognostic operational data signatures.

8. The method of any preceding claim which comprises classifying the at least one sensor of the machine.

9. The method of claim 8 which comprises classifying the at least one sensor by comparing data from the sensor with reference to at least one sensor ontology.

10. The method of claim 9 in which the reference sensor ontology includes at least one of sensor type, sensor measures and sensor units.

11. The method as claimed in any of claims 8 to 10 in which the at least one sensor is classified in a substantially automatic manner by the data processor.

12. The method as claimed in any preceding claim which comprises generating at least one of a machine ontology, a machine component ontology, a machine failure mode ontology and a detection mode ontology.

13. The method as claimed in any preceding claim in which the contextual information is stored in a predetermined structured manner.

14. The method as claimed in any preceding claim which comprises applying stored contextual data to operational sensor data from multiple machines being monitored.

15. The method as claimed in any preceding claim which comprises updating and/or supplementing stored contextual data, based on at least one of: a data feed from a sensor, separately sourced or derived data, user input data, and data which is derived or inferred from either the already stored contextual data or any received data.

16. The method as claimed in claim 15 in which the user input data comprises data provided through a user feedback input.

17. The method of claim 15 in which machine learning processing is employed to update and/or supplement the stored contextual data.

18. The method as claimed in any preceding claim in which comprises performing processing for identification of potential failure modes and/or detection methods of the failure modes associated with a machine to be monitored.

19. A data processor for monitoring the operation of a machine to provide prognostic and/or diagnostic information, which receives an input comprising operational data from at least one sensor connected to the machine, the data processor arranged to contextualise the machine in an at least semi-automated manner, in which the data processor arranged to use data received from the at least one sensor and to use metadata, and wherein the data processor arranged to contextualise the machine and in doing so generates prognostic and/or diagnostic contextual information.

20. A data processor as claimed in claim 19 in which the data processor comprises an interface arranged to connect to a communications network, and thereby receive data from the at least one sensor.

21. A system comprising a data processor, a machine, and at least one sensor connected to the machine which is arranged to sense operational data from the machine, the data processor arranged to receive data from the at least one sensor over a communications network, the data processor arranged to contextualise the machine in an at least semi-automated manner, in which the data processor arranged to use data received from the at least one sensor and to use metadata, and wherein the data processor arranged to contextualise the machine and in doing so generates prognostic and/or diagnostic contextual information.