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 one 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 launch 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 manufacturing company and augment its own warranty system. Existing systems typically look out for tolerance, threshold or trend data, and they use this data to compare against pre-defined models or historic patterns of failure modes to detect which failure mode is most likely to be present and thus deduce the root cause. However there is nothing available which automatically detects and resolves the root causes of faults (whether previously known and defined or not) on-the-fly in real time or near-real time, both within and outside the factory. This, in the opinion of the inventors, is a reason why the Cost of Poor Quality is still a significant factor in manufacturing today, despite the technology contained in the state of the art.

The three aspects holding back the prior development of such a system both statically or dynamically are:

(i) the inability of a system to deal with incomplete or 'partial', disparate and/or 'dirty' (i.e. semantically and/ or syntactically incorrect due to poor manual inputting or systematic data capture failures) data including text; (ii) the inability of a system to generate root causes of previously unknown and/ or unclassified faults;

(iii) the lack of flexibility or 'tunability' of the system to accommodate for selecting the best root cause (and therefore the best fix) of any particular issue based on practical metrics such as cost saving, cost to fix, signal strength/probability of fix, environmental impact, speed of fix, completeness of fix etc.

It will be apparent to someone familiar in the field that the ability to detect, classify and resolve issues early relies on the capability to resolve with few data points and that this is synonymous with point (i) above in terms of data prevalence and quality; if the data are numerous and ordered, especially with a clear target signal, then there the task of resolving root causes becomes more straightforward. However by the same token, it might be 'too late' i.e. the problem might already be widespread in the field such as an expensive warranty recall or a ruined batch.

Conventional fault detection systems are shown in patent applications GB2476246, US2012/0226474, US2012/0005533, US2010/0138694, US2012/0173927,

US2010/060470, and US2004/0250166. None of these systems can reasonably deal with dirty and/or incomplete data. US2004/0250166 specifically requires pre- processed data. All of these systems specify a model or historical knowledge of the target fault a priori to identifying the root cause. None of these could reasonably be 'tunable' given that they are designed for certain explicit systems, i.e. US2012/0226474 is explicitly designed for turbo-machinery and has a priori knowledge;

US2012/0005533 is similarly designed specifically for "multi-host systems" i.e.

computer networks; US2012/ 0173927 is similarly designed specifically for data centres; US2010/060470 is similarly designed specifically for semi-conductors; GB2476246 specifies that the are a priori failure mode or modes, and so on. It is also to be noted that US2010/060470 contains its own tester and 'trouble collector' specific to the system.

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 which may overcome the limitations as noted above and thus can properly address the Cost of Poor Quality which cannot be resolved with prior art. This may comprise 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 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 may be arranged to perform 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 received from the one or more data pumps into a format suitable for performance of root cause analysis. This element may enable the EWAP to be 'domain-agnostic' (also referred herein as 'flexible'), i.e. it can be applied to any system and environment without standardising the inputs and in particular where there are heterogeneous data from disparate systems which need to be merged. This is a common situation for most real-life systems given that 'in-tolerance' failure inherently means that the 'failure markers' occur later on in the manufacturing or maintenance process than the root- cause data which is by definition all within tolerance. For illustration purposes, one example of this would be a warranty database which notifies where products have failed or not, and to compare this to the manufacturing and testing data which of course passed all tests (i.e. it was all 'in-tolerance') to enable the product to leave the factory.

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 application 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 may be arranged to generate heuristics to guide the root cause analysis means.

The server maybe arranged to provide feedback control to the means for receiving data such that recommendations can be generated on further data to be collected/ analysed to improve the result.

The EWAP system may further comprise 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.

The user interface means may be arranged to output recommendations on data gathering where insufficient data is available to resolve 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 with a predetermined confidence level.

The predetermined confidence level may be associated with economic factors.

A 'cost function' comprising ratios or real cost data maybe generated to enable the most economic root cause to be determined and therefore recommend the 'best fix' from the data provided. 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, 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 example, the Root Cause Analysis Solver Engine (RCASE) as developed by Warwick Analytical Software Limited) in a dynamic system. The specific example of RCASE comprises a set of proprietary, tunable, non-statistical algorithms which fall into the field of supervised, clustering algorithms. The term "tunable" relates to the "configurable" or "flexible" aspect of the present invention, in the sense that it can be applied to a number of different applications or data sources, through adjustment of parameters such as thresholds, and definitions of fault signatures. The flexibility is brought out because the root cause analysis algorithm is able to operate without any a priori knowledge of the mapping of parameters to error codes or issues. Consequently, new or unknown root causes or non-defined modes can be handled, which sets apart the present invention from conventional system which rely on parameter maps, or predefined fault signatures. The algorithm is thus dynamic and is able to evolve through learning new fault signatures.

The EWAP method therefore picks up a signal earlier than would otherwise be possible due to its constant feedback of a new 'failure marker' with existing clusters and alarm- thresholds based on confidence. Part of the value of the EWAP method is to reduce the time to identify similar faults (which might otherwise need manual classification rather than automatic parametric clustering), and particularly for latent or 'sleeper' warranty problems this could make a significant difference to outcomes e.g. preventing or mitigating mass recalls of a faulty product. Part of the capability of the EWAP method is the ability to merge and transform disparate data as above in order to serve different and disparate systems. There are many, many situations where the data are disparate and it is uneconomic or impractical to perform ETL (Extract, Transform, Load) first where a speedy dynamic system is required.

Above and beyond the usual 'dashboard' capabilities of visualising data, the root cause analysis of the invention has the following novel technical effects:

(i) It can identify and classify faults based on their parametric data profile even with dirty and/or incomplete data. 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 field.

(iv) It can generate many possible root causes and ranks them based on the relevant tunable metric as noted above such as cost of fix, certainty of fix etc.

(v) It can work with 'No Fault Found' sometimes known as 'No Trouble Found' or 'No Defect Found' situations where faults are intermittent and indeterminate by highlighting areas of correlation or causation in the manufacturing process. (vi) Where complete data are not available to resolve the problem, it can still identify possible root causes and actions to obviate the problem, or make

recommendations on the data gathering required to more accurately resolve it. This also means it can deal with a significant amount of 'false negatives' as well as 'false positives' data.

(vii) It has been optimised to run rapidly to allow for a practical real-time or near- real time dynamic application, for example in-database or in-memory within a company's IT systems. (viii) The system can be tuned to provide immediate course solutions with finer solutions produced over a longer time period.

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.

The description of exemplary embodiments of the present invention provided below is merely exemplary 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 explicitly but which would be understood by those skilled in the art, 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 l. 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 l, 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 relating to product design, manufacturing processes, and performance in the field, 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 Control (SPC) module 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.

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 subsystem 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 modules running either within the manufacturing company's various databases, or interfacing to those database, which interrogate the databases 400 continuously (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 typical, 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.

The source data may vary in nature by sector or technical field, and may be at least 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 application in aerospace, the source data may represent diagnostic data from a remotely-tested aircraft.

The source data may be incomplete or 'partial', disparate and/or 'dirt/ (i.e.

semantically and/ or syntactically incorrect due to poor manual inputting or systematic data capture failures) data, and may include text, numeric characters, a combination of both, although the skilled person will appreciate that a variety of data types may be retrieved from the databases 400. 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 analysis and other algorithms can be performed.

Root Cause Analysis (RCA) Server(s) 204:

This is an array of one or more servers running software modules 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, using information or entropy theory as examples of the underlying data processing technique. 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 power required. The computational output of this component feeds two other modules, 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, evidenced by a voltage recorded on a ground rail, for example. Rather than being a discrete fault, 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" or "failure 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. It will be apparent to someone familiar in the field that a 'failure marker' can be a parameter denoting improvement over a threshold not just an ΌΚ/fail' situation so that the EWAP system according to an embodiment of the invention can also be used for continuous improvement such as improvements in aerodynamics, fuel efficiency, quietness, and other desirable features which are not necessarily binary 'OK/fail' parameters.

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 performance data has been obtained, such as an operating temperature being close to a 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 to a particular profile defined by the three factors which have high values, rather than the absolute values, or the numerical 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 microcontroller is operating at too high a temperature. This could be represented directly 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 overactivity 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 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 empirically to 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. The RCA server 204 root cause results can be re-ranked, filtered and sensitised based on external parametric functions such as (i) cost to fix; (ii) speed to fix; (iii) certainty of fix; (iv) environmental impact of fix etc. etc.

Data Clean & Validation Server(s) 205:

This is an array of one or more servers running software modules which take the output from the root cause analysis server(s) 204 and perform one or more algorithms 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 algorithms. It may also incorporate artificial intelligence 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 and effective real-time failure-reporting output, which ensures applicability of the

EWAP system to real -world environments where the input data may be 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 less than 100% if the input data is incomplete or unclean. 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 example, they may capture 80% of product failures. Ideally, x should 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".

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 results 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 associated with economic factors.

As an example, if the EWAP system were to be built into a vehicle production plant, there maybe 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, potentially increasing the number of false negatives, and setting x low, decreasing the number of false negatives, but in turn failing to identify vehicles 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 maybe 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 set than if x were 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 economically 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

(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 correlation 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 heuristics where there is a limited or null result (sometimes known as a scattered, diffuse or unclear result) from the root cause analysis server(s) 204These 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 applications, 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 successful 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 vehicle chassis. - ι ₅ -

In this way the user will be guided to gather or clean more data so that the root cause of the particular fault might be discerned. In one embodiment, the RCA server 204 may be controlled by the search space application 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.

(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 order to potentially reconfigure and guide 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 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 1). 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 same fault occurs regularly, so that the user can then identify 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 alarms proactively rather than just a passive display device. The EWAP Dashboard 302 may be 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 may be 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.

In physical terms, the EWAP system may have the form of a computer program running on a dedicated server or distributed over a set or servers as a multi-core system, 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.