Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent
4907167
Skeirik
March 6, 1990
Title
Process control system with action logging
Abstract
An integrated system for process control in which a process supervisor procedure defines parameters for one or more controller systems (or control procedures). The supervisor procedure changes control parameters only in discrete changes, and the decision to act is sufficiently constrained that every change must be a significant change. Every change is logged (or otherwise reported out to human experts). Since every change is significant, the history of changes will provide a meaningful record which can be reviewed by human experts.
Inventors:
Skeirik; Richard D.
(Newark,
DE
)
Assignee:
E. I. Du Pont de Nemours and Company
(Wilmington,
DE
)
Appl. No.:
103118
Filed:
September 30, 1987
Current U.S. Class:
700/10
706/10
706/906
706/914
Field of Search:
364/496,513,131,132,148,300,550,138-139
U.S. Patent Documents
4215396
July 1980
Henry et al.
4616306
October 1986
Kuzma et al.
4628435
December 1986
Tashiro et al.
4642782
February 1987
Kemper et al.
4644479
February 1987
Kemper et al.
4648044
March 1987
Hardy et al.
4649515
February 1987
Thompson et al.
4658370
April 1987
Ermon et al.
4670848
June 1987
Schramm
4672529
June 1987
Kupersmit
4740886
April 1988
Tanifuji et al.
4752889
June 1988
Rappaport et al.
4754410
June 1988
Leech et al.
Other References
Edblad et al., U.S. Pat. No. 4,227,245 (Jumbo), cols. 58-59, 10/7/80. .
"Applying Artificial Intelligence to Process Control Systems", P. D. Christopherson, vol. 2 of Auton Control Pet, Petrochem Dealin, Proc IFAC Workshop, (1986) pp. 151-155. .
"Dispatcher: An Intelligent Approach to Factory Control", R. Zemel and M. Acock, Proceedings of the 1986 American Control Conference, (Jun. 18-20, 1986) vol. 1, pp. 152-155. .
"Experience in the Development of an Expert System for Fault Diagnosis in a Commercial Scale Chemical Process", P. S. Dhurjati et al., Foundations of Computer Aided Process Operations, Proceedings of the First International Conference of Foundations of Computer Aided Process Operations, Park City, UT, (Jul. 5-10, 1987). .
"Control Software Comes to Personal Computers", M. Manoff, Control Engineering, (Mar., 1984) pp. 66-68. .
Expert Systems, (ed. R. Forsythe 1984). .
P. Harmon and D. King, Expert Systems, (1985). .
D. Waterman, A Guide to Expert Systems (1984). .
"An Academic/Industry Project to Develop an Expert System for Chemical Process Fault Detection", D. E. Lamb et al., presented Nov. 13, 1985 at the Annual Meeting of the American Institute of Chemical Engineers, Chicago, Illinois. .
"Process Control Using Modular Package Software", Watson, EIII Conference Publications Number 102 (1973). .
"On-Line Process Simulation Techniques in Industrial Control Including Parameter Identification and Estimation Techniques", in Proceedings of the Eleventh Annual Advanced Control Conference (1985). .
"Real-Time Expert Systems in Process Control", the Digest of the IEEE Colloquium held 29 Nov. 1985 at Salford, U.K. .
"RESCU-On-Line Real-Time Artificial Intelligence", Ray Shaw, Computer Aided Engineering Journal, (Feb., 1987) pp. 29-30. .
"Expert Systems in On-Line Process Control", Robert L. More, Mark A. Kromer, (undated). .
"Plant Scale Process Monitoring and Control Systems: Eighteen Years and Counting", L. E. DeHeer, in the volume Foundations of Computer Aided Process Operations, Proceedings of the First International Conference of Foundations of Computer Aided Process Operations, Park City, Utah, Jul. 5-10, 1987 (1987) p. 33. .
"Application of Expert Systems to Process Problems", Sripada et al., Energy Processing/Canada, vol. 78, (1985) pp. 26-31. .
"Process Control Applications of Artificial Intelligence", K. W. Goff, Proceedings of the Refining Department of the American Petroleum Institute, vol. 65 (1986) pp. 26-31. .
"Expert Systems--Applications of AI in Engineering", William S. Faught, Computer (IEEE), (Jul. 1986). .
"Chemical Plant Fault Diagnosis Using Expert Systems Technology: A Case Study", Duncan A. Rovan, Reprints of Papers for IFAC Kiota Workship of Fault Detention and Safety in Chemical Plants, (Sep. 26, 1986). .
"Historical Data Recording for Process Computers", John C. Hale et al., CEP, (Nov., 1981), pp. 38-43. .
"A Real Time Expert System for Process Control", L. Hawkinson, et al., Artificial Intelligence Applications in Chemistry, (American Chemical Society 1986). .
"Using an Expert System for Fault Diagnosis", D. A. Rowan, Control Engineering, (Feb., 1987). .
"Plexys: The Plant Expert System Enhancement to KEE: Knowledge Aided Engineering and Plant Operations Analysis", Intellicorp EPPS, (Jun. 5, 1986). .
"AI and MAP in Processing Industries", Kane, Hydrocarbon Processing, (Jun., 1986). .
"Expert Systems: Are They the Next Generation of Process Controls?", Moore et al., InTech, (May, 1985) pp. 55-57. .
"Troubleshooting Comes Online in the CPI", Chemical Engineering, (Oct. 13, 1986) pp. 14-19..~
Primary Examiner:
Lall; Parshotam S.
Assistant Examiner:
Black; Thomas G.
Attorney, Agent or Firm:
Saidman, Sterne, Kessler & Goldstein
Claims
What is claimed is:
1. A computer-based method for operating a substantially continuous process, comprising the steps of:
(1) operating the process with one or more sensors connected to sense conditions in the process, and one or more actuators connected to change conditions in the process;
(2) controlling one or more of said actuators with a process controller in accordance with signals received from said sensors and in accordance with control parameters, said control parameters indicating a respective threshold, wherein attainment of said threshold as indicated by said signals creates an indicia for action; and
(3) repeatedly running a process supervisor procedure for selectively defining one or more of said control parameters for said process controller;
(4) wherein, for each of said control parameters, said process supervisor procedure is constrained not to make changes to said control parameters unless the indicia for action exceed said respective threshold; and
(5) wherein said process supervisor procedure reports every instance where it changes a control parameter.
2. The method of claim 1, wherein said process controller of step (2) uses a cycling step, and said process supervisor procedure of step (3) uses a cycling step.
3. The method of claim 1, wherein said process supervisor procedure uses a cycling step, and said process controller of step (2) operates in substantially real-time.
4. The method of claim 1, wherein said process supervisor procedure of step (3) comprises the step of being implemented using a computer running one or more programs, including a cycling process which repeatedly samples a plurality of signals corresponding t inputs, forms inferences from said inputs according to a stored knowledge base, and provides outputs in accordance with said inferences, and then goes into a dormant state having a duration limited by timing;
wherein said duration of said dormant state is sufficiently large that said process does not on average occupy more than 50% of the available CPU time of the computer;
and wherein said duration of said dormant state is selected to be sufficiently short that process fluctuations cannot diverge to an out-of-control situation during the periods when said process is dormant.
5. The method of claim 1, wherein said process supervisor procedure of step (3) comprises the step of defining parameters including parameters for a feedback control relation including a deadband on said control parameters.
6. The method of claim 1, wherein said process supervisor procedure of step (3) comprises the step of having a maximum iteration period significantly longer than the maximum iteration period of said process controller of step (2).
7. The method of claim 1, wherein said process controller of step (2) uses analog logic for controlling.
8. The method of claim 1, wherein said step of repeatedly running a process supervisor procedure comprises the step of running said process supervisor procedure using a cycling step.
9. The method of claim 1, wherein said control parameters of step (2) comprises the step of including goals of said process controller.
10. The method of claim I, wherein said respective threshold on said indicia for action of step (2) comprise the step of being dependent on the particular action in prospect.
11. The method of claim 1, wherein said respective thresholds on said indicia for action of step (2) comprise the step of being different for at least some of said control parameters.
12. The method of claim 1, wherein said process controller of step (2) and said process supervisor procedure of step (3) comprise processes running on the safe computer system.
13. The method of claim 1, wherein said process controller of step (2) and said process supervisor procedure of step (3) are both respective parts of the same software system.
14. A computer-based method for operating a substantially continuous process, comprising the steps of:
(1) operating the process with one or more sensors connected to sense conditions in the process, and one or more actuator connected to change conditions in the process;
(2) controlling one or more of said actuators with a process controller in accordance with signals received from said sensors and in accordance with control parameters; and
(3) repeatedly running a process supervisor procedure for selectively defining one or more of said control parameters for said process controller;
(4) wherein, for each of said control parameters, said process supervisor procedure is constrained not to make changes to said control parameters unless the amount of the change would exceed a certain threshold.
15. The method of claim 14, wherein said process supervisor procedure of step (3) uses a cycling step, and said process controller of step (2) operates in substantially real-time.
16. The method of claim 14, wherein said process supervisor procedure of step (3) comprises the step of implementing a feedback control relation including a deadband on at least some of said control parameters.
17. The method of claim 14, wherein said process supervisor procedure of step (3) comprises the step of having a maximum iteration period significantly longer than the maximum iteration period of said process controller of step (2).
18. The method of claim 14, wherein said process controller uses analog logic for controlling.
19. The method of claim 14, wherein said control parameters of step (2) comprise the step of including goals of said process controller.
20. The method of claim 14, wherein said certain thresholds of step (2) comprise the step of being different for at least some of said control parameters.
21. The method of claim 14, wherein said process controller of step (2) and said process supervisor procedure of step (3) comprise processes running on the same computer system.
22. The method of claim 14, wherein said process controller of step (2) and said process supervisor procedure of step (3) are both respective parts of the same software system.
23. A computer-based method for operating a substantially continuous process, comprising the steps of:
(1) operating the process with one or more sensors connected to sense conditions in the process, and one or more actuators connected to change conditions in the process;
(2) controlling one or more of said actuators with a process controller in accordance with signals received form said sensors and in accordance with control parameters, said control parameters indicating a respective threshold, wherein attainment of said threshold as indicated by said signals creates an indicia for action; and
(3) repeatedly running a process supervisor procedure for selectively defining one or more of said control parameters for said process controller;
(4) wherein, for each of said control parameters, said process supervisor procedure is constrained not to make changes to said control parameters unless the indicia for action exceed said respective threshold.
24. The method of claim 23, wherein, for each of said control parameters, said process supervisor procedure of step (3) comprises the step of being constrained not to make changes to said control parameters unless the amount of the change would exceed said respective threshold; and wherein said process supervisor procedure reports every instance where it changes a control parameter.
25. The method of claim 23, wherein, for each of said control parameters, said process supervisor procedure of step (3) comprises the step of being constrained not to make changes to said control parameters unless the amount of the change would exceed said respective threshold.
26. The method of claim 23, wherein said process supervisor procedure of step (3) comprises the step of implementing at least one feedback control relation including a deadband on at least some of said control parameters.
27. The method of claim 23, wherein said process supervisor procedure of step (3) comprises the step of having a maximum iteration period significantly longer than the maximum iteration period of said process controller of step (2).
28. The method of claim 23, wherein said process controller of step (2) uses analog logic for controlling.
29. The method of claim 23, wherein said control parameters of step (2) comprise the step of including goals of said process controller.
30. The method of claim 23, wherein said respective thresholds on said indicia for action of step (2) comprise the step of being different for at least some of said control parameters.
31. The method of claim 23, wherein said process controller of step (2) and said process supervisor procedure of step (3) comprise processes running on the same computer system.
32. The method of claim 23, wherein said process controller of step (2) and said process supervisor procedure of step (3) are both respective part of the same software system.
33. A computer-based method for operating a substantially continuous process, comprising the steps of:
(1) operating the process with one or more sensors connected to sense conditions in the process, and one or more actuators connected to change conditions in the process;
(2) controlling one or more of said actuators in accordance with signals received from said sensors and in accordance with control parameters;
(3) repeatedly running a process supervisor procedure for selectively defining one or more of said control parameters; and
(4) wherein at least some of said actuators are controlled in a feedforward relation to respective measured variables, and
wherein said feedforward relation includes a deadband.
34. The method of claim 33, wherein said process supervisor procedure of step (3) uses a cycling step, and said step (2) operates in substantially real-time.
35. The method of claim 33, wherein said process supervisor procedure of step (3) implements at least one feedback control relation including a deadband on at least some of said control parameters.
36. The method of claim 33, wherein said process supervisor procedure of step (3) has a maximum iteration period significantly longer than the maximum iteration period of said step (2) for controlling.
37. The method of claim 33, wherein said step (2) uses analog logic for controlling.
38. The method of claim 33, wherein said control parameters comprise the step of indicating a respective threshold, wherein attainment of said threshold as indicated by said signals creates an indicia for action, wherein said respective thresholds on said indicia for action comprise the step of being different for at least some of said control parameters.
39. The method of claim 33, wherein said respective feedforward relation of step (4) comprises the step of including a deadband applied to a measured variable.
40. The method of claim 33, wherein said step (2) for controlling and said process supervisor procedure of step (3) comprise processes running on the same computer system.
41. The method of claim 33, wherein said step (2) for controlling and said process supervisor procedure of step (3) are both respective parts of the same software system.
42. A computer-based method for operating a substantially continuous process, comprising the steps of:
(1) operating the process with one or more sensors connected to sense conditions in the process, and one or more actuators connected to change conditions in the process; and
(2) controlling one or more of said actuators in accordance with signals received from said sensors;
(3) wherein at least some of said actuators are controlled in a feedback relation with respective corresponding measured variables,
and said feedback relation includes the use of statistical filtering, and/or a deadband; and
(4) wherein at least some of said actuators are controlled in a feedforward relation to respective measured variables,
wherein said feedforward relation includes a deadband.
43. The method of claim 42, further comprising a process supervisor procedure step implementing at least one feedback control relation including a deadband on at least some of said control parameters.
44. The method of claim 42, further comprising a process supervisor procedure step having a maximum iteration period significantly longer than the maximum iteration period of said step (2) for controlling.
45. The method of claim 42, wherein said step (2) uses analog logic for controlling.
46. The method of claim 42, wherein said step (2) further comprises the step of using said control parameters comprise the step of indicating a respective threshold, wherein attainment of said threshold as indicated by said signals creates an indicia for action, wherein said respective thresholds on said indicia for action comprise the step of being different for at least some of said control parameters.
47. The method of claim 42, further comprising process supervisor procedure step, wherein said step (2) or controlling and said process supervisor procedure step comprise processes running on the same computer system.
48. The method of claim 42, further comprising a process supervisor procedure step, wherein said step (2) for controlling and said process supervisor procedure step are both respective parts of the same software system.
49. A computer-based process control system, comprising:
(a) one or more sensors connected to sense conditions in materials being processed, and one or more actuators connected to change conditions in the process;
(b) a plurality of process controllers, each connected to control one or more of said actuators in accordance with signals received from said sensors and in accordance with respective control parameters; and
(c) a process supervisor means for selectively defining one or more of said control parameters for said process controllers;
(d) wherein, for each of said control parameters, said process supervisor means is constrained not to make changes to said control parameters unless the amount of the change would exceed a certain threshold; and
(e) wherein said process supervisor means reports every instance where it changes a control parameter.
50. The system of claim 49, wherein said process supervisor means reports said control parameter change instances by means including voice messaging.
51. The system of claim 49, wherein said process supervisor means implements at least one feedback control relation including a deadband on at least some of said control parameters.
52. The system of claim 49, wherein said process supervisor means of element (c) has a maximum iteration period significantly longer than the maximum iteration period of said process controller of element (b).
53. The system of claim 49, wherein at least one said process controller of eleven (b) is an analog controller.
54. The system of claim 49, wherein one or more of said control parameters of element (b) goals of said process controller.
55. The system of claim 49, wherein said certain thresholds of element (d) are different for at least some of said control parameters of element (b).
56. The system of claim 49, wherein said process controller of element (b) and said process supervisor means of element (c) comprise processes running on the same computer system.
57. The system of claim 49, wherein said process controller of element (b) and said process supervisor means of element (c) are both respective parts of the same software system.
58. A computer-based process control system, comprising:
(a) one or more sensors connected to sense conditions in materials being processed, and one or more actuators connected to change conditions in the process;
(b) a plurality of process controllers, each connected to control one or more of said actuators in accordance with signals received from said sensors and in accordance with respective control parameters, said control parameters indicating a respective threshold, wherein attainment of said threshold as indicated by said signals creates an indicia for action; and
(c) a process supervisor means for selectively defining one or more of said control parameters for said process controllers;
(d) wherein, for substantially all of said control parameters said process supervisor means is constrained not to make changes to said control parameters unless the indicia for action exceed said respective threshold; and
(e) wherein said process supervisor means reports every instance where it changes a control parameter.
59. The system of claim 58, wherein said process supervisor means of element (c) has a maximum iteration period significantly longer than the maximum iteration period of said process controller of element (b).
60. The system of claim 58, wherein at least one said process controller of element (b) is an analog controller.
61. The system of claim 58, wherein said respective thresholds on said indicia for action of element (b) are different for at least some of said control parameters of element (b).
Description
PARTIAL WAIVER OF COPYRIGHT
CROSS-REFERENCE TO OTHER APPLICATIONS
BACKGROUND OF THE INVENTION
Process Control Generally
Modularity
Historical Process Database
Continuous Control Action
Control of Multiple Manipulated Variables
Expert Systems Generally Knowledge Input and Updating Expert System Knowledge Structures
Expert Systems for Process control
"RESCU"
"Falcon"
"ONSPEC Superintendent"
"PICON"
Self-tuning Controllers
SUMMARY OF THE INVENTION
BRIEF DESCRIPTION OF THE DRAWING
DESCRIPTION OF THE PREFERRED EMBODIMENTS
General Organization of Hardware and Procedures
Process Context
Historical Process Database
Supervisor and Build-Supervisor Procedure
Base Cycle Procedure
Sample Source Code
Build-Supervisor Procedure
Top-Level Menu
Data Source Specification
Block Timing Information
Primary Block Switching
Secondary Block Switching
Block Description Fields
Action Logging
Block Status
Feedback Blocks
Parameters
Block Operation
Data passed to the user routine
Sample Source Code
Feedforward Block
Parameters
Block Operation
Data passed to the user routine
Sample Source Code
Statistical Filtering Blocks
Parameters
Block Operation
Sample Source Code
User-Defined Program Block
Parameters
Block Operation
Build-User-Program Procedure
Block-Handling Utilities
Monitoring
Block Initialization
Build-Expert and Expert Procedures
Preferred Menu Structure
Standardized Data Interface
Constructing the Expert System
Sample Expert System
Expert Rule Structure
Retrieval Rules
Analysis Rules
Action Rules
Generating the Expert Procedure
Generating Source code
Sample Source Code
CLAIMS
A portion of the disclosure of this patent document contains material which is subject to copyright protection . The copyright owner has no objection to the facsimile reproduction by anyone of the patent disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.
CROSS-REFERENCE TO OTHER APPLICATIONS
The following applications of common assignee contain some common disclosure, and are believed to have effective filing dates identical with that of the present application:
EXPERT SYSTEM WITH NATURAL-LANGUAGE RULE UPDATING (filed Sept. 30, 1987: Ser. No. 103,050);
EXPERT SYSTEM WITH THREE CLASSES OF RULES (filed Sept. 30, 1987: Ser. No. 102,832);
PROCESS CONTROL SYSTEM WITH RECONFIGURABLE EXPERT RULES AND CONTROL MODULES (filed Sept. 30, 1987: Ser. No. 103,014);
PROCESS CONTROL SYSTEM WITH ON-LINE RECONFIGURABLE MODULES (filed Sept. 30, 1987: Ser. No. 103,047); and PROCESS CONTROL SYSTEM WITH MULTIPLE MODULE SEQUENCE OPTIONS (filed Sept. 30, 1987: Ser. No. 103,124).
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to expert systems (also known as knowledge-based systems), to process control systems, and to hybrids thereof.
2. Discussion of Related Art
Various known teachings which are believed to be related to various ones of the innovations disclosed in the present application will now be discussed. However, applicant specifically notes that not every idea discussed in this section is necessarily prior art. For example, the characterizations of the particular patents and publications discussed may relate them to inventive concepts in a way which is itself based on knowledge of some of the inventive concepts. Moreover, the following discussion attempts to fairly present various suggested technical alternatives (to the best of applicant's knowledge), even though the teachings of some of those technical alternatives may not be "prior art" under the patent laws of the United States or of other countries. Similarly, the Summary of the Invention section of the present application may contain some discussion of prior art teachings, interspersed with discussion of generally applicable innovative teachings and/or specific discussion of the best mode as presently contemplated, and applicant specifically notes that statements made in the Summary section do not necessarily delimit the various inventions claimed in the present application or in related applications.
Process Control Generally
To compete in global markets, manufacturers must continually improve the quality and cost of manufacture of their products. They must do this in the face of changing market needs, changing raw materials costs, and reduced staffing. Automatic computer control of the manufacturing process can play an important part in this, especially in the chemical process industry. Most process plants already have the basic automatic regulating controls (low level controls) needed to control the plant at a given operating point. These provide the foundation for higher level supervisory controls (referred to here as supervisor procedures or supervisors) that seek to improve quality, reduce cost, and increase plant uptime by moving the plant to a different operating point. These changes can be made directly via the lower level controls, or indirectly via the plant operator.
Although supervisory controls have been in use for years, they have lacked a number of desirable features. To best improve quality and cost, a supervisor procedure should:
help control the quality of the end product;
reduce the cost of operating the plant;
help avoid unnecessary upsets or shutdowns;
work effectively with plant operators;
act in concert with standard operating procedures; and
be supportable by plant operating and support people.
To measure quality, a supervisor procedure should ideally have access to measurements of the basic properties of the product which affect its value and usefulness to the customer. Since most product properties measurements are sampled (and are measured in a laboratory), the supervisor should have access to a historical process database which can store these measurements as well the basic process data from the lower level control systems. Since sampled measurements and the process itself normally include some components of random variation, the supervisor should include statistical tests which can determine if a sequence of sampled measurements is varying normally around its aim value (i.e. is "on aim"), or has shifted significantly from aim (is "off aim").
To control quality, a supervisor procedure should have the capability to change the operating point of the process (via the lower level controls) when a measured property goes off aim. It should have the ability to act in response to new data or statistical tests, or to act at regular time intervals. It should also be able to preemptively change the operating point when basic conditions (such as plant production rate) change. It should allow a number of independent control objectives, and new ones should be easy to add. Since the process may use any number of different low level controllers, the supervisor should be able to communicate with all of them.
To work effectively with plant operators, a supervisor procedure should be understandable. It should carry out its control actions in a way that is natural and understandable to operators. It should provide enough information about its current state and its past actions for the operator to judge its performance. It should inform the operator when it acts (or chooses not to act), explaining how much action was taken, where it was taken, why it was done, and what effect it might have. Since the effect of actions taken to control quality and reduce cost can last longer than a single shift, it should provide a record of all its actions.
To act appropriately under all circumstances, to reduce operating costs in a way consistent with quality, to help avoid unnecessary upsets and shutdowns, and to take operating procedures into account, a supervisor should ideally include the logical decision making capabilities of expert systems. Because decisions will normally focus on a specific task or area, many independent expert systems should be allowed. The expert systems should have access to the many sources of process measurements, laboratory measurements, and control system parameters. They should be able to reason symbolically using that information, and to make their decisions take effect through communication and control actions. To work effectively, the supervisor should be able to control its expert system functions in concert with its other functions.
To be supported by plant personnel, the supervisor should be easy to use. It should allow common control actions to be set up easily, with a means of customizing less common functions. It should allow control actions to be changed easily. It should have a simple means of specifying the informative messages to be generated about it actions. Its expert systems should allow process knowledge to be entered, stored, and updated in a way that plant support people understand. It should provide a simple, appropriate knowledge representation which naturally includes data retrieval, symbolic reasoning, and effective means of implementing decisions in the plant. The knowledge structure should allow any authorized plant expert to enter knowledge, without restricting access to those who know computer languages or have memorized special rule structures.
The present invention addresses many of these concerns.
Normally supervisory control has been thought of separately from another higher level of control called optimizing control, which seeks to minimize operating cost. In some cases, the requirement to minimize variation in product properties (i.e. to improve product quality) is absolutely primary, so that cost optimization only be performed as an objective secondary to quality objectives. In this environment, use of classical optimization techniques to achieve cost optimization may not be possible. In other cases, it has been possible to integrate a balance of supervisory and optimizing control into the supervisor.
Modularity
Supervisory control systems using a modular structure are well known. For example, the Process Monitoring and Control-1000 (PMC-1000) control package marketed by Hewlett Packard is a modular control package which can function as a supervisory control system. PMC modules, called blocks, perform alarming and limiting, proportional/integral/derivative control, trending, driving an electrical output, running programs, and other functions. Each block writes one or more output values into memory. To build PMC control structures, the user creates as many blocks as needed and links them to other block output values. A new runnable system must then be generated. Once the system is running, parameters such as gain constants can be changed, but the linking of blocks is fixed. PMC runs on a base time cycle, and blocks can only be scheduled to execute at multiples of the base cycle time. Although PMC maintains a historical database, it cannot be used for control, and does not effectively store intermittently sampled data. It is believed that there is no maximum number of blocks.
It is believed that some earlier discussion of the significance of modularity in process control software is found in Watson, "Process Control Using Modular Package Software," IEE Conference Publications number 102 (1973) (which is hereby incorporated by reference).
Historical Process Database
A database of historical process data is generally described in Hale and Sellars, "Historical Data Recording for Process Computers," 77 Chem. Eng'g Progress 38 (1981) (which is hereby incorporated by reference).
Continuous Control Actions
In classical feedback and feedforward control, the prior art teaches that the best control results are achieved by making continuous changes to the process. In computer control, where cyclic operation forces changes to be made in discrete steps, many small, frequent steps are conventionally preferred. While in principle this gives the best possible control performance, such control actions are very difficult to visualize. In fact, it may be impossible to determine what actions have been taken by what control strategies, and how long the control strategies have been making changes. This makes it very difficult to judge whether control strategies are working properly, or even if they are working at all. This method of control also runs counter to the methods used by operators, who generally make a few significant changes and wait to see the effects.
In feedback control, the use of a deadband is a well known way of avoiding small actions caused by a noisy measurement. (That is, if the control variable falls within a specified deadband of values surrounding the goal value, the control value will not be manipulated.) This deadband, as is well known, helps to avoid instability in control systems. Statistical process control also tends to reduce the number of feedback control actions. However, neither technique is sufficient to make all control actions understandable, since some actions will not be considered noisy.
The use of a feedforward relation among control variables is also well known among those skilled in the art of process control. That is, in some cases, whenever one variable changes (e.g. if a particular control variable is manipulated for any reason), another variable will also be manipulated according to a predetermined relationship. For example, in a distillation process, it may be desirable to immediately decrease the heat input whenever the rate of feed of the crude feed stock is decreased. In feedforward control, a deadband is normally not used.
Control of Multiple Manipulated Variables
In many process control applications, several manipulated variables must be jointly controlled in a single control loop (e.g. in some relation to a single measured variable). A special (and very common) case of this is seen in many situations where a single manipulated variable can normally be used, but alternate manipulated variables should be used instead if the first-choice manipulated variable becomes constrained. When human operators optimally handle problems of this kind, their choice of which output to change will often be made heuristically, based on cost, quality, response dynamics, and process stability.
"Decoupling" is a conventional way of reducing multi-input multi-output problems to sets of single-input single-output problems. In decoupling, it is usually assumed that all of the manipulated variables should be changed.
A different but related problem arises when a number of manipulated variables ("knobs") can be changed to respond to a single measured variable. Operators often use a heuristic approach in choosing which knob (or knobs) to manipulate, and sometimes choose not to act. The heuristic approach may consider cost, quality, response dynamics, and process stability. It may include alternate knobs to be used when all of the preferred knobs are constrained. Classic control methods are not well suited to this approach.
Expert Systems Generally
The term "expert system" is used in the present application (in accordance with what is believed to be the general usage at present) to refer to a system which includes non-trivial amounts of knowledge about an underlying problem. Almost any control system which has been customized for a particular application might be argued to embody small amounts of relevant knowledge in its very structure, but the term expert system is generally used only for systems which contain enough accessible information that they can usefully supplement the knowledge of at least some (but normally not all) human users who must deal with problems of the type addressed. Expert systems at their best may serve to codify the expert knowledge of one person (a "domain expert"), so that that person's expertise can be distributed and made accessible to many less expert users who must address problems of a certain type. Some well-known successful examples include a medical diagnostic program (MYCIN) and a diagnostic program which assists mechanics working on diesel engines.
As these examples show, one very common area of application for expert systems has been fault diagnosis. Many other areas of application have been recognized; see generally Expert Systems (ed. R. Forsythe 1984) (which is hereby incorporated by reference); P. Harmon and D. King, Expert Systems (1985) (which is hereby incorporated by reference); and Donald Waterman, A Guide to Expert Systems (1984) (which is hereby incorporated by reference).
Knowledge Input and Updating
One of the very general problems in the area of expert systems is how knowledge is to be gotten into an expert system in the first place. That is, specialists in artificial intelligence often assume that a "knowledge engineer" (that is, a person who is experienced and competent in the specialized computer languages and software commonly used for artificial intelligence applications) will interview a "domain expert" (that is, a person who actually has expert knowledge of the type of problems which the expert system is desired to be able to address) to extract his expertise and program an expert system accordingly. However, there are some very important drawbacks to this paradigm. First, competent "knowledge engineers" are not readily available. In particular, the requirements of maintaining a real-world application (such as an expert system for chemical process control, as in the preferred embodiments disclosed below) are such that it is dangerous to rely on a sufficient supply of "knowledge engineers" to go through the iterations necessary to not only input the knowledge base reliably, but also maintain the software base once it is created.
The rapidly developing art of software engineering has shown that one of the key requirements for a large software system is that it be maintainable. Thus, for example, the software system must be set up so that, after the technologist who first puts together an expert system is gone, it can be maintained, modified, and updated as necessary by his successors.
Thus, one key problem in the area of expert systems is the problem of maintenance and updating. Especially in more complex real-world applications, it is necessary that a large software structure, such as that required for a sophisticated expert system, be maintainable. For example, in an expert control system, control strategies may be modified, new control strategies may be introduced, sensor and/or actuator types and/or locations may be changed, and the economic factors relevant to cost versus throughput versus purity tradeoffs may change. Normally, expert systems attempt to maintain some degree of maintainability by keeping the inference rules which the processor executes separate from the software structure for the processor itself. However, this normally tends to lead to a larger software structure which operates more slowly.
Specialists in expert systems also commonly assume that expert systems must be built in a symbolic processing environment, e.g. in environments using LISP or PROLOG. Even for complex processes, a single large knowledge base is usually assumed. The program which processes the knowledge therefore requires complex procedures for processing the knowledge base, and these are typically coded separately from the knowledge. This leads to large software structures which execute slowly on conventional computers. Specialized "LISP machines" are commonly recommended to speed up the inference process.
Expert System Knowledge Structures
Published material regarding knowledge based systems (expert systems) has proposed several classifications for the types of rules which are to be used. For example, U.S. Pat. No. 4,658,370 to Erman et al., which is hereby incorporated by reference, describes "a tool.. for building and interpreting a knowledge base having separate portions encoding control knowledge, factual knowledge, and judgmental rules." (Abstract). The method described in this patent still appears to rely on the availability of a "knowledge engineer." This patent appears to focus on the application of an expert system as a consultation driver for extracting the relevant items of knowledge from a human observer. Knowledge is separated into factual knowledge such as classes, attributes, allowed values, etc., which describe the objects in the domain; judgmental knowledge, which describes the domain (and its objects) in the form of rules; and control knowledge describing the problem solving process to be used by the inference procedure in processing the knowledge. (The control knowledge has nothing to do with control of an external process.) This knowledge structure is designed to make the task of knowledge engineering easier, and to make the knowledge system and its reasoning during a consultation easier to understand. The knowledge base is written in a specialized programming language. This is a very powerful structure, which requires a very high skill level.
Expert system development tools which are designed to make the input of knowledge easier have been developed. U.S. Pat. No. 4,648,044 to Hardy, et al., describes "a tool for building a knowledge system.. [which] includes a knowledge base in an easily understood English-like language expressing facts, rules, and meta-facts for specifying how the rules are to be applied to solve a specific problem". (Abstract). Although this tool is not as complex as some current expert systems tools, the knowledge must be entered in a rigidly structured format. The user must learn a specialized language before he can program the knowledge base. Despite some simplification in the development process, a fairly high skill level is still required.
Expert Systems for Process Control
Chemical processing plants are so complex that few people develop expertise except in limited areas of the process. Plants run around the clock, production rates on a single line are very high, and startup is usually long and costly, so improper operation can be very costly. It has also been found that, in a complex chemical processing plant, some operators can achieve substantially higher efficiencies than others, and it would be advantageous if the skill level of the best operators could be made generally available. Expert systems promise significant benefits in real-time analysis and control by making scarce expertise more widely available. However, application of expert systems in this area has not progressed as far as it has in interactive, consultative uses.
Integration of expert system software with process control software poses special problems:
First, there is the problem of how the software structure for an expert system is to be combined with the software for a process control system. Several expert systems which have been suggested for process control have used an expert system as the top-level supervisor procedure for the control system.
Second, as discussed above, many process control strategies have difficulty with situations where there are multiple control parameters (inputs to the process) which could be manipulated. That is, for processes which have only one primary control parameter (as many do), the problem of what value to set for that control parameter is in significant ways a much simpler problem than the question of which one or ones of multiple control parameters should be addressed, and in which direction.
It should also be noted that the use of an expert system to design a new process (or to debug a newly introduced process) has significantly different features from the problem of optimally controlling an existing process. Similarly, while expert systems have also been applied to the automatic distribution of jobs to multiple workstations through an automated materials handling system (an example of this is the DISPATCHER Factory Control System developed by Carnegie Group Inc.), the queuing problems presented by the allocation of different types of materials in batches to many parallel assembly workstations making different products are quite different from the problems in continuously operating single line processes, particularly chemical processes.
"RESCU"
The system known as "RESCU" resulted from a collaborative demonstration project between British government and industry. See, e.g., Shaw, "RESCU online real-time artificial intelligence," 4 Computer-Aided Engineering J. 29 (1987) (which is hereby incorporated by reference); and the Digest of the IEE Colloquium on `Real-Time Expert Systems in Process Control`, held 29 November 1985 at Salford, U.K. (which is hereby incorporated by reference). From available information, it appears that this is a real-time expert system which was developed to provide advice on quality control in an detergent plant. The system searches for a hypothesis about the plant which is supported by process data, and uses it as the basis for advice. This system also uses a single knowledge base for the entire plant and thus requires complex inference control methods.
"Falcon"
"Falcon" is a fault diagnosis system for a chemical reactor, which monitors up to 30 process measurements and seeks to identify a set of up to 25 failures in the process. This was developed as a demonstration project between DuPont, the Foxboro Company, and the University of Delaware, and is described, for example, in D. Rowan, "Using an Expert System for Fault Diagnosis," in the February 1987 issue of Control Engineering, which is hereby incorporated by reference. See also "Troubleshooting Comes On Line in the CPI" in the Oct. 13, 1986, issue of Chemical Engineering at page 14, which is hereby incorporated by reference. This system required several man years of development, and because it is programmed in LISP, it has proven difficult to maintain the knowledge base through process changes.
"ONSPEC Superintendent"
The "ONSPEC Superintendent" (TM), marketed by Heuristics Inc., is a real-time expert systems package which monitors data from the ONSPEC (TM) control system. See Manoff, "On-Line Process Simulation Techniques in Industrial Control including Parameter Identification and Estimation Techniques," in Proceedings of the Eleventh Annual Advanced Control Conference (1985) (which is hereby incorporated by reference); and Manoff, "Control Software Comes to Personal Computers," at page 66 of the March
1984 issue of Control Engineering (which is hereby incorporated by reference). The "Superintendent" monitors for conformance with safety and control procedures and documents exceptions. It can also notify operators, generate reports, and cause control outputs.
"PICON"
The PICON (TM) system, which was marketed by Lisp Machines, Inc. (LMI), was apparently primarily intended for real-time analysis of upset or emergency conditions in chemical processes. It can monitor up to 20,000 input process measurements or alarms from a distributed control system. It uses a single knowledge base (e.g. containing thousands of rules) for an entire process. To handle such a large number of rules, it runs on a LISP computer and includes complex inference control methods. PICON must be customized by a LISP programmer before the knowledge base can be entered. The domain expert then enters knowledge through a combination of graphics icons and Lisp-like rule constructions. See, for example, L. Hawkinson et al. "A Real-Time Expert System for Process Control," in Artificial Intelligence Applications in Chemistry (American Chemical Society 1986), which is hereby incorporated by reference, and the R. Moore et al. article in the May 1985 issue of InTech at page 55, which is hereby incorporated by reference.
Self-tuning Controllers
Another development which should be distinguished is work related to so-called "self-tuning controllers." Self-tuning single- and multiple-loop controllers contain real-time expert systems which analyze the performance of the controller (See "Process Controllers Don Expert Guises", in Chemical Eng'g, June 24, 1985). These expert systems adjust the tuning parameters of the controller. They affect only low-level parts of the system, and use a fixed rule base embedded in a microprocessor.
SUMMARY OF THE INVENTION
In this section various ones of the innovative teachings presented in the present application will now be discussed, and some of their respective advantages described. Of course, not all of the discussions in this section define necessary features of the invention (or inventions), for at least the following reasons: (1) various parts of the following discussion will relate to some (but not all) classes of novel embodiments disclosed; 2) various parts of the following discussion will relate to innovative teachings disclosed but not claimed in this specific application as filed; 3) various parts of the following discussion will relate specifically to the "best mode contemplated by the inventor of carrying out his invention" (as expressly required by the patent laws of the United States), and will therefore discuss features which are particularly related to this subclass of embodiments, and are not necessary parts of the claimed invention; and (4) the following discussion is generally quite heuristic, and therefore focusses on particular points without explicitly distinguishing between the features and advantages of particular subclasses of embodiments and those inherent in the invention generally.
Various novel embodiments described in the present application provide significant and independent innovations in several areas, including:
systems and methods for translating a domain expert's knowledge into an expert system without using a knowledge engineer;
software structures and methods for operating a sophisticated control system while also exploiting expert system capabilities;
generally applicable methods for controlling a continuous process; and
innovations, applicable to expert systems generally, which help provide highly maintainable and user-friendly experts.
Various classes of embodiments described herein provide a process control system, wherein a process which operates substantially continuously is controlled by a system which includes (in addition to a process control system which is closely coupled to the underlying process and which operates fairly close to real time, i.e. which has a maximum response time less than the minimum response time which would normally be necessary to stably control the underlying process) at least some of the following features:
(1) A supervisor procedure, which has a modular structure, and retrieves process measurements from the process control system (or other process data collection systems), passes control parameters to the process control system, and communicates with people. Preferably, the supervisor includes the capability for statistical process control. The supervisor preferably runs on a computer system separate from the process control system.
(2) The supervisor procedure can preferably call on one or more expert system procedures as subroutines. This is particularly useful in control applications where there are multiple possible manipulated variables, since the expert system(s) can specify which manipulated variable (or variables) is to be adjusted to achieve the end result change desired, and the supervisor system can then address simpler one-dimensional control problems.
(3) Preferably, at least some users can call on a build-supervisor procedure which permits them to define or redefine modules of the supervisor procedure by editing highly constrained templates. The templates use a standardized data interface (as seen by the user), which facilitates the use in control actions of data from a wide variety of systems. The templates in the available template set preferably contains highly constrained portions (which are optimized for the most common functions), and pointers to functions which can be customized by the user.
(4) Preferably, the build-supervisor user can also call on a build-user program procedure, which allows fully customized control functions to be programmed by sophisticated users. The build-user program procedure can also be used to create customized message generation functions. These can be used to generate messages describing the actions of the supervisor, and also to call other sub-procedures, such as the expert procedures.
(5) Preferably at least some users are also permitted to call on a build-expert procedure which can be used to construct an expert system. Knowledge is specified by user input to a set of highly constrained, substantially natural language templates. The templates use a standardized data interface (as seen by the user), which facilitates the use in the expert system of data from a wide variety of systems. The completed templates can then be compiled to produce a runnable expert system. Preferably, the user can also retrieve, examine, and modify the input from previously specified templates. Thus, an expert system can be modified by recalling the templates which specified the current expert system, modifying them, and recompiling to generate a new runnable expert.
(6) A historical process database advantageously standardizes the access to current and historical process data by the supervisor and expert procedures. This is particularly useful for collecting the results of laboratory characterizations over time of the underlying process.
Control of Continuous Processes
The goals in management of a substantially continuous process include the following:
(1) Maximizing quality: In the chemical process industry, it is important to reduce variation in measured properties of the product, and to control the average measured properties at specified aim values.
(2) Minimization of cost of manufacture: The process must be operated in a way that efficiently uses energy and feedstocks without compromising quality objectives. Upsets and inadvertent process shutdowns, which adversely affect quality and production rate, and reduce the total utility (fractional uptime) of the plant, are all costly and must be avoided.
Control of Multiple Manipulated Variables
As noted above, in many process control applications, several manipulated variables must be jointly controlled in a single control loop (e.g. in some relation to a single measured variable). A special (and very common) case of this is seen in many situations where a single manipulated variable can normally be used, but alternate manipulated variables should be used instead if the first-choice manipulated variable becomes constrained. When human operators optimally handle problems of this kind, their choice of which output to change will often be made heuristically, based on cost, quality, response dynamics, and process stability.
One novel approach to this problem (which is used in several of the preferred embodiments below) is to decompose the multiple-variable problem into a set of single-variable problems. An expert procedure is used to decide which control parameter(s) to adjust, and one or more from a set of single-input single-output procedures are used to make the adjustment(s). Not only does this facilitate quality, cost, and plant operability objectives, but it results in control strategies which act properly over a much wider range of conditions. Correct actions are taken, where conventional control methods would make no action or wrong actions. This improves the usefulness of the control strategy to the operator, and leads to higher use of the controls.
The various novel ideas described below are particularly advantageous in such multiple control parameter problems. In the presently preferred embodiment discussed below, a dimethyl terephthalate process (DMT) process is presented as an actual example to show the advantages achieved by the various novel ideas disclosed in this context.
Discrete Control Actions
As mentioned above, control systems that continuously change manipulated parameters are very difficult to monitor. Since operators depend on the supervisor procedure to maintain important product properties and process operating conditions, it is important that they be able to understand and judge supervisor performance. By restricting supervisor changes to a reasonably small number of significant discrete actions, supervisor performance becomes much more understandable.
One novel teaching stated in the present application is an integrated system for process control in which a process supervisor procedure (which is preferably the top level procedure) defines parameters for one or more control systems (or control procedures). The supervisor procedure changes control parameters only in discrete actions, and the thresholds for the decision to act are preferably made large enough (for each control parameter) that every action must be a significant change.
A related novel teaching herein is that every control action taken by the supervisor should be reported out to plant personnel in a substantially natural language message. Preferably, instances where action would be desirable but is not possible (because of constraints or other unusual circumstances) should also be reported. Preferably, a cumulative record of the messages is kept, and is available for review by operators and plant support people. Preferably, the message should report the time, amount, location, and reason for each action. Other relevant information, such as the time stamp of relevant sampled data, and the nature of statistical deviations from aim should preferably be included as well. Since every action is significant, and the number of actions is reduced, the cumulative record provides a meaningful record of supervisor performance.
This is particularly advantageous for systems where some of the relevant time constants are so slow that dynamic process responses last several hours (or longer). A new operator coming on duty at a shift change can use the cumulative record to judge what effects to expect from supervisor actions on the previous shift.
The use of a deadband in feedforward action is one novel means that is advantageously used to discretize supervisor actions. Feedforward action is taken only when the measured value changes by more than the deadband from its value at the last action. This generates a series of discrete changes in the manipulated variable, which can be effectively logged and evaluated by operators.
Statistical filtering of discretely measured values also serves to reduce control actions to a few significant changes. Statistical tests, as is well known, distinguish normal variation around the average from significant deviations from the average. In most cases, a number of measurements will be needed to indicate a deviation. By only acting on statistical deviations, relatively few, but significant, actions will result.
Expert Systems for Process Control
A general problem with expert systems is how the expert system software is to be integrated with process control software. Several expert systems which have been suggested for process control have used an expert system as the top-level supervisor procedure for the control system. However, several of the novel embodiments disclosed herein achieve substantial advantages by departing from this conventional structure. For one thing, if the expert system is the top level procedure, then it becomes more difficult to accommodate more than one expert in the system (or, to put this another way, the potential modularity of the expert system cannot be fully exploited). Thus, one significant advantage of several of the novel embodiments disclosed here is that use of more than one expert system within a single integrated system becomes much more advantageous.
Types of Process Control Systems
It should also be noted that the use of an expert system to design a new process (or to debug a newly introduced process) has significantly different features from the problem of optimally controlling an existing process. While various ones of the novel ideas disclosed herein may have significant applications to such problems as well, the presently preferred embodiment is especially directed to the problem of optimally controlling an existing operating process, and the various novel ideas disclosed herein have particular advantages in this context.
A significant realization underlying several of the innovations disclosed in the present application is that the structure of expert systems for process control applications can advantageously be significantly different from that of other expert system problems (such as consultative expert systems problems, in which a human is queried for information). The Hardy et al. and Erman et al. patents illustrate this difference. Consultative expert systems seek to substantiate one of a number of possible causes by interactively querying the user about the symptoms. Such systems must use complex knowledge representations and inference methods to minimize the number of user queries by carefully selecting the information they solicit. Moreover, since the user is not an expert, the system should be able to explain why it is requesting information.
In contrast, the real-time process problem is much simpler. The information needed by the expert is typically in the form of process measurements, which can be rapidly retrieved from process control and data systems without human intervention. There is much less need to minimize the requests for information. In fact, it may be faster to retrieve all the data that could be relevant to the problem than to determine what data is relevant. Moreover, since the experts will run automatically, there is no need to explain the reasoning during the inference process. As long as the rulebase is not too large, the process control expert can operate effectively using a simple "forward chaining" (or data driven) inference method. There is no need for the complex "backward chaining" procedures used in the consultative systems. Moreover, if a number of modular expert subprocedures are used within a single process, each expert tends to be smaller, and is more likely to work effectively in forward chaining mode. The presently preferred embodiment is especially directed to process control and monitoring, and the novel ideas disclosed herein have particular advantages in this context. However, various ones of the novel ideas may have significant applications to other problems as well.
It is believed to be a significant innovation to use expert system techniques to point to the direction of action in a multi-parameter control problem, as discussed above. One advantage is that the use of the expert permits more cases to be handled; for example, when one control parameter is up against its limits, the expert system can specify another parameter to be changed. The expert can also be especially advantageous in preventing a wrong action from being taken: in some types of processes it is conceivable that erroneous control strategies could potentially cause property damage or injuries, and the natural language inference rules of the expert (possibly combined with a more quantitative optimization scheme) can usefully ensure that this cannot happen. Thus, one advantage of various of the process control expert system embodiments disclosed in the present application is that they facilitate reliable implementation of a control strategy which (primarily) prevents a clearly wrong action from being taken, and (secondarily) permits minimizing costs.
In particular, it is especially advantageous to use a knowledge based (functional) structure where the rules are constrained to be of the three types described in the context of a process control application. The retrieval rules permit the predominantly quantitative sensor data (and other input data) to be translated into a format which is suitable for expert system application, and the control rules provide a translation back from expert system reasoning into an output which matches the constraints of the control problem.
The present invention is particularly advantageous in controlling processes which are substantially continuous, as distinguished from job shop processes. That is, while some computer-integrated manufacturing systems focus primarily on issues of queuing, throughput, statistical sampling of workpieces for inspection, etc., substantially continuous processes (such as bulk chemical synthesis and/or refining processes) typically demand more attention to issues of controlling continuous flows.
Expert Systems Generally
The present application contains many teachings which solve specific problems and offer corresponding advantages in the sub-class of expert systems used for process control, or even the sub-sub-class of expert systems used for control of substantially continuous processes. However, the present application also discloses many novel features which could be adopted into many other types of expert systems, and/or into many other types of control applications, while still retaining many (if not all) of the advantages obtained in the context of the presently contemplated best mode.
Similarly, while the present application describes numerous novel features which are particularly applicable to rule-based forward-chaining expert systems, some of the innovations described herein are believed to be very broadly novel, and could be adapted for use with other types of expert systems too.
Natural-Language Rule Statements
One of the innovative teachings in the present application provides an expert system tool in which knowledge is entered into the knowledge base through a limited set of pre-defined, highly constrained, natural-language knowledge structures which are presented as templates. In typical previous expert systems, knowledge is coded in the strict syntactical format of a rule or computer language, which allows great flexibility in knowledge representation. The person entering the knowledge (hereafter referred to as the developer) must learn the syntax, must choose an appropriate knowledge representations, and must formulate syntactically correct input.
In contrast, by restricting the developer to constrained, pre-defined structures, the need to learn rule or language syntax and structure is eliminated. Moreover, if the number of such pre-defined knowledge structures is small enough, the total knowledge representation in the expert system can be easily understood. Thus, a knowledge engineer is not needed. The domain expert can enter the knowledge to build an expert system directly. The developer's input can then be translated automatically into an operational expert system. The developer need not be concerned with or aware of the specific language or system used to implement the expert.
Another innovative teaching is that the knowledge entered into the pre-defined natural-language structures is stored in substantially natural-language form. This permits the knowledge to be revised at any time in the form in which it was originally entered: the developer simply recalls the stored template information, modifies it, and stores the modified knowledge. This is also simple enough to be done by the domain expert. The modified knowledge can then be automatically translated into a modified operational expert.
Another significant advantage of several of the disclosed novel embodiments for creating an expert system is that the expert can be significantly more compact and faster in execution. This is achieved by integrating the expert system's rules with the code which performs the inference function. This allows many independent runnable expert systems to be created. Moreover, the ease and simplicity of knowledge updating can still be preserved by maintaining the natural language form of the knowledge. The knowledge base can easily be reviewed and modified without hindrance from the specific inference method used in the runnable system.
Another novel feature of several of the disclosed embodiments is the use of a standardized data interface (as seen by the user) in the knowledge templates, which facilitates the use in the knowledge base of data from a wide variety of systems. Expert systems are allowed to require data from process or laboratory measurements (both current and historical), or data collected from other sources (such as on-line analyzers), or data and parameters from the process control systems. A standard interface to all such data sources facilitates use of the data in expert systems, since domain experts usually lack the programming expertise that would otherwise be needed to access these data sources.
Expert System Rule Types
As mentioned above, previous expert systems tools normally use a rule or computer language which allows great flexibility in knowledge representation. One innovative teaching in the present application is the restriction of the knowledge structure within an expert system to rules of three highly constrained types. The three rule types are: (1) retrieval rules, which each assign one of several descriptors to a name in accordance with the values of numeric inputs; (2) analysis rules, which each can assign a descriptor to a name in accordance with the descriptor/name assignments made by other rules; and (3) action rules, which either execute or don't execute a command in accordance with the descriptor/name assignments made by other rules.
Preferably only the retrieval rules include numeric operations. Preferably only the action rules can enable execution of an external command (i.e. of a command which does not merely affect the operation of the expert procedure). Preferably each of the action rules requires only a logical test for the assignment of a descriptor to a name. Preferably none of the action rules can assign a descriptor to a name.
While this organization of an expert system's structure is especially advantageous in the context of a process control expert system, it can also be applied to other types of expert systems. In a process control system, the relevant inputs will normally be process data, laboratory data, or control system parameters. The relevant outputs will normally be executable procedures which affect the operation of control or supervisor systems, or communicate with operators or domain experts. This teaching could also be applied to expert systems generally, in which other input and output functions are more important.
For example, in consultative use, retrieval rules need not be confined to numeric inputs, but could accept the natural language descriptor/name assignments as input from the user. To better control the requests for input, such consultative retrieval rules could advantageously execute contingent upon a test for the previous assignment of a descriptor to a name.
In general, this structuring of the inference rules provides for a more understandable expert. The retrieval rules provide access to process and control system data, and translate from quantitative input data into a natural language form. The emulation of natural-language reasoning is concentrated as much as possible in the analysis rules, which capture knowledge in a form which might be used to communicate between domain experts. The action rules translate from the natural language inference process back to output procedures which are meaningful in the computer and control system being used.
Modular Organization
The organization preferably used for process control has substantial advantages. The top level procedure is a modular process supervisory controller. The supervisor modules allow flexible specification of timing and coordination with other modules. Modules carry out commonly used control functions, using data specified through a standard data interface, as well as calling user customized functions. User customized functions might generate messages, perform unusual control actions, or call expert system procedures. Using the build-supervisor procedure, users can define or redefine modules by editing highly constrained templates which include a standard data interface specification. The standardized data interface (as seen by the user) facilitates communications with an extremely wide variety of systems. Dynamic revision is achieved by storing the user input to the constrained templates as data in a storage area accessible to both the supervisor and build-supervisor procedures. The running supervisor examines the stored data to determine which functions have been specified for that module, and what data sources have been specified through the standard data interface. The supervisor then calls an appropriate modular function and passes the user-specified data.
This organization is especially advantageous in providing parallelism and branching in control strategies. That is, the modular organization of the presently preferred embodiment permits at least the following capabilities:
(a) control strategies for more than one independent control application can be defined and updated;
(b) control strategies for more than one lower level process control system can be defined and updated;
(c) alternative control strategies can be defined and stored, so that an expert system (or other software or user command) can switch or select between control strategies merely by selecting or "de-selecting" modules;
(d) timing and coordination of module functions is facilitated;
(e) multiple independent expert system procedures can be utilized within a single supervisor;
(f) more than one user can define control strategies by accessing different modules, simultaneously if desired.
Another innovative teaching herein is that each supervisor module (or, less preferably, less than all of the module types) should preferably contain a pointer to optional user-customized functions. These functions can be used to generate informative messages about module actions, or a sophisticated user can implement unusual or non-standard control functions, or other customization utilities (such as the build-expert procedure in the presently preferred embodiment) can be used to generate functions accessed in this manner.
This structure is "modular" in the sense that users can call up and modify the various blocks separately; but, as will be discussed below, the command procedures which perform the standardized block functions are not necessarily separate within the source code. That is, modularity is advantageously achieved by storing the template-constrained user inputs to each block as data; when the user wishes to modify the block, the data is translated back into corresponding fields in the template.
Preferably, one of the modular functions in the supervisor is statistical filtering. This is particularly useful in that statistical filtering can be introduced wherever it is advantageous, without requiring extensive custom programming by the users. As described above, statistical filtering is advantageous both for avoiding overreaction to insignificant changes, and also for aiding the understanding by plant operators by reducing the number of actions.
One of the novel teachings contained in the present application is that the use of statistical filtering helps to minimize the number of control parameter adjustments performed by the expert system, which in turn is very advantageous (as discussed below) in providing an understandable log of control actions taken.
Sequencing Modular Blocks
One innovative teaching herein is a system for process control having a modular supervisor procedure which includes novel module timing and sequencing methods. Users can preferably specify modules by editing highly constrained templates, which include several specifiers for methods to be used in controlling and coordinating module execution. Preferably the module timing options include: (1) execute module function at fixed time intervals; (2) execute module function when new data becomes available for a specified data source; (3) execute module function whenever another module executes; (4) execute module function only on programmatic request; and combinations of these. Preferably a standardized data interface is used to specify the data source for the second of these options.
Integration of Expert Procedures
The integration of expert systems into process control has been a challenging problem. Most previous attempts to use expert systems in process control have used LISP based expert systems running on a dedicated machine, often a symbolic processing machine. Usually only one expert system with a single large knowledge base is created for a process. Since the knowledge base could contain many rules, a complex knowledge representation and inference process are needed to make inferences fast enough for real-time use. The expert system typically runs independently, scheduling its own activities, and thus is effectively the "top level" procedure. Using a top level expert makes it more difficult to accommodate more than one expert system. (Another way to regard this area of advantage is to note that, without the inventions contained in the present application, the potential modularity of the expert system cannot be fully exploited.)
Several of the novel embodiments described herein achieve substantial advantages by using more than one expert system subprocedure within a single integrated system. Since expert decisions will normally focus on a specific task or area, the modularity of the problems can be exploited in the structure of the expert system. Also, if the experts run under control of the supervisor, it is much easier to coordinate the decisions of the expert systems with the control actions of the supervisor. Since many important uses of expert systems will affect control actions, this is an important factor.
Another advantage of a modular structure, where expert systems are included as independent procedures called by the supervisor, is that the overall process control system is more reliable. A badly or incompletely functioning expert system within an overall supervisor system will affect only the functions it specifically interacts with. However, the failure of a top level expert system, which controls timing and execution of control functions, could disable all supervisor functions. The modular structure also has significant advantages in maintenance and debugging.
Thus, the organization preferably used for process control has substantial advantages. The top level procedure is a cycling procedure which functions as a process control supervisor. The supervisor process can call on one or more expert system procedures, and the user can call on a build-expert procedure which can reconfigure one of the expert systems already present, or create a new expert system. The supervisor procedure can preferably also call on a historical data base.
The modular organization described is especially advantageous, as discussed above, in providing parallelism and branching in control strategies. This is especially advantageous in process control situations, since the appropriate strategies for different circumstances can be fully pre-defined by the user, and he can rapidly switch between pre-defined strategies as the need arises.
Historical Process Database
The use of a historical database of process data in combination with a process supervisor procedure and/or expert system procedure is particularly advantageous. In the presently preferred embodiment, a historical database is used which can provide a time-stamp with each piece of output data, to clearly indicate provenance, and can retrieve the stored data (for a given parameter) which bears the time-stamp closest to a given time. The historical database can preferably maintain a record of continuously measured process data (such as temperature, pressure, flow rate), as well as discretely sampled, time-delayed measurements, such as laboratory measurements. The database greatly facilitates the use of laboratory (or other sampled type) measurements. Because of the time delay in making laboratory measurements, the value of the measurement when it becomes available in the database will correspond to the continuously measured data for the instant at which the measurement sample was actually taken, which might be several hours in the past. The historical database allows time delayed measurements and their corresponding continuous measurements to be used together. This is advantageous for balancing component material flows in the process. In the presently preferred embodiment, the historical process database may be thought of as providing a way to "buffer" time-stamped data and provide a standardized data interface, but it also permits other functions to be served.
The historical database also advantageously provides a basis for statistical tests. Some statistical tests will require a number of past measurements, which can be retrieved from the database. The database also advantageously allows the calculation of time average values of measurements. This can be useful in dampening noisy signals for use in a control action. In general, the database advantageously serves to buffer data input from a number of sources, standardizing access from the supervisor and expert procedures.
One of the innovative teachings in the present application is an integrated system for process control in which a process supervisor procedure (which is preferably the top-level procedure) is configured as a modular software structure, with modules which can be revised by a user at any time, without significantly interrupting the operation of the process supervisor. The supervisor can define control parameters for many process control procedures, and can retrieve data from many sources (preferably including a historical database of process data, which can provide time-stamped data). The supervisor can also call on various expert subprocedures. Preferably the expert subprocedures can also be modified by an authorized user at any time, by calling up and editing a set of natural-language rule templates which correspond to the rules being executed by the expert subprocedure.
One of the innovative teachings in the present application is an integrated system for process control in which the user can customize the process supervisor procedure with reference to a standardized data interface. The data values to be used by the supervisor are specified in the standard interface by two identifiers. The first identifies which (software) system and type of value is desired. The value of a setpoint in a particular distributed control system, the value of a sensor measurement in a particular process monitoring system, the value of a constraint from a process control or supervisor system, and time averages of sensor measurements from a particular historical database are examples of this. The second identifier specifies which one of that type of value is desired, for example the loop number in the distributed control system.
Data values specified through the standard interface may be used as measured values, manipulated values, or as switch status values indicating an on/off status. Preferably the interface allows the user to specify data in any of the relevant process control and data collection systems used for the process, or for related processes. Preferably, the interface also allows specification of data (both current and historical) in a historical process database. Since multiple control systems (or even multiple historical databases) may be relevant to the process, the standard interface greatly facilitates the use of relevant data from a wide variety of sources.
BRIEF DESCRIPTION OF THE DRAWING
The present invention will be described with reference to the accompanying drawings, wherein:
FIG. 1 schematically shows the structure of hardware and procedures preferably used to embody the novel process control system with expert system capabilities provided by various of the innovative features contained in the present application.
FIG. 2 is a schematic representation of the flow of information in the expert system structure preferably used.
FIG. 3 shows the template used for a retrieval rule in the presently referred embodiment, together with a sample of a retrieval rule which has been entered into the template.
FIG. 4 shows an example of a different kind of retrieval rule, known as a calculation rule.
FIG. 5 shows an example of an analysis rule 220.
FIG. 6 shows the presently preferred embodiment of the template for action rules, and an example of one action rule which has been stated in this format.
FIG. 7 shows an example of a chemical synthesis processing layout in which the method taught by the present invention has been successfully demonstrated. FIG. 8 schematically shows the structure preferably used for the supervisor procedure 130
and the build-supervisor procedure 810.
FIG. 9 shows a menu which, in the presently preferred embodiment, is presented to the user by the build-supervisor procedure 810 to select a template to provide user inputs to define or modify a block within the supervisor procedure.
FIGS. 10-13 show specific templates which, in the presently preferred embodiment, are presented to the user by the build-supervisor procedure to provide input to define or modify a feedback, feedforward, statistical filtering, or program block, respectively.
FIG. 14 shows a block-editing utility menu presented to the user, in the presently preferred embodiment, by the build-supervisor procedure.
FIG. 15 shows a flow chart for the base cycle procedure used in the supervisor procedure in the presently preferred embodiment.
FIG. 16 shows a menu which, in the presently preferred embodiment, is the top-level menu presented to the user by the build-supervisor procedure, and FIG. 17 shows a menu which is the top-level menu within the build-expert procedure.
FIG. 18 is another schematic representation of the interrelations among the various procedures which permit user customization of functionality.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
General Organization of Hardware and Procedures
FIG. 1 schematically shows the structure of hardware and procedures preferably used to embody the novel process control system (with expert system capabilities) provided by various of the innovative features contained in the present application. An underlying process (for example a chemical process) is very schematically represented as a single pipe 160, on which sensors 156 and one actuator 158 are explicitly shown. Of course, real world examples are substantially more complex; FIG. 7 shows the chemical process flow of a sample system in which the presently preferred embodiment has been successfully demonstrated. The various actuators 158 are controlled, in accordance with feedback signals received from various sensors 156, by one or more controllers 154.
In the presently preferred embodiment, the controller 154 is configured as a pneumatic proportional, integral, derivative (PID) controller. However, a wide variety of other controller technologies and configurations could be used. Pneumatic controllers are used in this example because they are common in the chemical process industry, and match well with the feedback requirements of chemical process control. Alternatively, an all-electronic distributed control system could be used instead. Moreover, the controller functionality could be different, e.g. a proportional/integral controller or a proportional controller could be used instead. In the presently preferred embodiment, the PID controller 154 is directly controlled by a computer control system 152. (This system 152 is referred to, in the various examples of user menus shown, as "PCS" (process control system.) The computer controller system 152 and the PID controller 154 may be regarded together as a single first level controller 150, and could easily be configured in that fashion (as with a distributed digital control system) to implement the present invention.
The control system 150 receives at least some of its parameters 132 (e.g. setpoints or feedforward ratios) from a supervisor procedure 130, which is preferably a higher level of control software. (In many of the sample user menus and forms shown, the supervisor procedure 130 is referred to briefly as "ACS.") The supervisor not only receives inputs 157 indirectly (or directly) from various sensors 156, it also receives lab measurement data 162, and also can issue calls to and receive inputs from the expert system 120, as will be described below.
In the presently preferred embodiment, the supervisor and build-supervisor procedures run on a minicomputer (e.g. a VAX 11/785), while the computer control system 152 is a PDP-11.
The supervisor 130 is preferably also connected to a historical process data base 140, which directly or indirectly receives the inputs from the sensors 157 and the off-line lab measurements 162. Thus, when the supervisor needs to access a value
157 or 162, it is not necessary for it to call on a physical device or read a real-time signal. It can simply call a stored value (together with a time stamp) from the database 140. However, many of the advantages of the present invention could also be obtained without using the historical process data base 140.
In addition, the supervisor 130 preferably also embodies a statistical control system. Statistical control systems, as are well known in the art of chemical processes, are advantageous when the process characteristics and measurement characteristics are subject to significant random variation, as they normally are in the chemical process industry. Statistical filtering tests are preferably performed to filter out statistically normal variation, and ascertain whether a process has significantly deviated from its current goal or average. (Alternatively, the statistical filtering functions could be performed elsewhere in software, e.g. in the database software.)
The supervisor procedure 130 is preferably run as a cycling process, and can call multiple expert systems 120 when indicated. (In many of the sample user menus and forms shown, the expert and build-expert procedures are referred to briefly as "PACE.")
A sample realistic process context (in which numerous innovative features have been successfully demonstrated) will first be described. The operation of the historical process database will next be described, since that provides a standardized data interface to which many of the other functions connect. Next, the functioning of the build-supervisor procedure will be described in detail, since that provides many details of how the supervisor is configured in the presently preferred embodiment, and after that the organization of the supervisor procedure itself will be discussed in greater detail. In later sections, the structure of the expert systems preferably used will be described in detail, and the operation of the build-expert procedure which constructs the expert systems will also be described in detail.
Sample Process Context
FIG. 7 schematically shows a sample embodiment of a chemical process incorporating several novel features described in the present application. The system shown is one in which various novel aspects set forth in the present application have been advantageously demonstrated.
It should be understood that the present invention provides a tool of very broad applicability, which can be used in many processes very different from that of FIG. 7. Thus, for example, various of the claims herein may refer to sensors which sense "conditions" in a process, or to actuators which change "conditions" in a process, without reference to whether one sensor or many sensors is used, whether one or several parameters is sensed by respective ones of the sensors, whether the actuators are valves, motors, or other kinds of devices, etc.
FIG. 7 shows part of the distillation train of a process in which paraxylene is air oxidized to make terephthallic acid, which is then esterified with methanol and refined to dimethyl terephthalate (DMT). DMT is sold as a bulk product, and commonly used as a polyester precursor. The esterification process will produce a significant fraction of the impurity methyl formyl benzoate (MFB). One of the key objectives in a DMT synthesis process is controlling the compositional fraction of MFB, since it affects the properties of products made from DMT. The refining train shown in FIG. 7 will reduce the average MFB fraction to a fairly constant level which i s(in this example) about 22 ppm (by weight).
The crude feed 702 will typically have a composition which is (by weight) about 74% DMT, about 20% orthoxylene (and related components which tend to recycle with the orthoxylene), about 5% methyl hydrogen terephthalate (MHT), and about 0.2% of methyl formyl benzoate (MFB). The MFB-depleted product 740 is preferably further refined to reduce the MHT fraction.
The crude feed 702 is fed into approximately the middle of a first distillation column 710. The column 710 is heated at its base by a steam reboiler 712. The steam flow is controlled by a flow controller 714 (which is connected to an actuator
716 and a sensor 718.) Similarly, the feed flow controller 704 is connected to an actuator 706, and a sensor 708. The column 710, as operated in the presently preferred embodiment, has internal pressures and temperatures which range from about 230 Torr at about 230.degree. C. at its bottom to about 55 Torr at about 70.degree. C. at its top. The vapor stream 720 is passed through a condenser 722, and some of the resulting condensate is fed back into the column as reflux 724. The product stream 726
has a mass flow rate of about 20% of the crude feed 702, and is recycled. A bottom product 728 is fed to the top of a second distillation column 730. The second distillation column has a steam reboiler 732 near its bottom (controlled by a steam flow controller 734, actuator 736, and sensor 738). The pressures and temperatures in the second column 730 (which in the user screens of the presently preferred embodiment is frequently referred to as the "MFB column") range from about 240.degree. C. at about 235 Torr at the bottom of the column to about 70 Torr and about 190.degree. C. at the top of the column. The bottom product 740 of the column 730 (which has a mass flow of about 0.8 of the crude feed 702) is the MFB-purified product. (In this product the fraction of MFB will on average have been reduced to about 22 ppm, for the conditions given.) The top product 742 of the column 730 is passed through a condenser 744 and reintroduced into column 710 as a bottom feed. (Column 710 is referred to, in the specific example given below, as the "xylene column".) The mass flow in the loop 728/742 is quite large; typically the mass flow of flow 728 will be about three times the mass flow of the crude feed 702.
In addition, a third distillation column, in the presently preferred embodiment, is operated in parallel with a middle section of column 710. This third column 750 is fed a side draw stream 752 from the first column 710. The vapor stream 754 of column 750 is passed through a condenser, and part of the condensate is reintroduced to column 750 as a reflux 758. Most of the remaining condensate is reintroduced to first column 710 as an upper middle feed. Similarly, the liquid stream 762 of third column 750 is partly reintroduced as a bottom feed after being vaporized in the reboiler 764, but is also partly fed back into column 710 as a lower middle feed 766. The additional separation provided by the third column 750 enhances the net compositional segregation of MFB. The middle product 768 of the third column 750 is a low-flow-rate product flow (typically 0.003 times the mass flow of the crude feed 702), and this product flow removes most of the undesired MFB impurity from the system. The temperatures and pressures in the third column 750 range from (in this example) about 230.degree. C. at about 260 Torr at the bottom of the column to about 60 Torr at about 125.degree. C. at the top of the column. Stream 761 is a small purge stream removing intermediate materials.
In the sample embodiment, the three primary control points for control of MFB composition are the steam feed to the MFB column reboiler 730, which is controlled by flow controller 734; the steam feed to the xylene column reboiler 710, which is controlled by flow controller 714; and the feed of crude feed stock to the xylene column 710, which is controlled by flow controller 704. Numerous other controllers, pumps, and other process equipment maintain the temperatures, pressures, and flow rates at other points in the process. In accordance with principles well known in the art of chemical engineering, this serves to maintain mass and energy balances and compositional trends consistent with the ultimate control objective, which is to maintain a high and constant purity in the product stream 740.
Historical Process Database
In the presently preferred embodiment (as shown in FIG. 1), the supervisor 130 receives data primarily through a historical process data base 140, which directly or indirectly receives the inputs from sensors 157 and off-line laboratory measurements 162. Thus, when the supervisor needs to access a value 157 or 162, it is not necessary for it to call on a physical device or read a real-time signal, since it can simply call a stored value (together with a time stamp) from the database
140.
In the preferred embodiment, every data value provided by the historical database has a timestamp attached. Data are received in at least two ways: first, some parameters are received as nearly continuous data flows (more precisely, as high-sampling-rate time series). For example, the data 157 from sensors 156 (e.g. temperature sensors) will be received as a series of digital values from analog-to-digital converters 155. In the presently preferred embodiment, compression algorithms are used to reduce the storage requirements of this data, and permit a usefully long period of time to be represented without requiring impractical amounts of storage space. However, this operation (which includes both compression and decompression algorithms) is essentially invisible to the supervisor procedure 130.
Secondly, lab analysis data 162 can also be stored in the historical database 140. For example, compositional measurements must normally be done off-line. A physical sample will be pulled from the physical process flow and sent to the laboratory for analysis. The resulting lab analysis value is entered into the historical database, timestamped with the time the sample was taken.
A third source of data is simulations: running processes can be simulated, using any of a variety of currently available simulation methods, and predicted conditions can be stored in the historical database (together with the proper timestamp). Thus, for example, control strategies can access data generated by complex real-time simulations.
Thus, many of the advantages of the database 140 derive from the fact that it can provide a timestamp to accompany every piece of data it provides. In addition, in the presently preferred embodiment, the database also stores the name and units for each parameter. As presently practiced, the database is also able to perform a variety of other functions, including monitoring, activating alarms if certain sensed measurements reach certain critical levels, output processing (i.e. loading data out to physical devices), generating plots of selected parameters over time, as well as other common database functions (e.g. generating reports).
This structure is quite flexible: for example, in alternative embodiments, one supervisor procedure could interface to multiple databases 140, and/or one database 140 could receive calls from more than one supervisor procedure 130 (which optionally could be running on different systems).
Supervisor and Build-Supervisor Procedures
The present application describes some very advantageous features of novelty in the supervisor procedure 130 and build-supervisor procedure 810, which could optionally and less preferably be incorporated in embodiments which did not include at least some of the innovative features described in the context of the expert and build-expert systems 110 and 120.
The supervisor procedure 130 preferably used contains a modular software structure which greatly facilitates initial setup and also modification. Preferably the supervisor procedure 130 is a cycling procedure constructed as a set of blocks. That is, each block defines a core procedure which (as seen by the user, both initially and whenever called up for modification) is substantially self-contained, and which (in the presently preferred embodiment) is of one of four types. Preferably each block is either a feedforward block, a feedback block, a statistical filter block, or a program block. (That is, preferably each block is configured by user inputs to a template for one of these block types.) Preferably each kind of block also has the capability to call a user subroutine, and in fact the "program blocks" used in the presently preferred embodiment perform no other function.
The functional templates and data interface definitions for the most commonly used functions are pre-defined, but the user can also add code of his own if he wishes to do so. Providing standardized templates for the most commonly used functions expedites initial functional definition, and also facilitates maintenance, but sophisticated users are not prevented from writing their own customized functions (such as messaging).
Feedback blocks are used when a manipulated parameter must be adjusted to keep a measured parameter near a desired goal. Feedforward blocks are used when two parameters (which are not necessarily in a causal relation) are linked, i.e. when a manipulated parameter must be adjusted to keep it in some ratio (or other relation) to a measured parameter. Statistical filtering blocks are used, in the presently preferred embodiment, to provide the advantages of statistical process control, and to facilitate minimizing the number of control parameter adjustment actions.
Preferably a maximum number of blocks is predefined. (In the presently preferred embodiment, 200 blocks is the preset maximum, and this number is large enough to serve the control needs of several different systems simultaneously.) The imposition of a maximum helps to maintain the software, by limiting the number of functions which can be crowded into any one software structure, and by motivating users to delete obsolete block definitions.
Thus, a software structure like that described can be used to control several systems and/or used by several users. The provision of "ownership" identification for each block, which may optionally be combined with access privilege restrictions, advantageously helps to preserve maintainability in multi-user environments.
FIG. 8 shows the preferred organization of the supervisor procedure 130. The top level loop (shown as a base cycle controller procedure 802), which calls the various blocks 851, 852, 853, . . . , sequentially, is preferably a cycling procedure. For example, the dormant time waiting block 891 might be set, in the dimethyl terephthalate synthesis application described, so that the base cycle procedure 802 is executed every 15 minutes (and therefore the entire sequence of blocks 851 etc. is called for possible execution every 15 minutes). The base cycle procedure also preferably performs some overhead functions. For example, the base cycle procedure 802 optionally contains the appropriate commands for branching on interrupts 804, and for initialization after a start command 806. Secondly, the base cycle procedure 802, upon calling each block, will preferably look at the header of the block (which is stored as data in shared memory, as discussed below), and usually also at some external information, such as the system clock value or the time stamp of a variable, to see if that block is due to execute. In the presently preferred embodiment, each block will also have status flags which indicate whether it may be executed, and will also have timing options which can be used by the user to specify, for example, that a particular block is to be executed only every 175 minutes.
The base cycle procedure 802 is not the only procedure which is relatively "high-level" with respect to the blocks 851, 852, etc. The build-supervisor procedure 810 is able to present the user with templates 812, and to (effectively) change the operation of the blocks 851, 852, etc., by changing shared memory values in accordance with the user's inputs to the templates 812.
That is, the real time control actions of the supervisor procedure blocks are supervised by the base cycle procedure 802. The base cycle procedure is responsible for determining when blocks are on/off, when blocks should be initialized, and when blocks should be executed. It also controls the timing of the base scan through all blocks.
In the presently preferred embodiment, each time the base cycle procedure executes a block, it checks the block type label (in shared memory) and calls the appropriate subroutine. That is, a single block of executable code is used for all of the feedback blocks, and similarly another block of code is used for all the feedforward blocks, etc., so that all 200 blocks require only four subroutines for their standard functions. Each time the base cycle routine executes a feedback block, it calls up the user-defined parameter set for that particular block, and passes those parameters to the subroutine which performs feedback functions in accordance with those parameters.
Base Cycle Procedure
FIG. 15 shows a flow chart of the logic preferably used in the base cycle procedure 802. The sequence of actions used in the main control program, when it is first started (e.g. by submitting it to a job queue) is:
Check to see if more than 30 minutes has passed since the last control cycle in the supervisor procedure. If so, initialize all blocks whose status is "On", "Active", or "Just turned on". (Initialization sequence is given below).
Start the control cycle loop: (This loop is shown as 1510 in the flow chart of FIG. 15.)
Set the system status to "Running-Computing".
Compute the next cycle time by adding the base scan interval to the current time.
Start a loop through all blocks, starting with block number 1 and counting up to the maximum number of blocks (This loop is shown as 1520 in the flow chart of FIG. 15):
Check block status:
*Get the switch status of the block. If the block is switching with an external switch parameter, get its status. (The switch status will be "On" if the external switch is on, or "Off" if the external switch is off.) If the loop is switched manually, the switch status is the same as the block's current status.
* If the switch status is "On", "Active", "Toggled On", or "Just turned on", the block is on.
* If the block is on, and the current block status is not "On" or "Just turned on", then the block is just being turned on. Set the Block Status to "Just turned on".
* If the block is on, and the current block status is "On" or "Just turned on", then the block is continuing to be on. Set the Block Status to "On".
* If the block is not on, it is off. Set the block status to "Off".
If the block status is "Off", "Inactive", or "Failed", loop back up and start the next block.
If the block status is "Just turned on", INITIALIZE the block (These steps are shown as 1524 in the flow chart of FIG. 15):
* If the block has a measured variable, set the "Last measured time" equal to the current time of the measured variable.
* If the block has a Key block, set the "Key block time" equal to the "Last execution time" of the key block.
* Set the "Last execution time" of the block to the current time.
* If the block is a feedforward block, set the "Old measured value" equal to the current value of the measured variable.
If the block has a measured variable, get its current time.
If the block has a key block, get its last execution time.
If the block timing option includes fixed interval, and if the elapsed time since the "last execution time" of the block is greater than or equal to the execution time interval, set the execute flag for the block.
If the block timing option includes keying off the measured variable, and if the current time of the measured variable is more recent than the "last measured time" of the block, set the "last measured time" for the block equal to the current time of the measured variable, and set the execute flag for the block.
If the block timing option includes keying off another block, and if the last execution time of the key block is more recent than the "key block time", set the "key block time" equal to the last execution time of the key block, and set the execute flag for the block.
If the execute flag for the block is set, set the last execution time for the block equal to the current time, and execute the block. Only execute the block once, even if more than one timing option was satisfied. (The block execution procedures are discussed in greater detail below, and are shown generally as 1530 in the flow chart of FIG. 15.)
If more blocks need to be processed, loop back to the next block.
This is the end of the loop 1520 through all the blocks.
Set the system status to "Running-Sleeping".
Set a wake up timer for the next cycle time computed above, and go to sleep until the timer expires, or until awakened by a request to terminate the program.
Wake up. Check to see if interrupted to terminate. If so, set the system status to "Terminated normally", and stop completely.
If not terminated, branch back to the start of the control cycle loop 1510.
Sample Source Code
The source code for the procedure which actually performs this function, in the presently preferred embodiment, is as follows. Due to the formatting requirements of patent applications, some portions of this and other portions of source code provided herein contain statements which are wrapped across more than one line (and hence would need to be restored to singleline format, or appropriate leaders inserted, before being loaded for execution); but those skilled in the art will readily recognize these instances, and can readily correct them to produce formally perfect code.
TABLE 1 __________________________________________________________________________ C********************************** C Control.for C Main control program for the Advanced Control System, C a high level optimization and control system C running on the Vax, using Vantage facilities. C C*********************************** C Program Control Include `ACS$includes:Block.sub.-- parameters.inc/nolist` Include `ACS$includes:Van.sub.-- functions.inc/nllist` Include `ACS$includes:Sys.sub.-- functions.inc/nolist` Include `ACS$includes:Manp.sub.-- params.inc` Include `ACS$includes:Meas.sub.-- params.inc` Include `ACS$includes:Filter.sub.-- params.inc` Include `ACS$includes:ACSserv.inc` Include `ACS$includes:ACSstatus.inc` C Integer*4 Block Integer*4 Integer.sub.-- Now Character*20 Character.sub.-- now Integer*4 Timbuf(2) Integer*4 Measured.sub.-- time.sub.-- stamp Integer*4 Key.sub.-- block.sub.-- exec.sub.-- time Logical*2 Execute.sub.-- block Logical Success Logical First Character*18 Debug.sub.-- time Logical Force.sub.-- initialization Parameter (Force.sub.-- initialization = .True.) Logical Dont.sub.-- force.sub.-- initia