MONITORING AND CONTROLLING THE MONITORING OF VACUUM SYSTEMS

Abstract

A method of controlling monitoring of a vacuum system, the vacuum system, and the monitoring control system are disclosed. The method comprises: selecting at least one of a plurality of processes for monitoring the vacuum system from a data store storing the plurality of processes. Executing the at least one selected process Wherein one of the at least one selected processes comprises a process for monitoring a parameter of the vacuum system and for responding to changes in the parameter to trigger at least one of: execution of a further one of the plurality of processes; output of an alarm or notification signal; and output of a control signal for controlling operation of at least one component of the vacuum system.

Claims

1. A method of controlling monitoring of a vacuum system, said method comprising: selecting at least one of a plurality of processes for monitoring said vacuum system from a data store storing said plurality of processes; and executing said at least one selected process; wherein one of said at least one selected processes comprises a process for monitoring a parameter of said vacuum system and for responding to changes in said parameter to trigger execution of a further one of said plurality of processes.

2. The method according to claim 1, wherein at least some of said plurality of processes stored within said data store comprise one or more of: a process for monitoring a parameter of said vacuum system; a process for monitoring at least one of: a value and rate of change of a value output by at least one sensor sensing a parameter of said vacuum system; a process for comparing a value output by at least one sensor sensing a parameter of said vacuum system to a threshold value; and a process for performing a predefined mathematical function on at least one parameter sensed by a sensor in said vacuum system; and a process for adjusting a threshold at which to respond to changes in said parameter in dependence upon data from previously executed processes; and a process for triggering an alarm, notification or control signal.

3. The method according to claim 1, wherein said process of monitoring a parameter of said vacuum system comprises requesting said parameter from a data interface, said parameter requested comprising at least one of a current value of said parameter and one or more historic values of said parameter.

4. The method according to claim 1, wherein said step of selecting comprises one of: periodically selecting at least one of said processes for execution from said data store; selecting at least one of said processes for execution from said data store in response to an output of an executed process; and selecting at least one of said processes for execution in response to an input from a user.

5. The method according to claim 4, wherein said step of selecting comprises: periodically selecting one of said plurality of processes for execution every predetermined first period; periodically selecting another of said plurality of processes for execution plurality of processes for execution every predetermined second period, said predetermined second period being different to said predetermined first period.

6. The method according to claim 1, wherein said parameters comprise at least one of: temperature; flow rate; vibrations; counter values; pressure; and power.

7. The method according to claim 1, comprising in response to determining execution of one of said processes failing, terminating operation of said process.

8. The method according to claim 7, comprising following terminating of said operation of said process deleting said process from said data store.

9. The method according to claim 1, comprising storing data determined from execution of said process in a further data store.

10. The method according to claim 1, comprising periodically storing said process to said data store at preselected points during execution of said process.

11. The method according to claim 1, wherein said step of selecting comprises uploading said process for execution from said data store and decrypting said process prior to said execution.

12. The method according to claim 10, comprising encrypting said process prior to storing said process to said data store.

13. The method according to claim 1, comprising a further step of at least one of adding, updating or deleting at least one process from said data store.

14. (canceled)

15. A control system for controlling the monitoring of at least one vacuum system, said control system comprising: a processor; and a data store associated with said processor storing a computer program comprising a plurality of computer-executable instructions which when executed by the processor are operable to perform the method of claim 1.

16. The control system according to claim 15, further comprising a data store storing a plurality of applications each comprising a plurality of computer executable instructions operable when executed by said processor to control said processor to perform a corresponding plurality of monitoring processes, at least some of said plurality of monitoring processes comprising one or more of: a process for monitoring a parameter of said vacuum system; a process for monitoring at least one of: a value and rate of change of a value output by at least one sensor sensing a parameter of said vacuum system; a process for comparing a value output by at least one sensor sensing a parameter of said vacuum system to a threshold value; and a process for performing a predefined mathematical function on at least one parameter sensed by a sensor in said vacuum sensor; a process for adjusting a threshold at which to respond to changes in said parameter in dependence upon data from previously executed processes; and a process for triggering an alarm, notification or control signal.

17. A vacuum system comprising: the control system according to claim 15 for controlling the monitoring of said vacuum system; at least one of: a vacuum pump and an abatement unit; a plurality of sensors; and a data interface for receiving and storing data from said plurality of sensors.

18. A plurality of vacuum systems each comprising: the control system according to claim 15 for controlling the monitoring of said plurality of vacuum systems; at least one of: a vacuum pump and an abatement unit; a plurality of sensors; and a data interface for receiving and storing data from said plurality of sensors of each of said vacuum systems.

19. A method according to claim 1, wherein said process for monitoring a parameter of said vacuum system and for responding to changes in said parameter further triggers at least one of: output of an alarm or notification signal; and output of a control signal for controlling operation of at least one component of said vacuum system.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0067] Embodiments of the present invention will now be described further, with reference to the accompanying drawings, in which:

[0068] FIG. 1 schematically shows a monitoring control system, data store and vacuum system according to an embodiment;

[0069] FIG. 2 schematically shows a monitoring control system selecting and executing processes from a data store according to an embodiment;

[0070] FIG. 3 schematically shows a monitoring control system determining a process is corrupt and deleting the corrupt process;

[0071] FIG. 4 schematically shows a monitoring control system, data store and vacuum system according to an embodiment; and

[0072] FIG. 5 schematically shows a method of monitoring a vacuum system according to an embodiment.

DETAILED DESCRIPTION

[0073] Before discussing the embodiments in any more detail, first an overview will be provided.

[0074] The monitoring control system in some embodiments formed as a Smart Rules Engine is a lightweight workflow engine that uses re-usable building blocks to build diagnostic/prognostic models for vacuum and abatement equipment.

[0075] The Smart Rules Engine uses a data interface to communicate with the vacuum system. The smart rules engine controls monitoring of the vacuum system to analyse pump and abatement parameters to output information to a User Interface to allow for better servicing and understanding of the state of a system. Furthermore, it provides diagnostics/prognostics that can be understood and updated by non-software developers allowing the domain knowledge from users such as service engineers to be included in the monitoring of the system.

[0076] In some embodiments the smart rules engine can start and stop models or processes both locally and remotely. It is able to run models against different time intervals, e.g.: once a day, once a month or all the time. In addition, in some embodiments it can read and run encrypted and un-encrypted models. In order to protect itself, it can identify broken models and remove them from the system without adversely impacting the system or other running models.

[0077] The models or processes make use of built-in and custom blocks that may comprise graphical and business logic layers. The graphical interface component allows for more understandable communication between technical and non-technical persons. These blocks can be written to perform any task, e.g.: requesting data from a remote or local source or performing advanced mathematical functions. These blocks may involve the manipulation of data utilising domain knowledge to provide information to users about the state of the system.

[0078] Embodiments provide a monitoring control system that allows or provides: efficient CPU performance, smart management of model execution, dynamic deployment, data-input flexibility, custom creation In embodiments, the monitoring control system is formed as a modular computer program that can be expanded for use with new products without any major software re-engineering. Indeed embodiments allow new models to be provided to the data store and then selected, uploaded and executed without the need to restart the system.

[0079] FIG. 1 schematically shows a monitoring control system 10, data store 20 and vacuum system 30 according to an embodiment. The monitoring control system 10 is connected to a data store 20 which stores a plurality of processes or models for monitoring an integrated vacuum system 30. The monitoring control system 10 selects processes in the form of applications stored in the data store, uploads them from the data store, decrypts them and then executes them as required. During execution the processes acquires and processes data output from the vacuum system 30. The data may be received directly from the vacuum system or via a data interface (not shown). Alternatively, they may come via the web 25 which acquires data from different sources as required by the monitoring system.

[0080] When the monitoring control system 10 has finished executing a particular application it may encode it and store it back to the data store 20. In some embodiments, personnel may have access to the data store such that they can add, delete or amend applications within the data store. This allows threshold values to be updated for example or different mathematical functions to be performed.

[0081] FIG. 2 schematically shows how the monitoring control system 10 may execute a plurality of processes 12 in parallel and how these can be uploaded from data store 20 and stored back to data store 20 in some cases along with the data that the models generate. These processes 12 and data 14 associated with them may be uploaded from the data store 20 and executed by a processor on the monitoring control system 10.

[0082] In some embodiments the processes are stored in encrypted form in the data store 20 and the monitoring control system 10 encrypts or decrypts the processes when storing or uploading the processes to the data store 20. In some embodiments, the processes 12 and associated data 14 may be stored at preselected points during execution such that data is not lost if there is an interruption of service. Furthermore, where a process is configured to run periodically it may be downloaded to the data store between executions and then re-uploaded.

[0083] The ability to store these different models or processes enables scalability, recovery in the face of failure and the ability to manage both the processor and memory more efficiently.

[0084] FIG. 3 schematically shows how this system is also adept at managing failure of a particular process 12. Thus, in this example one of the models/processes 12 running within the monitoring control system 10 fails and this process is stopped and deleted from the monitoring control system and is also deleted from the data store 20. A message may be sent to a user interface 40 to notify the user of the failure of the process.

[0085] FIG. 4 schematically shows the vacuum system 30, data interface 20 and monitoring control system 10 of an embodiment. In this example vacuum system 30 comprises an abatement unit 32 and two vacuum pumps 34 and 36. Each of these different components comprise a number of sensors each of which output sensed data to data interface 50. These sensors may include pressure, temperature, flow rate and vibration sensors. They may also include power sensors for sensing the amount of power required to drive motors within the system and counters for counting the number of times a certain function has been performed since the component was installed or since the component was serviced. There may also be a timer to indicate the time elapsed since a previous service and/or counters to count of number of times certain thresholds have been exceeded.

[0086] Data interface 50 is an interface that receives data from one or more vacuum systems and stores the data in data store 52. Data interface also comprises, in this embodiment data store 20 that stores the processes in the form of computer applications that the monitoring control system can select for execution.

[0087] Monitoring control system 10 is linked to the data interface 50 and selects applications from data store 20 for executing on processor 18. When executing the processes the monitoring control system may request data from data store 52 within data interface 50 as required by the processes.

[0088] In operation monitoring control system 10 requests one or more applications from data store 20, and decodes the uploaded application using encoder/decoder 16 and stores the decoded application in cache 15. Processor 18 then executes the process and may generate notifications or alarms that are output to user interface 40 and/or it may trigger execution of a further process. Where that process has already been uploaded to monitoring control system 10 then that is executed by processor 18. Where the application is not within the monitoring control system 10 then it is requested from data store 20 and uploaded, decoded and executed. Once a process has completed execution then it is removed from cache 15. Data generated during execution of the process may used to trigger an alarm or process, and/or some or all of it may be stored to data store 52. If during execution the process is determined to be corrupt then it may be removed from the cache 15 and deleted from data store 20 and a warning to this effect output to interface 40.

[0089] In some embodiments, the monitoring system may only monitor and may not control the vacuum system, while in other embodiments the monitoring system may trigger a control signal to be sent back via data interface 50 to vacuum system 30 to stop operation or slow down operation of one or more of the components in response to the monitoring system detecting that some parameter is approaching a critical level.

[0090] Examples of the processes executed by processor 18 include the monitoring of parameters, the comparison of parameters and/or rate of change of parameters with threshold values, the triggering of alarms or notifications or the triggering of execution of one or more further processes, the application of a particular mathematical method to analyse changes in parameters. One or more of these different processes may be used to diagnose the condition of the vacuum system and/or to perform prognosis of future problems. This may enable servicing to be scheduled and/or rescheduled as required and it may also enable catastrophic failures to be inhibited.

[0091] The modular nature of this system enables applications within data store 20 to be generated and updated individually while other applications are still executing or are available for execution. Furthermore, as they are formed of simple process steps which are straightforward to encode and for which encoding blocks are available they can be updated and amended without the requirement for a skilled software engineer. Thus, as the vacuum systems 30 are amended with new or additional equipment and/or as service engineers discover more information regarding the operation of the vacuum system this can be included within the processes or models stored in data store 20 and the monitoring/diagnosis and prognosis of the vacuum system can be improved.

[0092] The domain logic used within the blocks is in effect reusable and the rules can be updated as required. Furthermore, as this is a modular system the amount of processing power required is both limited and controllable, by controlling the number of modules being executed at any one time. Furthermore, the system can be controlled remotely.

[0093] A user can interact with the system 10 via interface 40 to request certain processes to be performed and to start and stop the monitoring as well as to receive notifications.

[0094] The data interface 50 stores data from the vacuum system 30 and this data can be used for analysis and to help in the predictions of future system operation and thus in the updates of the processes stored in data store 20.

[0095] FIG. 5 shows a flow diagram schematically illustrating steps performed by the monitoring control system 10 of an embodiment when it is executing one of the processes. The first step within the process is to request the temperature at the pump inlet and this is performed in step S10. In step S20 the temperature is compared to a threshold value and if it is determined that it is not above the threshold then at step S30 the rate of temperature increase is determined to see if that is above a threshold. If neither are above a threshold then at S100 this process ends. This process will be repeated again at a later point as it is a process performed periodically to check that the inlet to the system is not blocked.

[0096] If at step S20 the temperature is determined to be above the threshold or if at step S30 the rate of temperature increase is determined to be above a threshold then step S40 is performed where the pressure at the pump inlet is requested. If this is determined to be above a pressure threshold at step S50 then an inlet block alert is triggered at step S70 and this will be displayed on the user interface 40. The process is then ended and the user may perform whatever steps are required to address this.

[0097] If at step S50 it is determined that the pressure threshold is not exceeded then it is checked how many times this pressure has been checked. This is performed by checking the output of a counter at step S60 and if the pressure check has not been performed three times then the pressure at the inlet is again requested after a predetermined time delay to determine if it has risen above the pressure threshold. If the counter indicates that the pressure has been checked three times then the process is ended.

[0098] This example process allows a temperature rise, or rate of temperature rise, that is above a threshold to be detected and to trigger a pressure check over a time period. This allows the monitoring system to both detect an unexpected increase in temperature and to determine whether the rise in temperature is due to a pressure increase which may indicate a blocked inlet. If no temperature increase is detected or if after a predetermined time it is determined that the pressure is not unduly high then the process can be stopped. In some cases where there was a temperature rise but no increase in pressure, a further process may be triggered to determine perhaps if vibration levels have risen above a certain level to check that the temperature is not rising for some other reason such as motor wear.

[0099] Although illustrative embodiments of the invention have been disclosed in detail herein, with reference to the accompanying drawings, it is understood that the invention is not limited to the precise embodiment and that various changes and modifications can be effected therein by one skilled in the art without departing from the scope of the invention as defined by the appended claims and their equivalents.

[0100] Although elements have been shown or described as separate embodiments above, portions of each embodiment may be combined with all or part of other embodiments described above.

[0101] Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are described as example forms of implementing the claims.