CA1297559C - Process control system with reconfigurable expert rules and control modules - Google Patents

Abstract

PROCESS CONTROL SYSTEM WITH RECONFIGURABLE
EXPERT RULES AND CONTROL MODULES

ABSTRACT
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 modular software structure 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.

Description

~L2~ 5 5~

PARTIAL WAIVER OF COPYRIGHT

A portion of the disclosure of this patent docum~nt contains material which is subject to copyri~ht protection. The copyright o~ner has n~ objection to th~
facsimile reproduction by anyone of the patent disclnsure. as it app~ars in the Patent Office patent files or records, but otherwise res~rves all copyright rights whatsoever.

C~OSS'-~ E ~ C}: ~ R APPI,.~C~T;~ONS
ThQ rollowlng applications o~ common ass~gnee csntain ssmQ co~mon disclosure, and ar~ b~lieved to have Q~ctive ~iling dates identical wlth tha~ o~ the pr~gent application:
EXPERT SYSTEM W ~ ~HREE ~ SSES OF R~ (DuPont docket ~.
PI-446 (11 00/2)~ filed Septemker 28, lgB8: Serial Nb. 578,705;
PRO~SS CON~ROL Sy~E~l ~ITH NATT,~L I~GUAGE RULE
UPDA~ING (DuPont Docket no. PI-445 (1100/1)) filed September 28, 1988: Serial No. 578,704;
. _ .
PRO~SS C0N~OL SYSTEM WIn~ AClION LOG~NG (DuPont do~ket no. PI-448 (1100/4)) filed September 28, 1988: Serial ~. 578,692;
RROCESS _ CONTRO~ 8~STE13E WIT~ ON--LIN8 ; ~ MODI~ ~Dupont do~k~t no. PI-449 (1100/5) ) S filed September 28, l988: Serial Nb. 578,694, and PROCESS CONTROL_SYS~ ~ L_lEJ ~TI~E
HO ~ n~NCE OPTIQ~ t~Upont docko~ no. PI-450 tllooi6)); ~iled Sept~r.28, 1938. ~ial Nb. si8,698, l~f~7x~l~
BACRGROUND QF THE I~VENTIOM
Eigl~ - ~ - ~B Invention The present invention relates to expert systems (also known as knowledge-hased systems), ~o process control systems, and to hybrids thereof.
Discussion of Related Art Yarious known teachings which are believed ~o be related to various ones of the innovations disclosed in the present application will now be discussed. However, applicant specifically no~es 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 ~9~
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 guality, a supervisor procedure should ideally have ac~ess 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 proc~ss itself normally include some components 1~9~7~5~3 of random variation, the supervisor should include statistical t~sts which can determine if a sequence of sa~pled measurements is varying normally around its aim value (~ is "on aim"), or has shifted significantly from aim (is loff aim").
To control quality, a supervisor procedure should have the capabillty to chanye 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 enoùgh 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 co~ts in a way consistent with quality, to help avoid unnecessary upsets and shutdowns, and to take operating procedures into account, a supervisor 12~7~ 9 should id~ally include th,e logical decision making capabilities of e~pert syste~s. Becausç deoi ions will normally focus on ~ spec:ific 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 supe_visor should be easy to use. It should allow common control actions to be set up easily, with a means of customizing less COD on 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 reasoniny, 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 presPnt invention addresses many o~ 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 produc~

~2~t7~
quality) is absolutely pri~ary, so that cost optimization only be perfo~med as a~n objective secondary to quality objectives~ In this environment, use of classical optimization techniques to achieve cost optimization may not be possible. :tn sth~r cases, it hzs been possible to integrate a balance of supervisory and optimizing control into the supervisor.
Modulari~Y
Supervisory control systems using a modular structure are well ~nown. For example, the Process Monitoring and Control-1000 (P~C-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 func~ions. Each block writes one or more output values into memory. T~ build PMC control structures, the user creates as many blocks as needed and links them to other block output values. A new runnable system ~ust 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 ~locks can only be scheduled to execute at multiples of the base cy le time. ~lthough P~C
maint~ins a historical database, it cannot be used for control, and does not effectively store intermittently sa~pled data. It is believed that there is nc maximu~
nu~ber of block6.
It i~ believed that some earlier discussion of the significance of modularity in process control software ~s found in Watson, ~Process Control Using Modular Package Softwar~ E ~Conference P~bl~cations number 102 (1973), 1297~91 ~isto~çal P~ocess Database A d~tabase o~ historical process d~ta is gen~rally described in Hale and Sellars, "Historical Data Recording for Process Computexs,~ 77 Chem. Ena'q E~oq~YQ~ 3~ (19~1) Continuous_Q~5~ g~i~ns In classical feedback and feedforward control, the prior art teaches ~hat ~he best csntrol results are achieved by Daklng continuous changes to the process.
In computer control, where cyclic operation forces changes to be ~ade in discrete steps, many small, frequent steps are conventionally preferred. While in principle this gives the best possible control 15 . performance, such control actions are very difficult to visualize. In fact, it ~ay 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 ~11. This method of control also runs counter to the methods used by operators, who ~enerally make ~ few ~ignificant changes and wait to see the effects.
In feedb~ck control, the use of a deadband is a well known way of ~voiding small ~ctions caused by a noisy ~easure~ent. ~That is, if the control variable ~115 within a ~pec~ied deadband of values surrounding the goal value, the control value will not be ~nnipulated.) This deadband, ~s is well known, helps to avo~d inst~bility in control systems. Statist~cal proce~ control al~o tends to reduce the number of feedback control ~ctions. However, neither technique is ~37~

sufficient to make all conlrol actions understandable, since some actions will not be csnsidered noisy.

The use of a feedfo~7~rd relation among control variables is also well known among those sXilled in the art of process control. That is, in some cases, whenever one variable changes (e.g. if a particular control variable i5 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 th crude feed stocX is decreased. In feedforward control, a deadband is normally not used.

~ontrol of Multiple Manipulated Variables In many process control applications, several manipulated variables must be jointly controlled in a single control loop (e.a. 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 ch~nged.
A different but related problem arises when a number of manipulated variables ("Xnobs") can be changed 1~7~9 to respond to a ~lngle me~sured v~riable. Qperntor~
often use ~ heuri~tic ~pproach ln choos~ng which knob (or knobs) to ~a~ipulate, a~d ~omet~mes choose not to ~ct. The hel~ristic ~ppro~oh may consider C05t, quality, S response dynami~s, ~nd proce~s st~bllity. It may include altern~te knobs to be used when ~11 of the preferred knobs are co~strained. Cl~ssic control methods ~re not well su~ted to ~h~s approaoh.

ExDert SY~te~s ~en~r~llv lD The term Nexpert ~ystem" is used ~n the present application (in accordance with what is believed to ~e the general usage at present) to refer to a system which ~ncludes non~trivial amounts of knowledge ~bout an underlying problem. Al~ost ~ny control system wh~ch has been custo~ized for a particulnr applicat~on might be argued to embody ~mall ~mounts of relevant knowledge in its very ~tructure, but the term expert ~yste~ is generally used only for systems which contain enough accessible information ~hat they can usefully supplement the knowledge of nt le~st ~ome (but normally not all) h~man 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 "do~a~n expert~), so that that person's expertise can be distri~uted and ~ade access~ble to many less expert u~ers who must address problems of a certain type. Some well-known succes~ful examples include a ~edical diagnostic program (MY~IN) and a dlagnostic program which assists mech~nics working on diesel engines.
As these exAmples show, one very com~on area of applicntion for expert systems has been fault diagnosis.
~ny other area~ 9f ~pplic~tion h~ve been recognized;
see gener~lly ExDeIt--~y~tem~ (ed. R. Forsythe 1984~

~ 97S59 P. Harmon and D King, Expert Systems (1985); and Donald Waterman, A ~uide to Expert Systems (1984).

Rnowled~e In~ut and U~datina One of the very general problems in ~he area of expert systems is hsw knowledge is, to be gotten into an expert system in the first place. That is, specialists in artificial intell$gence o~ten assume that a "know-ledge engineer" (that i5, 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" (th~t is, a person who actually has expert knowledge of the type 15 . of pro~lems which the expert syste~ is desired to be a~le to address) to extract his expertise and program an expart system accordingly. However, there are some very important drawbacks to this paradigm. ~irst, ~ompetent "knowledge enginecrs" are not readily available~ In particular, khe requirements of maintaining a real-worl~
application (such as an expert system for chemical process control, ~s in the preferred embodiments disclosed below) are such that it is dangerous to rely on a sufficient supply of "knowledge engineers" to go ~hrough 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 reguirements for a large software system i~ that it be m~intainable. Thus, for example~ the software ~ystem must be set up so that, after the technologist who first puts together an expext syctem is gone, it can be maintained, ~odified, 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 necess~ry that a large software structure "such as that reguired for a sophisticated expert system, be maintainable. For example, in an expert control system, control strategies may be modified, new control strategies may be intro-duoed, 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.
Norm~lly, exper~ systems attempt to maintain som~ degree of maintainability by Xeeping the inference rules which the processor executes separate from the software structure for the processor itself. However, this normally ~ends tD lead to a larger software structure which operates more slowly.
Specialists in expert systems also commonly assume that expert ~ystems ~ust be built in a ~ymbolic proces~ing environment, e.a~ in environments using LISP
or PROL0~. Even for complex processes, a single large knowledae base is usu~lly assumed. ~he 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 l~rge so~tware structures which execute slowly on conventional computers. Specialized "LISP machines"
are commonly recommended to speed up ~he inference process.

~xDer~ Svste~ Knowl~dae Structures Published materi21 regarding knowledge based 6y tems (expert ~ystems) has proposed several clas-~ific~tions ~or the types of rules which ~re to be use~.
For example, U.S. P~tent No. 4,658,370 to Erman describe "a 1~97S5~9 tool~. for building and interpreting a knowl~dge base having separate portions encoding control knowledge, factual knowledge, ~nd judc~ental rules." (Abstxact).
The method described in ~his patent still appears to rely on the availability of 21 "knowledge engineer." This patent appears to focus on th~ application of an expert system as a consultation driver for extracting the relevant items of knowledge from a human observer.
Rnowledge 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 solvins 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 ~ngineering easier, and to make the knowledge system and its reasoning during 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. Patent 4,648,044 to Hardy, et al., describes "a tool for building a knowledge system [which] includes a knowledge base in an easily understood E~glish-like language expressing facts, rules, and meta-facts for specifying how the rules are to be applied to s~lve 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 1~3t75S9 base. Despite some simplification in the develvpment process, a fairly high skill level is still required.

Expert Svstems 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 v~ry 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 ~ubstantially higher efficlencies 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 lX97S59 multiple control parameters should be addressed, and in which direct~on.
It should also be not~d that the use o~ an expert system to design a new process (or to debug a newly introduced process) has signiflcantly different features ~rom the problem of optimally controlling an existing process. Similarly, while expert systems have ~lso been applied to ~he automatic distribution o~ jobs to multiple workstations through an automated materials ~0 handling system (an example of this is the DISPATC~ER
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, p~rticularly chemical processes.

"REscu~
The system known as "RESCU-- resulted from a collaborative demonstration project between 8ritish government and industry. ~, e.q., Shaw, nRESCU online real-time nrtificial intelligence," 4 Com~u~er-aided ~naiDeeFina J. 29 (1987): and the Digest of the IEE
Colloquium on 'Real-Time Expert Systems in Process Control', held 29 November 1985 at Salford, U.K.... 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 of the entire plant and thus requires complex inference control methods.

;S9 ~ alconn "Falcon" ~s ~ f~ult diagnosiç system for a chemical re~c~or, which monitors up to 3~ process measurements and seeks to identify a set of up to 25 failures in the process. This w~s dsveloped as a demonstration pro~ect b~tween DuPont, the Foxboro Company, and the University of Delaware, and ls described, for example, in D. Rowan, ~Using an Expert System for Fault Diagnosis, n in the February 1981 issue of Control En~ineerina See also "Troubleshooting Comes On Line in the CPI" in the October 13, 1986. issue of Chemical ~naine~ering at page 14. This system required several man years of development, and because it i6 programmed in LISP, it has proven difficult to maintain the knowledge base through process changes.

nONSPE:C Su~erintendent"
The "ONSPEC Superintendent" (TM), marketed by Heuristics Inc., i~ A real-time expert systems package whi~h mon~tcrs data from the ONSPEC (TM) control system.
Se~ Manoff, ~On-Line Process Simulation T~chniques in Industri~l Control including Parameter Ide~tification nnd Estimation Techniques," in Proceedinq~ of the ~leventh Annua~ Advanced Çontrol Conference (1985);
and Manoff, "Control Software Comes to Per~onal Computers." at page 66 of the March 1984 issue of Control Enainee~inq. The "Superintendent" monitors for conformance with safety and control procedures and 3n documents exceptions. It can also notify operators, generated reports, and cause control outputs.

~X~37~

n p ~ÇON ~t The PICON (TM~ syste~, ~hich was marketed by Lisp ~achines, Inc. (LMI), was apparently primari~y intended for real-time analy~is of upset or emergency ~onditions 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 proeess.
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 ~nowledge base can be entered. The domain expert then enters ~nowledge 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 IrLtelliaen~
APPlications_~n _ShemistrY (American Chemical Society 1986), and the R. Moore et al, article in the May 198S
issue of InTech at paye 55.

Self-tunina Controllers Another develop~ent which should be distinguished is work related to ~o-called "self-tuning controllers. n Self-tuning single- and multiple-loop controllers contain real-time expert systems which analyze the performance of the controller (See "Process Controllers ~on Expert Guises~, in Chemical Eng'g, June 24, 1985~.
These expert systems adjust the tuning parameters of the controller. ~hey ~ffect only low-level parts of the ~ystem, and use a fixed rule base embedded in a ~croprocessor.

1~75~9 SU~RY OF T~[E INVE~TION
In this section various ones of the innovativP
teachings presented in ~he presen~ application will now be discussed, and some of their respective advantages described. Of course, not all of the discussions in this section de~ine necessary features of the invention (or inventions), for at least the following reasons: l) various par~s of thP following discussion will relate to some (but not all) classes of novel embodiments disclosed; 2) ~ariou~ 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 in~ention" (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 an~ methods for operating a sophisticated control system while also exploiting expert system capabilities;
generally applicable methods for controlling a continuous process; and ~97S59 innovations, applicable to expert systems generally, which help provide highly maintainable and user-friendly exp~rts.
Various classes of e~bsdiments described h~rein provide a process control system, wherein a process which operstes substantially continuously is controlled by a system which includes (in addition to a process control ~ystem which is closely coupled to the underlying proc~ss and which operates fairly close to real time, l.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 ~yste~ procedures as sub-routines. 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 procedur~ which permits them to define or redefine modules of the supervisor procedure by editing highly constrained templates. The templates 55~t use a standardized data intexface (as seen by the user), which facilitates the use in control actions of data from a wide variety of syst:ems. The templates in the available template set preferably contains highly constrained portions (which are optimized for the most common functions), and pointers to functio~s 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 ssphisticated 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 acces~ to current and historical process data ~y the supervisor and expert procedures. This is particularly useful for collecting ~Z~75~
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) ~inimizatisn of cos~ 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 Mani~ulated Variables A~ noted above, in many process control applications, several manipulated variables must be jointly controlled in a single control loop (e.q. 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 manipul~ted 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) i5 to decompose the multiple-variable problem into a set of 1~97~5~3 single-variable problems. An expert procedure is used to decide which con~rol parameter(s) to adjust, and one or more from a ~et 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 actio~s are taken, where conventional control m thods would make no action or wrong actions. This improves the use~ulness of the control strategy to the operat~r, 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 proce~s (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 ~ reasonably small number of significant discrete actions, supervisor performance becomes much more understandable.
One novel teaching stated in the present application is an integrated ~ystem for process control in which a process supervisor procedure (which is preferably the top level procedure) defines parameters 5~t for one or more contr~l systems (or control procedures).
The supervisor pro~edure 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 csntrol 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 lon~er). A new operator CQming 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 ~upervisor actions. Feedforward action is taken only when the measured value changes by more than the deadband from its value at the last action. This s~
generates a series of discrete changes in the manipulated variable, which can be effectively logged and evaluated by sperators.
Statistical filtering of discretely measured values also serves to reduce control actions to a few significant changes~ Statistical tests, as is well known, dis~inguish normal variation around th~ 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 S~stems 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.

Tv~es o~ Process Control SYstems ~9'755~3 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 signi~icant 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 hu~an is queried fcr infor~ation). 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 infor~ation. In fact, it may be faster to retrieve all the data that could be relevant to the problem than to determine what data is '7555~
relevant. Moreover, since the experts will run automatically, there i5 no need to explain the reasoning during the inference process. As long as the rulebase is not too large, the proGess 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 sy~tems. 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 i5 that they facilitate reliable implementation of a control strategy which (primarily) prevents a clearly wrong action from 1~97559 being taken, and (secondarily3 permits minimizing costs.
In particular, it is especialiy advantageous to use a knowl~dg~ based (functional) structure where the rules are constrained to be of the three types described in the context of a process control application. Th~ retrieval rules permlt the predominantly quantitative sensor data (and other input data) to be translated in~o a format which is suitable for expert system application, and tha control rules provide a translation back from expert system reasoning into an output which matches the constraints of the control problem.
~he present invention is particularly advantageous in controlling processes which are substantially continuous, ~s distinguished from job shop processes.
That is, while some computer-integrated manufacturing systems focus primarily on issues of queuing, throughput, statistical ~ampling 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.

ExDert Svste~s 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 ~ub-sub-class of expert systems used ~or control of substantially continuous processes. However, the present application ~lso discloses many novel features which could be adopted into many other types of expert systems, ~nd~or into many other types of contxol applications, w~ile 5till retaining many (if not all) of the advantages obtained in the context of the presently conte~plated best mode.

~7~59 Similarly, while the present applica~ion 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 adapt~d for use with other types of expert systems too.

Natural-Lanouaae Rule Sta~ements One of the innovative teachings in the present application prsvides an expert system tool in which knowledge is entered into the knowledge base through a limited set of pre-defined, highly constrained, natural-l~nguage 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.
~oreover, 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 systam 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.

~2~7S59 Another innovative teaching is that the knowledge entered into the pre-defined natural-lanyuage struc~ures 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 ctored te]nplate information, modifies it, and stores the modified knowledge. This is also simple enough to be done by th~ domain expert. The modified knowledge can then be automatically translated in~o a modified operational expert.
Another si~nifican advantage of several o~ the disclosed novel embodiments for creating an expert system is that the expert can be significantly more compact and faster in execution This i5 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 ssurces (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 ~2~55C~
lack the pro~ramming ~xpertis~ th~t would otherwi~e be ne~ded to acc~ss these data sources.

Ex~ert SYstem Rule T~
As mentioned ab~ve, previ3us expert sys~em tools no~mally use a XU18 or computer language which allows great ~lexibility in knowledge represantation. one innovative teaching in the present application is the restriction o~ the knowledge struc~ure within an expert ~ystem to rules of three highly constr in~d types. The thxee rule types are: 1) retrieval rules, which each assign one of several descriptors to a name in acco~danc~ with the values of numeric inputs; 21 analysis ~ules, which each can assign ~ descriptor to a name in accordance with the descriptor~name assignments made ~y 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 opera~ions. Preferably only the action rules can enable Rxecution ~f an external command ~.e. o~ a command which does not merely a~fect the operation o~ the expert procedure ) . Preferably each of the action rules rQquiras only a logical test for thR assignment of a . descriptor to a name. Pre~erably none of the action rules can assi~n a descriptor to a name.
While this organization of an expert system's structure i5 especially advanta~eous in the context of a process control expert systPm, it can also be applied to other types of expert systems In a process control system, the relevant inputs will normally be process data, la~oratory data, or control systam paxameters.
The relevant outputs will nor~ally be exec~ltable procedures which af~eat the operation af control or supervisor systems, or communicate with operators or 12~7~5~

domain experts. This teaching could also b~ 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 acc pt 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 cont:ingent upon a test for the previous assignment of a descriptor to a name.
In general, this structuring of the inferenre rules provide~ for a more understandable expert. The retrieval rules provide access to process and control system data, and translate from guantitative 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 1~97559 ox redefine modules by editing highly constrained templates which include a 6tandard data interface specification. The standardized data interface (as se~n by the user) facilitate communications with an extremely wide variety of s;ystems. 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 lo which functions have been specified for that module, and what d~ta sources have been specified through the standard data inter~ace. 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 ~975~

strategies by accessillg 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 generat infor~ative messages about module actions, or a sophisticated user can implement unusual or non-standard control functions, or other customization utilities (such as the build-exper.
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 ~ser 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 adjustme~ts performed by the expert system, which in ~9~75~

turn is very advanta~eous (as discussed ~elow~ in providing an understandable log of control action~
taken.

Seouensina Modular 810cks One innovative teaching herein is a system Cor process control having a modular supervisor procedure which includes novel module timing and sequencing methods. Users can preferably specify mcdules by editing highly constrained templates, which include several specifiers for methods to be used in controlling and coordinating module execution. Preferably th~
module timing options include: 1~ execute module function at fixed time intervals; 2) execute module function when new data becomes available for a specified 15 . 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 Ex~ert 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 ~ymbolic 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 .5~

difficult to accommodate more than one expert system.
(Another way to regard this area of advantage i5 to note that, withsu~ the inven~ions contained in the present application, the potential modularity of the expert system cannot be fully exploited.) Several of the novel embodiments described herPin achieve substantial advanta~es by using more than one expert system subprocedure within a si~gle integrated system. Since expert decisions will normally focus on a specific task or area, the modularity of the pro~lems 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 Gf 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 prscess can call on sne or msre expert system procedures, and the user can call on a build-expert procedure which can reconfigure one of the expert systems already present, ~9755~
or create a new expert system. The supervisor procedure can preferably also call on ~ historical data bas~.
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 ~s 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. ~he historical database allows time delayed measurements and their corresponding continuous measurements to be used together. T~is is advantageous for balancing componen~

75~9 material flows in the process. Irl 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 bP 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.
Th~ 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 su~procedure.
One of the innovative teachings in the present application is an integrated system for process control 7'~

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 sp~cified 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 syste~, 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) ~ay be relevant to the process, the standard interface greatly facilitates the use of relevant data from a wide variety of sources.

:~9~5~

The present in~ention will be described with reference to the accompanying drawings, wherein-Figure 1 schematically shows the structure of hardwar0 a~d procedures preferably used to embody the novel pro~ess control system with expert system capabil-ities provided by various of the innovative features contained in the present application.
Figure 2 i5 a schematic repr~sentation of the flow of information in the expert system structure preferably used.
Figure 3 shows he template used for ~ retrieval rule in the presently referred embodi~ent, together with a sample of a retrieval Nle which has been entered into the template.
Figure 4 shows an example of a different kind of retrieval rule, known as a calculation rule.
Figure 5 shows an example of an analysis rule.
Figure ~ 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.
Figure 7 shows an example of a chemical synthesis processing layout in which the method taught by the present invention has been successfully demonstrated.
Figure 8 schematically shows the structure preferably used for a supervisor procedure and a build-supervisor procedure.
Figure 9 shows ~ menu which, in the presently preferred e~bodiment, is presented to the user by the build-supervisor procedure to select a template to provide user inputs to define or modify a block within the supervisor procedure.
Figures 10-13 show specific templates which, in the presently preferred e~bodi~ent, are presented to the user by the build-supervisor procedure to provide input 12~7559 to define or modify a feedbac}c, feedforward, statistical filtering, or program block, respectively.
Figure 14 shows a block-editing utility menu presented to the user, in the presently preferred embodiment, by the build-supel~isor procedure.
Figure 15 shows a flow chart for the base cycle procedure used in the supervisor procedure in th~
presently preferred embodiment.
Figure 16 shsws a menu which, in the presently preferred embodiment, is the top-level menu presented to the user by the build-supervisor procedure, and Figure 17 shows a menu which is the top-level menu within the build-expert procedure.
Figure 18 is another schematic representation of the interrelations among the various procedures which permit user customization of functionality.

1~975~9 ~ PTION OF ~HE PRL~ 8~ 9~

General Orqanization of Hardware and Procedures Figure 1 schematically shows the structure of hardware and procedures preEerably 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 lS8 are explicitly shown. Of course, real world examples are substantially more complex; Figure 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 receiYed 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 u~ed instead. Moreover, the controllPr functionality could be different, e.a. 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 1~9~559 computer controller syst~m 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 te~q. setpoints or feedforward ratios) from a supervisor procedure 130, which is preferably a higher leYel 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.~. a VAX 11/785), while the computer control system 152 is a PDP-ll.
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 proces ~297~55~

characteristics and measurement charac~eristics are subject to significant random variation, as they normally are in the chemical process industry.
Statistical filtering tests are prPferably performed to filter out statistically normal variation, and ascertain whether a process has significantly d~viated from its current goal or average. (Alternatively, the statistical filtering functions could be performed elsewhere in co~tware, e.q. in the database so~tware.) The supervisor procedure 130 is preferably run as a cycling proc~ss, 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.
SamDle Process Context Figure 7 schematically shows a sample embodiment of a chemical process incorporating several novel ~eatures described in the present application. The system shown is one in which various novel aspects set forth in the ~l23~53 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 Figure 7. Thus, for example, Yarious of the claimc herein may refer to sensors which sense "conditions" in a process, or t4 actuators which change "conditions" ~n a prscess, without referenc~ to whether one sensor or many sensors is used, whether one or several parameter~
is sensed by respective ones of the sensors, whether the actuators are valves, motors, or other kinds of devices, etc.
Figure 7 shows par~ 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 terephthallate (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 MF8, since it affects the properties of products made from DMT. The refining train shown in Figure 7 will reduce the average MFB fraction to a fairly constant level~which is (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 terephthallate (MHT), and about 0.2~ of methyl formyl benzoate (MFB). The MFB-depleted product 740 is preferably further refined to reduce the MHT fraction.

~;~97559 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~ T~e 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 7~4 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 C at its bottom to a~out 55 Torr at about 70D 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 72B 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- C at about 235 Torr at the bottom of the column to about 70 Torr and about 190- 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 qiYen below, as the "xylene column".) The mass flow in the loop 728/742 is quite large;

~2~755~t 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 S 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 i5 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- C at about 260 Torr at the bottom of the column to about 60 Torr at about 125- C at the top of the column. Stream ~61 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 equipmen~ maintain the temperatures, pressures, and flow 12~7~

rates at other points in the process. In accordance with principles well known in the art of chemical en~ineering, this serves to maintain mass and energy balances and compositional trends co~sistent with th~
ultimate control objective, which is to maintain a high and consta~t purity in the product stream 740.

Historical Process Data~ase In the presently preferred embodiment (as shown in Figure 1), the supervisor 130 receives data primarily through a historical process data base 140, which dirertly 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 stamp3 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 tws 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.~. 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.

~297~
Secorldly, lab analysis data 162 can also be stored in the historical databas~ 140. For example, compositional measurements ~ust normally be done off-line. A physical sample will be pulled`from the physical S process flow and sent to ~he laboratory for analysis.
The resulting lab analysis value is entered into the historical datahase, timestamped with the time the sample was taken.
A third source sf 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 ~erform a variety of other functions, including monitoring, activating al~rms 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.a. generating reports).
This structure is quite ~lexible: for example, in alternative embodiments, one supervisor procedure could interf~ce 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).

~7 ~L~9~5~3 SuDervisor and Build-Su~ervisor Procedures The present application describes some very advantageous features of nsvelty in the ~upervisor procedure 130 and b~ild-supervisor procedure B10, 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 supe~isor 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 al50 has the capability to call a user subroutine, and in fact the "program blocks" used in the presently preferred embodiment perform no other functicn.
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, ~ut sophisticated users are not prevented from writing their own customized functions (such as messaging).
Feedback blocks are used when a ~anipulated parameter m~1st be adjusted t3 keep a measured parameter 12975~

near a desired goal. Feedfo3~ard blocks are used when two parameters (which are not necessarily in a causal relation) are linked, i~ when a manipulated parameter must b~ 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.
Pxeferably a maximum number of bl~cks is pre-defined. (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.
Figure 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 exe~ution every 15 minutes~.

~2~ 5~;~

The base cycle procedure also pr~ferably performs some overhead functions. Fo~ example, the b~se 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 892, upon calling each block, will preferably look at the header of the block (which is stored as data in shared memory, 2s discussed below), and usually also at some external information, such as the system clock valu~ or the time stamp of a variable, to see if that block is due to execute. In the presently preferred emhodiment, 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 blocX 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 ~10 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 ~5 appropriate subroutine. That is, a single block of ~2~7S59 executable code is used for all of the feedhack 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. ~ach 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 Figure 15 shows a flow chart of the logic preferably used in the base cycle procedure 802. The sequence of actions used in the ~ain control program, when it is first staxted (e.q. 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: (~his loop is shown as 1510 in the flow ch2rt of Figure 15.) - S e t t h e s y s t e m s t a t u s t o "Running-Comp~ting~.
- 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 ~low chart of Figure 15~:
- Check block ct~tus:
* Get the switch status of the block. If the block i~ ~witching with an external switch ~9~5~

parameter, get its status. (The switch sta us will be "On" if the external switch is on, or "Off" if the external switch is of f . ) 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 sn, and the current block statu~ is not "On" or "Just turned on", then the block is just being turned on. Set the Rlock Status to "Just turnsd 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 bloc~ is not on, it is off. Se' the block status to "Off".
- If the block status is "Off", "Inactive", or "Failed", loop back up and start the next blosk.
- If the block status is "Just turned on", INITIALIZE the block (These steps are shown as 1524 in the flow chart of Figure 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 hlock, 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.

~ ~9'755~

- 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 ~ariable ic 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 o~f another block, and if the last execution time of the key block is more recent than the "key bl~ck 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 Figure lS.) - 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.

~2~755~
- Wake up. Check to se~ 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 15]Ø

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 o~
this and oth r portions of source code provided herein contain statements which are wrapped across more than one line (and hence would need to be restored to single-line format, or appropriate leaders inserted, before lS being loaded for execution); but those skilled in the art will readily recognize these instances, and can readily correct them ~o produce formally perfect c~de.
Ta~le 1 C**********************************
C Control.for C Main control program for the Advanced Control C System, C a high level optimization and control system C running on the Vax, using Vantage facilities.
C********~****************~*********
C Program Control Include 'ACSSincludes:Block Parameters.inc/nolist' Include 'ACS$includes:Van functions.inc/nolist' Include 'ACS$includes:Sys functions.inc/nolist' Include 'ACS~includes:Manlp Params.inc' Include 'ACS$includes:Meas Params.inc' Include 'ACS includes:Filter ~arams.inc' Include 'ACS$includes:ACSserv.inc' Include 'ACS$includes:ACSstatus.inc' Integer*4 Block Integer*4 Integer Now Character~20 Character now 1~7~
Integer*4 Timbuf(2) Integer*4 Measured time_stamp Integer*4 Xey block exec time Logical*2 Execute_block ~ogical Success Logical First Character*18 Debug_time Logical Force initialization Parameter (Force initialization z .True.) Logical Dont force initialization Parameter (Dont forc initialization = .False. ;
C

Integer*2 Meas type Integer~2 ~eas var Integer*2 Filt type Integer*2 Filt var C

Intes~r~4 Event flag state Integer*4 Ti~er flag Integer*4 Interrupt flag Character*9 Cluster name Parameter ( Cluster name = 'ACS_FLAGS' ) Integer*4 Fla~ mask C
Logical Interrupt flag set Interrupt flag_set() = Btest(Event flag state,l) C

Timer flag = 64 Interrupt flag = 65 First = .TrueO
Flag mask = O
Flag_mask = Ibset ( Flag mask , O ) Flag mask = Ibset ( Flag mask , 1 ) C

C...Record control program startup in the log file C

Yan status = VssS from ascii time ( ' ' , Integer now ) Van status = Vss~ to ascii tlme ( Integer now , 1 Character now ) Write (6,*) ' Started the ACS control program at ', 1 Character now C

C...Create the event flag cluster , clear interrupt flag C

Sys status = Sys~ascefc ( %Val(Timer flag ) , 1 %descr(Cluster name) , O , ) Sys status = sys$clref ( Sval(Interrupt flag )) C

C...Check to see if ACS control has been down for more than C 30 minutes. If so, initialize all active blocks.
C

Yan status = VssS from ascii time ( ' ' , Integer now lX~3~755~

If ( Inte~er now ~ Integer next cycle .gt. 30*60 ) Then Do 10 Block = l,Max blocks I~ ( ( Block_status(Block)(1:2) .eq. 'On' ) .or~
1 ( Block status(Block)(1:6) .eq. 'Active' ) .or.
1 ( Block status(~lock)(l:l4) .eq. 'Just turned on' ) 1 Call Initialize block ( Block ) Continue End If C

C....The main block control loop 1 Continue C

C....Set syste~ status to Running C

System_status = 'Running-Computing C

C...Set Wake up time to ACS base_scan minutes from now C

Van status = Vss5 from ascii_time ( ' ' , Integer now ) van status = VssS to ascii time ( Integer now , 1 Character now ) Integer next cycle = Integer_now + ACS base scan~60 Call Vss$ get systime ( Integer_next_cycle , Timbuf ) - C
C....Loop through all the blocks C

Do 100 Block = 1,Max_blocks C....Update the block Status from the info coming from PCS
C

Call Check block status t Block ) C...Check the block status, if inactive or off, skip it C

If ( ( Block_status(Block)(1:8) .eq. 'Inactive' ) .or.
1 ( Block status(Block)(1:6) .eq. 'Failed' ) .or.
1 ( Block status(Bleck)(1:10) .eq. 'On-holding') .or.
1 ( Block status(Block)(1:3) .eq. 'Off' ) ) The Go To 100 End if d If ( Firs~ ) d 1 write(6,*) ' Block: ',block,' Status = ' 1 block status(block) C

C...If the block has just been turned on, initialize it If (Block_status(Block)(1:14) .eq. 'Just turned on' ) Then Call Initialize block( Block ) End if C

C....Check to see if it is time to execute the block 5~

c C...... U5e appropriate calls for 1:he block type C

If ( 1 ( Block type ( Block )(1:8 ) .eq. 'Feedback' ) .or.
1 ( Block_type ~ BlocX )(l~ .eq. 'Feedforward' ) .or.
l ( Block type ( Block )(1:7 ) .eq. 'Program' ) l ) Then ACS status - ~CS get_meas var type ( Block , Meas typ~ ) If ( Me~s_type .eq. Cur val van var ) Then ACS_status = ACS get meas var num ( Block , Meas var ) Van_sta~us = Vss~ curtime ( Meas var , l Measured time stamp ) Else Heasured_time stamp = 0 End If C

Else If ( l ( Block_type ( Block )(l:~ ) .eq. 'Shewhart' l ) Then ACS status = ACS get filtered var_type ( Block , Filt_type If ( Filt type .eq. Van var filter ) Then ACS status = ACS_get filtered var num ( Block , Filt var - Van status = Vss$g curtime ( Filt var , l Measured time stamp ) Else Measured_time stamp = 0 End If End If C

C...Get exec time of key block, if defined C

Rey ~lock = Var num2(Block) If ( Key block .ne. Empty ) Then Key block_exec time = Last execution time ( Key block ) Else Key block exec time = 0 End If C

Execute block = .False.
d If ( First .eq. .True. ) Then d Van STATUS = vss$ to ascii time ( integer now , Debug time ) d ~rite(6,*) ' Block o ',block d write(6,*) 'Integer now = ',Debug time d Van STATUS = Yss$ _to asc~i time ( last_execution time(block) d l , Debug time ) d write(6,*) 'last execution time = I,debug time d Van STATUS ~ vss$ to ascii time ((-l)*Frequency(block)*60 d l , Debug time ) d write(6,*) 'Frequency(block) = I,~ebu~ time d Van STATUS - vssS to ascii ~ime ( last measured time(block) d l , Debug time ) ~L~97~ 3 d write(6,*) 'last measured time = ',Debug time d Van STATUS = vssS t~_ascil time ( measured time stamp d 1 , Debug time ) d write(6,*) 'measured time stamp = ',Debug time d write(6,*) 'timing option ~- ', Var num3(BLock) d End If I timing option = Var_num~(Block) If ( ( I timing_option .eq. Interval ) .and.
1 ( Integer now - Last execution time(Block) .ge.
1 Frequency(Block)*60) ) Then 1 Last_execution ~ime(Block) = Integer_now Last measured_time~Block) = Measured time stamp Execute block = .True.
C

Else If ( I timing option .eq.
1 Key_off_measured_varia~le ~Tne~
If ( Measured_time_stamp .gt.
1 L2st measured_time(Block) ) Then Last_execution_time(Block) = Integer now Last measured_time(Block) = Measured_time_stamp Execute block = .True.
End If C
Else If ( I timing option .eq.
1 Xey off ACS block ~ Then If ( Xey block exec time .gt.
1 Fix time(Block) ) Then Last execution time(Block) = Integer now Last measured time(Block) = Measured time stamp Fix time(block) = Xey block exec time Execute block = .True.
End If C

Else If ( I timing option .eq.
1 Intrvl and key off ACS block) Then If ( 1 ( Key_block_exec_time .gt.
1 Fix time(Block) ) .or.
1 ( Integer now - Last execution time(Block) .ge.
1 Frequency(Block)~60) 1 ) Then Last execution time(Block) = Integer nGw Last measured_time(Block) = Measured time stamp Fix time(block) s Key block exec time Execute ~lock = .True.
End If C
Else If ( I timi~g option .eq.
1 Intrvl and key o~f meas var) Then If ( 1 ( Measured time stamp .gt.

~9~i9 1 Last_measured_time(Block) ) .or.
1 ( Integer now - Last execution_time(Block~ .ge.
1 Frequency(Block)*60) 1 ) ~hen Last execution time(Eilock~ = IntPger_now Last_measured_time(Block) = Measured time stamp Pix_time(block) = Key blo~k exec_time Execute_block = .True.
E~d If C

Else If ( I_timing_option .eq.
1 Key_off meas Yar - and_block) ~'hen If ( l ( Rey block exec_time .gt.
1 Fix time(Block) ) .or.
1 ~ Measured_time stamp .gt.
1 Last measured_time(Block) ) l ) Then Last execution ti~e(Block) = Integer now Last measured_time(Block) = Measured ti~e stamp Fix time(block) = Key_block exec time Execute_block = .True.
End If C

Else If ( I timing_option .eq.
1 Intrvl_and_~ey meas and_block)Then If ~
1 ( Xey_blsck exec time .gt.
1 Fix_time(Block) ) .or.
l ( Measured_time stamp .gt.
1 Last measured time(Block) ) .or.
1 ( Integer now - Last execution time(310ck) .ge.
1 Frequency(Block)*60) 1 ) Then Last execution time(Block) = Integer now Last measured_time(Block) = Measured time stamp Fix time(block) = Xey block exec time Execute block = .True.
End If End if C

C...If Time to execute, call the Subroutine for the appropriate bloc~
If ( Execute block .eq. .True. ) Then If ( Block type(Block)(l:ll) .eq. IFeedforward' ) then Call Feedforward block(Block) Else If ( Block type(Block)(1:8 ) .eq. 'Feedback' ) then Call Feedback block(Block) Else if ( Block type(Block)(1:7 ) .eq. 'Program' ) then Call Program block ( Block) Else if ( Block type(Block)(1:8 ) .eq. '~hewhart' ) then Call Shewhart block( Block) 1~755~
End if End i~
lO0 Continue C.. ...All Blocks checked and executed if needed; go to sleep until neede C
102 Continue Sys status ~ Sys$setimr ( ~val (Timer flag~ , ~ref(Timbuf),, If (Sys status ~eq. ~loc(Ss~ normal) ) Then d Write(6,*) ' Successfully set timer.' Else Write(6,*) ' Error return from setimr in Control at ', 1 Character now End If System status - 'Running-Sleeping Sys_status = Sys~wflor ( Sval(Timer flag) , %val(Flag_mask) If ( .not. Sys status ) Call LibSsignal(%val(Sys status)) Sys status = sysSreadef ~ Sval(Timer_flag ) , 1 %ref(Event flag state) c If ( .not. Sys ~status ) Call LibSsignal(Sval(Sys st~tus)) If ( ~ Sys status .ne. %loc(SsS wasclr) ) .and.
l ( Sys status .ne. %loc(SsS wasset) ) ) ~hen Write(6,~) ' Problem reading event flag status' End If C.. Test the interrupt bit- if set, process the request If ( Interrupt flag_set() ) Then d Write(6,*) Igot an interrupt' Call Shutdown ( Event flag state ) Else d WRite(6,*) ' Timer expired.' End If C
First - .False.
Go To 1 C

End Copyright (c) 1987 E.I. DuPont de Nemours & Co., all rights reserved 1~75i~9 Build-SuDervisor ProceduFe The build-supervisor procedure 810 presents templates 812 to the user ar~d stores the user responses to these templates in a "global section'l portisn of memory (i. e . a shared or co~only accessible portion of memory). That is, the user inputs to the templates for the various blocks 851, 852, etc., are stored where the base cycle procedure 802 can access them and the build-supervisor procedure 810 can also access them. Thus, an authorized user can at any time interactively call up data from shared memory space 814, see these parameters in the context of the templates 812, and modify the functions of the various blocks 852, 853, etc. and/or define new blocks (and/or delete existing blocks), while the base cycle procedure 802 continues to call the various blocks on the appropriate schedule. That is, the base cycle procedure 802 is preferably a cycling procedure which satisfies the real-time process control demands of the underlying process, while the build-supervisor procedure 810 retains the capability for reconfiguring the operation of the various blocks in the supervisor, according to user input.
It should be noted that the structural features and advantages of the build-supervisor procedure are not entirely separate from those of the supervisor procedure. The two procedures are preferably operated separately, but they provide an advantageous combination. The features of the supervisor procedure are partly designed to advantageously facilitate use of the build-supervisor procedure, and the features of the build-supervisor procedure are par~ly designed to advantageously facilitate use of the supervisor procedure.
In the presently preferred embodiment, the nexus between the build-supervisor procedure and the 75'~9 SUpQrVisor procedure is somewhat diffPrent from the n~xus between the build--~xpert procedur~ and the operating expert procedures. The user entries made into the more constrained parts of the templates can be transferred fairly directly to the operating supervisor procedure: the build-supervisor procedure store~ values (corresponding to the data input by the user in the accessible fields of the templates~ in a shared section of memory, which is immediately accessible by the supervisor procedure as soon as the stored status value for the block is changed to "Active". By contrast, if the customized user routines (including the expert routines generated by the build-expert software) are modified, they must be compiled and linked with the supervisor procedure.
The build-supervisor procedure 810 preferably also has the capability to stop or restart the base cycle procedure 802, independently of whether the build-supervisor procedure 810 has updated the shared memory 814 in accordance with user inputs to templates 812.

To~-Level Menu The user who begins an interaction with the build-supervisor procedure is first presented with a menu which (in the presently preferred embodiment) resembles that shown as Figure 16. This ~enu provides options which permit the user to setup (or modify) blocks, to monitor blocks, to call block-management utilities, to exit, or to go into a structured environment for writing user programs.
If the user chooses block setup, he next sees a menu like that shown in Figure 9. This menu is presented to the user by the build-supervisor procedure 810 to select a specific existing template 812' (i.e. a template with the previously defined data values of a 1;2~'755~

particular block are shown in the appropriate fields of the template~ or a blank template 812 of a given type to provide user inputs to define or modify a block 851, 852, etc.
This form allows th~ user to choos~ which blocX to enter setup parameters for, and, if th~ block is a new one, allows a choice of which type block it will be. To go back to the previous form (in this case the top-level menu), he can press the "-" key on the keypad.
To set up a new block, the user can either enter a block number which he knows is not in use, or the build-supervisor procedure will provide him with the lowest number block which is not in use. To enter a block number, the user can simply type the number in the block number field and press the return key. To get the build-- supervisor procedure to find the lowest number unused block, the user can press keypad 8. The cursor will move to the block type field and the build-supervisor procedure will request that the user enter the number from the list for the type of block desired. The build-supervisor procedure will then present the user with a block setup form for that block type. If the user mistakenly enters a block number which is already in use, the build-supervisor procedure will go directly to the setup form for that block, but the user can simply press keypad minus on the setup form to go back to the block setup selection form and try again. To enter or modify setup parameters for an existing block, the user can simply enter the block number and press the return key, and the build-supervisor procedure will present the block setup form for that block.
In the best mode s presently practiced, all four block se~up for~s have some common features. Xeypad 9 will ~ove the cursor from anywhere on the form up to the blook nu~ber field. Keypad 8 will find the lowest num~er ~37~s19 available block and ~et it up as the same block type as the form showinq on the screen. Keypad 7 tests all the parameters on the block and changes the block status to switch it on or off, or requests new data if the user has not yet supplied it. (In addition, many of the parameters are checked for gross error as the user enters them.) The various block setup forms shown as Figuxes 10 through 13 will be individually described below; but first, some features common to some or all of the block se~up f orms, and some features characteristic of the operation of the blocks thus defined, will be described.
When a block is turned on, the block status will not go directly to "On." (The full system of block status options (in this embodiment) is described below.) - Depending on how the block is set up to be switched on and off, the status will change to "Toggled on" or "Active". The base cycle procedure will update the status as the block is executed, changing to "Just turned on" and then to "On". When turning a block off, the status will change to "Off" or "Inactive", again depending on how the block is set up to switch. These status sequencing rules facilitate use of initialization and/or shutdown steps in controlling block 2~ functionality.
Any time a parameter is entered or changed on a setup form, the block status will be set to "Inactive."
This means that the block parameters have not been checked to assure that everything needed has been entered and is consistent. If a parameter is changed on a block which is currently on, the block ~ust be toggled fro~ "Inactive" to "~ctiYe" or "Toggled On" using Keypad 7.

755~

Data Source Speci~ication The tempiates presented to the user for block customization include 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. ~he value of a setpoint in a particular distributed control system, the value of a sensor measurement in a particular process monitoxing system, the value of a constraint from a process control or supervisor system, and tim~ 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 dis.ributed control system.
For example, in Figure 10 the user has entered "4"
in the highlighted area 1002 after the phrase "Measured Variable Type:". This particular identifier (i.e. the value entered in this field by the user) indicates that the variable type here is a current value of a variable from the historical database, and the build-supervisor procedure adds an abbreviated indication of this ("Current Val Hist Dbase Var #") onto the user's screen as soon as the user has entered this value in the field 1002. (If the user entered a different code in the field, a different short legend might be shown. For example, as seen in Figure 10, the user has indicated a variable type of "2" after the phrase "Manipulated Var Type", indicating that the manipulated variable is to be a loop goal of the DMT control system.) As the second identifier, the user has indicated a value of "2990" in field 1004, to indicate (in this example) which particular Database variable's current value is to be used. For this identifier too, the build-supervisor 3S procedure adds an abbreviated indication of its ~'75~9 interpretation of this iden1:ifier ("DMT PRD ~FB SHWRT
DEVIAT") onto ~he user's scr,een as soon as the user has entered this value in the field 1004.
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.

Block Timinq Information In the presently preferred embodiment, all blocks except the Shewhart block provide the same block timing options. Block timing determines when a block will perform its control actions. The build-supervisor procedure provides three fundamental block timing options, which can be used in any combination, providing a total of 7 block timing options. The three fundamental options are:
Fixed Time Interval: the block will execute at a fixed time interval. The user specifies the ti~e interval, e.q. in minutes. (Note that a combination of this option and the following has been specified in the example of Figure 13, by the user's entry of "5" into field 1306.) ~ey Off Measured Variable: the block will execute every time a new value is entered into the proce~s database for the measured variable. The measure~

1~975i~
variable must be a ~Isampled~ type variable. (Note that this option has been specified in the example of Figure 10, by the user's entry of "2" into field 1006.) Rey Off Another ACS Block: the block will execute every time a (~pecified) lower numbered block executes. The user specifies which block will be the key block. Any combination of one, two or three timing options can be used. Blocks using a combination timing option execute whenever any of the specified timing options are satisfied. (Note that this option has been specified in the example of Figure 11, by the user's entry of "3" into ~ield 1006.) Block timing options are represented on the setup forms by a number code. The user enters the number code corresponding to the desired timing option. If the timing option includes fixed interval timing, an execution time interval must also be specified. If the block is to key off another block, the key block number must be specified.
In future alternative embodiments, the block timing options set forth here may be especially advantageous in multi-processor em~odiments: the separation of the control action specifications in multiple blocks shows the inherent parallelism of the problem, while the keying options in which one block keys off another show the block sequencing constraints which delimit the parallelism. The standardized data interface used in the presently preferred embodiment may also be advantageous in this context, by allowing block execution to be keyed off events external to the supervisor.

primary Block__wi tchinq The supervisor procedure provides several ways to switch block actions on and off. If the block needs to be turned on and o~f by an operator, the build-lZ'r~7~i9 supervisor procedure allows the user to specify an external switch system and a switchable entity within that system which the block on/off status i5 to follow.
For example, the user may specify a specific control system and a loop number within that system. The block will turn on when that loop is on, a~d off when that loop is off. The standardized data i~terface allows any accessible control system to act as the switch system.
As a further alternative, the blocks can be set to switch on and off only under the control of the developer (l.e. under the control of the build-supervisor user). In this case, the block can only be switched using the toggle on/off function on the block setup form.
The external switch system is represented on the block setup forms by a number. The user enters the number corresponding to the external switch system he wants to use. The entity within the switch system ( e . a .
the loop number) is entered in the next field. (In the example of Figure 10, the user entries in fields 1008 and lOlO have specified an external switching variable.) If the block is to be turned on and off only from the build-supervisor procedure setup form, a zero is entered for the switch system number, and the word "Manual" will show in the field for the switch entity number. (This option hac been selected in the example of Figure 13.) Secondarv Block Switchina The supervisor also provides secondary means of controlling block execution. Blocks which have been turned "on" by their primary switch controls may be "selected", "de-selected", or "held" by programmatic requests. The status of selected blocks changes to "On-selected". Selected blocks continue to function as if they were "On". The status of blocks which are 1~7515~

deselected by programmatic request changes to "On-deselected". De-selected blocks take no ~ontrol action. ~owever, they differ from blocks which are lloff'l because they continue to maintain all their internal information so that they are always ready to execute if "selected". The status of blocks which are held by programmatic request changes to l'on- holding".
The programmatic request includes the length of time the block is stay on hold. Blocks which are holding act as if they were off. When the holding ~ime expires, the status of holding blocks changes to t'Just turned on,'}
and they initialize.
One advantage of these block switching options is that they pro~ide a way to embed alternative control strategies in the supervisor procedure. That is, control strategies can be readily changed merely by selecting some blocks in the supervisor procedure and/or deselecting other blocks. This is advantageous in terms of software documentation, since it means that alternative control strategies can be documented and maintained within the same software structure. It is also advantageous in interfacing to other procedures:
for example, the expert systems called by the presently preferred embodiment will frequently take action by selecting and/or deselecting blocks of the supervisor procedure.
These block control options facilitate the use of one supervisor procedure to interface to multiple controllers, and the use of one supervisor procedure by different users to control different processes. The block status system permits one or more blocks to be updated without interfering with the running supervisor process; in fact, in optional environments, multiple users could be permitted to update different blocks at the same time.

12~755~3 ~`~
All blol:k~ allow thE~ us~r t:o ante~ three desc:riptive ~ields. l~ese ~i~lds are ~ar user reference and can b~ ~sarched when printing list~i o~ ~loc3c par2~me~ers~ T~ey haYç! no e~fect on block actions.
"con~rol application name" ~ield allows thQ user to group bloclcs that are part o~ 'ehe ~ contrDl application by givi ng them all the 5ame~ AppliCation na~ne. (~n the ~ca~ple o~ Figure 10, ~Q user entry ~n ~ield lol~ has pecified "MF8 Control". ~ot~ l~at thQ
~ucamples of Figures 11, lZ, and 13 ~how correspondi ng ~ntries in ~chis field. ) ThR bloc3c description field allowE; th~ user to describe the bloclc's speci~ic action or pUrpOSB, (In the example o~ Figure 13, the UsQr ~ntry in rield 1316 has explainQd that this is a "Bloc~ to run expert deciding where to take MFB feedback action".) The ownership ~i~ld ~peci~i~s which u3~r b~ control o~ the block. (~n th~ ~xa~le o~ Figur~ 10, ~he user ~ntry in ~ield 1012 ha~ specified ~Skeirik~'. Note ~hat the aXample5 0~ ~igUrR5 11, 1~, and 13 show correspond~ng Qntrie~ ~n this ~ield.l This ~ield ~acilitat~s U3Q 0 ~he orqaniz~tion ~escribed in anvironments where ~ultiple u~rs are de~ining ~locXs which run within the ~ame 3upervigor procedure.
0~ cours~ in ~ulti-user en~Lronments it may ~e desirable to ~llow ~03e u~ers a greater degree o~ access than others. muS, ~or QxamplQ ~ SOme USQ~ may be authorized to ~d~t a ~lock, whil~ othar~ may ba ~uthoz~zed to toggl~ the block on or of bu~ not to ~dit it, and oth~r~ ~ay be a~hor~ zed to moni~or ~lock operation ~ut not ~u~horized to changa ~t. Slmilasly, ~cce~ to ~xFert ~yste~s zay be constraLned ky gi~ing ~rent~r aut~oriz~tion to ~ome users than to others; 50me users ~y bQ permitted ~4 mak~ ca~ls to the expert .

s~

system but not to ~dit the r~lebase, and other users may not be permitted to do either. In the presently preferred embodi~ent, all of these choices can readily be implemented by using thle f il8 ownership and access S control list options available in the YMS operating systems, but of course this functionality could be implemented in many other ways instead.

Action Loaqina The supervisor procedure provides a means of reporting control actions and/or logging them in a file for recall. Control action messages are written by a user routine. Control blocks call user routines after their control actions are complet~, and pass data regarding their actions. The action log file field allows the user to enter the name of the file to which logging messages will be written. The same log file can be used for more than one block (e.a. if the two blocks' actions are part of the same control application). (For example, note that field 1018 in the example of Figure 10 and field 1118 in the example-of Figure 11 both specify "MFBCONTROL" as the action logging file.) The log file name is limited to letter and number characters, and no spaces are allowed (except after the end of the name).
~lock Status Note that, in the example of Figure 10, a block status of "On-selected" is displayed in area 1020. This is not a field into which the user can directly enter data, but it will change in response to user actions (e.a. the user can toggle the block on or off by hitting keypad 7). The block status codes used in the presen~ly preferred embodiment reflect several aspects of block setup and execution, including:
Proper configuration of block parameters;
7~

~3755~3 ~n/off status ~f block;
Failure of block actions; and Failure of user routines.
Some common block status values are:
"Inactive:" this indicates that the block has not been properly configured and toggled on, or that a parameter was changed. This is also the normal "off"
status of a block which has been configured to switch on and off with a switch system variable, if the user toggles it off from the setup form.
"On:" this is the normal status for blocks which are performing their control actions.
"Off:" this is the normal status, for a block which has been configured to switch on and off with a switch system variable, when that variable is in its off state. This is also the normal status for blocks which are ~onfigured to switch on and off through the setup form only and have been toggled off from the setup form.
"Active:" this is the status to which a block is toggled on if it is configured to switch on and off with a switch system variable. This status will change on the next cycle of the control program, to "On" or to another value, depending on the state of the switch system variable.
"Toggled on:" this is the status to which a block is toggled on if it is configured to switch on and off through the setup form only. This status will change on the next cycle of the control program.
"Just turned on:" this is a norm~l transition state for blocks going from an "off" status (eg: off, inactive) to "On" status. Blocks whose status is "Just turned on" will be initialized by the base cycle procedure, which resets the last execution time and the measured variable and key block times used for block ~.2~7~i5~

timing. Feedforw~rd blscks initialize the "sld"
measured variable value to the current value.
"On~selected": indicates that a block which is on has been selected by a programmatic request. The block continues to function as if it were On.
"On-deselected": indicates that a block which is on has been de-selected by a programmatic request.
The block takes no control actions, but continues to maintain its internal parameters as if it were On. This keeps the block ready to act if selected.
"On-holding": indicates that a block has been put on hold for a specified length of time by a programmatic request. The block takes no control action. A block that has been holding will re-initialize and go back to "On" status when the holding period expires.
"On-Failed usr routin:" this status indicates that a user routine called by this block had a fatal error which was bypassed by the supervisor procedure on the most recent execution of the block. Fatal errors in user routines are reported in the control program log file (not the same as action log files), and can be reviewed using the "List log file" option on the System Functions screen, described in the section on block monitoring.
"On-Recovrd usr Error:" this indicates that a fatal error was bypassed in the user routine, but that the user routine ran successfully on a later execution.
Again, the log file will give more details about what happened.
"Qn-Err ...... :" many abnormal status values can indicate that problems were encountered in block execution, e.~. problems in the input or output of data to control systems. The latter part of the status field gives some indication of the problem. Most such errors are also recorded in the control pro~ram log file.
Various other block status values can readily be inserted, along the lines demonstrated by these examples.

Feedback Blocks Figure 10 shows a sample of a templat~ 812 presen-ted to the user to define a ~eedback block. In the specific example shown, the block being worked on is block number three of the 200 available blocXs 8S1, 852, etc., and the various data values shown in this Figure reflect the entries whieh have been made at some time to define this particular block.
The feedback block provid~s proportional feedback lS action. In feedback action, the user specifies a measured value tcalled the "measured variable") and a goal value (setpoint) at which he wants to maintain it.
Feedback action calculates the "error" in the measured variable ~measured variable value - goal), and computes its action by multiplying the error times the 'Iproportional gain". The current value of the "manipulated variable" is changed by the amount of the calculated action.
The basic feedback action can be altered by several additional parameters. A deadband around the goal can be specified. If the measured value falls within plus or minus the deadband of goal, no action is taken. The amount of action taken can be limited to a fixed amount.
The range over which the value of the manipulated variable can be changed can be limited to k~ep it within operable limits. Screening limits can be specified on the measured variable value, in which case measured values outside the screening limits will be ignored.

1~755~

Block timing and ~witching and the block description fields ~ollow the general outlines given above.
Specifying a feedback block on the block setup selection form (FigurQ 9) brinqs up a feedback block setup form, as shown in Figure ~.o.

Parameters The parameters which the user is asked to specify include:
Measured variable type: a number code representing the software system and the type of entity which the block should use for the measured variable.
(A sample response might be a number code indicating a Historical database variable.) Measured variable number: the number of the entity within the specified system which the block will use for the measured variable. For example, if the measured variable type is a historical database variable, the measured variable number is the number of the variable in the historical database. After the measured variable type is entered, the label next to this field will show what type of data is needed. When the measured variable number is entered, other fields will also be filled in: the name and units for the measured variable, deadband and goal; units and default values for the max and min measured values. If block timing is to key off entry of new data into the measured variable, only discretely sampled variable types can be used.
Goal: the value at which the measured variable is to be "held". The value is entered in the units of the ~easured variable.
Nanipulated variable type: a number code representi~g the "target system'l - the software package and the type o~ entity which the block should manipulat~. Examples ar~: c~ntrol system loop goal, historical datab~se Yariable, a setpoint in a distributed control system, or ~ setpoint for a programmable 1QP controller.
Manipulated variable number: th~ number of the æntity within the target system which the blocX will manipulate. For example, if the manipulated vaa~iable type is a control system loop goal, the manipulated variable number would be the number of the loop whose goal is to be changed~ The label next to this field will show what type of in~ormation is needed; in this case the label would show "Cont Sys loop ~".
Proportional gain: the constant relating the change in the manipulated variable to the error. ~he units of the gain are shown to the right of the field after the measured and manipulated variable have been specified. Control action is calculated:

Error = [Measured variable value - goal value]

Manipulated delta = Error * [Proportional gain]

The manipulated delta is added (subject to limits~ to the current value of the manipulated variable.
Deadband: A range around the goal value. If the value of the me sured va~able ralls within a range defined by the goal plus or minus the deadband, no action is taken Timing option, execution time interval, and Rey bloc~ number: these parameters are those described above.
- External switch cystem and switch number:
these parameters ~re de~cribed above.
Maximu~ ~anip delta: the maximum change that 12~:37S~9 can be made in the manipulated variable's value in one control action.
Minimum and maxim~lm value of the manipulated variable: limit values outside which contr~l action will not move the value of the manipulated variable. If a computer control action would put the manipu~ated value outside the limits, the value is set equal to the limit.
If the manipulated value is moved outside the limits (by operator action, for example) the next control action will re,urn the value to within the limits.
Minimum and maximum value of measured variable: Screening limits for reasonable values of the measured variable. Any time the measured variable value falls outside these limits, the value will be ignored and no action is taken.
- Action log file: this specifies the name of the log file for action logging.

- Feedback Block Operation The sequence of actions performed by each feedback block, when executed by the base cycle routine, is:
- If block status is "On-deselected", do no further actions;
- Get the current value of the measured variable (If not accessible, set status to "On-err...."
and do no further actions);
- Get the current time stamp of the measured variable;
- Test the value of the measured variable. If it is outside the minimum and maximum allowed values, set status to "On-msrd out of lims" and do no further actions.
- Get the current value of the manipulated variable. If not accessible, set status to "On-err ....1l and do no further actions.

12~3755~3 ~ Compute the error (= Measured value - Goal).
If absolute value is less than the deadband, do no further actions.
- Compute the change in the man~pulated variable:

Delta_manip = Error * proportional Gain If the absolute delta is greater that the maximum allowed delta, set it equal to the maximum (maintaining proper sign).
- Compute the new value of the manipulated variable:

New manip value = Current manip value + delta_manip If the value is outside the max/min limits, set it equal to the nearest limitO If limited, recompute the delta using the limitO
- Change t~e manipulated variable value to the new value computed. If not accessible, changs status to "On-err ..." and do no further actions.
- Load user array values for use by the user routine.
- If delta manip is not zero, update the past action values and times.
- Call the user routine.

Data passed to the user routine In the presently preferred embodiment, each feedback block is able to pass information about its actions to the user routine, by using a commonly accessible memory block named "User vars." (The use of this data by the user routines is described in more ~97~:;5~

detail below.) The data passed by the feedback block may include:
"User integer(1~" - the time stamp of the measured variable (from the database);
"User integer(~ the time the action das taken;
"User real(1)" the change in the value of the manipulated variable;
"User real~2)" - the computed error; and "User character(l)" - a string (alphanumeric) sequence which describes ~he bloc~ type; or feedbacX
blocks this is set to be = 'Feedback'.

SamDle Source Code The source code for the procedure which actually performs this function, in the presently preferred embodiment, is as follows.
Table 2 C
C Feedback block.for C ACS subroutine to do feedback action on the Vax, communicating C directly with the target system.
C
C
Subroutine Feedback block ( Block ) Include 'ACS$includes:Block Parameters.inc/nolist' Include 'ACSSincludes:Van_functions.inc/nolist' Include 'ACSSincludes:User vars.inc/nolist' Include 'ACS$includes:ACSstatus.inc/nolist' Include 'ACS~includes:ACSserv.inc' Include 'AcsSincludes:TIserv.inc' Include 'AcsSincludes:TIstatus.inc' Include 'ACSSincludes:Manip params.inc' Include 'ACSSincludes:Meas Params.inc' C

129~75~9 c Integer*2 Meas_var system Integer*2 Meas var number Integer*2 Manip var system Integer~2 Manip var number Integer*4 Block Integer*4 Measured time stamp Integer~4 Integer_Now Character*20 now time Real*4 Measured value Real~4 Current manipulated value Real*4 New manipulated value C...Special handling for 'On-deselected' status do nothing C

If ( Block status(Block~ 13) .eq. 'On-deselected') Then Return End If C

ACS status = ACS get meas_var type ( Block , MEAS_VAR system ) Manip var system = Manipulated variable(Block) Manip var_number z New manipulated variable(Block) D Write(6,*) ' Calling new fePdback - block = ',block C

C...Get the measured value C

Van status = VssS from ascii time ( ' ' , Integer now ) van_status = Vss$ to ascii_time( Integer now , now time ) C

C...Measured Value is TPA PCS loop goal C

If ( Meas_var_system .eq. PCS TPA Loop_goal ) Then ACS status = ACS get pcs goal( 'TPA
1 Measured variable(Block) , Measured value ) If ~ ACS Status .ne. Sloc(ACS success) ) Then C....... ......If PCS goal value not available, don't execute Block status(Block) = 'On-Err-PCS goal get' Write( 6, *) 'Feedback exit due to measured var not availa write(6,*)' ACS Block: ',block,' at: ',now time Return End If C

C...Measured Value is DMT PCS loop goal C

Else If ( MEAS var system .eq. PCS DMT loop goal ) Then ACS status = ACS get pcs goal( 'DMT ' , 1 Measured variable(Block) , Measured value ) If ( ACS Status .ne. %loc(ACS_success) ) Then C........... If PCS goal value not available, don't execute 7~59 Block_status(Block) - 'On-Err-PCS goal get' Write( 6, ~) 'F@edbaGX exit due to measured var not availa write(6,*)' ACS Block~ lock,' at: ',now time Return End If C

C...Measured Value is ACS block goal C

Else If ( MEA5 var system .eq. ACS block goal ) Then ACS status = ACS get goal ( 1 Measured variable(Block) , Measured v~lue ) If ( ACS Status .ne. ~loc(ACS_success) ) Then C....... ......If ACS goal Value not available, don't execute Block status(Block) = 'On-Frr-ACS goal get' Write( 6, *~ 'Feedback exit due to measured var ~ vaila write(6,*)' ACS Block: ',block,' at: ',now time Return End If C

C...Measured Value is Vantage variable C

Else If ( Meas var system .eq. cur val_Van_var ) Then Van Status = VssSg current( Measured variable(Block) , 1 Measured_value ) If ( Van Status .ne. ~loc(vss normal) ) Then C.... .......If Variable Value not available, don't execute Block status(Block) = 'On-Failed Msrd var ' Write( 6, *) 'Feedback exit due to measured var not availa write(6,*)' ACS Block: ',block,' at: ',now time Return End If C
end if Van status = VssSg curtime ( Measured variable(Block) , 1 Measured t~me stamp ) C.... Check the Measured variable to see if it is within limits If ( (Measured value .lt. Measured min(block) ) .or.
1 (Measured value .gt. Measured max(block) ) ) Then C.... ..... Reject the data point Write( 6, *) 'Feedback exit due to out of limts measured' write(6,*)' ACS 81ock: ',block,' at: ',now time Block statustBlock) = 'On-Msrd out of lims ' Return End if C
C..;Get the current manipulated value C
C

5~9 C...Tar~et is TPA PCS loop goal C

If ~ Manip var syst~m .eq. PCS TPA Loop ) Then ACS status - ACS get_pcs_goal( 'TPA
1 Manlp_var_number , Current manipulated value , If ( ACS Status .ne. %loc(ACS success) ) Th~n C....... ......If PCS goal value not available, don't executa BlocX_status(Blsck) = 'On-Err-PCS goal get' Return E~d If C

C... Target is DMT PCS loop goal Else If ( Manip var_system .eq. PCS_DMT_loop ) Then ACS statu~ - ACS get pcs goal( 'DMT ' , 1 Manip var_number , Current_manipulated value ) If ( ACS Status .ne. %loc(ACS success) ) Then C... ..........If PCS goal value not available, don't execute BlocX_status(Block) = 'On-Err-PCS goal get' Return End If C

C... Target is ACS ~lock goal Else If ( Manip var_system .eq. ACS block ) Then ACS status = ACS get goal ( Manip var number , 1 Current manipulated value ) If ( ACS Status .ne. %loc(ACS success) ) Then C... ..........If ACS goal Value not available, don't execute Block status(Block) = 'On-Ezr-ACS goal get' Return End If C

C...Target is Vantage variable Else If ( Manip var system .eq.
1 Vantage variable ) Then Van Status = Geteuval ( Manip var number , 1 Current manipulated value ) If ( Van Status .ne. %loc(vss success) ) Then C... ..........If Variable Value not available, don't execute Block_status(Block) = 'On-Err-Vant var get ' Return End If C... Target is Texas Instruments PM550 controller setpoint in CRD
Else If ( ( Manip var system .ge. Low PM550 ) .and.
1 ( ~anip var system .le. Hi PM550 ) ) Then If ( Manip var system .eq. CRD ESCHS PM550 01 ) Then ACS status - TI get_loop setpoint ( 'TI PM550 01 PO~T' 12975~
1 Manip_var number , Current manipulated value ) Else If t Manip var system .eq. CRD ESCHS PM550 02 ~ Then ACS status 3 rI get loop setpoint ( 'TI_PM550 02 PORT' , 1 Manip var number , Current manipulated value ) Else If ( Manip var Sy5t8m . eq. CRD_ESCHS PM550 03 ) Then ACS status = TI get loop setpoint ( 'TI PM550 03 PORT' , 1 Manip var_number , Current manipulated value ) Else If ( Manip var system .eq. CRD ESCHS PM550 04 ) Then ACS status ~ TI get loop setpoint ( 'TI PM550 04 PORT' , 1 Man~p var number , Current manipulated value ) Else If ( Manip var system .eq. CRD ESC~S PM550 05 ) Then ACS status = TI_yet_loop_setpoint ( 'TI PM550_05 PORT' , 1 Manlp var number , Current_manipulated value ~
Else If ( Manip_var system .eq. CRD ESCHS PM550_06) Then ACS status = TI get loop setpoint ( 'TI PM550 06 PORT' 1 Manlp_var number , Current_manipulated_value ~
Else If ~ Manip_var system .eq. CRD ESCHS PM550 07) Then ACS_status = TI get_loop_setpoint ( 'TI PM550 07 PORT' 1 Manip_var number , Current manipulated_value ) End If If ( ACS Status .ne. %loc(TI success) ) Then C....... ......If PM550 setpoint value not available, don't execute Block status(Block) = 'On-Err-TI setpnt get' Write( 6, *) 1 ' Feedback exit - TI PM550 Manip var not gettable.' Write (6, *) ' ACS Block: ',block,' at: ',now_time Return End If Else ! Other Manip device type End If C

C...Value is within limits - Test to see if the error is less th deadband C

Error = Measured value - Goal(81Ock) If ( Abs(Error) .lt. Absolute deadband(Block) ) Then d Write( 6, *) 'Feedback error less than deadband' Return End If C

C..... Compute proportional Feedback Response-Test Delta to see if too C

Delta ~ Error * Proportional gain(Block) If ( Abs(Delta) .gt. Max manip delta(Block) ) Then Delta = Sign(Max manip delta(Block),Delta) End If C...Cal ulate new manipulated value, check to see it within limits C

New manipulated value = Current manipulated value + Delta C

If ( New_manipulated value .gt. Manipulated_max(~lock) ) ' 97~ 9 New manipulated value a Manipulated_max(Block) Else If ( New manipulated value .lt. ~anipulated min(Block) ) New manipulated value - Manipulated min(Block~
End If Delta - New manipulated value - Current_manipulated value C

C... Transmit the new Manipulated Value to the manip variable C...Target is TPA 2CS loop goal C

If ( Manip var system .eq. PCS_TPA_Loop ) Then ACS status - ACS PUt pcs soal( 'TPA ' , 1 Manip var number , New manipulated value ) If ( ACS S~atus .nP. %loc(ACS success~ ) Then C... ..........If PCS goal value not available, don't execute Block status(Block) = 'On-Err-PCS goal put' Write( 6, *) 'Feedback exit due to failed manip Yar put.
Write(6,*)' ACS Block: ',block,' at: ',ncw tlme Return End If 'C
C... Target is DMT PCS loop goal C

Else If ( Manip var system .eq. PCS DMT loop ) Then ACS status = ACS put pcs goal( 'DMT ' , 1 Manip var number , New manipulated value ) If ( ACS Status .ne. %loc(ACS success) ) Then C....... ......If PCS goal value not available, don't execute Block status(Block) = 'On-Err-PCS goal put' Write( 6, *) 'Feedback exit due to failed manip var put.
Write(6,*)' ACS Block: ',block,' at: ',now time Return -.
End If C

C...Target is ACS block goal C

Else If ( Manip var system .eq. ACS block ) Then ACS status = ACS put goal ~ Manip var number , 1 New manipulated value ) If ( ACS Status .ne. %loc(ACS success) ) Then C....... ......If ACS goal Value not available, don't execute Block status(Block) = 'On-Err-ACS goal put' Write( 6, *) 'Feedback exit due to failed manip var put.
Write(6,*)' ACS Block: ',block,' a~: ',now time Return End If C

C...Target is Vantage variable C

~297559 Else If ( Manip var system .eq.
1 Vantage_variable ) Then Van status - Puteugen ( Manip_var number , 1 New mani.pulated value ) If ~ Van Status .ne. %loc(vss; success) ) Then C....... ......If Variable Value not available, don't execute ~lock status(BlocX) = 'On-Err-Yant var put ' Write( 6, *) 'Feedback exit due to failed manip var put.
Write(6,*)' ACS Block: ',block,' at: ',now_time Return End If C

C...Target is Texas Instrumen~s PM550 con roller setpoint in C~D
C

Else If ( ( Manip_var system .ge. Low_PM550 ) .and.
1 ( Manip_var_system .le. Hi PM550 ) ) Then C

If ( Manip var_system .eq. CRD ESCHS PM550 01 ) Then ACS_status - TI put loop setpoint ( 'TI PM550 01_PORT' , 1 Manip_var number , New_manipulated value ) Else If ( Manip_var_system .eq. CRD_ESCHS PM550_02 ) TAen ACS status = TI p~t loop_setpoint ( 'TI PM550 02 PORT' , 1 Manlp_var number , New manipulated_value ) Else If ( Manip_var system .eq. CRD ESCHS PM550 03 ) Then ACS_status = TI put loop setpoint ( 'TI_PM550_03 PORT' , 1 Manip_var_number , New manipulated value ) Else If ( Manip var system .eq. CRD ESC~S PM550 04 ) Then ACS status = TI put loop setpoint ( 'TI PM550 04 PORT' , 1 Manip_var_number , New_manipulated_value ) Else If ( Manip_var system .eq. CRD ESCHS PM550 05 ) Then ACS status = TI put loop setpoint ( 'TI PM550 05_PORT' , 1 Manip var number , New_manipulated_value ) Else If ( Manip var system .eq. CRD_ESCHS PM550_06) Then ACS_status = TI Put-loop-satpoint ( 'TI PM550 06_PORT' , 1 Manip var number , New manipulated value ) Else If ( Manip var_system .eq. CRD ESCHS PM550 07) Then ACS status = TI put loop_setpoint ( 'TI PM550 07_PORT' , 1 Manip var number , New manipulated value ) End If If ( ( ACS Status .ne. %loc(TI_success) .and.
1 ( ACS_status .ne. Sloc(TI_clamped) ) Then C........... ....If PM550 setpoint value not accessible, dont execute Block_status(Block) = 'On-Err-TI setpnt put' Write( 6, *) ' Feedback exit - TI PM550 Manip v puttable.' Write (6, *j ' ACS Block: ',block,' at: ',now time Return End If Else ! Other manip device types End If C....Load special arrays for user programs to log messages.

c 12~75~;9 User integer(l) Measured time stamp User integer(2) = Integer now User real(l) ~ Delta User real(2) ~ Error User cbar~cter(l) - 'Fe~dback C...If Delta is non-zero, update past actions C

If ( Delta .ne. 0 ) Then Do 90 J ~ 5,2,-1 Past action value(810ck,3) = Past action value(Block,J-1) Past action time tBlock,J) = Past_action_time (Block,J-1) Past action value(Block,l) = Delta Past action time (Block,l1 = Integer now End If C.... Call User subprograms for this block Call User ProgramstBlock) C

C...All done C

Return End Copyright (c) 1987 E.I.DuPont de Nemours & Co., all rights reserved ~L2~7S5~
F~edforward Block Figure ll shows ~ sa~ple of ~ template 812 pr~sen-ted to the user by the build-supervisor procedure ts define a feedfo~ward block. In the specific example shown, the block being worked on is block number six of the 200 available blocks 851, 8S2, etc., and the various data values shswn in this Figure reflect the entries which have been made at some time to define this particular block.
The ~eedforward block provides proportional feedforward action. In feedforward action, the user specif ies a measured value (called the "measured variable") and a manipulated variable whose value is to be changed in proportion to (or, more generally, in accordance with) the change in value of the measured variable. Feedforward action begins when the "old measured value" is set equal to a current value (usually when the block is first turned on)~ The measured variAble is then ~onitored for changes in value and ~he manipulated variable value i5 changed in proportion. The "old measured value" is then updated to the value at the time o~ this action. (The use of the "old measured valu~" in ~eedforward rules is one reason why an initialization stage is needed: if a feedforward block were switched from inactive status directly to on status, it might indicate a very larqe change to the manipulated variable if the delta were calculated from an out-of-date "old measured value.n) In the presently preferred embodiment, the basic eedforward action can be altered by several additional par~meters. A deadband can be specified, so that, i~ the ~easured value ~hanges by less than the deAdband, no ~ction is taken. The amount of ~ction taken can be l~mited to a fixed ~mount. The rango over which the 3S vnlue of the ~nipulated variable can be changed can-be ~2~S~

limited to keep it within operable limits. Screening limits can be specified on the measured variable value, S9 that measured values outside the screening limits are ignored~ Block timing and switching options and the block description fields follow the general outlines given above~
In the presently preferred embodiment, specifying a feedforward block on the block setup selection form (Figure 9j brings up a feedforward block setup form liXe that shown in Figure 11.

Parameters The parameters are:
Measured variable type: a number code representing the software system and the type of entity which the block should use for the measured variable.
Measured variable number: the number of the entity within the specified system which the block will use for the measured variable. For example, if the measured variable type is a historical database variable, the measured variable number is the number of the variable in the historical database. After the measured variable type is entered, the label next to this field will show what type of data is needed. When the measured variable number is entered, other fields will also be filled in: the name and units for the measured variable, deadband; units and default values for the max and min measured values. If block timing to key off entry of new data into the measured variable, only discretely sampled variable types can be used.
Goal: the goal field cannot be used for feedforward blocks.
Manipulated variable type: a number code representing the software package and the type of entity 129'75~
which the block should manipulate. Examples are: control system loop goal, historical database variable.
Manipulated variable number: the number of ~he entity within the specified system which the block will manipulate. For example, if the manipulated variable type is a control system loop goal, the manipulated variable number would be th~ nu~er of the loop whose goal is to be changed. The label next to this field will show what type of information is needed; in this case the label would show "Cont Sys loop #".
Proportional gain: the constant relating the change in the manipulated variable's value to the change in the measured variable's value. The units of the gain are shown to the right of the field after the measured and manipulated variable have been specified. Control action is calculated as-Measured delta = [Measured variable value - Old value]

Manipulated delta = Measured delta * [Proportional gain]

The manipulated delta is added (subject to limits) to the current value of the manipulated variable.
Deadband: A range around the "
old measured value" (i.e. the measured value at the time of the last block action). If the value of the measured variable is within plus or minus the deadband of the old measured value, no action -is taken and the old measured value is not changed.
Timing option, execution time interval, and Key block number: these parameters are described above.
Switch system and switch number: these are described above.

~1.2975ri9 Maximum output delta: the maximum change that can be made in the manipulated variable's value in one control action.
Minimum and maximum value of the manipulatPd variable: limit values outside which control action will not move the value of the manipulated variable. If ~
computer control action would put the manipulated value outside the limits, the value is set equal to the limit.
If the manipulated value is moved outside the limits (by operator action, for example) the next control action will return the value to within the limits.
Minimum and maximum value of measllred variable: These define screening limits for reasonable values of the measured variable. Whenever the measured variable value fall~ outside these limits, the value will be ignored and no action is taken.
Action log file: this field is described above.
The use of a deadband in feedforward blocks is one of the features which tend to force process control into discrete steps, rather than continuous small changes.
One advantage of this novel teaching is that full logging can be used: every single change made by the supervisor procedure can be logged, without generating an excessive number of messages. This in turn means that monitoring, diagnosis, and analysis of processes (and of process control systems) becomes much easier.

Block O~eration The sequence of actions performed by a feedforward block is:
- Get the current value of the measured variable (If not accessible, set status to "On-err..."
and do no further actions);

S5~

- ~est the value of the measured variable. If it falls outside the allowed range of values, set status to l'On-msrd out of lims" and do no further actions.
- Compute the change in the value of the measured variable:
Delta measured = Measured value - Old measured value.
If the absolute value of the change is less than the deadband, do no further actions.
- Compute the change in the manipulated variable:
Delta manip = Delta measured * Proportional gain.
- Set "old measured value" equal to the current value of the measured variable.
- If block status is "On-deselected", do no further actions;
- Check the magnitude of the manipulated value delta~ If greater than the maximum allowed delta, set magnitude equal to the maximum.
- Get the current value of the manipulated variable. If not accessible, set status to "On-err ..... " and do no further actions.
- Compute the new value of the manipulated variable:
New manip value = Current manip value + delta_manip.
If the value is outside the max/min limits, set it equal to the nearest limit. If limited, recompute the delta using the limit.
- Change the manipulated variable value to the new value computed. If not accessible, change status to "On-err .. ." and do no further actions.
- Load usex array values for use by the user routine.
- If delta manip is not zero, update the past action values and times.
3S - Call the user routine.

75~9 ~ata passed to the user routine The feedforward block passes information about its actions to the user routine through the User vars common block. The use of this data is described in more detail in the chapter covering User routines. In the presently preferred embodiment, the data passed by the feedforward block includes:
User integer(l) - the time stamp of the measured variable;
User integer(2) - the tlme the action was taken;
User real(1) - the change in the value of th~
manip variable;
User real(2) - the change in the value of the measured variable from the last time the "old measured value" was updated:
User_character(1) - = 'Feedforward'.

Sam~le Source Code The source code for the procedure which actually performs ~his function, in the presently preferred embodiment, is as follows.
Table 3 C******************************~****~
C

C FEEDFO~WARD block.FOR
C Subroutine to do feedforward calculations on the Vax, C communicating directly with the target sys~em.
C
C****************************.********
Subroutine Feedforward block ( Block ) Include 'ACS$includes:BlocX_parameters.inc/nolist' 1~37S59 Include 'ACSSincludes:Van funct.ions.inc/nolist' Include 'ACS~includes:User varsOinc/nolist' Include 'ACSSincludes:ACSstatus.inc/nolist' Include 'ACSSincludes:ACSserv.inc' Include 'AcsSincludes:TIserv.inc' Include '~csSincludes:TIstatus.lnc' Include 'ACS$includes:Manip Params.inc' Include 'ACS~includes:Meas params.inc' C

Integer~2 Manip var type Integer*2 Manip var num Integer*2 Meas_var type Integer*2 Meas_var num Integer*4 BlocX
Real*4 Measured value Real*4 Current manipulated_value Real*4 New manipulated value Integer~4 Integer Now Character*20 Character now Integer*4 Measured time stamp C

Van status = VssS from ascii_time ( ' ' , Integer now ) Van status = Vss$ to ascii_time( Integer now , Character_now ) C
C...Get the measured value C

ACS status = ACS get_meas var type ( Block , Meas var_type ) ACS status = ACS get meas var num ( Block , Meas var_num Measured time_stamp - O
C

C...Measured Value is TPA PCS loop goal C

If ( Meas var_type .eq. PCS TPA Loop goal ) Then ACS status = ACS qet pcs goal( 'TPA
1 Meas var num , Measured value ) If ( ACS Status .ne. %loc(ACS success) ) Then C....... ......I~ PCS goal value not available, don't execute Block status(Block) = 'On-Err-PCS goal get' Write( 6, *) 'Feedback exit due to measured var not availa writet6,*)' ACS Block: ',block,' at: ',Character_now Return End If C

C...Measured Value is DMT PCS loop goal C

Else If ( Meas var type .eq. PCS DMT loop goal 3 Then ACS status = ACS get pcs goal( 'DMT ' , 1 Meas var num , Measured value ) If ( ACS Status .ne. %loc(ACS success) ) Then C....... ......If PCS goal value not available, don't execute Block status(Block) = 'On-Err-PCS goal get' Write( 6, *) 'Feedback exit due to measured va- ilOt ~vaila 1~755~
write(6,~ CS 310ck: ',blocX,' at: ',Character now Return End I f C

C... Measured Value is ACS block goal Else If ~ Meas_var type .eq~ ACS block_goal ~ Then ACS status = ACS get_goal ( 1 Meas var num , Measured value ) If ( ACS Status .ne. %loc(ACS success) ) Then C... ..........If ACS goal Value not available, don't execute 810ck status(Block) = 'On-Err-ACS goal get' Write( 6, *) 'Feedback exit due to measured var not avai write(6,~)' ACS Block~ lock,' at: ',Character now Return End If C

C...Measured Value is Vantage variable C

Else If ( Meas var type .eq. cur val Van_var ) Then Van Status -- Vss$g_current( Meas var num , 1 Measured value ) If ( Van Status ~ne. %loc(vss normal) ) Then C....... ....If Variable Value not available, don't execute Block status(810ck) = 'On-Failed Msrd var ' Write( 6, *) 'Feedback exit due to measured var not availa write(6,*)' ACS Block: ',block,' at: I,Character now Return End If Van status - VssSg curtime ( Meas var num , 1 Measured time stamp ) C

End If C.... Check the Measured variable to see if it is within limits If ( (Measured value .lt. Measured min(block) ) .or.
1 ~Measured value .gt. Measured max(block) ) ) Then C.... .Reject the data point Return End if C

C...Test to see if the change in the measured value is less th deadband C
Delta meas = Measured value - Old measured value(Block) If ( Abs( Delta meas ) .lt.
1 Absolute deadband(Block) ) Then Return End I f C

~2~37S59 C...Special action for 'On-deselecte~' status - update old meas valu exit.
C

Old measured_value(Block~ - Measured value If ( Block status(Block)(1:13) .eq. 'On-deselected' ) Then Return End If C

C...Value is within l imits - Compute Feedforward Response C

Delta ~anip = Delta meas * Proportional gain(Block) C

C...Test Delta manip to see if too sreat C

If ( Abs(Delta manip) .gt. Max manip_delta(Block) ) Then Delta manip = Sign(Max manip delta(Block),Delta manip) End If C

C...Get the current manipulated value C

ACS_status = ACS_get manip var_sys ( Block , Manip var_type ) ACS status = ACS get manip var num ( Block , Manip var num C...Target is TPA PCS loop goal C

If ( Manip var type .eq. PCS TPA_Loop ) Then ACS status - ACS get pcs goal( 'TPA
1 Manlp var num , Current manipulated value , ) If ( ACS Status .ne. %loc(ACS success) ) Then C....... ......If PCS goal value not available, don't execute Block status(Block) = 'On-Err-PCS goal get' Return End If C

C...Target is DMT PCS loop goal C

Else If ( Manip var type .eq. PCS DMT loop ) Then ACS status = ACS get pcs goal( 'DMT ' , 1 Manip var num , Current manipulated value ) If ( ACS Status .ne. %loc(ACS success) ) Then C....... ......If PCS goal value not available, don't execute Block status(Block) = 'On-Err-PCS goal get' Return End I f C

C...Target is ACS block goal C

Else If ( Manip var type .eq. ACS block ) Then ACS_status 8 ACS get goal ( Manip var num , 1 Current manipulated value ) If ( ACS Status .ne. %loc(ACS_success) ) Then C.......... If ACS goal Value not available, donit execute 12~7S~C~

Block status(Block) = 'On-Err-ACS goal get' Return Fnd If C

C...Target is Vantage variable C

Else If ( Manip var_type .eq.
1 Vantage variable ) ~hen Yan Status = Geteuval ( Manip_var_num , 1 Current manipulated value If ( Van Status .ne. %loc(vss successj ) Then C....... ......If Variable Value not available, don't execute Block status(Block) = 'On~Err-Vant var get ' Return End If C

C...Target is Texa~ InstrumPnts P~550 controller setpoint in ~D
C

Else If ( ( Manip var type .ge. Low PM550 ) .and.
1 ( Manip_var type .le. Hi_PM550 ) ) Then If ( Manip var type .eq. CRD ESCHS PM550_01 ) Then ACS status s TI get loop setpoint ( 'TI PM550 01 PORT' , 1 Manip var num , Current manipulated value ) Else If ( Manip var_type .eq. C~D ESCHS PM550 02 ) Then ACS status = TI get loop setpolnt ( 'TI PM550 02 PORT' , 1 Manip var num , Current manipulated value ) Else If ( Manip var type .eq. CRD ESC~S PMS50 03 ) Then ACS status - TI get loop setpolnt ( 'TI PM550 03 PORT' , 1 Manlp var num , Current manipulated value ) Else If ( Manip var type .eq. CRD ESCHS PM55Q 04 ) Then ACS status = TI get loop setpoint ( 'TI PM550 0~ PORT' , 1 Manip var num , Current manipulated value ) Else If ( Manip_var type .eq. CRD ESCHS PM550 05 ) Then ACS status = TI get loop setpoint ( 'TI PM550 05 PORTI , 1 Manlp var num , Current manipulated value ) Else If ( Manip var type .eq. CRD ESCHS PM550 06) Then ACS status = TI get loop setpoint ( ITI PM550 06 PORT' , 1 Manip var num , Current manipulated value ) Else If ( Manip var type .eq. CRD ESCHS PM550 07) Then ACS status = TI get loop setpoint ( 'TI PM550 07 PORT' , 1 Manip var num , Current manipulated_value ) End If If ( ACS Status .ne. %loc(TI success) ) Then C......... ....If PM550 setpoint value not available, don't execute Block status(Block) = IOn-Err-TI setpnt get Write( 6, *) 1 I Feedforward exit - TI PM550 Manip var not accessible Write (6, *) ' ACS Block: ',block,' at: ',now time Return End If Else ! Other Manip devicP type '755~
E~d I
C...Calculate new manipulated value, check ~o see it within limits C

New_manipulated value = Current_Manipulated value + Delta_mani C

If ( New manipulated value .gt. Manipulated_max(Block) ) ~hen New_manipulated value = Manipulated_max(Block) Else If ( New manipulated_value .lt. Manipulated_min(Block) ) New_manipulated value - Manipulated_min~Block) Fnd If Delta manip = New_manipula~ed value - Current Manipula ed_valu C... Transmit the New Manipulated Value to the manipulated variable C

C...Target is TPA PCS loop goal C

If t Manip var_type .eq. PCS_TPA Loop ) Then ACS_status = ACS ~ut_pcs_goal( 'TPA ' , 1 Manip var_num , New_manipulated value ) If ( ACS Status .ne. ~loc(ACS_success) ) Then C....... ......If PCS goal value not available, don't execute Block status(Block) = 'On-Err-PCS goal put' Write( 6, *~ 'Feedback exit due to failed manip var put.
Write(6,*)' ACS Block: ',block,' at: ',now_time Return End If C .
C...Target is DMT PCS loop goal C

Else If ( Manip var type .eq. PCS_DMT_loop ) Then ACS status ; ACS put_pcs_goal( 'DMT ' , 1 Manip var num , New manipulated value ~
If 1 ACS_Status .ne. %loc(ACS success) ) Then C....... ......If PCS goal value not available, don't execute Block_status(Block) = 'On-Err-PCS goal put' Write( 6) *) 'Feedback exit due to failed manip var put.
Write(6,*)' ACS Blocko ',block,' at: ',now_time Return End If C

C...Target is ACS block goal C

Else If ( Manip_var_type .eq. ACS block ) Then ACS_status = ACS put goal ( Manip var_num , 1 New_manipulated_value ) If ( ACS_Status .ne. %loc(ACS_success) ) Then C....... ......If ACS goal Value not available, don't execute Block_status(810ck) = 'On-Err-ACS goal put' Write( 6, ~) 'Feedback exit due to failed manip var put.

7~5~
Writ~(6,~)' ACS Block: ',block,' at: ',now time Return End I~
C

C...Target is Vantage variable C

Else If ( Manip var type .eq.
1 Vantage variable ) Then Van status = Puteugen ( Manip var num , 1 New_manlDulated value ) If ~ Van Status .ne. ~loc(vss success) ) Then C.O~....... ~ If Variable Value not avaiIable, don't execute Block status(Block) = 'On-Err-Vant var put ' Write( 6, *~ 'Feedback exit due to failed manip var put.
Write(6,*)' ACS Block: ',bloc~,' at: ',now time ~eturn End If C...Target is Texas Instruments PM550 controller setpoint in CRD
C

Else If ( ( Manip var type .ge. Low PM550 ) .and.
1 ( Manip var type .le. Hi PM550 ) ) Then If ( Manip var type .eq. CRD ESCHS PM550 01 ) Then ACS_status - TI ~ut loop setpoint ( 'TI PM550 01 PORT' , 1 Manip var num , New manipulated value ) Else If ( Manip var type .eq. CRD ESCHS PM550 02 ) Then ACS status = TI put loop setpoint ( 'TI PM550 02 PORT' , 1 Manip var num , New manipulated value ) Else If 7 Manip var type .eq. CRD ESCHS PM550 03 ) Then ACS status = TI PUt loop setpoint ( 'TI PM550 0~ PORT' , 1 Manip var num , New manipulated value ) Else If ( Manip var type .eq. CRD ESCHS PM550 04 ) Then ACS status = TI put loop setpolnt ( 'TI PM550 04 PORT' , 1 Manip var num , New manipulated value ) Else If ~ Manip var type .eq. CRD ESCHS PM550 05 ) Then ACS status = TI put loop setpoint ( 'TI PM550 05 PORT' , 1 Manlp var num , New manipulated value ) Else If ( Manip var type .eq. CRD ESCHS PM550 06) Then ACS status = TI put loop setpoint ( 'TI PM550 06 PORT' , 1 Manip var num , New manipulated value ) Else If ( Manip var type .eq. CRD ESCHS PM550 07) Then ACS status = TI put loop setpoint ( 'TI PM550 07 PORT' , 1 ~anip var num , New manipulated value End If If ( ACS Status .ne. %loc(TI success) ) Then C......... ....If PM559 setpoint value not available, don't execute Block status(Block) = 'On-Err-TI setpnt put' Write( 6, *) 1 ' Feedforward exit - TI PM550 Manip var not puttable.' Write (6, ~) ' ACS Block: ',block,' at: ',now time Return 55g End IP
Else 1 Other Manip dsvice type End I~
C
C......... .Load ~peci~l ~rray~ ~or user pxogr~s to log mess~ges.
User integer(1) = Measured time stamp User integer(2) 3 Integer now User real(l) = Delta manip User real(2) = Delta ~eas User charactert1) - '~eedforward C......... If Delta is non-zero, update past actions If ( Delt~ manip .ne. 0 ) Then Past action value(Block,J) ~ Past action value~Block,J-l) Past action time (Block,J) = Past action time ~Block,J-1) - Past action value~Block,l) z Delta manip Past action time (Block,1) = Int~ger now End If . ......... .Call User subprograms for this block Call User Programs(810ck) Return End Copyright (c) 1987 E.I. DuPont de Nemours & Co.
all rights reserved ~7~59 atistical Filterina Blo~s Figure 12 shows a sample of a template B12 presen-ted to the u~er by the build-supervisor procedure to define a statistical filtering block. In ~he spsoifiG
example shown, the block ~eing worked on is block number one of the 200 available blocks 851, 852, etc., and the various data values shown in this Figure reflect ~he entries which have been made at some time to define this particular block.
The Shewhart block provides statistioal filtering of a sampled measurement using Shewhart tests. The user specifies an aim value (field 1222 in Figure 12) and a standard deviatisn (sigma) (field 1224 in Figure 123 which characterizes the normal variability in the ~easurement. The Shewhart tests a series of rules to determine whethex the sequenoe of measurements are statistically the ~ame as ("on aimn) or different from ("off aimn) tbe normal variability with the average at the aim. After each test, the Shewhart block 6tores in the process database an estimate of the deviation from aim and a value ind~cating what rule was broken.
In the presently preferred e~bodiment, Shewhart blocks do not allow timing options to be specified. They perform their tests only when a new ~easurement is entered into the database for the filtered variable. In the presently preferred e~bodiment, the conditions tested for by the Shewhart block are:
Was the last point more than 3 sigma different from aim?
Were two of the last three points more than 2 sigma different from aim in the same direction?
Were four of the last five point~ morc t~an 1 ~igma different from ~im in the s~me direction?
- Were the last seve~ points ~11 o~f ~i~ on the sa~e ~ide of ~i~?

375'~9 The rules are tested in the order shown. For the second and third rules, thP test is first applied to the last two (or four) points in a row, then to the last three (or five) points. If any rule is violated, the process is off aim, and a deviation from aim is calculated by averaging the points which broke the rule. For example, if the last four points were outside the 1 sigma limit, the average of the four is taken as the deviation. If four of the last five points were outside the 1 sigma limits, the average of the last five points is taken.
The basic Shewhart action can be altered by several additional parameters. A fix time interval can be specified (in field 1226), so that, if one of the Shewhart tests shows a rule violation, Shewhart tests will be suspended for this interval after the time of the sample that violated the rule. This is useful in process control to allow control action in response to a rule violation to have time to move the process back to a statistically "on aim" position before taking any further actions. The range of calculated deviations can be limited, as specified by the data entered into fields 1228 and 1230. Screening limits can be applied to the filtered variable, so that measurements falling outside the range defined in fields 1232 and 1234 are ignored.
The Shewhart block differs from the feedback and feedforward blocks in that it requires resources outside of the supervisor procedure. It uses two process database variables to store its computed deviation from aim and its rule value. To configure a Shewhart block, in this sample embodiment, the user must get database variables allocated and properly configured. Since this is usually a database system manger's function, the details are not covered here.
Specifying a "Shewhart" (i.e. statistical filtering) block on the block setup selection form ~2~?7559 (Figure 9) brings up the Shewhart block setup form shown in Figure 12.

Parameters The parameters shown on this form include:
Filtered variable type: a number code representing the software system and the type of entity which the block should use for the filtered variable.
Filtered variable number: the nu~ber of the entity within ths specified system which the block will la use for the filtered variable. For example, if the filtered variable type is a historical database variable, the filtered variable number is the number of the variable in the historical database. After the filtered variable type is entered, the label next to this field will show what type of data is needed. When the filtered variable number is entered, other fields will also be filled in: the name and units for the filtered variable, aim, and sigma; units and default values for the max and min filtered values. Since ~a Shewhart block timing always keys off entry of new data into the filtered variable, only discretely sampled variable types can be used.
Deviation variable type: a number code representing the software system and the type of entity into which the block should store the computed value of deviat_on from aim.
Deviation variable number: the number of the entity within the specified system into the block will store the computed deviation from aim. For example, if ~a the deviation variable type is a historical database variable, the deviation variable number is the number of the variable in the historical database. After th~
deviation variable type is entered, the label next to this field will show what type of data is needed. When ~975~
the deviation variable number is entered, other information will be automatically filled in by the build-supervisor procedure; in the example of Figure 12, region 1236 indicates the pre-stored de~ignation of historical database variable 2084. Such automatically completed inormation will preferably include the name and units for the deviation variable; units and default values for the max and min deviation values. Since Shewhart blocks execute on entry of new data into the filtered variable, only discretely stored deviation variable types can be used.
Rule variable type: a number code representing the software system and the type of entity into which the block should store a number code indicating which rule was broken.
Rule variable number: the number of the entity within the specified system into the block will store a number code indicating which rule was broken. For example, if the rule variable type is a historical database variable, the rule variable number is the number of the variable in the historical database.
After the rule variable type is entered, the label next to this field will show what type of data is needed.
When the rule variable number is entered, the name and units for the rule variable will also be filled in.
Since Shewhart blocks execute on entry of new data into the filtered variable, only discretely stored rule variable types can be used.
Aim: the "on aimU value of the filtered variable.
Sigma: the standard deviation of the value of the filtered variable when the measurement is "on aim".
Fix time: A time interval after rule violations during which no rule tests are done. New measurements entered during the fix time interval ~re 12~7~i59 ignored. The fix time is entered as a delta time character string: "ddd hh:mm: ss" where "ddd" is the number of days, "hh" is the number of hours, "mm" is the number of minutes, and "ss" is the number of seconds.
The fix time is taken fro~ the timestamp of the ~iltered variable value which caused the deviation to be identified. The timestamp of later samples is compared against this, and if the difference is less than the fix time interval the sample is ignored.
Switch system and switch number: th~se are described above.
Min.mum and maximum value of the calculated deviation: limits on the allowed value of the calculated deviation from aim. Deviations outside this range are set equal to the closest limit.
- Minimum and maximum value of filtered variable: Screening limits for reasonable values of the filtered variable. Any time the filtered variable value falls outside these limits, the value will be ignored and no action is taken.
Action log file: this field is described above.

Bloc~ O~eration In the presently preferred embodiment, the sequence of actions performed by the Shewhart block is:
- If the block status is "On-deselected", do no further calculations.
- Retrieve the last 7 values of the filtered variable. If not available, do no further calculations.
- Check the last value of the filtered variable. If it is outside the allowed limits, do no further calculations.
- Search backward through the stored values of the deviation variable for the most recent non-zero 755~
value. If a non-zQro value is found wi~hin one fix ~ime interval before the present instant, do no ~urther calculations.
- Compute the cutoff time = time of last non-zero deviation plus the ~ix time.
- Initialize the deviation and rule values (to zero).
- Begin testing Shewhart rules:
~ I~ the last point is older than t]le cutoff time, do no further calculations.
* If the last point is outside the 3 sigma limits ( .e. A~s(point-aim) is greater than 3 sigma), then:
Deviation = Last point - aim Rule = 1 Skip remaining rules.
* If the second newest point is older than the cutoff timel Skip remaining rules.
* If the last 2 points are both either greater than aim + 2 sigma or less than aim - 2 sigma, then:
Deviation = Sum(last 2 points )/2 - Aim Rule = 3 Skip remaining rules.
* If 2 out of the last 3 points are both either greater than aim + 2 sigma or less than aim - 2 sigma, then:
Deviation = Sum(last 3 points)/3 - Aim Rule = 3 Skip remaining rules.
* If the last 4 points are all either greater than aim + sigma or less than aim - sigma, then:
Deviation = Sum(last 4 points)/4 - Aim Rule = 5 Skip remaining rules.

* If 4 of the last 5 points are all either greater than aim + sigma or less than aim -sigma, then:
~eviation - Sum(last 5 points)/5 ~ ~im Rule = 5 Skip remaininq rules.
~ If all of the last 7 points are greater than aim or all less than aim, then:
Deviation = Sum(last 7 point)/7 - Aim Rule = 7 SXip remaining rules.
- Check and store result:
* If the deviation is outside the allowable limits, set equal to the closest limit.
* Store the devia ion value and rule value in the respective variables. These values are time stamped the same as the last filtered value.
- If the deviation is non-zero, update past actions.
- Call the user routine.
Of course, other statistical filtering methods could be used instead. It is generally realized that statistical filterin~ is highly advantageous, and that numerous algorithms can be used to accomplish statisti-cal filtering.The Shewhart algorithm used in the presently preferred embodiment could be replaced by any of a wide variety of other known algorithms.

Sample Source Code The source code for the procedure which actually performs this function, in the presently preferred embodiment, is as follows.

37~59 Table 4 C
C Shewhart block.for C****~*****~********************~
Subroutine Shewhart block ( Block) Include 'ACS$includes:Block_parameters.inc/nolist' Include 'ac~$includes:ACSserv.inc/nolist' Inçlude 'acs$includes:AC5status.inc/nolist' Include 7ACS$includes:Van functions.inc/nolist' Include 'ACSSincludes:Filter params.inc/nolist' Include 'ACSSincludes:dev_params.inc/nolist' Include 'ACSSincludes:rule params.inc/nolist' Include 'ACS$includes:User vars.inc' Integer*4 Block Integer Error lun Parameter ( Error lun = 6 ) Character*20 Store time Character~20 now tlme C

Integer*2 Filtered variable Integer*2 Deviation variable Integer~2 Rule variable Integer*2 Filtered variable type Integer*2 Deviation variable type Integer*2 Rule variable type Integer*4 I4 deviation variable Integer*4 I4 rule variable Real*4 Aim Real*4 Sigma Integer*4 Integer fix time Integer*4 Cutoff time Integer*4 Safe time Real*4 Deviation Real*4 Rule Real*4 Last filtered value Logical All same sign Logical Need violation C

Integer*4 Num oints Parameter (Num points = 7) Real*4 Point(Num~points) Integer*4 Times(Num_points) Character*18 Char times(Num Points) Integer*4 Num Pointsl Parameter (Num pointsl = 8) Real~4 Pointl(Num ~ointsl) Inteqer*4 Timesl(Num_pointsl) Character*18 Char timesl(Num_pointsl) Real*4 Violation value(l) Integer*4 Violation time(l) Integer*4 Newest time Integer~4 Oldest time Integer*4 Buffer size Logical*l First request Integer*4 Block location Integer*4 Entry count Integer~4 Begin span status Byte Interp flags Integer*4 Beyin span time Integer*4 End span time Integer*4 Num DointS retrieved Integer~4 Integer Now Integer*2 Start point C

C....Special case for 'On-deselected' status C

If ( Block status(Block)(1:13) .eq. 'On-deselected' ) Then Return End If C

C..Set the value of the local variables C

ACS status = ACS_get_filtered var type(Block,filtered_variable Filtered_variable = Measured variable(Block) ACS_status = ACS get dev var type ( Block , deviation variabl ) Deviation_variable = Manipulated_variable(Block) ACS status = ACS get rule var type ( Block , rule variable typ Rule variable - New manipulated variable(Block) Aim - Goal(Bloc~) Sigma = Absolute deadband(Block) Integer fix time = Fix time(Block) C

Van status = Vss$ from ascii_time ( ' ' , Integer now ) Van status = VssS to ascii time ( Integer now , now_time ) d Van status = Vss~ to ascii time ( Integer now , Store_time ) d write(6,202) ' Calling Shewhart on var ',filtered_variable,' a d 1 Store time d 202 ~ormat(//,a,' ',i5,' ',a,' ',a) C...Retrieve enough points to test all the rules C

If ( Filtered variable type .eq. Van_var_filter ) Then C
Newest_time = Integer now Oldest time = Newest time - 365*24*60~60 1~7~S~

Buffer size = Num ~oints First_request = .True~
Num points retrieved 8 0 Start ~oint - 1 C

Do 777 ~ 2 l,Num Points Times(j) = o 777 Point(j) 2 0.0 C

Van status = Sloc(vss systemdown) Do While ( (Van status .eq. ~loc(vss_systemdown)) .or.
1 (Van_status .eq~ ~loc(vss unavaildata)) ) c Van_status = Vss~ Retrieve ( Filtered variable , Newest_tim 1 Oldest time , ~uffer size , Ti~es(start_point) , 1 Point(Start_point) , 1 First request , Block location , Entry count , 1 Begin span status , Interp_flags , Begln_span_tlme , 1 End_span time ) Num Points retrieved = Num points retrieved + Entry_count If ( Num points retrieved .lt. Num_points ) then ~uffer size = Buffer size - Num points retrieved Start point ~ Start Point + Entry count End If d write(6,*) 'Finished data retr.' c End Ds c d do 11 J =l,Num_points d 11 Van status = Vss$ to ascii time ~ Times(j) , Char times(j)) d write(6,12) (Char_times(j),Point(j),~=l,num Points) d 12 Format( /,' ~ere are the times and points:',//
d 1 (' ',al8,' ',fl2.4 , / ) d write(6,*) ' Got ',Num_points retrieved,' points.' If ( Num points retrieved .lt. Num points ) then Write(Error lun,*) 1 'Shewhart Failed to get enough data on Variable ', 1 Filtered variable write(error lun,*)'from ACS block:',block,' at:',now time Write~Error lun,*) 'Wanted ',Num points,'; Got ', 1 Num Points retrieved Return End If d write(6,*) 'Got enough points.' C
C.... Check the ~easured varia~le to see if it is within limits C

Last filtered value = Point(1) If ~ (Last filtered value .lt. Measured min(block) ) .or.
1 (L2st filtered value .gt. Measured max(block) ) ) T
C..... Re~ect the data point 1~9 S5'~

Write( 6, ~) 'Shewhart exit due to sut of limts filter d.' write(6,*)' ACS Block: ',block,' at: ',now tim Return End if Else i~ t Filtered variable_type .eq. Van_run 2 filter ) Then Newest time = Integer now Oldest_time = Newest time - 365*24*60*60 Buffer size = Num Polnt First request a . True.
Num Points retrieved = O
Start Point = 1 C

Do 1777 j = l,Num Pointsl Timesl(j) = 0 1777 Pointl(j) = 0.0 C

Van_status = ~loc(vss_systemdown) Do While ( (Van_status .eq. %loc(vss_systemdown)) .or.
l (Van_status .eq. %loc(vss_unavaildata)) ) Van_status = Vss~ Retrieve ( Filtered variable , Newest_tim l Oldest time , Buffer size , Timesl(start point) , 1 Pointl(Start point) , 1 First request , Block location , Entry count , 1 Begin span_status , Interp flags , Begin span_time , 1 End span time ) Num ~oints_retrieved = Num points retrieved + Entry count If ( Num points retrieved .lt. Num pointsl ) then Buffer size = ~uffer size - Num Points retrieved Start point = Start point + Entry_count End If d write(6,*) 'Finished data retr.' c End Do d do 111 J =l,Num_pointsl d lll Van status = Vss$ to ascii time ( Timesl(j) , Char timesl(j)) d write(6,112) (Char timesl(~),Pointl(j),j=l,num_pointsl) d 112 Format( /,' Here are the times and points:',//
d 1 (' ',al8,' ',fl2.4 , / ) d write(6,*) ' Got ',Num points retrieved,' points.' If ( Num points retrieved .lt. Num_pointsl ) then Write(Error lun,*) l 'Shewhart Failed to get enough data on Variable ', 1 Filtered variable write(error lun,~)'from ACS block:',block,' at:',now time Write(Error lun,*) 'Wanted ',Num ~ointsl,'; Got ', l Num points retrieved Return End If d write(6,*) 'Got enough points.' 1~375~
c C
C.... Check the Measured variable to se~ if it is within limits Last ~iltered_value = (Pointl(l)+Pointl(2))~2.
If ( (Last filtered value .lt. Measured min(block3 ) .or.
1 (Last filtered v lue .gt. Measured max(block) ~ ~ T
C.... .Reject the data point Write( 6, *) 'Shewhart exit due to out of limts filtered.' write(6,*)' ACS Block: ',block,' at: ',now time Return End if C

Do j = 1,num_points ! running avera~e point(j) = (pointl(j)+pointl(j+l))/2 times(j) 3 timesl(j) end do Else ! Improper filtered type Write( 6, ~) 'Shewhart exit due to invalid filtered var :ype.' write(6,*)' ACS Block: ',block,' at: ',now time Return End If ! Filtered types C
C....Check to see if the last violation was within the Fix time -C If so, do no calculations.
C...Retrieve the last stored nonzero deviation from aim C

If ( Deviation vari~ble type .eq. Van var dev ) Then C

Newest time a Integer now Oldest time = Newest time - 365*24*60*60 Buffer size = 1 First request = .True.
Need violation = .True.
Do While ( Need violation ) Van status = Vss'~ Retrieve ( Deviation variable , Newest_ti 1 Oldest time , Buffer_size , Violation time , 1 Violation value , 1 First request , Block location , Entry_count , 1 Begin span status , Interp flags , 8egin span time , 1 End span time ) c If ( ( Van status .ne. ~loc(vss systemdown) ) .and.
1 ( Van status .ne. %loc(vss unavaildata)) .and.
1 ( Van status .ne. %loc(vss notallfound)) ) Then Write(6,*)' Shewhart Violation retr - status vss badva write(6,*)' ACS Block: ',block,l at: ',now tlme ~75.5~

Else If ( Van status . eq. %loc (Vss_badtime) ) then Write(6,*) ' Sh~whar'c Violation retr - status VS5 badti write(6,*) ' ~CS Block: ',block, ' at: ',now_time Else If ( Van status .eq. %loc(Vss badtimespan) ) then Write ( 6, * ) ' Shewhart Violation retr - s vss badtimespan ' write(6,*) ' AC5 Block: ' ,block, ' at: ' ,now_time Else Iî ( Van_status . eq. %loc (Vss badbufsize) ) then Write(6,*) ' Shewhart Violation retx - status vss badbu write(6,*) ' ACS Block: ',block, ' at: ',now time Else If ( Van status . eq. 9sloc (Vss normal) ) then Write(6,*) ' Shewhart Violation retr - status vss nor;na write(6, *) ' ACS Block: ' ,block, ' at: ' ,now time c Else If ( Van status . eq. %loc (Vss nonefound) ) then Write(6,~) ' Shewhart Violation retr - status vss nonef write(6,*) ' ACS Block: ',block, ' at: ',now time Else If ( Van status . eq. %loc (Vss nomoreonline) ) then Write ( 6, *) ' Shewhart Violation retr - s vss nomoreonline ' write(6, *) ' ACS Block: ' ,block, ' at: ' ,now time c End I f WRite ( 6, * ) ' Van status = ', Van status Van status = VssS to ascii time ( Violation time(1), Stor Write ( Error lun, * ) 'Shewhart-couldn' 't get a non zero deviation - exiting' write(6,*) ' ACS Block: ' ,block, ' at: ' ,now time Write (Error lun, * ) ' Oldest vlolation got: ' ,Violation value(l), ' at ' ,Store_ Return End I f If ( ( Abs(Violation value(1) ) .gt. 1.0 E-10 ) .or.
Violation time ( 1 ) . lt .
(Times(7) - Abs( Integer fix time ) ) ) ) Then Need violation = . False .
End I f c End Do Else ! Improper deviation var type Write( 6, *) 'Shewhart exit due to invalid deviation var type write(6, *) ' ACS Block: ' ,block, ' at: ' ,now time Return End If ! Get last deviation for allowed deviation types c ~L2~375~

d Van_status = Vss$_to_ascii_time ( Violation time(l) , Store_ti d write(6,*) ' Got a vlolation of ',Violation value(1),' at ', d 1 Store tlme C

C.... ~o throngh the shewhart Rules - any point older than the last vio C time + the fix time is not acceptable.
Cutoff time = Violation_time(1) + Abs(Integer fix time) d Van_status = VssS to_ascii time ( Cutoff time , Store time ) d write(6,*~ ' Cutoff time is ', Store_tlme Deviation = 0.0 Rule = 0.0 C

If ( Times(1) .lt. Cutoff time ) Return d write(error lun,*) 'Testing 1 out of 1 rule.' If ( Abs(Point(1)-Aim) .gt. 3*Sigma ) Then Deviation = Point(1) - Aim Rule = 1.0 Go To 1000 End if - C
C.... Test 2 in a row outside 2 sigma C

If ( Times(2) .lt. Cutoff time ) Go To 1000 d write(error lun,*) 'Testing 2 out of 2 rule.' Sum points = 0.0 Num out high = O
Num_out low = O
Do 2 J = l,2 Sum Doints = Sum ~oints + Point(J) If ( (Point(J)-Aim) .gt. 2*Sigma ) Then Num_out high = Num out high +1 Else If ( (Point(J)-Aim) .lt. -2*Sigma ) Then Num_out_low = Num out_low + 1 End If 2 Continue If ( ( Num_out high .eq. 2 ) .or.
l ( Num out low .eq. 2 ) ) Then Deviation = Sum_points/2 - Aim Rule = 3.0 Go To 1000 End If C

C... Test 2 out of 3 outside of 2 sigma If ( Times(3) .lt. Cutoff time ) Go To 1000 d write(error_lun,*) 'Testing 2 out of 3 rule.' Sum points = Sum Points + Point(3) If ( (Point(3)-Aim) .gt. 2*Sigma ) Then 1~3 1~755~3 Num out high ~ Num out high +l Else If ( (Point(3)-Aim) .lt. -2*Sigma ) Then N~m out low = Num out low t End If If ( ( Num out high .eq. 2 ) .or.
1 ( Num out low .eq. 2 ) ) Then Deviation = Sum ~oints/3 - Aim Rule = 3.0 Go To 1000 End If C

C...Test 4 in a row outside 1 sigma C

If ( Times(4) .lt. Cutoff time ) Go To 1000 d write(error lun,*) 'Testing 4 out of 4 rule~
Sum Points - O. O
Num out high = O
Num out low = O
Do 3 J - 1,4 Sum Doints = Sum points + Point(J) If ( (Point(J)-Aim) .gt. l*Sigma ) Then Num out high = Num out high +l Else If ( (Point(J)-Alm) .lt. -l*Sigma ) Then Num out_low z Num out low + 1 End If 3 Continue If ( ( Num out high .eq. 4 ) .or.
1 ( Num out low .eq. 4 ) ) Then Deviation = Sum points/4 - Aim Rule = 5.0 Go To 1000 End If C

C...Test 4 out of 5 outside 1 sigma C

If ( Times(5) .lt. Cutoff time ) Go To 1000 d write(error lun,*) 'Testing 4 out of 5 rule.' Sum Points = sum ~oints + Point(5) If ( (Point(5)~Aim) .gt. l*Sigma ) Then Num out high s Num out high +l Else If ( (~oint(5)-Alm) .lt. -l*Sigma ) Then Num out low - Num out low + 1 End If If ( ( Num out high .e~. 4 ) .or.
1 ~ Num out low .eq. 4 ) ) Then Deviation = Sum Points/5 - Aim Rule = 5.0 Go To 1000 End If C Test 7 in a row - same side of aim C

75~5~3 If ( ~imes(7) ~lt. Cutoff time ) 50 To 1000 d write(error lun,~) 'Testing 7 in a row rule.' Sum ~oints = O.O
5ign deviation = Siqn( 1.0,(Aim-Point(1)) ) If ( (Aim-Point(l)) .ne. O) Then All same sign = .True.
else All same sign = .False.
End if Do 4 J = 1,7 If ( (Aim-Point(J)) .eq. 0) Then All_same sign = .False.
Else If ( Slgn( 1.0,(Aim-Point(J)) ) .ne. Sign_deviation ) All_same sign = .False.
End if 4 Sum points = Sum points + ~oint(J) If ( All same sign ) then Deviation = Sum_points/7 - Aim Rule = 7.0 Go To 1000 End If C

- lOOO Continue d write(6,*) 'Got deviation, rule of ',deviation,rule C...Clamp the deviation at allowed limits C

If ( Deviation .gt. Manipulated max(Block) ) Then Deviation = Manipulated max(Block) Else If ( Deviation .lt. Manipulated min(Block) ) Then D~viation = Manipulated_min(Block) End If C...Store the Computed Deviation and Rule number with Timestamp d Van status = Vss$ to ascii time ( Times(l) , Store time ) d write(6,*) 'putting var ',i4 deviation_variable,' at ',store t d 1' with value ',deviation If ( Deviation_variable type .eq. Van_var_dev ) Then I4_deviation_variable = Deviation_variable Dmt_status - DmtS_putlab ( I4_deviation variable , Times(l) , 1 Deviation , 2 , .False. ) Else I Other deviation types End If ! Deviation types c d write(6,*3 ' Did putlabs -first status = ',dmt status d write(6,*) 'putting var ',i4_rule_variable,' at ',store_time, d 1' with value ',rule If ( Rule_variable_type . 2q. Van_var_rule ) Then 75~
I4 rule variable ~ rule variabl~
Dmt status ~ Dmt$~putlab ( I4 rule variable , Times(l) , 1 Rule , 2 , .False. 3 Else ! Other rule types End If ! Rule types c ~tatus - vss$_mehclose() !close file just in ca d write(6,*) ' Did putlabs -second 5tatu5 S ~ ~dmt status d write(6,*) ' Did putlabs -exiting' C...... If Deviation i5 non-zero, update past actions If ( Deviation .ne. o ) Then Do 90 J = 5,2,-1 Past action value~Block,J) = Past action_value~lock,J-1) Past action time (Block,J) = Past action time (Block,J-l~
Past action value(Block,l) = Deviation Past action time (Block,1) = Times(l) End If C

C...Load user arrays for user programs User integer(l) = Integer now ! Time of Tests User integer(2) = Rule User real(l) ~ Deviation Do J - 1 , ~ax ( Num Points , 18 ) User integer(2+J) ~ Times(J) ! Time of samples used in test User real (2+J) - Point(J) ! Value of samples used in tes End Do If ( Rule .e~. 0.0 ) Then User character(1) - 'On aim, No rules broken ' User charactert2) ~ 'On aim, No rules ~roken.' Else If ( Rule .eq. 1.0 ) Then User character(l) ~ 'Shewhart 1 out of 1 rule' User ch~racter(2) ~ 'Shoe heart 1 out of 1 rule' Else If ( Rule .eq. 3.0 ) Then Vser character(l) ~ 'Shewhart 2 out of 3 rule' User character(2) - 'Shoe heart 2 out of 3 rule' Else Tf ( Rule .eq. 5.0 ) Then User char~cter(1) - 'Shewhart 4 out of 5 rule' User character(2) G ~ Shoe heart 4 out of 5 rule' Else If ( Rule .eq. 7.0 ) Then User character(l) - 'Shewhart 7 in a row rule' User_ch~racter(2~ - 'Shoe heart 7 in a row rule' End If C...Call ~ser routine C

Call User vrogram~ ( Block ) Return End - Copyright (c ) 1987 E.I. DuPont de Nemours & Co., all rights reserved 7S~9 ~ e~ined Proaram ~Lock Figure 13 shows the for~ wh.ich (in the presently preferred embodiment) is presented to a user who has chosen the "User program" option from the menu shown in Figure 9.
The user program block provides a means of controlling the execution of a user written FORTRAN
subroutine. Thç block itself performs no control actions, but allows the user to specify a timing option and switch parameters for executing the block's user routine. A user routine exists for every block in the supervisor procedure. (In the example shown in Figure 13, where the block shown is block number 2, the block will (selectively) make calls to BL3CK2 USER ROUTINE.) Initially these routines (BLOCXl USER ROUTINE, 3LOCK2_USER ROUTINE, BLOC~3 USER_ROUTINE, etc.) do nothinq (i.e., their default content is merely the FORT~AN statements Return and ~nd), but they can be modified by the user. The user program block only sets up parameters for controlling execution of the user program.
The user program timing options include keying off a measured variable. In this case the variable is not used for anything but timing. This option can be altered by specifying screening limits on the measured variable value (using fields 1332 and 1334), so that measured values outside the screening limits are ignorad. Block timing and switching and the block description fields follow the general outlines given above.

Parameters The parameters are:
Measured variable type: a number code representing the software system and the type of entity which the block should use for the measured variable.

~2~3~7559 Measured variable number: the number of ~he en~ity within the specified system which ~he block will use for the measured variable. For example, if the measured variable type is a historical da~abase 5variable, the ~easured variable number is the number of the variable in the historical database. After the measured variable type is entered, the label next to this field will show what type of data is needed. When the measured variable number is entered, other flelds 10will also be filled in: the na~e and units for the measured variable; units and default values for the max and ~in measured values.
Timing option, execution time interval, and Key bloc~ number: these parameters are described above.
15switch system and switch number: these are described above.
Minimum and maximum value of measured variable: These define screening limits for reasonable values of the measured variable. Whenever the measured 20variable value falls outside these limits, the value will be ignored and no action is taken.
Action log file: this field is described above.

Pro~ram Block O~eration 25The sequence of actions performed by a User program block is:
- If block status is "On-deselected", do not execute the user routine.
- If a measured variable is specified:
30* Get the current value of the measured variable (If not accessible, set status to "On-err..."
and do not execute the user routine).
* Test the value of the measured variable. If it outside the range of allowed values, se~

755~

status to "On-msrd out of lims" and do not execute the user routine.
- Execute the user routine. The routine name is derlved from the block nul~er. Block 1 ralls Bl oc k l user routine, bl ocX 199 calls Blockl99 user_routine, etc.
- If a fatal error occurs in the user routine, bypass the rest of the routine, and set the block status to "On-Failed usr routin".
lo - If the block failed on the last execution, but did not fail on this execution, set the block status to "On".
- Clear all the values in the user vars common block.

3uild-User-Proaram Pro~edure The build-supervisor procedure (in the presently preferred embodiment) also provides a structured environment for creating user programs. As will be described below, the build-expert procedure will create the source code for one or more customized expert systems; but the user must still insert a call to this expert code into one of the blocks in the supervisor procedure. The build-user-program procedure facilitates this, and also provides convenient support for sophisticated users who are able to write their own utilities.
In the presently preferred embodiment, this is a structured environment in which users can write FORTRAN
subroutines and incorpor~te them into control blocks.
User programs can be run as the only block function by defining a User Program block (as described above), or they can be used to take additional actions (such as message logging) in combination with feedback or feedforward control blocks.

~ ~7~i59 At a minimum, a user with no programming Xnowledg~
can insert a one-line call into a user program block, to make use of an expert subprocedure created using the build-expert procedure. However, to take full advantage of the capability for user progra~ming, the user should (in the presently preferred embodiment) already be comfortable programming in FORTRAN and using FORTRAN
functions and subroutines, and in using the Vax EDT
editor. The build-user-progra~ environment 1810 in this embodiment is menu driven rather than forms driven, and therefore provides less online help than some of the other functions described.
Writing a basic user program involves 5 steps:
- Selecting which block number's user program to edit;
- Editing the file which contains the user program code for that block. The EDT editor 1812 is used to write and modify the FORTRAN language code;
- Checking the code for errors in FORTRAN
syntax;
Updating the supervisor procedure by incorporating the latest version of the user program into the base cycle procedure and running the new base cycle procedure; and - Monitoring user program execution to assure that the program is executing properly.
In the example shown in Figure 16, the top level build-supervisor menu permits the user to enter the build-user-program environment by pressing keypad 5.
While in the build-user-program environment, the user can edit the block user routine; check the block user routine for errors in FORTRAN syntax; and update the supervisor procedure by incorporating the new version of the block user routine. The first prompt from the user program menu asks what block number's routine the user 1~9755~

wants to wor~ on. Entering the block number and pressing return brings up another program menu, with options which will now be described.
Editing the user routine begi.ns by selecting menu option 1 ("~dit user routine"). This will start the EDT
editor. User routines of some sort already exi~t for all the blocks. Blocks which have never had any special programming have a user routine which does nothing - it consists simply of a RETURN statement followed by an END
statement, and, if the block's user routine has never been worked on, this default routine will be brought up by the editor. To make a functioning routine, the user must add FORTRAN code before the RErJRN statement to perform the desired function. (In the presently preferred embodiment, the user can simply edit the file - like any other FORT~AN source code file on the VAX.) For example, code fsr logging messages or calling an expert subroutine can be inserted at this point.
Once the user has edited the user routine and returned to the menu, he can select option 5 to check for FORTRAN syntax errors. If the new routine has no FORTRAN syntax errors, the screen will show "The user's routine compiled with no errors in synt~x." If the new coding has syntax errors, the user will see them reported on the terminal screen. The user can then correct the errors using Option 1 (edit), and repeat until all errors have been removed.
Once the user has a routine that compiles with no errors, he can include it in the running version of the supervisor procedure by using menu option 8 ("Update").
This will compile the userls routine, relink the base cycle procedure using the user's newly compiled routine, stop the procedure which is currently running, and restart the base cycle procedure using the newly linkPd version containing the user's new routine.

.37~ 5~

After compiling the user's routine, the build-supervisor procedure will ask if there are any other subroutines in separate files that need to be compiled.
Some application may require more than o~e ~ubroutine, and, if desired, they can b0 split up in separat~ files.
To make a routine in a separate! file, the user can select option 2 ("Edit a separate FORTRAN subroutine") to c~eate and modify the file, and then select option 6 ("Chec~ a separate subroutine for FORTR~N errors") to check for FORTRAN errors. To include the separate file into the supervisor procedure, the user can use the update option, then answer "Y:" when asked if any separate routines need to be compiled and included. The base cycle procedure can then be linked, and then restarted.
After the user's routine has been incorporated into the base cycle procsdure, the user can monitor it to make sure it executes properly. There are two key indicators of a problem with the user's user routine:
the block status and the control program log file. If the user's routine has an error which would normally cause a stand-alone FORTRAN program to terminate, the base cycle procedure will bypass the error and the remainder of the user's routine, and change the block status to l'On-Failed usr routin". This can be seen using the block monitoring screen. If the user's routine fails once but runs successfully on a subsequent execution, the block status will be changed to "On-Recovrd Usr Error", and a message will be posted in the control program log file indicating which user routine had the error, when it occurred, and what the error was. The log file can be viewed using the "List log file" option on the System functions screen.
The user can print a listing of a user routine by using option 3 (or option 4 for a separate routine).

75~'3 If the ~ser ' s user routine fails and the user needs to retreat to the last version that was running, he can use the restsre option (keypad 9). This will prompt the user Por any separate routines that need to be restored, 5; and retrieve the old versions saved by the build-supervisor procedure.
In the presently preferred embodiment, there are several include files which can be used in user routines: "User_vars . inc" contains a common block which Ia~ is used to pass information about control block actions to user routines. The common block contains a Real array, an integer array, and a character*80 array.
Control blocks load ~Jalues into these arrays for the amount of change made in the manipulated variable, the error in a feedback bloc3c, the time the action was taken, etc. The user program block zeros out these values after the user routine executes a RETURN
statement. "ACSserv. inc" declares all the ACS service routines (which are integer*4 functions) .
"ACSstatus. inc" declares all the legal ACS status return values. These values must be declared external before they can be used. 'IVan functions. inc" declares some of the retrieval and time functions from the historical process database, and declares some of the status return ZS; values.
Of course, many different computer languages and architectures could be used in practising the present invention: the sample FORTRAN routines specified (as well as other features which, for example, relate 3~, specifically to the use of a VMS operating system) simply sets forth the best mode as presently practiced, but a tremendous variety of other languages, operating environments, and/or hardware could be used instead.

~7~5~
~lock-Handlina Utilities Figure 14 shows a menu which is preferably presented to a user who has elected to use the utilities provided in the build-supervisor procedure (e . a . by hitting keypad 9 when façed with the menu shown in Figure 16). While these utilities are not necessary parts of every implementation of the innovative concep~s described in the present application, they do help users to take advantage of the full power available.
In the presently preferred embodiment, the supervisor procedure includes the capabilities for copying and deleting blocks, and for printing listings of blocX setup parameters. Deleting a block (Xeypad 7) removes all the block type and setup parameter data for the block, leaving it available for another use. Copying a block (Keypad 8) reproduces the block type and setup param~ters of one block into another. Printing blocks (Keypad 9) allow the user to select blocks to be printed either by number range or by searching for string matches in the application name or block description fields, and makes full or abbreviated listings of block parameter data on the printer of the user's choice.
If the user elects to copy a block, the build-supervisor procedure prompts the user to enter in the "Source block" field 1402 the number of the block to copy. ~he build-supervisor procedure then fills in the information fields appropriately for that block, allowing the user to confirm that he has entered the right block number, and prompts the user again for the target block into which the block should be copied (field 1404). After this is entered the build-supervisor procedure fills in the information fields for the target block, and prompts the user again. When the user confirms that the block is to be copied, the block type and parameters are overwritten in the shared memory 814.

5:~3 After the block is copied, the build-supervisor procedure prompts the user again, asking whether the source block should be deleted or left unchanged. The build-supervisor procedure confirms that the source block was either deleted or not deleted.
Block information can only be copied into target blocks whose status is "Off" or "Inactive". To copy information into a block with an active status, the user must go to the block setup form for that block, and toggle the block off. This safeguard provides greater system integrity.
In the presently preferred embodiment, keypad 9 will initiate printing a lis~ing of selected block parameters. The build-supervisor procedure will prompt the user to enter in field 1410 for the starting range of block numbers to print, or to hit return if he wishes to select blocks by string searches. To print a range of block numbers, the user can enter the lowest number block in the range, press return, then enter the higher number block (in field 1412) and press return. To select the blocks to be printed by search for string matches, the user can press return without entering a number for the starting block. To search the block description fields, the user can enter the desired string in the description search string field 1406. To search the block application name field, the user can press return without entering anything in the description field, and enter the desired string when prompted in the application name field 1408. In either case, the user can use capital and lower case letters interchangeably, since case is not checked in the string searches. The user need not fill in the whole search string field. A
block will be selected to print if the string the user enters appears anywhere in the searched field.

~ ~7~

The build~supervisor procedure will now prompt the user ~or ~ short or long list. A short list 6hows only the block numher, type, description, and application name. A long list shows the ntire setup form for that block. The build-supervisor procedure will clear the screen and prompt the u~er for the printer he wishes to use. The user can type the number of the printer if he knows it, or enter L to get a list of printers to choose from. The user's terminal screen and its attached printer can be selected, as well as Vax system printers.
When the print job is completed, the build-supervisor procedure will report the numDer of blocks that were printed.

Monitorin~
In addition, the supervisor procedure provides several functions for following the performance of control strategies as they operate. The block monitoring screen allows the actions of individual blocks to followed. The system functions screen shows the status of the supervisor procedure. The control system runs as a batch-type process on the Vax, and so it has a log file which contains all the error messages generated by the system.
A user who requests block-monitoring i5 presented with a block description form which includes a block number field in which he can insert the number of the block to be monitored. The remaining fields on the form then are filled in appropriately by the build-supervisor procedure, and are subsequently updated every 5 seconds.
The information shown includes:
- the current time;
- the time at which the supervisor base cycle procedure will make its next scan through the blocks (and blocks which are due to execute will be executed);

;5~

- the block type (which was specified during block setup, e.~. feedforward, feedback, etc.);
- the block description (which was entered during setup);
- the type, number, name and units of the measured variable which was speciied in block setup (if none was specified (e.g. in a program block), this field will be blank);
- the current value and time stamp of the measured variable (the time stamp for compressed variables is the time the last new value was received;
for manual entry variables it is the time stamp of the last entered ~alue; and if no measured variable was specified, this field is blank);
- the goal value for feedback blocks (for other block types, this field is empty);
- the number, name, units and type of manipulated variable;
- the current value of the manipulated variable (with time stamp if one has been defined);
- the timing option entered during block setup;
- the execution time interval specified during block setup. I~ the block timing does not include any fixed frequency, this field is blank.
- the time the block last did its scheduled actions (this is nor~ally the last time the block was scheduled to execute according to its timing option parameters, regardless of whether the block acted to change the manipulated variable);
- the current status of the block; and - the last five control actions made by the block (or, ~or Shewhar~ blocks, the last five deviation values) and the times at which they occurred.

~l2~75~

In the presently pref~rred embodiments, a similar overhead function permits the user to take a look at the current status of key system parameters, including:
- Base scan interval: the time interval at which the base cycle procedure scans through aLl the properly configured blocks, checking for changes in the on/off ~tatus, testing each according to its timing option and status to determine whether it should execute, and execl~ting those that are due to execute.
- Next base cycle time: the time at which Lhe supervlsor procedure will actually do the next scan.
This time should always be in the future, and should never be more than the bas~ scan interval away.
- Current system status: provides information about what the supervisor procedure syst m is currently doing. Since the supervisor procedure only does its actions once every base scan interval, the system spends most of its time sleeping - i.e. waiting for the next cycle time to come. The normal system status values are:
* Running-Sleeping : the normal status value. All control actions on the las~ scan have completed and the system is waiting for the next scan.
* Running-Computing : the system is currently performing block checks and executing blocks.
Since calculations in the supervisor procedure finish rather quickly, this status will rarely be seen.
* Terminated normally: This status indicates that the supervisor procedure system has been stopped in an orderly way. Normally this status value will only be seen if the system manager has stopped the system, or briefly when a user performs the Update function on the user program menu.
An authorized user can change the base scan interval, stop the superYisor process (together with any auxiliary processes used for communication with PCS or ~28 other control systems), restart the supervisor process (and any auxiliary processes), or view the log file to which the base çycle procedure writes error reports and messages.

BlocX Initialization Blocks are initialized when they are first turned on, or when the supervisor procedure is restarted after an outage of 30 minut s or more and the block had already been on. Block initialization sets the "last execution time" of the block to the current time. The "last execution time" value is used in fixed interval timing and also as a block monitoring parameter. If the block has a measured variable, the "last measured time"
is set equal to the current time of the measured variable. This parameter is used when block timing is keyed off the measured variable. If the block timing i5 set to key off another block, the key block time is set equal to the last execution time of the key block. For feedforward blocks, the "old measured value" is set equal to the current value of the measured variable.

7~5~1 Build-Exnert ~nd ExDert Proce~ures The pro~edures for construc1:ing an expert system fro~ a domain expert's knowledge will now be described, together with the procedures by which the experk system s is called up by the operating soEtware (preferably the process control ~upervisor procedure, as d~scribed above).
It should be noted that the structures and advantages of the build-expert procedu~e are not entirely separate from those of the expert procedure (or prooedures~ generated thereby. The two procedures are preferably operated separately, but they are designed for advantageous combination. The features of the expert procedure are partly designed to advantageously facilitate use of the ~uild-expert procedure, and the features of the build-expert procedure are partly designed to adYant~geously facilitate use of the expert procedure.
The build-expert procedure works especially advantageously as an integral part of the supervisor procedure, which (in the presently preferred embodiment) is a VAX-based layered control system. The build-expert procedure produces complete FORTRAN subroutines that execute the expert actions. The supervisor procedure (e~a, via ~ user program block) provides the functions for running an expert su~routine at specified times, ~nd also provides callable routines that can be used by the~e ~ubroutines to ~ake and modify supervisor actions.
The build-expert procedure can be used without the preferred superv~sor procedure, but the user must provide ~ host program running at appropriate times to c~ll the subroutines.

~7~5~

Prç~r~ed Mçnu Structur~
In the presently preferred embodiment, the build-expert procedure is accessed by selecting the "User progra~l' option on the top~level menu in the build-supervisor procedure (see Fi~ure 16), entering the desired block number, and then selecting the Expert system development option on the user program menu. This will take the user to the build-expert procedure, which (in the presently preferred embodiment) preser.ts a menu as shown in Figure 17.
From this menu the user can access setup templates for the 3 rule types~ The user also has acces-~ to functions for printing the rulebase, and for building a new expert subroutine.
lS The rule templates used in the build-expert procedure allow the user to enter and modify the specification information for rules. The build-expert procedure is different from the build-supervisor procedure in the way it handles data. When a rule name is entered in the build-expert procedure and the RETURN
or TAB key pressed, the letters are capitalized and the embedded spaces are transformed to underscores. This is how the build-expert procedure stores all character data. The other fields on rule templates are not transformed liXe this until the rule is stored. When the rule is recalled onto the template, the other fields will be capitalized with embedded blanks changed to underscores. In the presently preferred embodiment, the rule name, data type, and data number fields are the only fields on the rule templates for which the user's entry is checked immediately (others may be modified in the future to do this). The remaining fields can be filled in with any data that the template allows (some fields accept only integers, some only alphabetics, etc). The data on the remaining fields is tested only ~ 7~

when the user presses the keypad "-" to store the rule.
The build-expert procedure then examines the data for errors, and requests corrections i~ needed. The build-expert procedure always checks rule names (and condition names) to be sure they are valid and meaningful where entered. In the present~y prefer-ed embodiment, the build-exper~ procedure checks other data for most errors, but it does not check for all conceivable errors. Da~a entered on a rule template is NOT stored until ~he keypad "-" key is pressed to store the rule.
Data on a template will not be stored if the rule name field is hlank. Data on a template can be lost if the user enters the data, then modifies the rule name field before pressing keypad "-". All the rule templates have a "delete rule" (keypad "-") and "top of form" (keypad 9~ softkey. The delete rule key will ask the user to confirm the deletion by pressing the key again, and then deletes the rule from the rulebase. The top of form key simply takes the user to the top of the template.
After all the rules have been entered, the FORTRAN
expert subroutine must be generated using keypad 9, "Generate Expert". Changes made in the rules will not become effective until the expert is rebuilt. When the build-expert procedure is used within the build-user-program environment (as discussed above), the FORTRAN
subroutine is generated in the same directory with the user program and is named 810ckn expert_system.for, with the subroutine name Blockn_expert_system (n is the number of the block being worked on.) To use the expert from within the supervisor procedure, a one line user program must be written to call the expert. The one executable line is:
Call Blockn_expert_system .

~75~i~
~tanda~i~ed ~ta I~terface The build-expert procedure uses a standard data interfa~e. In the presen~ly preflerred embodiment, data sources are specifi~d by a pair of integer paxamet~rs.
One, the "d~t~ type", is a coded value which identifies the type of data desired and the dat~ collection system from which the data is to come. The second , the "dat~
number", identifies the specific data entity of that type within that system. Some data types ~e.q. ~ime averages3 require a third parameter sp~cifyi~g the time over which to average.
This system has several advantages. First, it provides a ~imple methcd of data identification in a many-system environmen~. Seco~dly, it allows the rules to e~sily referenc~ data of many types from ~any diverse (and possibly remote) sources without requiring the user to write any custom program code for data retrieval.
Some useful data sources might include: any lower level process control system: any supervisor process (whether running on the same h~rdware system or another): any process datab~se (whether running on the s~me hardware system or ~nother); of any computer which collects or generates d2t (ncomputer" be~ng defined verY broadly to include, Ç~a-, ~ny system which includes a microprocessor, such as a microprocessor based single loop controller).
In the presently preferred embodiment, the data types allowed by the build expert procedure are: 1) the latest value of a database variable; 2) a ti~e weighted average over a given time interv~l of th2 value of a datab~se v~ri~ble; 3) A simple average over a giv~n time ~nterval of the discrete data values o~ ~ database varlable: 4) the ~eedback error of a feedback block ln the ~uperv~sor process; 5) the chsnge in the v~lue of thB ~e~sured vari~ble o~ a superv~sor feed~orward block 1~75S9 since the last time thP block acted; 6),7) the goal values of control loops in two particular lower level control systems; 8) the second most recent value of a discretely sample process database variable; 9),10) the maximum and minimum limits for ~he manipulated variable value in a supervisor control block. Other sources could be used, for example any kind of parameter from any of the systems named in the previous paragraph, or system lexical functions (such as the system clock). As a further alternative, it might also be advantageous in some embodiments to make one of the options here a one-line blank, in which the user could enter a pointer to a callable procedure to fetch a variable value.
In the presently preferred embodiment, the user must specify the data type before the data number. When the data type is entered, a prompt line pops up on the template indicating the specific data type, which aids the user in entering the proper value for the data number. When the data number is entered, it is tssted to be sure it is a meaningful entry for the data type specified. Some additional information is then displayed (such as a variable name and its units) to aid the user in confirming his input. These fields also serve to aid understanding of rule function and meaning when recalled for review or modification.

Constructinq the Expert Svstem An expert system goes through four steps in using knowledge: l) The expert gets information from the outside world; 2) analyzes that information using i~s rules; 3) deduces the correct conclusion from its analysis; 4) communicates its decision to ~he outside world.
Rules state that WHILE one thing is true THEN
something else must be true. For example, WHILE the 12~'755~

composition of water in the Feed mix drum is greater than 12%, we say "FEED MIX WATER COMPOSITION" is "~IGH".
Or, WHI~E "FEED MIX WATER COMPOSITION" is "~IGH", AND
"DEHY COLUMN BOTTOMS ~ATER't is "HI~H", we say "TOTAL
SYSTEM WATER" is "TOO HIGH". WHI~ "TOTAL SYSTEM WATER"
is "TOO HIGH", we "Give a high water warning message."
This simple example shows the three basic types o rules which are used in the build-expert procedure: the sample retrieval rule described tests the VALUE (12%~ of a process measurement (FEED MIX WAT~R), and assigns a value (HIGH, LaW, etc.) describing the condition of the measurement. The sample analysis rule given tests for combinations of values defined by other rules. If it finds the combination, the analysis rule creates a new condition (TOTAL SYSTEM WATER) and assigns a value (TOO
HIGH) describing that condition. The sample action rule described tests for one specific condition (TOTAL SYSTEM
WATER) has one specific value (TOO HI~H), and takes a specified action (Give a high water warning message~.

Sam~le Ex~ert ~vstem An example o~ construction of an expert system using novel methods and system as set fortA in the present application will now be described in detail.
The sample system here chooses an optimum control action from among three possibilities. A key element of the problem here is to control the composition of by-product MF8 in the product stream of a refining train like that shown in Figure 7. MFB is separated in two columns in series. Essentially equivalent response in MFB
composition can be achieved by changing the steam flow to either column. Both columns use high value steam in their reboilers. The first, the Xylene column, dumps the steam energy to cooling water. The second column, the MFB column, recovers most of the energy by generating 7~ 9 steam overhead. ~quipment limitations constrain both steam flows to within high and low limits.
As column feed rate varies, steam loading can change from minimum steam on both columns to maximum steam on both columns. The optimum operation maximizes steam on the low cost column (MFB) and minimizes steam on the high cost column (XYL).
In this example, control of the MFB composition is done statistically. The laboratory measurements of MFB
are statistically tested using Shewhart tests. The Shewhart tests determine the on aim status of ~FB: Off aim high, Off aim low, or on aim. When MFB is off aim, the Shewhart test generates an estimate of how far off aim MFB is. This estimate can be used to compute the feedback action needed to bring MFB back to aim: off aim high requires an increase in steam to the two columns, off aim low requires a decrease.
The expert system which is sought to be developed should instruct the supervisor procedure to make the least cost control action. Plant startup, problems, or poor manual operation may distribute steam in a non-optimal way, and this cannot be known beforehand.
The objective will be to move toward the optimum steam distribution through control action response to off aim conditions. Steam will not be shifted for cost savings only, since this complicates control and may negatively affect quality.
Although this may seem like a trivial decision, it actually involves considering 3 variables in the correct sequence. This is where the "expertise" gets into the "expert" system. Developing the logic is the task of the human expert, and the system disclosed herein merely expedites the transfer of that logic into the expert ~ystem. ~he process cvntrol decision tree which will be ~755~3 implemented, in the sample embodiment described, is as follows: First, decide whether to add or cut 6team:
(1) I~ adding steam:
(1.1) First check the MFB column. If MFB
S colu~n steam below maximum, add steam here.
(1.2) If the MFB column steam is maxi~um, then (1.2.1) ChecX the Xylene column. If xylene column steam is below the maximum, add steam here.
(1.2.2) If xylene column steam is maximum, the user cannot add steam. To get MFB on aim, feed to the column must reduced. Cut column feed.
(2) If cutting steam:
(2.1) First, check the xylene column~ If xylene column steam is above the minimum, cut steam here.
(2.2) If xylene column steam is minimum, then (2.2.1) Check the MFB column. If MFB
columns steam is above minimum, cut steam here.
(2.2.2) If MFB column steam is minimum, the user cannot cut steam. To get MFB on aim, Feed to the column must be increased. Add column feed.
It is highly desirable that the decision tree being implemented should cover all the possible cases, and that the conclusions should be mutually exclusive. If it does not cover all the possible cases, the expert will sometimes be unable to come to a conclusion. If the conclusions are not mutually exclusive, then more than one conclusion could exist. Although this might logically be possible, this condition might mean unpredictability as to which conclusion will be reached, so that there would not be a reproducible basis for action.

Domain expert~, in performing the analytical steps which the e~pert system should ideally emulate, will carry out many steps implicitly; but implementing a process in a comput r requixes that each ste~ b~
expressly spelled out. To make the decision, the u er must first speoify:
- what measurements will De used to evaluate the process condition (in this example, MFB STEAM, XYL STEAM, DIRECTION OF CHANGE);
- what ranges of values of the measurements (e.~. 40 ~ XYL STEAM) match what status values for the measurements (e.a.MID RANGE);
- what co~binations of status values (e.~.
MFB STEAM is MAX and XYL STEAM is MIN, and DIRECTION OF CHANGE is ADD) will result in what other conditions (e.a. ACTION is CHANGE XYL STEAM):
- what must be done to make the desired action happen.
The det~iled specifications needed to handle this problem are de$ined a~ follows:
Measurements: For MFB column steam, th2 goal on the computer loop for MFB steam is a good measure. In the sample system referred to, this is loop 30 in the UDMT PCS~ system. For xylene column ~tea~, the goal on the computer loop is a good measure. In th~ sample ~ystem referred to, this is loop 5 in the "~MT PCS"
system. For the direction of change, the best measure is the feedback error on the control block that will be changing steam (in this case, the third block in the ~upervisor procedure). For MFB column steam, we know the operatlng li~its of steam flow to the column (in thous~nds of pounds per hour (MPPH)):
~AX ~ 49.5;
MIN ~ 28.5:
MID > 28.5 ~ 49~5.

75~;9 And for the xylene column:
MAX > 66.5 MIN < 4 0 . 5 MID > 40.5 ~ 66.5.
For the direction of action, we know that an off aim high condition means a steam increase. Our feedback block ( in the supervisor procedure) is usinq the Shewhart deviation from aim as the measured variable, with an aim of 0. 0. Thus if the feedbac3c error is positive, we increase steam:
ADD i f Feedback error > 0 CUT i f Feedback error < 0 or = 0 For the analysis of these conditions, we need to specify what combinations of conditions lead to what result. This expert provides only one re~ult: it defines what the manipulated variable will be - xylene column steam ( "xyl col steam" ), MFB column steam ("MFB col steam"), or column feed ("column feed"). This logic results in the following rules:
Table 5 MANIPULATED VARIABLE is MFB COLUMN STEAM While Direction of change is ADD
and MFB COL STEAM is not MAX

MANIPULZ~TED VARIABLE is XYL COLUMN STEAM While Direction of change is ADD
and MFB_COL STEAM i s MAX
and XYL COL STEAM is not MAX

MANIPULATED VARIABLE is COLUMN FEED While Direction of change is ADD
3 0 and MFB COL STEA~ is MAX
and XYL COL STE~M is MAX

55~3 MANIPULATED VARIA~LE is XYL COL~ STEAM While Direction_of change is CUT
and XYL COL STEAM i5 not MIN

MANIPULATED VARIABLE is MFB COLUMN_S~EAM while Direction of change is CUT
and XYL COL_STEA~ is MIN
and MFB_COL S~EAM is not MIN

MANIPULATED_VARIABLE is COLUMN FEED While Direction_of_change is CUT
and XYL COL STEAM is MIN
and MFB_COL STEAM is MIN

Note that: 1) some of the conditions are negated, 1-5-; i.e. it is specified that a rule or condition must NOT
have a certain value (MFB COL STEAM is NOT MIN). 2) More than one test can set the value of the same condition (MANIPULATED VARIABLE in this case). 3) More than one test can assign the same value to the same condition (i.e. th~ second and fourth both set MANIPULATED
VARIABLE to XYL COL STEAM, under different conditions).
By contrast, the retrieval rules each assign one of several descriptors to a name which is unique to that specific rule.
Finally, the expert must do something with its conclusion to change the way the supervisor acts. In this case, assume that there are three feedback blocks in the supervisor procedure, all having the Shewhart MFB
deviation as measured variable, with aims of 0Ø One (#3) manipulates xyl COL steam, one (#4) MFB_column ~te~m, and one (#5) column feed rate. The supervisor procedure includes a FORTRAN callabl~ function named ACS_SELECT BLOCR, which allows only one block out of a set to take action. The others are "de-selected" and ~ 7.3~

stand ready to act if selected~ When ACS sele~t block is called, the first block number in the argument list becomes selected, the others are deselected. Trailiny 7eros are ignored.
Thus, to enable the expert being built to chan~e the control stra~egy, the following rules are added :o the rule set:

While MANIPULATED VARIABLE is XYL COL_ST~M Then do the FORTRAN statement:
ACS status - ACS select block ( 3, 4, 5, 0, 0, o , While MANIPULATED VA~IABLE isMFB_COL_ STEA~f Then do the FORT~AN statement:
ACS status = ACS_selPct block ( 4, 3, 5, 0, 0, 0 ) While MANIPULATED VARIA8LE isCOLUMN F~ED Then do the FORTRAN statement:
ACS status - ACS select_block ( 5, 3, 4, 0, 0, 0 ) The ~oregoing data entries are all the inputs needed to define the expert system.
Within the supervisor procedure, an expert system can be developed for each block. Used in this way, the build-expert procedure will create the FORTRAN
subroutine Blockn expert system (where n is the block number, i,ç. the subroutines will be named BLOC~2 EXPERT SYSTEM etc.), compile it, and place it in the proper library so that it can be called from within a supervisor block (by a user routine).

Expert Rule St~ucture This sample embodiment provides an example which may help clarify what an expert procedure does. Some ~7S~S~
more general teachings regarding expert system methods and structure will now be set forth.
Figure 2 is a schematic representation of the organization preferably used for the knowl~dge base.
Three main categories of rules are used, namely retrie-val rules 210, analysis rules 220, and action rules 230.

Retrieval Rules ~he retrieval rules 210 each will retrieve one or more quantitative inputs (which may be, e.q., sensor data 157 from one of the sensors 156, historical data 141 and/or laboratory measurements 162 from a historical data base 140, limits on variable values, goals 132 defined by the supervisor procedure 130, combinations of these, or other inputs). One of the significant advantages of the system described is that it provides a very convenient user interface for accessing quantitative inputs from a very wide range of sources:
essentially any data object which can be reached by the host computer can be used. (The presently preferred embodiment uses DECnet and serial communication lines to link the computer which will be running the expert system with the various computers it may be calling on for data, but of course a wide variety of other networking, multiprocessor, and/or multitasking schemes could be used instead.) In the presently preferred embodiment the retrieval rules are of two kinds: the s-mpler kind (referred to as "variable rules") will name one quantitative value (which may optionally be derived from several independen ly accessed quantitative inputs), and assign one of a predetermined set of descriptors (variable status values 222) to that name. Each of the more complex retrieval rules (referred to as :'calculation rules"~ permits descriptors to be assigned selectively 755~3 to a name in accordance with one or more calculated values (which may optionally be derived from a number sf quantitative variables~.
Figur~ 3 shows the te~plat~ used for a retrieval rule in the presently preferrecl embodiment, together with a sample of a ret~ieval rule which has been entered into the template. The areas in this drawing which are surrounded by dotted lines indicate the parts of the template which the user can modify, and which are prefera~ly highlighted to the user in some fashion, e.a.
by showing them in reverse video. In this example, the user has typed in the rule name as "xylene column steam." The build-expert software has automatically translated this rule name, by changing all the spaces in it to underscores, so that it appears as a one word name. (This can be conveniently used as part of a variable name in conventional computer languages.) Thus, the rule shown in Figure 3, when translated into an expert procedure by the build-expert procedure, will define a set of variables whose names each begin with "XYLENE COLUMN_STEAM."
For example, in the presently preferred embodiment the rule shown will translate into the following set of variables:
"XYLENE COLUMN_STEAM STATUS" is a character variable (also known as a string or alphanumeric variable) which will have a string value which is either "MIN," "MAX," or "MID;"
"XYLENE COLUMN STEAM VALUE" will be a real 3Q variable, representing the quantitative value originally retrieved for the parameter;
"XYTFNE COLUMN STEAM AGE" will be an integer variable representing the age of the quantita~ive value originally retrieved;

75~3 "XY1ENE COLUMN STEAM_ASTAT" will be a character variable which is defined to have values of "TOO OLD" or "OK," depending on whether the age valu~ is within limits (no~e, for example, that this variable could easily be configured as a logical variable instead);
and "XYL~NE_COLUMN STEAM FIRED" will be a logical variable which indicates whether this particular rule has been fired (on a givon pass).
In filling out the retrieval rule template, the user must fill in at least two of the classification blanks. However, in the presently preferred embodiment, only five classification ranges are permitted. (This limit could be changed, but there are significant advantages to permitting the user to input only a restricted number of ranges. Where the process control algorithm absolutely demands that the variable be classified into more ranges, two or more process variable rules could be used to label up to eight or more ranges.) ~nother constraint used in the presently preferred embodiment is that the user must enter at least the first two open ended ranges. He may enter up to three bounded ranges, to provide a complete coverage of all cases, but he must enter at least two open ended range specifications.
In the presently pre~erred embodiment, the build-expert procedure checks to see that the ranges defined are comprehensive and non-overlapping, before the rule is permitted to be added to the rule base.
Figure 4 shows an example of a different kind of retrieval rule, known as a calculation rule. The menu ~or this rule is (in the presently preferred embodiment) presented to the user as two screens. The user may specify up to ten quantitative inputs, of any of the 7~ 3 types just referred to, as well as up to ten values arithmetically derived from these inputs (or constants).
By having some of the derived values refer back to other ones that are derived values, quite complex formulas may be implementedO (One advantageous use of such formulas may be to relate off-line time-stamped laboratory measurements with the continuously-measured values of the same (past) time era, e.~. in a component material balance.) Moreover, notice tha~ the variable values and calculated values thus assembled may be used not only :o define a "key value" to be categorized, but also :o define the limits of the various categories against which the key value is sought to be tested.

Analysis Rules Analysis rules generally are used to embed the natural language reasoning as practiced by the domain expert. One important distinction between retrieval rules and analysis rules is that each retrieval rule has a unique name, but the analysis condition names defined by analysis rules are not necessarily unique. Figure 5 shows an example of an analysis rule 220. Again, the portions of the template which the user can modify are shown inside dashed boxes. Note that the template preferably used defines an analysis condition name and assigns a descriptor to that analysis condition name if specific conditions are met. In the presently preferred embodiment, the only tests permitted are ANDed combinations of no more than five logical terms, each of which can consist only of a test for identity (or non-identity) of two strings. Moreover, the string identity tests are preferably set up so that each of the com-parisons either tests a retrieval rule name to see if a certain variable status value 212 was assigned by that rule, or tests an analysis condition name to see if -.

~3755~3 certain analysis status value 222 was assigned by one of the analysi5 rules. That is, as seen schematically in Figure 2, there is potential for recursion among the analysis rules 220 considered as a group, since some of the analysis rules 220 can refer to the outputs of other analysis rules 220. Optionally the analysis rules could be sequenced so that there wsuld never be any open-ended recursions, but in the presently preferred embodiment this extra constraint is not imposed.
Any one analysis condition name ~ay (under various conditions) be assigned values by more than one analysis rule. That is, each analysis rule is preferably set up as an IF statement, and multiple such IF statements will typically be needed to specify the various possible values for any one analysis condition name.
In the presently preferred embodiment, the status of every analysis condition name and variable rule name are initially defined to be "unknown," and the logical comparisons are implemented 50 that no test will give a "true" result if one term of the comparison has a value of "unknown."
The order in which the analysis rules are executed may be of importance where an analysis condition name is multiply defined. ~hat is, it may in some configurations be useful to permit the conditions of the various analysis rules 220 to be overlapping, so that, under some circumstances, more than one analysis rule may find a true precondition and attempt to assign a status value to the same analysis condition name. In this case, the sequence of execution of the analysis rules 220 can optionally be allowed to determine priority as between analysis rules. However, as mentioned above, this is not done in the presently preferred embodiment.
~oreover, more than one analysis rule may assign ~7~5~3 the same analysis ætatus value 222 to the ~ame analysis condition name, under differ~nt circumstances.
It can be advantageous, for purposes of documenting the reasoning embedded in the expert system, to give names to the analysis rules which include both the name and descriptor possibly linked by that rule: thus, for instance, a rule which is able to conclude that column operation is normal might be named "COLUMN_OP NORMAL."

Action Rules I0 Figurs 6 shows the presently preerred embodiment of the template for action rules~ and an example of one action rule which has been stated in this format. Again, the portions of the template which the user can modify are indicated by dashed boxes.
The user has chosen to name this particular action rule "Change Xylene Steam," which the build-expert software has translated into CHANGE_XYLENE STEAM (for incorporation into various variable names such as "CHANGE_XYLENE STEAM FI~ED"). The names assigned to action rules are primarily important for documentation, so that, when this user or another user looks back through the rule base, the use of clear rule names for action rules will help to understand what the structure of the expert system's inference chaining is. In fact, it may be advantageous, as in the example shown, to generally pick analysis status values 222 which have fairly descriptive names, and then, to the extent possible, name the action rules identically with the corresponding analysis status values.
~0 Note also that the action rules can refer back to a variable status value 212 as well as to an analysis status value 222.
Thus, in the presently preferred embodiment the action rules embody an absolute minimum of logic. Thes~

55~

are used primarily as a translation from descriptive key words embedded within the inference chaining structure to the actual executable statements (or command procedures) which specify the action to be taken. Thus, one way to think about the advantagec of the expert ~ystem organization preferably used is that the emulation of natural language reasoning i5 concentrated as much as possible in the analysis rules, while the retrieval rules are used to provide translation from quantitative measurements into input usable with natural language inference rules, and the action rules are used almost exclusively to provide translation from the natural language inference process back to executable command procedures which fit in well with the computer system used.
Each of the action rule templates also gives the user several choices for the action to be taken to implement the action rule if its precondition is met.
The user can either insert an executable statement (in ~o FORTRAN, in the presently preferred embodiment) or insert a pointer to a command procedure, or simply have the action rule send advisory messages. The third option is useful for debugging, since the expert can be observed to see what actions it would have taken, without risking costly errors in the actual control of the system.
In the example shown, an executable FORTRAN
statement is used, but the statement specified merely passes an action code back to the supervisor process. In the example shown in Figure 6, the procedure call given will cause the supervisor procedure to turn on the block whose number is given first, and turn o~f all other blocks whose numbers are given. Thus, the statement acs status = acs select block (3, 4, 5, O, O, 0) ~r3~755~
would change the status of block 3 to "on-selected"
(assuming that it did not need t~ be initialized), and would set the status values of blocks 4 and 5 to "on-deselected." Thus, when the expert system has completed running, the supervisor procedure which called the expert procedure as a subroutine can selectively execute block functions depending on the values passed back to it by the subroutine.
Thus, the action rules permit a very large variety of actions to be performed. For example, one optional alternative embodiment provides synthetic-speech output;
optionally this can be combined with a telephone connection, to permit dial-out alert messages (e.a. to a telephone number which may be selected depending on the ~5 time of day shown by the system clock, so that appropriate people can be notified at home if appropriate).
Another optional embodiment permits an action rule to call up a further sub-expert. This might be useful, ~0 for example, if one expert subprocedure had been customized to handle emergency situations - who should be called, what should be shut down, what alarms should be sounded.

Generating the Expert Procedure After the user has input as many rule statements as needed, or has modified as many of an existing set of rule templates as he wishes to, he can then call the generate code option to translate the set of templates 115, including the user inputs which have been ~ade into the rule templates, to create the expert system 120.

~ 2~7559 Generatin~ SQ~Ce Code As a result of the constraints imposed in the various rule templates, the translation from the constrained format of the templates is so direct that the executable rules can be generated simply by a series of appropriate string-equi~alent tests, string-append operations, logical-equivalenc~ tests, arithmetic operations, and fetches.
Preferably three passes are perfor~ed: the first - does appropriate character type declarations; the second loads the appropriate initializations for each rule; and the third translates the inference rules themselves.
An example of the initialization steps is seen in initialization of the analysis rules: an initial value such as "dont_know" is assigned to each condition name, and the Pquivalence tests are redefined slightly by the translation procedure, so that, until some other value is assigned to the name by another rule, the statement "name" = "descriptor"
will be evaluated as false, and the statement NOT("name" = "descriptor") will also be evaluated as false.
SamDle Source Code A portion of the source code for the procedure which actually performs this function, in the presently preferred embodiment, is as follows.

Table~

C
C Build expert.for C

C Routine to ~enerat~ FORTRAN expert system code using C the process rulebase.
C
C**~******~********~******~*~****~****
C

Subroutine Build expert C

Include 'pace~includes:Variable_rule params.inc' Include 'pace$includes:Expert_data.inc' Include 'paceSincludes:Analysis commons.inc' Include 'paceSincludes:Analysis rule.inc' Include 'pace$includes:Action commons.inc' Include 'paceSincludes:Action rule.inc' Include 'pace$includes:Action ~arams.inc' .C
Logical First Logical No more Character*25 Last cond Character~80 code dir file Character~ a o Directory Integer~2 L dir Character*39 Subroutine name Character*14 Subprocess name Character*3 Cblock Integer*2 L sp Character*l Search string Integer*2 Srlen C

Call Fdv$Putl(' Generating Expert System code....') C...Rewind the code file C

d write(6,*) ' will rewind code file' Rewind ( Unit 5 Code lun ) Next label = 2 C...Get the name of the expert system code file, pick out the C subr name from it d Call Fdv$putl ( 'Will translate logicals.') Call LibSsys trnlog ( 'PACE5RULES' ,, Directory ,,,) Call LibSsys trnlog ( 'PACE~CODE' ,, Code dir file ,,,) d Call FdvSputl ( 'Did translate logicals.') Istart = Index ( Code dir file, ']' ) 75S~

Subroutine name z Code_dir file(Istart+l:8o)//Blank d Call FdvSputl ( 'Will get lndex of ".".') Iend = Index ( Subroutine name, '.' ) d Call Fdv$putl ( 'Will clip subrout name.') I~ ( Iend .gt. 1 ) Then Subroutine name s Subroutine name(l:Iend-l)//Blank Else Subroutine name = 'Expert'//Blank End If d Call Fdv$putl ( 'Will trim subroutine name.') Call Str$trim ( Subroutine_name, Subroutine_name, Srlen ) d Write ( 6, 100 ) Subroutine_name Write ( Code lun, 100 ) Subroutine_name C
C... construct a sub-process name C

If ( Subroutine_name(1:5) .eq. 'BLOCX' ) Then d Call Fdv$putl~'Is block.') d Call Fdv$wait ( It ) Read ( Subroutine_name(6:8), '(I3~' ,err= 91 ) Iblock d Call Fdv$putl('Is > 99.') d Call Fdv$wait ( It ) Liblock = 3 Go To 93 91 Read ( Subroutine name(6:7), '(I2)' ,err- 92 ) Iblock d Call Fdv$putl('Is > 9.') d Call FdvSwait ( It liblock - 2 Go To 93 92 Read ( Subroutine_name(6:6), '(Il)' ,err- 93 ) Iblock d Call FdvSputl('Is < 10.') d Call FdvSwait ( It ) Liblock = 1 Go To 93 93 Write ( Cblock, '(I3)' ) Iblock Istart = 4 - Liblock Subprocess_name = 'B'//Cblock(Istart:3)//'_' L_sp = 3 ~ Liblock Else L_sp = 1 End If C

100 Format( 1 ' Options /~xtend_source', /, 'C***~*****************************************'~/~
1 'C' ,/~
1 'C Expert System Code',/, 1 'C', /~
'C*****~*********~**************************~**'~/~
1 'C', /~
1 ' Subroutine ', A, /, 1 'C' ~ / ~

~L~'137~;9 1 ' Include "ACS~includes:~CSserv.inc'' ' , / , 1 ' Include ''ACSSincludes:~CSstatus.inc" ' , / , l ' Include ''ACS~includes:Sys functions.inc'' ' , / , 1 ' Include ''(SJpidef)'' ' , 7, l' Integer~4 Vss$_to ascii time' , / , 1 ' Integer This pass_fires' , / , 1 ' Character*25 Unknown' , / , 1 ' Parameter ( Unknown - "Unknown ")' l ' Character*25 OK' , / , 1 ' Parameter ( OK = "OK ?' , / , 1 ' Character*25 Too old' , / , 1 ' Parameter ( Too_old - "Too old '')' l ' Integer~4 Now' , / , 1 ' Integer*4 Then' , / , 1 ' Character*1~ ~ now' , / , 1 ' Integer*4 Itemlist(4)' , / , 1 ' Integer~2 Code(2)' , / , l ' Equivalence ( Itemlist(1) , Code(l) )' , / , l ' Integer*4 Mode' , / , 1 ' Integer*2 Len' , / , 1 ' Character*80 Line' , / , 1 'C' d wrlte(6,~) ' wrote header info.' C..~ake declaration code for variable rules C
First = .True.
1 Continue C

C..Read A rule Call Read var rule Params ( First , No more ) If ( No more ) Go To 200 C..Write out FORTRAN declarations C

Call Str$trim ( Rule name , Rule name , Len ) Write ( Code lun , 101 ) (Rule name(l:len) , J=1,5 ) 101 Format ( l ' Real*4 ' , A , ' value' , ~ , 1 ' Integer*4 ' , A , ' age' , / , 1 ' Character*25 ' , A , ' stat' , / , l ' Logical*l ' , A , ' fired' , / , l ' Character~10 ' , A , ' astat' , / , 1 'C' 1 ) C

Go To 1 200 Continue P~ 755~
c C..Make declaration code for calculation rules Call Declare calc rules C..Make declaration code for analysis rules C
Last cond = ' 7 First = .True.
C 2 Continue C..Read A rule Call Read anal_rule ~arams ( First , No_more ) If ( No more ) Go To 201 C..Write out FORTRAN declarations Call Str$trim ( An cond name , An cond name , Len ) Call StrStrim ( An rule name , An rule name , ILen ) Write ( Code lun , 104 ) If ( An cond_name .ne. Last cond ) 1 Write ( Code lun , 102 ) (An cond name(l:len) ) Write ( Code lun , 103 ) (An rule name(l:Ilen) ) Last cond = An_cond name 102 Format ( 1 ; Character*25 ' , A , ' stat' 103 Format ( 1 ' Logical*l ' , A , ' fired' 1 ) 104 Format ( 1 'C' Go To 2 201 Continue C..Make declaration code for action rules C
First = .True.
C252 Continue C..Read A rule Call Read action rule Darams ( First , No more ) If ( No more ) Go To 251 C.~Write out FORTRAN declarations c ~ 3~5~9 Call Str$trim ( Ac rule name , Ac rule_name , ~Rn ) Write ( Code lun , 262 ) Ac rule nametl:len) 262 Format ( 1 ' ~ogical*1 ' , A , ' fired' , / , 1 'C' 1 ) C

Go To 252 C

251 Continue C
C...Now Write Initialization code C

Write t Code lun , 401 ) Subroutine_name tl:Srlen) 401 Format ( 1 'C', / ~
1 'C Initialize the status values.' , / , 1 'C' ~ / ~
1 ' Van status = Vss$_from ascii_time ( " '' , Now ~' , /
1 ' Van status = Vss$ to ascii time ( Now , C_Now )' , / , 1 ' Codetl) = 4 ' , / , 1 ' Code(23 = jpi~ mode' , / , l ' Itemlist(2) = %loc~Mode)' , / , 1 ' Itemlist(3) = %loc(Len)' , / , 1 ' Itemlist(4) = 0' , / , l ' sys status = sys$getjpiw ( ,,,Itemlist,,,)' , / , 1 'd Write(6,901) C_now' , / , 1 '901 Format ( / , " Running ', A , ' at " , A )' , / , 1 'C' 1 ) C.... Initialize variable rules - This will set logical flags false and C retrievs the necessary data for the rule.
C

First = .True.
402 Continue C
C

C..Read A rule C

Call Read var rule params ( First , No more ) If ( No_more ) Go To 420 Call Str$trim ( Rule_name , Rule name , Len ) Write ( Code_lun , 403 ) ( Rule name(l:~en) , J =1,4 ) 403 Format ( 1 'C', / ~
1 'C....' , A , ' rule initialization' , / , 1 'C', / ~
1 ' ' , A , ' astat Y Unknown' , / , ~t7S~

A , ' stat - Unknown' 1 ' ' , A, ' fired = .False.' C

If ( Ret_meth .eq. Current val ) Then Write ( code lun, ~04 ) Var num, (Rule name~l:len),J=1,2j 404 Format 1 ' Call Get cur data ( ', I4, ', ', A, '_value, ' ' age 1 ) Else If ( Ret_meth .eq. Discrete_avg ) Then Write ( code_lun , 405 ) Ret_time , ~ar_n (Rule name(l:len),J=1,2) 405 Format ( 1 'C', / ~
1 ' Then = Now + ', I12, /, 1 ' Call Get_disc avg data ( ', I4, ', ', ~, ' value A, '_age, Then, Now )' Else If ( Ret meth .eq. Time wt_avg ) Then Write ( code_lun , 406 ) Ret_time , Var_n (Rule_name(l:len),J=1,2) 406 Format 1 'C', / ~
1 ' Then = Now ~ ', I12, /, 1 ' Call Get time wt_avg_data ( ', I4, ', ', A, '_val , A
, '_age, Then, Now )' Else If ( Ret meth .eq. Sec last vant ~oint ) Then Write ( code_lun, 411 ) Var num, Rule_name(l:len) 411 Format 1 'C', / ~
1 ' Call Get sec last vant Point ( ', I4, ', ', A, ' , Itime stamp )' Else If ( Ret meth .eq. ACS ff_delta ) Then Write ( code lun, 407 ) Var num, Rule name(l:len) 407 Format ( 1 'C', /, 1 ' ACS status = ACS get FF delta ( ', I4, ', ', A, ' 1 ) Else If ( Ret meth .eq. ACS fb_error ) Then Write ( code lun , 408 ) Var num , Rule name(l:len~
408 Format ( 1 'C', / ~
1 ' ACS status 8 ACS get_fb_error ( ' , I4 , ' , ' , A , ' 1 ) Else If ( Ret meth .eq. PCS DMT loop goal ~ Then Write ( code_lun , 409 ) Var num , Rule name(l:len) 409 Format ( 1 'C', / ~
1 1 ACS_status - ACS_get PCS goal ( "DMT '' , ' , 1 I , ' , ' , A , ' value )' El e If ( Ret meth .eq. PCS TPA loop goal ) Then Write ( code lun , 410 ) Var num , Rule nam~ len) 410 Format ( 1 'C', / ~
1 ' ACS_status = ACS get PCS goal ( ''TPA '' , ' , 1 I , ' , ' , A , ' value )' 1 ) Else Write( Code lun , * ) 'C....Bad retrieval method' End If Write ( Code lun , 510 ) (Rule name(l:len),J=1,2) 510 Format ( 1 'd Write(6,*) '' ' , A , ' value = '' , ' , A , ' value' Go To 402 C

420 Continue C....Initialize calculation rules Call Init calc rules C....Initialize analysis rules Last_cond - ' First = .True.
440 Continue C
C..Read A rule Call Read anal_rule Params ( First , ~o more ) I~ ~ No more ) Go To 450 Call Str$trim ( An cond name , An cond name , Len ) Call Str$trim ( An rule name , An rule name , ILen ) Write ( Code lun , 441 ) ( An rule name(l:ILen) , J =1,2 ) If ( An_cond name .eq. Last cond ) Go To 440 '~i''3 Last cond = An cond name Write ( Code_lun , 442 ) ( An cond name(l:~en) , J =1,1 ) 441 Format ( 1 'C', / ~
1 'C....' , A , ' rule initialization' , / , 1 'C', / ~
1 ' ' , A , ' ~ired = .False.' 442 Format ( 1 ' ' , A , ' stat = Unknown' C
Go To 440 C

450 Continue C

C....Initlalize action rules C

First = .True.
460 Continue CC
C..Read A rule Call Read_action rule params ( First , No more ) If ( No more ) Go To 490 C

Call StrStrim ( Ac rule name , Ac rule name , Len ) Write ( Code lun , 461 ) ( Ac rule name(l:Len) , J =1,2 461 Format 1 'C', / ~
1 'C....' , A , ' rule initialization' , / , 1 'C', / ~
1 ' ' , A , ' fired = .False.' C

Go To 460 490 Continue C

500 Continue C

C...Write the rule code Write ( Code lun , 501 ) 501 Format ( 1 'C', / ~
1 ' 1 Continue' , / , 1 'C', / ~
1 ' T~is Pass fires = 0' , / , 1 'C' 1 ) C
C

C...Write out variable rule code C

~75~'-3 First = .True.
502 Continue C

C..Read A rule C

Call Read var rule Params ( First , No more ) If ( No more ) Go To 600 C

Call 5tr$trim ( Rule name , Rule name , Len ) C

If ( Age_limit .eq. Empty ) Agle limit = -365*24*60*60 C

Write ( Code_lun , 299 ) ( Rule_name(l:len),J=1,3) , Abs(Age 1 ( Rule_name(l:len),J=1,2) 299 Format ( 1 'C', / ~
1 'C....' , A , ' Rules ' , / , 1 'C', / ~
l ' If ( ' , /
1 ' 1 ( ' , A , ' astat .eq. Unknown ) .and. ' , / , 1 ' 1 ( ' , A , '_age .le. ' , I , ' ) ' , / , 1 ' 1 ) Then ' , / , 1 ' ' , A , ' astat = OK ' , / , 1 'd Write(6,*) "' , A , ' age is OK.''' , / , 1 ' This pass_fires = This ass fires + 1' , / , 1 ' End If' 1 ) Wri~e ( Code lun ,Fmt=298 ) ( Rule name(l:len),J=l Abs(Age limit) , 1 ( Rule name(l:len),J=1,2) 298 Format ( 1 'C', / ~
1 ' If ( ' , / , l ' 1 ( I , A , '_astat .eq. Unknown ) .and. ' , / , 1 ' 1 ( ' , A , ' age .gt. ' , I , ' ) ' , / , 1 ' 1 ) Then ' , ~ , 1 ' ' , A , ' astat = Too old' , / , l 'd Write(6,*) ''' , A , ' age is Too old.''' , / , 1 ' This ~ass fires = This pass_fires + l' , / , End IP ' 1 ) C

~rite( code lun , 505 ) (Rule_name(l:len),J=1,3) , Log_opl , 1 Rule name(l:len) , Statusl , Rule name(l:len) , 1 Statusl , Rule name(l:len) 505 Format ( 1 'C', / ~

75~3 1 ' If ( ' , / , 1 ' 1 ( . not . ' , A , ' _ f ired ) .and. ' , / , 1 ' 1 ( ' , A , ' astat .eq. OK ) .and. ' , / , 1 ' 1 ( ' , A , ' value ' , A4 , ' ' , F12.5 , ' ) ' , 1 ' 1 ) Then ' , / , 1 ' ' , A , ' stat - " ', A25 ,' " ' , / , 1 'd Write(6,~) " ' , A , ' stat is ' , A ,'''' , / , 1 ' ' , A , ' fired = .True.' , / , 1 ' This ~as~ fires = This pass_fires + 1' , / , 1 ' ~nd If' 1 ) C

Write( code lun , 506 j (Rule name(l:len),J=1,3) , i-JOg_ op8 , 1 Rule name(l:len) , Status8 , Rule name(l:len) , 1 Status8 , Rule name(l:len) 506 Format ( 1 'C' ~ / ~
1 ' If ( ' , / , 1 ' 1 ( .not. ' , A , ' fired ) .and. ' , / , 1 ' 1 ( ' , A , ' astat .eq. OX ) .and. ' , / , 1 ' 1 ( ' , A , I_value ' , A4 , ' ' , F12.5 , ' ) ' , 1 ' 1 ) Then ' , / , 1 ' ' , A , ' stat = " ', A25 ,'''' , ~ , 1 'd Write(6,*) " ' , A , '_stat is ' , A ,'''' , j , 1 ' ' , A , ' fired = .True.' , / , 1 ' This Pass fires = This pass fires + 1' , / , 1 ' End If' 1 ) C

If ( Status2 .ne. ' ' ) Then C

Write( code_lun , 508 ) (Rule name(l:len),J=1,3) , Log_op2 , 1 Rule name(l:len) , Log op3 , Limit3 , 1 Rule_name(l:len) , Status2 , Rule name(l:len) , 1 Status2 , Rule name(l:len) 508 Format ( 1 'C', / ~
1 ' If ( ' , / , 1 ' 1 ( .not. ' , A , ' fired ) .and. ' , / , 1 ' 1 ( ' , A , ' astat .eq. OK ) .and. ' , / , 1 ' 1 ( ' , A , ' value ' , A4 , ' ' , F12.5 , ' ) .and 1 ' 1 ( ' , A , ' value ' , A4 , ' ' , F12.5 , ' ) ' , 1 ' 1 ) Then ' , / , 1 ' ' , A , ' stat = ' ", A25 ,'''' , / , 1 'd Write(6,*) " ' , A , ' stat is ' , A ,'''' , / , 1 ' ' , A , ' fired = .True.' , / , 1 ' This pass fires = This pass fires + 1' , / , 1 ' End If' 1 ) 7S5~
End If I ( Status4 .ne. ' ' ) Then Writet code lun , 509 ~ (Rule name(l:len),J=1,3) , Log_op4 , 1 Rule_name(l:len) , Log_op5 , Limit5 , 1 Rule name(l:len) , Status4 , Rule_name(l:len) , 1 Status4 , Rule name(l:llen) 509 Format ( 1 'C', / ~
1 ' If ( ' , / , 1 ' 1 ( .not. ' , A , ' fired ) .and. ' , / , l ' 1 ( ' , A , '_astat .eq. OK ) .and. ' , / , 1 ' 1 ( ' , A , '_value ' , A4 , ' ' , F12.5 , ~ ) .and 1 ' 1 ( ' , A , '_value ' , A4 , ' ' , F12.5 , ' ) ' , l ' 1 ) Then ' , / , 1 ' ' , A , '_stat = ''', A25 ,'''' , / , 1 'd Write(6,*) ''' , A , '_stat is ' , A ,'''' , / , 1 ' ' , A , '_fired = .True.' , / , 1 ' This pass_fires - This pass_fires + 1' , / , 1 ' End If' 1 ) End If If ( Status6 .ne. ' ' ) Then Write( code_lun , 511 ) (Rule_name(l:len),J=1,3) , Log_op6 , 1 Rule name~l:len) , Log_op7 , Limit7 , 1 Rule_name~l:len) , Status6 , Rule_name(l:len) , 1 Status6 , Rule_name(l:len) 511 Format ( 1 'C', / ~
1 ' If ( ' , / , 1 ' 1 ( .not. ' , A , ' fired ) .and. ' , / , 1 ' 1 ( ' , A , ' astat .eq. OK ) .and. ' , / , 1 ' 1 ( ' , A , ' value ' , A4 , ' ' , F12.5 , ' ) .and 1 ' 1 ( ' , A , ' value ' , A4 , ' ' , F12.5 , ' ) ' , 1 ' 1 ) Then ' , / , 1 ' ' , A , ' stat = ''', A25 ,'''' , / , 1 'd Write~6,*) "' , A , ' stat is ' , A ,' "' , / , 1 ' ' , A , ' fired = .True.' , / , 1 ' ~his ~ass fires = This Dass fires + 1' , / , 1 ' End If' 1 ) End If C

Go To 502 C

1.2 .~7~A59 6 0 0 Continue r C...Write out calculation rule code Call Write calc_rules C

C...Writ~ out analysis rule code First = .True.
C

602 Continue C

C..~ead A rule Call Read anal rule params ( First , No_more j I~ ( No more ) ~o To 700 C
Call Str$trim ~ An cond_name , An cond name , Len Call Str$trim ( An rule name , An rule_name , ILen ~
Write ( Code_ lun , 699 ) (An rule name(l:Ilen),j=1,2) 699 Format ( 1 'C', /, 1 'C....' , A , ' Rules ' , / , 1 'C', /, 1 ' If ( ' , / , 1 ' 1 ( .not. ' , A , ' fired ) .and. ' 1 ) If ( An rulel .ne. ' ' ) Then Call Str~trim ( An rulel , An rulel , Len ) C

If ( An notl .eq. '.NOT.' ) Then Write( code lun , 1001 ) An rulel(l:len) End If 1001 Format ( 1 ' 1 ( .not. ( ' , A , ' stat .EQ. Unknown ) ) .and.' 1 ) Write( code lun , 608 ) An notl , An rulel(l:len) , 1 An statusl 608 Format ( 1 ' 1 ( ' , A , ' ( ' , A , ' stat .EQ. ''' , A , ' .and.' 1 ) End If C

If ( An rule2 .ne. ' ' ) Then Call Str$trim ( An rule2 , An rule2 , Len ) C

If ( An nGt2 .eq. '.NOT.' ) Then Write( code lun , 1001 ) An rule2(1:len) End If Write( code lun , 603 ) An_not2 , An rule2(1Olen) , 1 ~n status2 509 Fo~mat ( 1 ' 1 ( ' , A , ' ( ' , A , ' stat .EQ. ''' , A , ' .and.' 1 ) End If C

If ( An_rule3 .n ' ' ) Then Call StrStrim ( An rule3 , An_~lle3 , Len ) C

If ( An not3 .eq. '.NOT.' ) Then Write( code lun , 1001 ) An_rule3(1:len) End If Write( code lun , 610 ) An not3 , An rule3(1:1en) , 1 An status3 610 Format ( 1 ' 1 ( ' , A , ' ( ' , A , ' stat .EQ. ''' , .~ , ' .and.' 1 ) End If If ( An rule4 .ne. ' ' ) Then Call Str$trim ( An rule4 , An_rule4 , Len ) If ( An not4 .eq. '.NOT..' ) Then Write( code lun , 1001 ) An rule4(1:1en) End If Write( code lun , 611 ) An not4 , An rule4(1:len) , 1 An_status4 611 Format ( 1 ' 1 ( ' , A , ' ( ' , A , ' stat .EQ. ''' , A , ' .and.' 1 ) End If I~ ( An rule5 .ne. ' ' ) Then Call Str$trim ( An rule5 , An rule5 , Len ) If ( An not5 .eq. '.NOT.' ) Then Write( code lun , 1001 ) An rule5(1:len) End I f Write( code lun , 612 ) An not5 , An rule5(1:1en) , 1 An status5 612 Eormat ( 1 ' 1 ( ' , A , ' ( ' , A , ' stat ~EQ. ''' , A , ' .and.' 1 ~3755~3 End If Call StrStrim ( An cond name , An cond name , Len ) Write ( Code lun , 613 ) 1 fAn_cond name(l:len),j=l,l) , An end status , 1 (An cond name(l:len),j=l,l) , An end_status , 1 (An rule name(l:Ilen),j=l,l) 613 Format ( 1 ' 1 ( .True. ) ' , /
1 ' 1 ) Then ' , / , 1 ' ' , A , '_stat = ''', A25 ,'''' , / , 1 'd Write(6,*) ''' , A , ' stat is ' , A ,;'~
1 ' This Dass fires = This Dass fires ~ ~' , / , 1 ' End If' 1 ) C

Go To fiO2 700 Continue CC
C...Write out action rule code First = .True.
702 Continue C

C..Read A rule Call Read action rule params ( First , No more ) If ( No more ) Go To 800 C
Call Str$trim ( Ac rule name , Ac rule_name , Len ) Write ( Code_lun , 799 ) (Ac_rule_name(l:len),j=1,2) 799 Format ( 1 'C', /, 1 'C....' , A , ' Rules ' , / , 1 'C', /
1 ' If ( ' , / ~
1 ' 1 ( .not. ' , A , '_fired ) .and. ' 1 ) Call StrStrim ( Ac_rulel , Ac rulel , Len ) C

Write( code lun , 708 ) Ac rulel(l:len) , 1 Ac statusl 708 Format ( 1 ' 1 ( ' , ' ( ' , A , ' stat .EO. ''' , A , ' " ) ) 1 ) ..
C

~7.~,5~

Call Str$trim ( Ac rule name , Ac rule name , Len ) Write ( Code lun , 713 ) (Ac :rule name(l:len),j-1,2) 713 Format ( 1 ' 1 ) Then ' , / , 1 'd Write(6,*) ''Doing action rule ' , A , '''' , / , 1 ' ' , A , ' ~ired = .True.' , / , 1 ' This_pass fires = This ~ass fires + 1' 1 ) Call Str$trim ( Ac data_line , Ac_data_line , LRn ) If ( Iac type .eq. Exec fort statement ) Then Write ( code_lun , 714 ) Ac data_line(l:Len) 714 Format ( 1 ' ' , A
Else If ( Iac_type .eq. Exec_dcl procedure ) Then Subprocess name(L sp:l4) = Ac rule name Call StrStrim ( Subprocess name , Subprocess name , ILen ) Write ( code lun , 715 ) Ac data line(l:Len) , 1 Subprocess name(l:Ilen) 715 Format ( 1 ' Call Lib$spawn ( "Q' , A , "',,,,'" , A , '' ,....
Else If ( Iac type .eq. Send vaxmail msg ) Then Call StrStrim ( Ac_rule name , Ac rule name , Len ) Call Str$trim ( Directory , Directory , L dir ) Subprocess_name(L sp 14) - Ac rule name Call Str$trim ( Subprocess name , Subprocess_name , ILen ) Write(Code lun , 788 ) 788 ~ormat ( 1 ' If ( Mode .eq. Jpi$k other ) Then' Write ( code_lun , 718 ) Directory(l:L dir) , 1 Ac rule name(l:len) , 1 Subprocess name(l:Ilen) 718 Format ( 1 ' Call Lib$spawn ( "~' , A , A , '.mailmsg'',,,,''' , A
,,, ,,,, ) ' Write(Code lun , 787 ) 787 Format ( 1 ' Else if ( Mode .eq. JpiSk interactive ) Then' 1 ) Write ( Code_lun , 789 ) Directory(l:L dir) I
1 Ac rule name(l:len) , Next label, Next label Next label = Next label + 1 789 Format ( 1 ' Open(ll,File='" , A , A , '.mailmsg'' ,Status= "old'' ~29'7S~3 1 ' Do J ~ 1,3 ' ,/, 1 ' Read ( 11 , ''(A) " ) Line' ,/, 1 ' End Do' ,/, 1 ' Do J ~ 1,60' ,~, 1 ' Re~d (11 , ''~A) " , End = ', I4, ' ) Line ' ,/, 1 ' Write(6,~) Line ' ,/, 1 ' End Do' ,/, 1 I4 ,' Continue' ,/, 1 ' Close ( 11 ) ' Write(Code lun , 786 ) 786 Format ( 1 ' End If' 1 ) C

Else Write ~ osde_lun , 716 ) 716 Eormat ( 1 ' Write~6,*) "Bad Action type.' "
End If C

Write ( Code lun , 717 ) 717 Format ( 1 ' End If' 1 ) C

Go To 702 C

800 Continue C

Write( Code_lun , 9998 ) 9998 1 'd Write(6,~) This Pass fires," rules fired this pass.' 1 ' If ( This ~ass f~res .gt. 0 ) Go To 1' , / , 1 'C', / ~
1 ' Return' , / , 1 ' C~ll FdvSPutl(' Generating Expert System code.... Done.') Return End Copyright ~c) 1987 E.I. DuPont de Nemo~rs ~ Co., all rights reserved 5~3 Thus, steps such as those listed above will produce (in this example) FORTRAN sourc~ code which defines an expert system including rules as defined by the user.
This source code can then be compiled and linked, ;lS
described above, to provide an expert procedure which is callable at run-time. This expert procedure is tied into the supervisor procedure, as described above, by inserting an appropriate ~all into the user program section of one of the blocks in the supervisor procedure. Thus, the expert procedure can be called under specific circumstances (e ~. if selection among several possible manipulated variables must be made), or may optionally be called on every pass of the base cycle procedure, or at fixed time intervals, or according to any of the other options set forth above.
As will be recognized by those skilled in the art, the innovative concepts described in the present application can be modified and varied over a tremendous range of applications, and accordingly their scope is not limited except by the allowed claims.

Claims (81)

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 one or more of said sensors and in accordance with one or more control parameters; and (3) running a process supervisor procedure, comprising one or more software modules, for selectively defining one or more of said control parameters for said process controller, said process supervisor procedure also calling on at least one expert subprocedure which uses a knowledge base and inference structure relevant to the process.

2. 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;
(3) running a process supervisor procedure for selectively defining one or more of said control parameters for said process controller, said supervisor procedure also calling on at least one expert subprocedure which uses a knowledge base and inference structure relevant to the process; and (4) using an historical database containing at least one time-stamped data regarding the process, wherein said supervisor procedure or said expert subprocedure fetch at least one value from said historical database.

3. 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;
(3) running a process supervisor procedure for selectively defining one or more of said control parameters for said process controller, said supervisor procedure also calling on at least one expert subprocedure which uses a knowledge base and inference structure relevant to the process; and (4) selectively presenting to a user a functional structure for a new rule for said expert subprocedure and/or a functional structure corresponding to the user input from which a current version of said expert subprocedure was generated, and selectively compiling one or more user inputs from said functional structure into a new version of said expert subprocedure.

4. 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;
(3) running a process supervisor procedure, comprising one or more software modules, for selectively defining one or more of said control parameters for said process controller, said process supervisor procedure also calling on at least one expert subprocedure which uses a knowledge base and inference structure relevant to the process;

(4) selectively presenting functional structures, to a user, for a new rule for said expert subprocedure and/or a functional structure corresponding to the user input from which a current version of said expert subprocedure was generated, and selectively compiling one or more user inputs from said functional structure into a new version of said expert subprocedure;
and (5) selectively presenting functional structures, to a user, for a new software module for said process supervisor procedure and/or a functional structure corresponding to a user input from which a current software module of said process supervisor procedure was generated, and selectively loading the user input from said functional structure to be used by said process supervisor procedure.

5. 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, using a process controller, one or more of said actuators in accordance with signals received from one or more of said sensors and in accordance with one or more control parameters, (3) wherein at least one of said control parameters is redefined in accordance with output(s) which is selectively provided by at least one expert subprocedure which includes a knowledge base and inference structure relevant to the process, and wherein said expert subprocedure fetches at least one value of a process variable from an historical database containing at least one time-stamped data regarding the process.

6. 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 one or more of said sensors and in accordance with one or more control parameters, (3) wherein at least one of said control parameters is redefined in accordance with outputs which is selectively provided by at least one expert subprocedure which includes a knowledge base and inference structure relevant to the process; and (4) selectively presenting functional structures, to a user, for a new rule for said expert subprocedure and/or a functional structure corresponding to the user input from which a current version of said expert subprocedure was generated, and selectively compiling one or more user inputs from said functional structure into a new version of said expert subprocedure.

7. A computer-based system for controlling a substantially continuous process, comprising:
(a) one or more sensors connected to sense conditions in the process, and one or more actuators connected to change conditions in the process;
(b) a process controller connected to directly receive sense data generated by at least one of said sensors, and connected to control one or more of said actuators in accordance with said sensor data and in accordance with respective control parameters;
(c) process supervisor means comprising one or more software modules, for communicating said control parameters to said process controller;
(d) at least one expert subprocedure means which uses a knowledge base and inference structure relevant to the process, and which is callable by said process supervisor means;
wherein said process supervisor means has a maximum iteration period significantly longer than the maximum iteration period of said process controller.

8. A computer-based system for controlling a substantially continuous process, comprising:
(a) one or more sensors connected to sense conditions in the process, and one or more actuators connected to change conditions in the process;
(b) a process controller connected to receive sense data generated by at least one of said sensors, and connected to control one or more of said actuators in accordance with said sensor data and in accordance with respective control parameters;
(c) process supervisor means comprising one or more software modules, for communicating said control parameters to said process controller;
(d) at least one expert subprocedure means which uses a knowledge base and inference structure relevant to the process, and which is callable by said process supervisor means;
(e) an historical database containing at least one time-stamped data regarding the process;
wherein said process supervisor means has a maximum iteration period significantly longer than the maximum iteration period of said process controller.

9. A computer-based system for controlling a substantially continuous process, comprising:
(a) one or more sensors connected to sense conditions in the process, and one or more actuators connected to change conditions in the process;
(b) a process controller connected to receive sense data generated by at least one of said sensors, and connected to control one or more of said actuators in accordance with said sensor data and in accordance with respective control parameters;
(c) process supervisor means comprising one or more software modules, connected to communicate said respective control parameters to said process controller;
(d) at least one expert subprocedure means which uses a knowledge base and inference structure relevant to the process, and which is callable by said process supervisor means; and (e) build-expert means which is configured to:
(1) upon command, selectively present to a user a functional structure for a new rule for said expert subprocedure means;
(2) upon command, selectively present to a user a functional structure corresponding to the user input from which a current version of said expert subprocedure means was generated;
(3) and selectively to compile one or more user inputs from said functional structure into a new version of said expert subprocedure means;
wherein said process supervisor means has a maximum iteration period significantly longer than the maximum iteration period of said process controller.

10. A computer-based system for controlling a substantially continuous process, comprising:
(a) one or more sensors connected to sense conditions in the process, and one or more actuators connected to change conditions in the process;
(b) a process controller connected to receive sense data generated by at least one of said sensors, and connected to control one or more of said actuators in accordance with said sensor data and in accordance with respective control parameters;
(c) process supervisor means comprising one or more software modules, for communicating said control parameters to said process controller;
(d) at least one expert subprocedure means which uses a knowledge base and inference structure relevant to the process, and which is callable by said process supervisor means; and (e) build-expert means which is configured to:
(1) upon command, selectively present to a user a functional structure for a new rule for said expert subprocedure means;
(2) upon command, selectively present to a user a functional structure corresponding to the user input from which a current version of said expert subprocedure means was generated;
(3) and selectively to compile one or more user inputs from said functional structure into a new version of said expert subprocedure means; and (f) build-supervisor means which is configured to:
(4) upon command, selectively present to a user a functional structure for a new software module for said process supervisor means;
(5) upon command, present to a user a functional structure corresponding to a user input from which a current software module of said process supervisor means was generated;
(6) and selectively to load the user input from said functional structure to be used by said process supervisor means;
wherein said process supervisor means has a maximum iteration period significantly longer than the maximum iteration period of said process controller.

11. The method of Claim 1, wherein said knowledge base and inference structure of step (3) comprise the step of running a substantially real-time expert control procedure.

12. The method of Claim 1, wherein said process controller of step (2) comprises the step of controlling said actuators substantially continuously in real time, and said expert subprocedure of step (3) comprises the step of not running continuously in real time.

13. The method of Claim 1, wherein said process controller of step (2) comprises the step of using real-time logic, and said expert subprocedure of step (3) comprises the step of recurrently running as a batch process.

14. The method of Claim 1, wherein said process controller of step (2) uses analog logic for controlling.

15. The method of Claim 1, wherein respective data definitions comprise the step of defining said one or more software modules of step (3), including pointers to procedures which will carry out a respective function, and, for at least some of said software modules, parameters to be passed to said procedures pointed to.

16. The method of Claim 1, wherein one or more of said control parameters of step (2) comprise the step of including goals of said process controller.

17. The method of Claim 1, wherein said process controller of step (2) and said process supervisor procedure of step (3) comprise the step of using processes running on the same computer system.

18. The method of Claim 1, wherein said process controller of step (2) and said process supervisor procedure of step (3) comprise the step of being part of the same software system.

19. The method of Claim 2, wherein said knowledge base and inference structure of step (3) comprise the step of defining a substantially real-time expert control procedure.

20. The method of Claim 2, wherein one or more of said control parameters of step (2) comprise the step of including goals of said process controller.

21. The method of Claim 3, wherein said functional structure of step (4) comprises the step of including user-alterable portions which appear differently to said user than do other portions of said functional structure.

22. The method of Claim 3, wherein said step of presenting functional structures includes presenting standardized data interface definitions such that the user can specify data having one of plural pre-defined temporal characteristics.

23. The method of Claim 3, wherein said knowledge base and inference structure of step (3) comprise the step of defining a substantially real-time expert control procedure.

24. The method of Claim 3, wherein one or more of said control parameters of step (2) comprise the step of including goals of said process controller.

25. The method of Claim 4, wherein said functional structure presented to the user in step (4) comprises the step of using a substantially natural language format.

26. The method of Claim 4, wherein said functional structure presented to the user in step (4) comprises the step of using a substantially natural language format which is readily understandable by a user who is technically skilled in a predetermined art but who is not necessarily competent in any computer language.

27. The method of Claim 4, wherein only restricted portions of said functional structure of step (4) comprises the step of allowing for user-alterability.

28. The method of Claim 4, wherein said user-alterable portions of said functional structures appear differently to said user than do other portions of said functional structures.

29. The method of Claim 4, wherein said step of presenting functional structure in step (4) further comprises the step of presenting standardized data interface definitions such that the user can specify data having one of plural pre-defined temporal characteristics.

30. The method of Claim 4, wherein said knowledge base and inference structure of step (3) comprises the step of defining a substantially real-time expert control procedure.

31. The method of Claim 4, wherein respective data definitions comprise the step of defining said one or more software modules of step (3), including pointers to procedures which will carry out a respective function, and, for at least some of said software modules, parameters to be passed to said procedures pointed to.

32. The method of Claim 4, wherein respective data definitions comprise the step of defining said one or more software modules of step (3), including pointers to procedures which will carry out a respective function, wherein most of said procedures pointed to correspond generally to one of a limited number of procedure types, and wherein at least some of said procedures pointed to also containing further pointers to procedures which do not correspond generally to any one of said limited number of procedure types, and, for at least some of said software modules, parameters to be passed to said procedures pointed to.

33. The method of Claim 4, wherein one or more of said control parameters of step (2) comprise the step of including goals of said process controller.

34. The method of Claim 5, wherein said knowledge base and inference structure of step (3) comprise the step of defining a substantially real-time expert control procedure.

35. The method of Claim 5, wherein said process controller of step (2) further comprises the step of operating substantially continuously in real time, and wherein said expert subprocedure of step (3) comprises the step of not operating continuously in real time.

36. The method of Claim 5, wherein said process controller of step (2) comprises the step of using real-time logic, and wherein said expert subprocedure of step (3) comprises the step of recurrently running as a batch process.

37. The method of Claim 5, wherein said process controller uses analog logic for controlling.

38. The method of Claim 6, wherein said functional structure presented to the user in step (4) comprises the step of using a substantially natural language format which is readily understandable by a user who is technically skilled in a predetermined art but who is not necessarily competent in any computer language.

39. The method of Claim 6, wherein only restricted portions of said functional structure of step (4) comprises the step of allowing for user-alterability.

40. The method of Claim 6, wherein said functional structure of step (4) comprises the step of including user-alterable portions which appear differently to said user than do other portions of said functional structure.

41. The method of Claim 6, wherein said step of presenting functional structures includes presenting standardized data interface definitions such that the user can specify data having one of plural pre-defined temporal characteristics.

42. The method of Claim 6, wherein said knowledge base and inference structure of step (3) comprise the step of defining a substantially real-time expert control system.

43. The system of Claim 7, wherein said process supervisor means of element (c) uses means for cycling, and said process controller of element (b) runs substantially in real-time.

44. The system of Claim 7, wherein said knowledge base and inference structure of element (d) define a substantially real-time expert control system.

45. The system of Claim 7, wherein said process controller operates substantially continuously in real time, and said expert subprocedure means of element (d) does not operate continuously in real time.

46. The system of Claim 7, wherein said process controller comprises real-time logic, and said expert subprocedure means of element (d) is recurrently run as a batch process.

47. The system of Claim 7, wherein said controller is an analog controller.

48. The system of Claim 7, wherein said one or more software modules of element (c) are defined by respective data definitions, including pointers to first means for carrying out a respective function, and, for at least some of said software modules, parameters to be passed to said first means pointed to.

49. The system of Claim 7, wherein one or more of said control parameters of element (b) use goals of said process controller.

50. The system of Claim 7, wherein said process controller of element (b) and said process supervisor means of element (c) comprise processes running on the same computer system.

51. The system of Claim 7, wherein said process controller of element (b) and said process supervisor means of element (c) are both respective parts of the same software system.

52. The system of Claim 8, wherein said knowledge base and inference structure of element (d) define a substantially real-time expert control system.

53. The system of Claim 8, wherein said one or more software modules of element (c) are defined by respective data definitions, including pointers to first means for carrying out a respective function, and, for at least some of said software modules, parameters to be passed to said first means pointed to.

54. The system of Claim 8, wherein said one or more software modules of element (c) are defined by respective data definitions, including pointers to first means for carrying out a respective function, wherein most of said first means pointed to correspond generally to one of a limited number of procedure types, and wherein at least some of said first means pointed to also containing further pointers to second means which do not correspond generally to any one of said limited number of procedure types, and, for at least some of said software modules, parameters to be passed to said first means pointed to.

55. The system of Claim 8, wherein one or more of said control parameters of element (b) use goals of said process controller.

56. The system of Claim 9, wherein said functional structure of element (1) presented to the user has a substantially natural language format which is readily understandable by a user who is technically skilled in a predetermined art but who is not necessarily competent in any computer language.

57. The system of Claim 9, wherein only restricted portions of said functional structure of element (1) is user-alterable.

58. The system of Claim 9, wherein said functional structure of element (1) comprises user-alterable portions which appear differently to said user than do other portions of said functional structure.

59. The system of Claim 9, wherein said functional structure of element (1) uses standardized data interface definitions such that the user can specify data having one of plural pre-defined temporal characteristics.

60. The system of Claim 9, wherein said knowledge base and inference structure of element (d) define a substantially real-time expert control system.

61. The system of Claim 9, wherein said one or more software modules of element (c) are defined by respective data definitions, including pointers to first means for carrying out a respective function, and, for at least some of said software module, parameters to be passed to said first means pointed to.

62. The system of Claim 9, wherein one or more of said control parameters of element (b) use goals of said process controller.

63. The system of Claim 10, wherein said build-supervisor means of element (f) does not allow data corresponding to fresh user inputs to become actively accessed by said process supervisor means of element (c) until a validation run has been performed.

64. The system of Claim 10, wherein said process supervisor means of element (c) uses means for cycling, and said process controller of element (b) runs substantially in real-time.

65. The system of Claim 10, wherein said functional structure of element (1) presented to the user has a substantially natural language format which is readily understandable by a user who is technically skilled in a predetermined art but who is not necessarily competent in any computer language.

66. The system of Claim 10, wherein only restricted portions of said functional structure of element (1) is user-alterable.

67. The system of Claim 10, wherein said functional structure of element (1) comprises user-alterable portions which appear differently to said user than do other portions of said functional structure.

68. The system of Claim 10, wherein said knowledge base and inference structure of element (d) define a substantially real-time expert control system.

69. The system of Claim 10, wherein said process controller of element (b) operates substantially continuously in real time, and said expert subprocedure means of element (d) does not operate continuously in real time.

70. The system of Claim 10, wherein said controller is an analog controller.

71. The system of Claim 10, wherein said one or more software modules of element (c) are defined by respective data definitions, including pointers to first means for carrying out a respective function, and, for at least some of said software modules, parameters to be passed to said first means pointed to.

72. The system of Claim 10, wherein said one or more software modules of element (c) are defined by respective data definitions, including pointers to first means for carrying out a respective function, wherein most of said means pointed to correspond generally to one of a limited number of procedure types, and wherein at least some of said first means pointed to also containing further pointers to second means which do not correspond generally to any one of said limited number of procedure types, and, for at least some of said software modules, parameters to be passed to said first means pointed to.

73. The system of Claim 10, wherein one or more of said control parameters of element (b) use goals of said process controller.

74. The system of Claim 10, wherein said process controller of element (b) and said process supervisor means of element (c) comprise processes running on the same computer system.

75. The system of Claim 10, wherein said process controller of element (b) and said process supervisor means of element (c) are both respective parts of the same software system.

76. The method of claim 1, wherein said expert subprocedure comprises the steps of:
(1) executing upon command from said process supervisor procedure;
(2) running under the control of a timing procedure;
and (3) preventing said process supervisor procedure from taking any further action until execution of said expert subprocedure is completed.

77. 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 w.ith signals directly received from one or more of said sensors and in accordance with one or more control parameters;
(3) running a process supervisor procedure, comprising one or more software modules, connected to define one or more of said control parameters for said process controller; and (4) calling by said process supervisor procedure an expert subprocedure which uses a knowledge base and inference structure relevant to the process for the steps of:
(i) defining one or more of said control parameters for said process controller; or (ii) controlling the defining of one or more of said control parameters by said process supervisor procedure.

78. The method of Claim 77, wherein step (4) comprises a step of using two or more expert subprocedures, each having its own knowledge base.

79. The method of Claim 77, wherein the step of using at least two expert subprocedures comprises the step of using a common inference structure for at least two of said expert subprocedures.

80. A computer-based method for operating a substantially continuous process, comprising the step 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, using a process controller, one or more of said actuators in accordance with signals directly received from one or more of said sensors and in accordance with one or more control parameters, (3) wherein at least one of said control parameters is redefined in accordance with output(s) which is selectively provided by at least one expert subprocedure which uses a knowledge base and inference structure relevant to the process.

81. 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 connect to change conditions in the process;
(2) controlling one or more of said actuators with a process controller in accordance with signals directly received from one or more of said sensors and in accordance with one or more control parameters; and (3) running a process supervisor procedure, for selectively defining one or more of said control parameters for said process controller, said process supervisor procedure selectively using an expert subprocedure which uses a knowledge base and inference structure relevant to the process.