GB2515115A - Early Warning and Prevention System - Google Patents

Abstract

An Early Warning and Prevention method and system is provided which can detect and resolving manufacturing and/or process faults. The system comprises data pumps 101 receiving manufacturing and/or process data from databases 400, servers 201, 203, 204, 205 and 206 which interpret the received data to determine a fault, perform root cause analysis to diagnose one or more causes of the identified fault and verify the statistical significance of the root cause analysis of the fault and visualisation means 300 outputting an indication of the identified fault and providing information relating to the determined one or more causes of the fault. The system may be able to determine whether further data is required to generate valid root cause analysis results. The system may be configurable to determine causes with a predetermined confidence level.

Description

Early Warning and Prevention System The present invention relates to an early warning and prevention (EWAP) system, and particularly, but not exclusively, to an EWAP system which can detect and resolve manufacturing and/or process faults continuously and automatically by providing causation or correlation links between particular factors and faults.

Despite the manufacturing industry adopting quality control processes such as Six-Sigma and computerised production systems, the Cost of Poor Quality (COPQ) is still Jo O]1 of the largest operating costs. It is vast, typically 15-30% of revenues. COPQ includes internal defects (such as a scrapped or reworked product) and external defects (product returns and warranty costs), and additionally, there are reputation or safety issues to consider, which are particularly relevant for healthcare and transport sectors.

COPQ is high because root causes are hard to resolve with so many potential variables in each defect, as well as the competitive pressure to lau]lch ever more complex products.

The state of the art of resolving faults, by using various quality and statistics tools, requires skilled, manual intervention and is statistical and hypothesis-led. There have been early warning systems and "preventative maintenance" systems implemented in manufacturing companies which are for the detection of faults in the field (i.e. warranty faults) to alert the manufactnring company and augment its own warranty system.

Existing systems typically look out for tolerance, threshold or trend data. However there is nothing available which automatically detects and resolves the root causes of faults on-the-fly in real time or near-real time, both within and outside the factory.

According to an aspect of the present invention, there is provided an Early Warning and Prevention System for detecting and resolving manufacturing and/or process faults, comprising means for receiving manufacturing and/or process data means for interpreti]lg the received data to determine a fault, means for performing root cause analysis to identify one or more causes of the determined fault, and means for outputting an indication of the identified fault and for providing information (also known as predictive analytics) relating to the determined one or more causes of the fault, wherein the system further comprises means for verifying the statistical significance of the output of the root cause analysis means.

The means for identifying a fault from the received data maybe arranged to perfoim profiling of the received manufacturing and/or processing data and to identify a fault from a profile of parametric data extracted from the received manufacturing and/or processing data.

The means for receiving manufacturing and/or process data may comprise one or more data pumps, each arranged to interrogate a database.

The EWAP may further comprise a data transformer server arranged to transform data io received from the one or more data pumps into a format suitable for performance of root cause analysis.

The EWAP system may further comprise means for cleaning statistical data output by the root cause analysis means.

The EWAP may further comprise a server arranged to host an appflcation for determining whether further data is required in order to generate valid root cause analysis results.

The hosted application may be arranged to report on data quality.

The hosted application maybe arranged to generate heuristics to guide the root cause analysis means.

The server may be arranged to provide feedback contr& to the means for receiving data.

The EWAP system may further comprise a user interface means for presenting an indication of the identified fauit and for providing information relating to the cause of o the determined fault in real time.

The user interface means may be arranged to output recommendations on data gathering where insufficient data is available to res&ve an identified fault.

The verification means may be arranged to control a fault threshold used by the root cause analysis means so as to enable one or more causes of the determined fault to be identified wfth a predetermined confidence leveL The predetermined confidence level maybe associated with economic factors.

According to another aspect of the present invention, there is provided an Early Warning and Prevention (EWAP) method for detecting and resolving manufacturing and/or process faults, comprising receiving manufacturing and/or process data, Jo interpreting the received data to determine a fault, performing root cause analysis to identify one or more causes of the determined fault, verifying the statistical significance of the root cause analysis, outputting an indication of the identified fault and for providing information relating to the determined cause of the fault.

The present invention makes use of root cause analysis algorithms (for examp'e, the Root Cause Analysis Solver Engine (RASE) as devdoped by Warwick Analytical Software Limited) in a dynamic system. Above and beyond the usual dashboaixl' capabilities of visualising data, it has the following novel technical effects: (i) It can identify and classify faults based on their parametric data profile. In other words it can detect which faults are similar by their data signature' even when there are semantic differences in the recording of the fault manually.

(ii) It can resolve the root causes of faults as they are recorded either within the factory or from external warranty failures. This happens either on an event-driven (i.e. new faults being recorded) or interval basis.

(iii) It can detect when the data signature' of a fault appears within the factory, thus alerting the company in real-time to review or reject the product before it progresses further in the process or leaves the factory. This also provides the capability of predicting (and ultimately preventing) faults occurring, and where relevant to direct preventative maintenance to products out in the fidd.

(iv) It can work with No Fault Found' or No Defect Found' situations where faults are intermittent and indeterminate by highlighting areas of correlation or causation in the manufacturing process.

(v) Where complete data are not available to resolve the problem, it can make recommendations on the data gathering required to res&ve it.

Embodiments of the present invention will now be described with reference to the accompanying drawings, in which: Figure 1 shows a system diagram in which is included an EWAP system according to an embodiment of the invention.

io The description of exemplary embodiments of the present invention provided bdow is merely exemplaiy and is intended for purposes of illustration only; the following description is not intended to limit the scope of the invention disclosed herein.

Moreover, recitation of multiple embodiments having stated features is not intended to exclude other embodiments having additional features or other embodiments incorporating different combinations of the stated features. Combinations of compatible features of different embodiments, which are not referred to expllcitly but which would be understood by those skilled in the ait, are also intended to fall within the scope of the invention.

The high-level architecture of a system in which is included an EWAP system according to an embodiment of the present invention, is shown in Figure 1. The key components of the embodiment are divided into three sub-systems (unshaded), which interface with a user company's databases and other systems shown via shading in Figure 1, although embodiments, in which more or fewer individual key components are present, will also fall within the scope of the invention, as described below.

The shaded components illustrate the data flow from a number of databases 400 of the user company, which may be original equipment manufacturer (OEM) databases, supplier databases, warranty databases and design databases, storing data r&ating to product design, manufacturing processes, and performance in the fidd, which provide a data feed to a conventional quality dashboard 501 and a conventional manufacturing execution system (MES) dashboard 502, which can provide feedback to the user. The MES dashboard in turn interfaces with a Statistical Process Contr& (SPC) modifle 503.

The components of the EWAP system of the present invention are configured to build on these existing components, so that improved feedback on the data in the databases 400 can be provided to the user.

The three sub systems shown in Figure 1 are: 1. Data extraction module 100, which consists of one or more data pumps' 101 (described in more detail below). These are attached to the user company's databases 400 which will typically be on the user company's premise, although these may potentially be hosted remotely, such as a datacentre. It is possible that one or more of the databases 400 may reside in a third-party such as a supplier (e.g. supplier components database) or outsource IT partner. I0

2. Core System 200, which is where the main computational activities take place, including the root cause analysis algorithms. This sub-system consists of (i) a data warehouse 203, (ii) root cause analysis server(s) 204, (iii) data cleaning and validation server(s) 205, (iv) data transformation server(s) 201 and (v) the discovery and search server(s) 206. These components are all described in more detail below. This sub-system can be situated physically on the premises of the user company, or it can be remote, for example in a datacentre of the company or even a third-party. It can be made up of one or many servers depending on cost and size of calculations.

3. Visualisation 300, which is where the results of the computation are shown, as well as the other useful data and metrics to enable the users to take the appropriate corrective actions. This sub-system consists of an Application Programming Interface 301 ("API") as well as an EWAP "dashboard" 302 where the output data will be displayed, as well as triggering any alerts and alarms, for example by email, text, telephone or siren.

The components used in the first embodiment of the invention will now be described in more detail.

Data Pumps 101: The data pumps 101 are software modifies running either within the manufacturing company's various databases, or interfacing to those database, which interrogate the databases 400 continuous'y (either at predetermined or user-set intervals or on an event-driven basis) to provide the data for the core system 200. There may be marked differences between the various databases which might mean that each data pump might need to be configured differently. For example some might be capturing text data, or event logs, or disparate vendors or configurations of databases.

There can be any number of data pumps. A typica', but not universal, arrangement is one data pump per input database.

The data pumps may retrieve information in a variety of formats, such as a parametric strings (for example, a Comma Separate Variable file), spreadsheets and outputs from data loggers as stored in the databases 400. I0

The source data may vary in nature by sector or technical field, and may be at east one of test data, service data, warranty data, field data, manufacturing data and diagnostic data. For example, where the EWAP system has application to consumer electronics, the source data may include warranty failure data which is received from a customer.

Where the EWAP system has appbcation in aerospace, the source data may represent diagnostic data from a remotely-tested aircraft.

Data Transformer Server(s) 201: This is an array of one or more servers running software modules which take the data from the data pumps 101 and perform appropriate transformations so that the data are in the right format to be stored in the data warehouse 203 to enable subsequent computations to be performed. The transformations may, for example, be data cleaning and checking functions for screening out outliers and reporting on statistical properties of the data to ensure that it is fit for purpose and not likely to give a false result. It also provides holistic transformations whereas each of the data pumps 101 might be performing transformations specific to the database to which it interfaces.

Data Warehouse 203: This is a master database where data are collated and stored such that the root cause anab'sis and other algorithms can be performed.

Root Cause Analysis (RCA) Server(s) 204: This is an array of one or more servers running software modu'es which perform root cause analysis computation on the data stored in the data warehouse, in order to identify a manufacturing and/or process fault, and to determine the cause or causes of the identified fault.

This computation could, for example, involve root cause analysis algorithms developed by Warwick Analytical Software Limited, such as the Root Cause Analysis Solver Engine (RCASE) with or without further enhancement algorithms.

There are a variety of modes in which fault analysis may be performed: event-driven, continuously, fault-specific, location-specific, holistically etc. The mode settings would depend on the objectives of the company, the issues experienced, the amount of data, the time required for solutions and also the cost and availability of the computational io power required. The computational output of this component feeds two other modifies, the data clean and validation server(s) 205 and the discovery and search server(s) 206.

A fault is determined either based on data obtained from a data pump 101 which explicitly indicates an isolated occurrence of a failure, such as a warranty failure report for a customer, or from diagnostic data indicating a short circuit in an electronic component, e;qdenced by a vokage recorded on a ground rail, for example. Rather than being a discrete fauk, the data may represent patterns of behaviour which indicates non-repeatable performance, for example due to fluctuations in an electronic ground rail, or unpredictable mechanical vibration modes.

The fault data may be directly identified through means of a "fault marker" associated with the fault, which indicates explicit details of the fault, for example in a customer's warranty failure report, or may be interpreted from the data. For example, high emissions levels obtained from vehicle diagnostic data may represent a fault in the exhaust or engine systems.

Alternatively, data can be obtained from data from a data pump 101 which suggests that a fault is likely to occur imminently in the product from which manufacturing or pcrformancc data has bccn obtained, such as an operating temperature being dose to a o particular safety limit. In the latter example, the identification of the cause of a fault enables the user to take preventative action. In this regard, the EWAP system provides an early warning of a potential future fault.

Dependent on the architecture of the system, the diagnosis of a fault can be taken from outside a user's premises where the EWAP system is hosted on servers remote from the user's hardware, enabling, for example web-based control or re-evaluation of a processing parameter so as to carry out the preventative action.

The RCA server 204 is able to operate in such as way that faults can be identified independently of the form in which data is provided from the data pumps 101, or even transformed by the data transformation server 201. This can be achieved through analysing a parametric "profile", rather than focusing solely on the absolute numerical values associated with a particular parameter. The profile may indicate, for example, high values associated with each of a combination of three different factors, which leads io to a particular profile defined by the three factors which have high vahies, rather than the absohite vahies, or the numerica' units of the parameters underlying the identified factors. This profile is interpreted by the RCA server 204 as a "fault signature" indicative of a fault, and having identified a particular fault signature, the fault can be identified.

As an example, a fault signature may be that a particular section of a microcontrofler is operating at too high a temperature. This could be represented direcfly using physical temperature information, or indirectly, via processing load, operating voltages, or current consumption. The RCA server 204 is able to identify that any one of these parameters is too high, and to then identify a more generic fault signature of over-activity in a particular region of the microcontroller. The underlying cause may be an error in the control software executed by the microcontroller, and so this could be isolated as a cause of a fault in the microcontroller independently of the semantics, or the exact way in which data is reported to the RCA server 204 from the data pumps. As such, the EWAP system of the invention is very flexible and can interface effectively with a number of systems.

Parametric profiles can be stored in advance for the purposes of comparison with data from the data pumps, either in database 203 or in a separate dedicated database, when o the EWAP system is to be configured to operate with a well-defined set of data, so that particular fault signatures can be anticipated. Alternatively fault signatures can be developed through a learning process and added to storage, either automatically, or based on user intervention reflecting changes applied empiricaflyto a manufacturing process, for example. The changes can be input via an interface (not shown) to the RCA server 204, or via an interface associated with the EWAP dashboard 302, to be described in further detail below.

Data Clean & Validation Server(s) 205: This is an array of one or more servers running software mod&es which take the output from the root cause an&ysis server(s) 204 and perform one or more &gorithms on it in order to check that the result is valid (e.g. statistically significant, or sensible given the expectation and inputs). If the result is not valid (e.g. certain thresholds of confidence are not reached) then it will iteratively perform certain cleaning tasks until the thresholds are met, or otherwise that only a null result is obtainable. Results are stored in the data warehouse 203 and can be used over time to compare performance of the Jo algorithms. It may also incorporate artificial intefligence and machine learning algorithms in order to develop the algorithms based on previous experiences.

In more detail, the presence of the data clean and validation server 205 enables the EWAP system of the present embodiment to take imperfect input data, and give a clear is and effective real-time faHure-reporting output, which ensures apphcability of the EWAP system to real-world environments where the input data maybe incomplete. For example, a customer with limited understanding of the behaviour of a product may not report a warranty failure in terms which explicitly point to the fault and its underlying cause, but may instead describe other behavioural aspects from which the fault can be inferred, or may provide data which must be supplemented by a product specification from a design database before the RCA server 204 can perform analysis.

The data clean and validation server 205 achieves this through using the output of the RCA server 204 to determine suitable performance and process thresholds against which failures are to be assessed.

The output of the RCA server 204 can be what is known as a "probabilistic output", in other words, a level of confidence that a particular parameter is the cause of a fault, the confidence being lcss than ioo% if thc input data is incomplete or unclcan. In the embodiment of the invention, parameter ranges are set at the RCA server 204 such they capture a certain percentage (x %) of product failures. As an examp'e, they may capture 80% of product failures. Ideafly, x shoffid be as high as possible, but due to the imperfections in the input data, there is the possibility that some products having parameters falling with the specified failure ranges have not in fact failed. These events represent "false negatives". -10-

Accordingly, a further measure of the success of the EWAP system of an embodiment of the present invention is that of how many products within the failure range have in fact failed -this should ideally be as high as possible. This is referred to as the "base" which is the proportion of normals that are included in the resdts against failures. The ideal result is 1.

The thresholds x and y are adjusted automatically by the data clean and validation server 205, with a view to ensuring that the reported failure data is of practical use.

What constitutes "practical use" may vary between technical fields, and may be io associated with economic factors.

As an example, if the EWAP system were to be built into a vehicle production plant, there may be an instant economic impact associated with unnecessarily discarding vehicles which are incorrectly identified as faulty (i.e. false negatives), and so a trade-off must be considered between setting x high, potentiay increasing the number of false negatives, and setting now, decreasing the number of false negatives, but in turn failing to identify vehides which may fail within their warranty period.

In an alternative scenario, if the EWAP system were to be built into a semiconductor processing plant, the cost associated with making a yield reduction, caused by discarding false negatives, may be smaller than the cost of replacing a completed product in which the semiconductor is installed. As an alternative, where testing is economically expensive, the EWAP can reduce areas where testing is required (sometimes known as virtual metrology).

As a further consideration, the thresholds may be set in conjunction with a particular service of product recall strategy, in other words, the way in which the vehicle is to be monitored and used in the field. If x is set to be low, a shorter warranty period, or more regular service requirement could be sct than ifxwere to be high.

As such, the control of thresholds by the data clean and validation server 205 ensures that the data which is output to the EWAP dashboard represents an economicafly viable report. Based on the report, the user can make appropriate changes to at least one of: (i) product design; (ii) manufacturing process and/or facility (i.e. design and/or tolerance parameters deployed for example in the process control rules); and -11 - (iii) service design / recall strategy.

The user will be able to predict, based on which of these actions is selected, the outcomes in terms of fault reduction or elimination. In some circumstances, it can be a moot point whether a strong corr&ation and "fault region" is found. Sometimes, corrective action might be recommended without a complete understanding of the root cause.

Discovery & Search Server(s) 206: This is an array of one or more servers running software modules which provide io heuristics where there is a limited or null resut (sometimes known as a scattered, diffuse or undear result) from the root cause analysis server(s) 2o4These heuristics provide insight and enable the users to take actions necessary to improve the performance of the root cause analysis module and also improve the interpretation of the results which are output. These heuristics might provide probabilistic results where deterministic ones are not available.

This component is, from a user's point of view, two separate appbcations, even though much of the computation is homogenous. It will be described by way of describing each application below: (i) The first application is a "search space" application, which is a software module which analyses the results from the RCA server 204 and calculates whether a good result has been achieved or whether further data is required and a recommendation from which sources. It provides heuristics in order to do this. These heuristics might be based, for example, on machine learning (i.e. a previous successftil experience), or a set of manually inputted rules such as a fault tree', or some rules based on vectors. For example, an imperfect result trying to find the root cause of a fault in a vehicle chassis might find a weak correlation which gets stronger in a particular dimension leading to the heuristic to gather more data from further down the vehick chassis.

In this way the user will be guided to gather or dean more data so that the root cause of the particular fauk might be discerned. In one embodiment, the RCA server 204 may be controlled by the search space appBcation so as to operate on a "just enough data" principle, so as to limit the increase in data which is to be retrieved from the databases.

-12 - (ii) The second application is a "discovery probe" which undertakes similar computations as the search space application (and may have others in addition) and is used initially to analyse and report on data availability and quality and also any improvements and recommendations to the manufacturing company's internal IT setup, data gathering and databases. It also provides ongoing monitoring of the data quality and availability, and therefore enhances and brings together the checking and cleaning that each of the data pumps 101 conducts.

The discovery and search server(s) 205 have a feedback loop to the data pumps 101 in io order to potentially reconfigure and gtude them to extract different data from the databases.

Application Programming Interface ("API") 301: This is a software component which takes the output feeds from the core system 200 is and enables them to be fed into the EWAP dashboard 302 described below, or other systems and dashboards of third-party software (which may have been extant prior to the implementation of the EWAP such as illustrated 502 and 503 in Figure i). It will be built in a typically standard language and architecture (such as RESTful or SOAP) to enable easy interface and flexibility of configuration to suit the users and their environment. Where the API 301 is accessed externally, it will provide security as required.

The output feeds represent an indication of a fault, together with an indication of the cause(s) of the fault which is identified by the RCA server 204, such that the user is able to determine causative factors and correlations with particular fault data. The information which is output by the core system has an impact on the degree to which processes can be evaluated and redesigned in order to eliminate and resolve future faults. For example, systematic errors in processing parameters can be identified where the samc fault occurs regularly, so that the user can then identi that the parameter in question (such as a threshold voltage in an electronic component) should be modified in a particular way (for example, reduction of the threshold voltage to avoid in-component overheating).

EWAP Dashboard 302: This is a software module (hosted or on premise) which takes the output from the API 301 and displays it in an appropriate form to suit users. It may also send out alerts and -13 -alarms proactively rather than just a passive display device. The EWAP Dashboard 302 maybe implemented using a dedicated user interface system, or may make use of existing user interface systems at the user's premises.

Whilst the components of this embodiment of the present invention are all shown on separate servers it maybe possible to combine onto a smaller, or split onto a larger number of servers in other embodiments of the invention, arranged so as to achieve the same data flow and functional effects.

io In physica' terms, the EWAP system may have the form of a computer program running on a dedicated server or distributed over a set or servers, which may interface with the existing components of a user's facility over a local or wide are network, or via the internet. Alternatively, the computer program may be hosted on components of the user's facility. The EWAP system is therefore equally capable of performing fault diagnosis and providing causative information from inside or outside the user's facility.

The present invention has been described above with reference to a number of exemplary embodiments and examples. It should be appreciated that the particular embodiments shown and described herein are illustrative of the invention and are not intended to limit in any way the scope of the invention as set forth in the claims. It will be recognized that changes and modifications may be made to the exemplary embodiments without departing from the scope of the present invention. These and other changes or modifications are intended to be included within the scope of the present invention, as expressed in the following claims.

Claims (10)

1. Claims 1. An Eary Warning and Prevention, EWAP, System for detecting and resoNing manufacturing and/or process faiths, comprising: means for receiving manufacturing and/or process data; means for interpreting the received data to determine a fault; means for performing root cause analysis to identify one or more causes of the determined fault; and means for outputting an indication of the identified fault and for providing io information relating to the determined one or more causes of the fault, wherein the system further comprises means for verifying the statistical significance of the output of the root cause analysis means.
2. 2. An EWAP according to claim 1, wherein the means for identifying a fault from the received data is arranged to perform profiling of the received manufacturing and/or processing data and to identify a faut from a profile of parametric data extracted from the received manufacturing and/or processing data.
3. 3. An EWAP system according to claim 1 or claim 2, wherein the means for receiving manufacturing and/or process data comprises one or more data pumps, each arranged to interrogate a database.
4. 4. An EWAP system according to claim 3, further comprising a data transformer server arranged to transform data received from the one or more data pumps into a format suitable for performance of root cause analysis.
5. 5. An EWAP system according to any one of claims ito 4, further comprising means for cleaning and validating the output from by the root cause analysis means.
6. 6. An EWAP system according to any one of the preceding daims, comprising a server arranged to host an application for determining whether further data is required in order to generate valid root cause analysis results.
7. 7. An EWAP system according to claim 6, wherein the hosted application is arranged to report on data quality.

   -15 -
8. 8. An EWAP system according to claim 6 or claim 7, wherein the hosted application is arranged to generate heuristics to guide the root cause analysis means.
9. 9. An EWAP system according to any one of claims 6 to 8 wherein the server is arranged to provide feedback control to the means for receiving data.
10. 10. An EWAP system according to any one of the preceding claims, further comprising a user interface means for presenting an indication of the identified fault and for providing information relating to the cause of the determined fault in real time. I0ii. An EWAP system according to claim 10, wherein the user interface means is arranged to output recommendations on data gathering where insufficient data is available to resolve an identified fault.12. An EWAP system according to any one of the preceding daims, wherein the verification means is arranged to contr& a fault thresh&d used by the root cause anabrsis means so as to enable one or more causes of the determined fault to be identified with a predetermined confidence level.13. An EWAP system according to claim 12 wherein the predetermined confidence level is associated with economic factors.14. An Early Warning and Prevention, EWAP, method for detecting and resolving manufacturing and/or process faults, comprising: receiving manufacturing and/or process data; interpreting the received data to determine a fault; performing root cause analysis to identify one or more causes of the determined fault; verifying the statistical significance of the root cause analysis; and outputting an indication of the identified fault and for providing information relating to the determined cause of the faffit.15. A computer program which, when executed by a processor, is arranged to perform the method of claim 14.