CA2030552A1 - Batch process control using expert systems - Google Patents

Abstract

Batch process (700) control is improved by defining a step endpoint condition (702) in an expert system (900) knowledge base;
using the expert system (900) to monitor for the occurrence of the endpoint in the batch process; and triggering a change in a batch process condition when the endpoint is found. Preferably, the expert system (900) and the batch process condition change are implemented as modules which execute under control of timing and sequencing functions in a supervisory control system, and the change affects a setpoint (or other control objective) in a continuous control system. Multiple instances of modular expert systems allow parallel process units to be easily controlled.

Description

WO ~0/1236~ P~/US~ 38~4 TCH PROCE5S CONTROL USI~6 EXPE~T SYSTEMS

BACK~ROUND OF THE INVENTION

1. Field of the invention The present invention relates generally to monitoring and control of batch processes, particularly chemical processes, and morP spec;fically to expert systems used in batch process control.

2. Associated Applications The present application is associated with the following United S~ates Patent Applications (and all non-U.S. patent 2pplications claiming priority therefrom) as follows:

(1) Serial No. 103,050, filed 9/30/87 (2) Serial No. 102,832, filed 9/30/87 (3~ Serial No. 103,014, filed 9/30/87 (4) Serial No. 103,118, filed 9/30/87 ~5) Serial No. 103,047, filed 9/30/87 (6) Serial No. 103,124, ~iled 9/30/87 Each of these applications and corresponding non-U.S.
applications is incorporated herein in its entirety.

3. Related Art a. Batch Processes A batch process is operated by moving the process through a set of steps. Each step requires different .

WO 90/1~368 P~/U~;90/01854 ... -?~ J

conditions in the process, and usually follows a pre-defined sequence or rec;pe.
Cooking is a typ;cal batch pr~cess. The cooking recipe spec;f;es process conditions during each step of the batch process (for example, oven temperature), as well as criteria for determining when the step has ended or been completed (for example, s;mmer for 20 minutes).
A "true" or "class;c" batch process begins at one point in time with ingredients or raw materials, and finishes later in time with final products. Such true or classic batch processes are used to make many valuable products, including, for example, pharmaceuticals and pest;c;des.
Also, some very impnrtant "continuous" processes, such as the refining of crude oil, use a repetitive cycle of steps, which cycle of steps is similar to a batch process.
Moreover, all continuous processes use a sequence of steps to start the continuous process up and to shut the process down.
These start up and shut down portions of such continuous processes constitute individual batch processes.
Thus, it can be appreciated that batch processes and batch processing play a very important role in all manufac-turing~ even in nominally continuous processes.

b. Batch Process Control Batch process control ;s used to automate the operation of batch processes. To csntrol a batch process, two basic functions are needed.
First, during each step, a batch process condition(s) must be maintained as close as possible to the desired condition(s~ for that step. As used herein, the specifica-tion of the desired process condition(s3 is referred to as the "control objective(s3." The inventor believes that maintaining control objectives of a batch process usually WV 90/12368 P~r/us9û/01854 requires the methods and functions of a continuous process control system. Some typical, conventional means or ways of providing continuous process control funct;ons are distri-buted control systems and single loops controllers, as described below.
The second basic function is that a batch process control system must be able to determine when tu change steps during the batch process. It must also be able to change control objectives to the ~alues required by the next step of the batch process. As used herein, when a step of a batch process is over, we say the step has reached its "endpoint."
A general discussion of batch process control, and the control systems which provide batch process control, is found in ~3~h Process Automation, by Howard P. Rosenoff and Asish Ghosh, Van Nostrand Reinhold Co., New York, 1987 which is incorporated herein in its entirety.

c. Endpoints in Batch Processes An endpoint of a batch process is usually defined either by time or by process conditions.
A time endpoint is defined as the amount of time a step is to take or last. It is analogous to the cooking time for a soup. A batch process recipe defines how long the step is to last in time. When that time has elapsed, the step is over. In other words, the step has reached its endpoint. At this point, conditions need to be chan~ed to the next step of the batch process. For exampl~, continuing the cooking analogy, the next step of preparing the soup would be turning the stove off.
An sndpoint can also be defined by one or more process conditions .
A process condition endpoint is the condition(s) that the batch process must obtain or meet in order for the step , ~

WO ~0/123G8, PT/US90/01854 ' ;j,. .. ..

-4-to be over or completed. Continuing the cooking analogy, this is analogous to baking a cake until a toothpick comes out clean. The amount of time required to complete the step may vary, but the step is over when that process condition(s) is satisfied or met. In the cake analogy, when the endpoint is detected by the tooth pick test, conditions need to changed by taking the baked cake out of the oven and turning the oven off.
Endpoint detection and/or timing in ba~ch processes has been automated for many years using mechanical devices such as drum timers and relays. Simple process condition end-points can be detected, for example, using a limit switch which is set to trip when a tank is 90% full. These func-tions are now primarily done by computer-based programmable logic controllers (called PLCs). Some PLC's can detect batch process endpoints when 2n analog input value crosses a limit threshold. Although current PLCs are often based on powerful microcomputers, their functions are still generally designed to emulate the mechanical devices which preceded them. This conventional approach tends to limit the methods of endpoint detection and/or t;ming to rather simple definitions sf the endpoint.
In many batch processes, however, step endpoints cannot be determined using such simple definitions. For example, a step in a process may not end until a complex endpoint definition made up of several elapsed times or conditions have been met. For example, this may occur when a feed tank has filled, the temperature has risen to its set point and has remained there for some predetermined time, and the next tank has emptied.
In particular, to start-up a large (and expensive) nominally continuous process, fairly complex condi~ions often need to be satisfied before the next start-up step can be entered. Detecting these more complex endpoint definitions , , ,, . .
' ' VVO ~OJ12368 P~/US9~/01854 ,, s ~

has generally required people (called process operators) to look at and evaluate the condition(s) in the process. The inventor believes that an effective way to automate the end point detection would be very valuable and would significant-ly advance the present state of the art o~ batch process control technology.

d. Changlng steps in a batch process The second function of a batch process control system is to make changes in control objectives once a step endpoint is reached.
Control objectives can be "analog" values, like a controller setpoint or gain constant. The most common change made to an analog value is an absolute change, in which the value is set to some pre-defined absolute number. In the cooking situation, this is analogous to setting the oven temperature to 350 degrees.
Analog values can also be incrementally changed, by adding a fixed amount to their current value. In the cooking situation, this is analogous to turning the oven temperature down by 20 degrees.
Control objectives can also be defined for "digital"
(on/off) V31UeS, which only have two (binary) st~tes.
Fxamples are on/off switches, valves that open or close, and so on.
As used herein, the ordered collection of the changes needed at the beginning o~ each step, and the endpoint definitions for each step, form or constitute a "recipe" or "sequence" for a batch prucess.
.

, .

WO 90~1~368 PCI~/US90/03B5'1 ~ J ~ J

e. Changing Control Objectiv2s Batch process control systems can change control objectives. However, such conventional process control systems are generally limited in the way changes can be defined and implemented. Of the conventional systems, the most common is the PLC. PLCs are reliable and easy to use, but their functionality is usually very strictly defined.
Some higher level batch control systems allow batch process recipes to be defined with setpo;nt changes. These kinds of systems are generally regulatory. Thus, they cannot handle changes in supervisory control strategies that might be controlling very important product properties.

f. Maintaining Control Objectives Process conditions of a step of a batch process can bP
maintained at or close to control objectives using conven-tional control systems. Two common forms are distributed control systems (called DCSs), which often implement feedback control loops, and sinyle loop controllers. Some PLCs also provide the functions ofi conventional control systems. DCSs and PLCs with control loops provide simple regulatory feedback control, in which temperatures, pressures, and flow rates are maintained as close as possible to goal or setpoint values.
The inventor has found that a batch process may require more than simple regulatory control. For example, the operation of a process unit during a step may require complex control. Or a composition or intermediate property may need to be held at a statistically stable value. These kinds of control problems can be too complex for conventional regula-tory control systems.
There are serious deficiencies in the present art for controlling batch processes. Among these are the following.

---- - . . :. . , : : -. . . -~ ~ -. . .
, - .
,. . , , WO 90~1236X P~/us9O/O~XSq ,, , -- ,, ;

First, because of the limitations of current batch control systems, it is very difficult, if not impossible, to automate the detection of step endpoints with complex definitions. Current control systems in both process applications are especially limited in their ability to detect endpoints which include time history conditions.
Second, because current batch control systems are regulatory systems, it is very difficult to US2 complex control during a batch step. In particular, it is difficult if not impossible to automate the use of statistical process control or expert system based control during batch steps.
These and other deficiencies in the conventional technology are significantly overcome by the present inven-tion.

II. SUMMARY OF THE INVENTION

Batch process control is improved by defining a step endpoint condition in an expert system knowledge base; using the expert system to monitor for the occurrence of the endpoint in the batch process; and triggering a change in a batch process condition when the endpoint is found. Prefer-ably, the expert system and the batch process condition change are implemented as modules which execute under control o~ timing and sequencing functions in a supervisory control system, and the changes affect setpoints (or other control objectives~ in a continuous control system. Multiple instances of modular expert systems allow parallel process units to be easily controlled.

W~3 ~0/1236~ P~r/US9O

r ~ 8--IV. BRIEF OESCRIPTION OF THE DRA~INGS

The present invention as described in the specification is better understood with reference to the following draw-ings.
Figure 1 shows the time history of using the expert system based batch process control method of the present invention, where the horizontal axis represents time.
F;gure 2 shows the time history of the expert system based batch process control method of the present invention for a multi-step process including both time and expert system-based endpoint determination, where $he horizontal axis represents time.
Figure 3A shows the time history of the expert system based batch process control method of the present invention for a multi-step process including both time and expert system-based endpoint determination, with an example of the method of determining endpoint by time shown in detaii, where the horizontal axis represents time.
Figure 3B shows the time history of the expert system based batch process control method of the present invention for a multi-step process including both time and expert system-based endpoint determination, with an example of the method of determining endpoint by expert system shown in detail, when the horizontal axis represents time.
Figure 4 shows the time history of the expert system based batch proccss control method of the present invention for a multi-step process including both time and expert system-based endpoint determination, with examples of hcw control objectives can be changed, where the horizontal -axis represents time.
Figure 5 shows the time history of the expert system based batch prooess contro7 method of the present inventicn for a multi-step process including both time and expert .: . .
- , ; ' ~ . : .

.
' WO ~0/123~8 P~/US9~/01~54 _. , -- ,^,, ;
f-:, ., ', .-.' ,J
_9_ system-based endpo;nt determination, with examples of what control ob~Pctives can be used3 where the horizontal axis represents time.
Figure 6 shows the time history of the expert system based batch process control method of the present invention for a multi-step process including both time and expert system-based endpoint de~ermination, with examples of what type of control functions might be used, where the horizontal ax;s represents time.
Figure 7 shows a simple block diagram of the expert system based batch process control system of the present invention.
Figure 8 shows two simple block diagrams of the expert system based batch process control system of the present invention including a sequence controller.
Figure 9 shows a simple block diagram of the expert system based batch process control system of the present invention including a sequence controller, showing examples of the components of the expert system.
Figure 10 shows a simple block diagram of the expert system based batch process control system of the present invention including a sequence controller, showing examples of the components of the sequence controller.
Figure 11 shows a simple block diagram of the expert system based batch process con~rol system of the present invent;on including a sequence controller, showing examples of the components of the control objectives.
Fiyure 12 shows a simple block diagram of the expert system based batch process contrvl system of the present invention including a sequence controller, showing examples of the components of the control means.
Figure 13 shows a simple block diagram of the expert system based batch process control system of the present invention including a sequence controller, showing examples W V 90/12368 PGr/us9~ 854 2 -~ - 1 o -of the types of process data that can be used in the expert system.
Figure 14 shows a simple diagram of the modular super-visory sequence control system of the present invention.
Figure 15 shows an example of a sequence implemented in the modular supervisory sequence control system of the present invention, using other control modules.
Figure 16 shows an example of a sequence implemented in the modular supervisory sequence control system of the present invention, using other control modules, showing examples of the components of the event module specifica-tions.
Figure 17 shows an example of a sequence implemented in the modular supervisory sequence control system of the present invention, using other control modules, showing examples of the components of th2 expert system module.
Figure 18 shows an example of a sequence implemented in the modular supervisory sequence control system of the present invention, using other control modules, showing examples of the types of other control modules that could be used.
Figure 19 shows an example of a sequence implemented in the modular supervisory sequence control system of the present invention, using other control modules, with examples of the types uf timing functions that could be used.
Figure 20 shows a romputer display template for the first event module of the present invention used in the example application.
Figure 21 shows the template for the expert system module of the present invention used in the example applica-tion.
Figure 22 shows the template for the second event module of the present invention used in the example application.

.

WO 90/12368 P~/U~OtO185 Figures 23 and 24 show the help screens listing the allowed event data types for the event modules of the present invention in the example application.
Figures 25 and 26 show the templates in accordance with the present invention for the calculation rule which classifies the reactor recycle ratio in the example applica-tion.
Figure 27 shows the template in accordance with the present invention for the variable rul~ whlch classifies the average reactor temperature in the example application.
Figure 28 shows the template in accordance with the present invention for the analysis rule which determines the endpoint condition in the example application.
Figure 29 shows the template in accordance with the present invention for the action rule which turns off the expert system block when the endpo;nt is detected in the example application.
Figure 30 shows the template in accordance with the present invention for the action rule which requests the execution of the second event block when the endpoint is detected in the example application.

DETAILED DESCRIPrTION OF THE PREFERRED EMBODIMENTS

I. 6eneral Overview of the In~entions The present invention as described in this application comprise methods and systems inventions ~or controlling batch processes using expert systems and expert system methods.

WO 9~/ 1 2368 PC~/USgt)/0~8~4 ?~ -12-1. Expert System Based Batch Process Control Method Referring now to Figure 1, one aspect of the presentinvention is a method of using an expert system to identify the endpoint in a batch process step. This method of the present invention operates as follows: (a) first, the batch process step is initiated, as shown by plot 102. Then, (b) an expert system of the present inYention is used to (c) monitor for the endpoint condition of the batch process, as shown by plot 104. Last, (d) a control objective as shown by plot 108 in the batch process is changed as shown by plot 106 when the expert syste~ detects the endpoint condition. It should be noted that plots 102, 104, 106, and 108 of Figure 1 shown only an illustrative example of this method of the present invent;on; in other words, this method of the present invention is not limited to that shown in Figure 1.
This method of the present invention is described in greater detail below:

a. Initiating the Step '!
:
Referring again to plot 102, if the batch process step --is the first step in the process, it is probably initiated manually by a person (process operator, which is not shown~.
A push button or a computer command could be used to do this initiaiion. If the batch process step is not the first step in the batch process, it typically would be initiated automatically when the previous step reached its endpoint.
Thus, the present invention contemplates all presently known or future developed ways to initiate the step.

WO 90/12368 P~tU~ig~)/018~4 ,_ , _. ~ .. . .

b. Expert System Expert systems (see generally Figure 9) of the present invention provide two generic functions: an inference eng;ne 906, and ;nterfaces 902, 910 to commun;cate data to and from people (;ndicated generally by reference numeral 912) and other systems includ;ng computer systems as shown by com-mun;cations links 914, 916, 918. These two functions are used to process knowledge, represented ;n a structured way (a rule base example is shown in F;gure 17 at reference numeral 1702) in a knowledge base 904, to make decis;ons. The dec;sions are then implemented by commun;cat;ng with people 912 or by tak;ng actions outside the expert system (see links 914, 916, 918). Most expert systems use rules (see reference number 1702) to represent knowledge. Some expert systems group rules around classes of objects (not shown, but known well in the expert system art). It should be understood, however, that the presen~ invention contemplates all present-ly known and future developed knowledge representations.
A batch process control expert system of the present invention preferably should have a knowledge representation (not shown) that can express the retrieval of process measurements, the temporal representation of that data, and perhaps some statistical processing of the data. In the preferred embodiment, this kind of knowledge representation as used by the present invention allows the knowledge base 904 to express the process condition(s) that define a typical batch endpoint condition(s~, as represented by block 702 of Figure 7O

W~ 90/1~3~8 P~tU~;90/01854 r-~ --14--c. Monitoring Since the expert system(s) of the present invention runs on a computer (not shown, but any type of presently known or future developed computer or processor can be used), it is fundamentally procedura'l. To monitor using an expert system 900 (which is fundamentally procedural) the expert system 900 must continue to monitor over time. One way to do this according to the present invention is to have the expert system 90Q cycle (run) continuously until it detects the endpoint condition. Assuming the knowledge representation and/or the inference engine 906 of the expert system 900 allows for such cycling, this can be accomplished within the expert system 900. That is, the expert system 900 never need return control to that computer function that started it.
This approach is called a cycling rule base.
Another way to repeat (or cycle) the expert system 900 in accordance with the present invention is to allow some idle time (as produced by the wait step 304 of Figure 3B, for example) between e~ecutions of the expert system 900. This idl;ng approach makes sense if the expert system 900 runs fast compared to the spe,ed at which the batch process changes.
To implement this id'le approach, a timing or trigger mechanism (an example for the modular batch supervisory process contrDl system embodiment (the "batch supervisor") is shown in box 1902 of module timing and sequencing function 1904 of Figure 19) is needed to start the next run of the expert system 9GO.
In this case, the computer of the present invention can do other things ~etween runs of the expert system 903.

.
:

:

W o 9O/1236X P~/USs~/~1854 ~?

d. Changing Control Objec~ives When the expert system 900 of the present invention detects the endpoint condition, it must somehow cause process control objectives (see block 802 of Figure 8) to change (examples of such changes are seen in block 402 of Figure 4).
(Examples of specific control objectives are shown in block 502 of Figure 5, and examples of classes of control objec-tives are shown in block 1102 of Figure 11). One way this is done in the present invention is to encode the changes to be made to the objectives directly in the expert system know-ledge base 904. In this case, the interface functions 902, 910 in the expert system 900 of the present invention must be able to communicate these control objective 802 changes directly to their destination such as a control means 804.
If the destination is a DCS or PLC, then the expert system 900 changes the setpoint or logic values in these systems.
Another way the expert system 900 of the present invention can trigger a change in control objectives 802 is to ask a batch-type (sequence) control $ystem 806;to execute a pre-defined step change. With this approach, the expert system 900 needs thel interface capability 910 to send a trigger message ~via link 914) to the batch control system 806, and the control system 806 must be able to accept such a trigger message. -A third option is for the expert system 900 to communi- -cate with people 912 (process operator), who can then manually change conditions, or manually trigger a ba~ch-type oontrol system 806.
It should be understood that in a multi-step batch .
.

' WO 90/12368 PCI/US90/018g4 process, the changing of the control objective (plot 106) for a step n ;s the same thing as the initiation (plot 102) of step n+l.

2. E~pert System Based Batch Process Control System Referring now to Figwre 7, in one aspect the expert system based batch process control method of the present invention can be implemented with a process controller 804 which can control the process 700 to try mee~ control objectives 802, and an expert system 900 which can detect conditions that match a defined endpoint condition 702 and : -change the control objectives 802 of the process controller 804.
This aspect of the present invention is described in greater deta;l below: -~. Process Controller The process controller (control means) 804 can be, for example, any of the regulatory control devices mentioned above (such as a DCS, PLC), and other devices such as a :-single 130p controller.

b. Control Objectiv~s '~
Referring now to block 1102 of Figure 11 and block 502 of Figure 5, control objec~ives 802 of the batch process step(s) may include setpoints of feedback controllers nr control loops 504, parameters used in feedback controllers ~such as gain constants) 506, or they can be on/off status of switohes 598, valves, controllers S12, etc., on~off inputs to logic controllers (7ndicated by 514), or a database value 510.

, , ~' . .

. .

WO 90/12368 P{~/US911/01854 " , , c. Exper~ System As discussed above in the section describing the expert system based batch process control method, the knowledge base 904 of the expert system 900 allows the expression of process conditions that define a batch endpoint 702, and can process that knowledge to detect the endpoint condition.

d. Endpoint Condition The endpoint condition describes the condition or conditions in the batch process 700 which, when present, indicates that the step of the batch process 700 is over.
The condition must be expressed in the knowledge base 904 of the expert system 900 of the present invention. Endpoin$
conditions 702 might include logical combinations of, for example, limit values on current measurements, trend or slope values, time average values, statistical behavior of sample measurements, and so forth. They may also be b~sed on --information about the state of the process controller 804, like setpoint values 504.

3. Batch C~ntrol S~stem ~ith Expert Subprocedures Re~erring now to Figure 15 showing the batch supervisory embodiment 1500, another aspect of the present invention is the integration of multiple expert systems 900 (shown as expert system modules 1502 in Figure 15) into a batch process control system so as to constitute subprocedures.
The batch process control system supervises the execu-tion of all the control functions 1502, 1504, 1506, including the expert systems 1502 it contains. The batch control system thus determines when each eon~rol function 1502, 1504, ' ' ' ~ ' . : ' . .
.. .

....
.

.

w o 90/1~368 PCT/US90/OIx54 r~ J ~ ~

1506 in a sequence 1508 or recipe should take place, as opposed to the batch control system determining when to perform its control funct;ons ;ndependent of when the expert systems 1502 perform their expert system functions.
Putt;ng expert systems 1502 as subprocedures in the control system makes it easy to turn on (as shown by links 1510) each expert system 1502 at the po;nt in the batch sequence 1508 (or recipe) where ;ts decision making functions are needed. Th;s eas;ly allows more than one expert system 1502 to be used in controlling the batch process 700, and makes it easier to coordinate the expert system functions with other control functions.

4. Modular Supervisory Sequence Control Method Referr;ng again to Fi~ure 15, another aspect of the present invention is a method of controlling a batch process 700 using expert system modules 1502 and event change modules 1504 (also referred to herein as event modules or fixed event blocks). First, (a) the batch process step is initiated by executing one or more event change modules 1504. Then, using a timing and sqquence method or function 1512, an expert system module 1502 is (b~ repeatedly run (for example, see block 302 of Figure 3) to (c) test for an endpoint condition 702. When the expert system module 1502 detects the endpoint condition, the expert system module 1502 (d) disables further execution of itself and causes one or more event change modules 15M to execute (seP Figure 15).
This aspect of the present invention is described in gre~ter detall below:

' ' .

Wo 9~ 368 P~T/US90/01~4 _ 1 9 _ ,., ~ J

a. Initiating the Step Referring again to plot 102, if the batch process step is the first step in the process, it is probably manualiy initiated by a person (process operator) causing one or more event change modules 1504 to execute. If the batch process step is not the first step in the process, it typically would be initiated automatically when the previous step reached its endpoint. Thus, the present invention contemplates all presently known or future developed ways to initiate the step.

b. Repeatedly Running Expert System An expert system module 1502 of the present invention implements an independent expert system as described above.
One ~ay that an expert system module 1502 can be run repeat-edly is by using a timing function which executes the module 1502 at a fixed t;me interval 1910 so as to produce the cycling function.

c. Testing ~,or an Endpoint Condition When an expert system module 1502 of the present invention runs, it tests for an endpoint condition of the batch process step, which endpoint condition 702 is defined in its knowledge base 904. The expert system uses its inference engine 906 to process its knowledge basQ 904. It may retrieve, via its interfaoe 902, 910, data (such as the examples shown in block 1302 of Figure 133 referenced in its knowledge base 904, and performs any actions 706 in its knowledge base 904 that are indicated as a result of its processing.
:::

. ~ " `

WO 90/1236~ P~/US90/~1854 "
J
-~!0- "

d. Executing Event Modules Once the expert system of the present invention detects the endpoint condition 702, it must initiate the next step in the batch process 700. This initiation is done by causing one or more event change modules 1504 to execute. These event change modules 1504 change the control objectives 802 (see block 502 of Figure 5 for examples) to their proper values for the next step in the batch process 700.
The knowledge base 904 in the expert system can toggle on an event change module 1504, or it can send a request via link 1514 to execute to an event change module 1504. Once this is done, the expert system module 1502 has fulfilled ~ts purpose for this stept and it no longer is needed in this recipe for the batch process 700. The knowledge base 904 in the expert system module 1502 can simply toggle off its own module via link 1510.

5. Modular Batch Supervisory Process Control System Referring now to Figures 14 and 15, in a preferred embodiment of the present invention, the recipe for the batch process 700 is implemented in a modular batch supervisory process control system 1500 (called a "batoh supervisor"), which provides a set of timing and sequencing functions (indicated by box lS12) which oan control the execution cf evenk modules 1504 and expert system modules 1502. The batch supervissr 1500 can also control other types of control modules 1506.
This embodiment is discussed in greater detail below.
-WO 9û/1236~ P~/US90/û1854 ,~ ,. . . . .
-21- , a. Timîng and Sequencing Functions Timing and sequencing ~unctions in accordance with the present invention are the highest level functions in the batch supervisor 1500 and provide a number o~ ways to specify when a module 1502, 1504, 1506 should execute. (Examples of possible t;mtng and sequencing functions are listed in block 1902 of Figure 19.) Each module 1502, 1504 or 1506 speci~ies which timing function it uses, and provides appropriate parameters for that timing function. Some timing functions (see 1906 and 1908 of Figure 19) allow modules to be e~ecuted in sequence with specified ~ime intervals between each module. Other timing functions may allow a module to execute repeatedly at a fixed time interval (see 1910), or to execute only when an explicit request to execute is received (see lgl2) .

b. Event Modules Event modules 1504 of the present invention contain the definitions of the control objective t502, 1102) changes that need to be made at the start of each step of the batch process 700. As shown in block 1602 of Figure 16, the most common changes are, for example, to se~ a setpoint to a value defined in the recipe (see 1604), or to set the state of a switch (see 1606), valve, ete. Setpoints can also be changed by incrementing their value by a fixed amount (see 1608).
Sometimes a desired setpoint value might be stored somewhere, and the actual setpoint is changed to match ~he stored value (see 1610~.

w o go/12368 PCT/US90/0l~54 c , ~ J Z2 c. Expert System Hodules The expert system modules 1502 of the present invention contain knowledge bases 904 (see Figure 17, which shows rulebase 1702 as an example) which test for endpoint condi-tions. Each expert system module 1502 usually has its own knowledge base 904. The knowledge base 904 may be completely independent, or it may be a subset (which is identified in some way) of a larger knowledge base. The expression of the knowledge can be in any suitable form, but is usually in rules (see 1702 of Figure 17), or object/ rule combinations.
Expert system modules 1502 include the capabili~y to send a request to execute to another module (see line 1704 of Figure 17 for an example).

6. Modular Expert System with Multiple Instances Some processes (both batch and nominally continuous) use many identical (or nearly identical) equipment units or machines in parallel. Generally, a common stream of feed material is split, and part is fed into each parallel unit.
The product from the parallel un~ts might be recombined and fed to further processing units or stored for sale. Examples include chemical reactors built in parallel because of size limitations on the reactors, and fiber spun from molten polymer on many spinning machines run in parallel.
When expert systems are used to monitor or control parallel units, the knowledge usually is the same for each unit. For example, if a rule knowledge representation is used, the same rules would generally apply to all of the units. Only specific data is different for each unit -- the measurements for each unit will have different data speci-fiers, and, for example, a newer unit might be able to tolerate slightly higher temperatures than a older unit.

wo so/1236~ p~rlussv/ol854 2; ~< 'J

It is much more efficient to build and maintain a si~gle rulebase for parallel units, and then customize the specific data for each unit. This could be achieved by using an object knowledge representation within a single expert system module 1502, but the modularity of the application would be reduced. It would be impossible to use the batch supervisor timing functions 1512 to coordinate the expert system analysis of individual units, since the knowledge for all the units would res;de in one module expert system 1502.
An expert system module 1502 of the present invention which allows multiple instances (data) 1502 provides a single knowledge base 904 fsr multiple process units, whi 1 e still preserving the modularity in controll;ng expert system analysis. It also allows simple rule representation to be used in place of a mure complex object representation.
In expert system modules 1502 of the present invention having multiple instances data, the knowledge base 904 is common to a set of more than one expert system moduie 1502.
A change made to knowledge for any module 1502 in the set changes the knowledge in all the modules 1502 in the set.
However, each module 1502 can specify unique data to custo-mize the knowledge. IFor example, the specifiers for the data to be used in the knowledge would probably be different for each module 1502 in the set. And numeric values, such as temperature limits, can be the same or different for each module 1502.

II. DET~ILED DESCRIPTION

l. Batch Processes As stated above, a batch process 700 is a way of producing a product using a procedure or a recipe which is carried out or run over time. Cooking is a classic batch W O go/1~368 P~T/US~0/01854 : : -24 process, in which a series of steps are followed through time to produce an end result.
One use of batch processing is what is designated herein as a "true" batch process. Such true batch processes are designed to work purely in time. In order to make something using a true batch process, you start with a given amount of the starting material. Later, when the process is complete, you have a related amount of end product. If you want more product, you have to make another batch.
True batch processes are used to manufacture commercial quantities of materials. For example, true batch processes are used to manufacture many chemicals, pharmaceuticals, pesticides, plastics and the like.
Batch processes can also be used by individuals for making small qualities of products. For example, cooking ~s that kind of true batch process. The sequence steps that can be programmed into some microwave ovens is a batch process.
Another kind of batch processing is a way of dealing with imperfect ("nominally") continuous processes. A
continuous process is like a car wash, where dirty cars continuously go in one end and come out clean at the other end. A car wash might not work well enough to run like this forever. The brushes might wear out, for example. In this case, the car wash has to be stopped, the old brushes removed, new ones put in, and then the wash restarted. Similar situations occur in continuous chemical processes, where, for example, a catalyst might deteriorate over time. At some point, the catalyst must be either be replaced or regenerated to keep the process operating properly.
These kinds of continuous processes usually go through a cycle, where they run in a continuous mode ~or a while, then they go through a replenishment sequence ~for example, to regenerate catalyst~, and then return to continuous mode.
This kind of technique is used in refining crude oil, and YV~90/12368 P~ S9 -25~

may be needed in any continuous process ~hen the equipment or the process performance deteriorat~s with time.
A third k;nd of batch processing is used for starting up and shutting down continuous processes. In general, a con-tinuous manufacturing process cannot be started up by simply switching it on. Con~inuous processes usually require fairly complex conditions to be establ;shed before they can be started up and run properly.
An example of this start up problem in a continuous chemical process is a distillation column. For example, consider a cnntinuously operating trayed distillation column which has an inventory of boiling liquid in its base and on each tray in the column. It also has a continuous flow o~
vapor boiling up from each tray to the one above, and a continuous flow of liquid from the top, and from each tray to the one below. The column msst likely is hot when it operates.
To start up a column such as this one, the base must be filled with cold liquid. This cold liquid must then be heated to its boiling point, but the heating must be slow enough so that the column is not thermally stresced. As the liquid begins to boil9 the vapor moves up the column, and the liquid in the base must be replenished. Eventually the vapor exits ~rom the top of the column, is condensed and is returned as the liquid reflux to the top of the column. At this point the column is on total reflux, and is ready to have feed ;ntroduced and prcduct removed so as to put it in continuous production. It thus can be appreciated that this kind of skart-up process can ~e very complex.
In essence, all nominally continuous processes include some batch processing. Consequently the present invention as described herein can be applied very widely and in many applications. The inventor believes that a batch process has some unique characteristics, which include:

' WO 9~/123~8 P~/US90/~185~

.. .~ .. : i, ., ~
~ . ,: , .

First, the process occurs over time. It s~arts at some point in time, and later the process is finished.
Second, the process is defined by a series of steps.
Each step performs some different task in producing the end result. Each step requires different process conditions.
Each step includes a definition of ~hen it is over. The simplest batch process has only one step, but most have many steps.
Third, the steps in the process take place in a specific order. The ordered collection of the step defini-tions makes what we call a sequence or a recipe. As used in this application, the two terms are intended to mean the same thing.
Fourth, although unusual in continuous processes, batch processes often include requirements to change things that have only two states, like flipping a switch. This kind of on/off control is some~imes called digital control, or logic control.`
It should be understood that chemical manufacturing processes are the primary Focus of the present invention as of the filing date. This is evident in the specific embodi-ment and the specif;c implementation options of the present invention that are described.
However, it should be understood that batch process are used for many manufacturing processes. For example, the cooking process in a programmable microwave oven is a batch process. The present invention describPd herein is appli-cable for all types of batch processes.
Batch processes are used to make many valuable products, including pharmaceuticals and pesticidec. Also, some very important nominally continuous processes, including the refining of crude oil, use a repetitive cycl~ of steps similar to a batch process. All nominally continuous processes use a sequence of steps to star~ the process up and W{:~ 9/~J123~ii8 PCr/U!~ 185 to shut it down. So batch processes and batch processing play a very important role in manufacturing.

2. Control Means A batch process recipe or sequence specifies conditions that are needed for each step. To use the batch process 700, those condit~ons have to be maintained in the process. In practice, the best one can do is to try to achieve the condi-tions. The inventor uses control means 804 to accomplish this goal. Most controllers 804 are standard and well-known, but more innovative or complex controllers could also be used with the present invention.
The most common control task ;n a batch process 700 is regulatory control, which maintains temperatures, pressures, motor speeds, and so on to try to match the desired condi-tions. These kinds of conditions are analog, meaning they can take on a continuous range of values.
Contrslling analog conditions requires a means of measuring the condition. Sensors, which sense a condition and generate a signal (sent via link 704) representing the value of the Icondition, and actuatorsS which can change a process condition in response to a signal provide a link 700 between the controller 804 and the process 700. The job of the controller 804, in general, is to use the sensor data to determine how to adjust the actuator to best meet the desired condition 802.
Feedback control tries to maintain a process condition to match a setpoint or goal value 802. Since batch proeess recipes usually specify the condltions for each step, feedbark control is an important control function in batch processes 700. Feedback con~rollers generally implement an algorithm that defines what the prooess state should be, or how the process state should be changed, as a function of the , :.

WO 90~123~8 P~r/US9O
?

setpoint value and the current and past measured values of the condition.
A wide range of algorithms can be used. The most common and serviceable are the proportional, integral, deriYative (PID), and the proportion, integral (PI) algorithms. For some kinds of batch proce~s problems, simpler algorithms, such as proportional only (P), integral only (I), or on-off control work better. Sometimes a complex dynamic algorithm like internal model control, or even adaptive control, can be useful. All control algorithms depend on parameters to quantify or modify their actions. Proportional, integral, and derivative constants are typical parameters. Also, controllers 804 may have limits on how they can change their output.
Feedback control can also try to follow a moving goal.
This is sometimes needed in batch processes 700 where the condition cannot be changed too quickly. To heat up a large vessel, the temperature might be ramped at a given rate so that the vessel is not thermally stressed. Specialized feedback controllers can do this.
Feedforward control can be used to head off problems in controlling a condition in a batch process. For example, if we are heating a stream of oold liquid, we know that as the temperature of the feed stream drops, we need to add more heat. We can adjust the heat input as soon as the feed stream temperature start to drop. If we really know enough about how the process behaves, we can keep the condition right where want it.
Feedforward control does not have a goal or setpoint.
It uses some kind of a model of the process that indicates haw much of change should be made in the process 700 to compensate for something else that is changing in the process 799. Feedforward control often uses a model which makes a O 9U/123fi8 ~/US90/~18~4 r~

change proportional to the measured change, but of course any appropr;ate model will give a good result.
The control as described above is single-input (sensor), single-output (actuator). This ;s the most common kind of control. However, there are more complex control methods, such as those that use multiple inputs and multiple autputs together. Such control methods are needed when controlling one condition which can adversely affect control of some other condition, and can also be used with the present invention.
Also, controls can be cascaded or operated in a super-visory mode, where one controller 804 changes the setpoint 802 (usually) of another controller 804 rather than changing the process 700 directly. All of the regulatory control methods described above can be used as supervisory control methods in the present invention.
In some situations, it is useful to have a very sophis-ticated controller. The modular supervisory controi system described in the associated patent applications listed above could serve as control means 804 for allowing for statistical or expert system based control to be used.
The other kind of control used in batch processes 700 operates on-off (binary) actuators. The most important ones are electrical switches and on/off valves. On/off states of controllers or software control funotions are also impcrtant in certain applications. Logic control defines relationships between on^off input signals and on-off outputs.
Batch process recipes often require things to be turned on or off. A logic control system in its simplest use cou1d simply take an nn/of~ indication for a process state and implement it via the appropriate actuator. A logic control system can also implement, for example, relay (or ladder) logic, which defines more complex logical relations between multiple inputs and multiple outputs. A batch recipe - . . .
~ ~ .
- :
.

WO 90~1236R R~/~JSgO/01854 ,. , i ., . ~, generally specifies on/off conditions which are inputs to a logic control system.

3. Control Objectives The controllers 804 (or control means) of the present invention seek to maintain batch process conditions at desired values. Here, the desired values are what we call control objectives 804. Most control objectives 802 are setpoint values or ontoff states of valves and devices. Some control objectives 802 might be more complex; for example, specifying the ramp rate and top of the ramp for a setpo;nt ramping task. Sometimes, a parameter like a controller gain might be an objective value.
Normally, control objectives 802 are maintained within the controller 804 that tries to meet the objective 802.
However, the control objective(s) could be stored anywhere that the controller 804 and the sequence controiler 806 (which is described below in detail) can both get access to it ~them).

4. IExpert Systems Expert systems 900 as used in the present invention are computer programs which make decisions. In practical applica-tion, an expert system 900 is an integral part of a larger environment for developing and running expert systems.
Because expert systems 900 are much easier to develop and maintain than conventional computer programs~ they are valuable tools for automating decision making.
Expert systems differ from conventional computer programs as follows: `
First, the decision-making knowledge in an expert system 900 is entered in relatively small, non-procedural pieces.

W~ 90/123~8 P~r/u59~/01854 -31- ~ .

The pieces often are simplA~ "If-Then" rules, but more complex knowledge representation can be used. To enter knowledge, it is not necessary to know the order in which the pieces will be used, or if they will be used at all. This makes it easier for people configuring or operating the expert system 900 to know what to put into the knowledge base. Only a small aspect of the problem has to be entered at any time.
Second, the knowledge in an expert system 900 is usually expressed in a way that is much closer to the way people normally talk. This makes it easier for people to put the knowledge in once they know what to put in. Th;s h;gher level expression may bring along some standard type proce-dures for working with the knowledge. As an example, a rule that makes a reference to the weather being sunny implies that a question should be posed to a user on a terminal ask;ng if the weather is sunny. When the expert system 900 is run~ the inference engine 906 of the expert system 900 would recognize this and use its interface 902,910 to request the data. A rule that references a process measurement may imply that a retrieval request should be made to a database or control system to get that value. The i nference engine 906 and intqrfaces 9029910 would also handle this kind of data input. As a result, less procedure about how to use the knowledge needs to be specified.
Because of the higher leve1 ~xpression and bite-sized knowledge entry, expert systems 900 cf the present invention can be deve70ped and modified quickly. This is a major advantage of the present invention over conventional computer programming.

, , A
.
, '.' , ',, . ,`' ~ , ~

w u 90/l2368 PC~/~S9~/Olg54 ;., -32-" ~
a. Components of an Expert Systems Enviror~ent An expert system environment provides a number of generic functions which are common to tll expert systems built in that environment, which are as follows:
One is the definition of the knowledge representation.
The inference engine 906 of thc expert system 900 needs to have the knowledge stored in a way that it can understand.
The knowledge representation defines how the knowledge can be expressed.
A knowledge entry function provides a way for people to put knowledge into a knowledge base 904. Sometimes this is a text editor, but it could more constrained. For example, in the associated applications listed above, a knowledge entry system and method is described that is template driven, which works with a highly structured knowledge representation. The present invention contemplates all presently known and future developed means of knowledge entry.
A compiler or transla'cor transforms the knowledge $rom the form in which it is entered to some internal representa-tion which can be used by the inference engine 906. This may take place before the expert system 900 runs, like a compi-ler. Or, the translation may take place at run time, like an interpreter, or both.
The inference engine 9~6 processes the knowledge base 904 to make decisions. The inference engine 906 selects which piece of knowledge in the knowledge base 904 to apply next, and decides when to ask for input data 902. It also decides what actions are indicatPd by the decisions it makes and carries them out ~910).
The (user) interface 90? communicates with people or with other computer systems to get input data, and to s~nd ~output~ decision results 910. For consultation e~pert systems, this is often a terminal query and text display WO 90/12368 P~t~lsg~/ol85~

,,, :, . i, function. Where the input data used in the knowledge base is coming from computer measurements, the interface will preferably connect via link g18 to the process measurement database or control system. The interface preferably is also able to send requests back to a control system via link 914 or 916 to make changes in the batch process 700.
In general, every expert system 900 has a unique knowledge base 904. The knowledge base 904 e~presses the decision-making knowledge about the domain. Most expert systems ~00 use rules tn represent knowledge. Some expert systems group rules around classes of objects, or use frames.
For the purposes of the present invention, any form of knowledge representation can be used by the expert system 900.

b. Batch Control Needs The role of expert systems 900 in the present invention is to identify the endpoint(s3 in a batch process step~s3.

Two parts of the expert system environment must be especially adapted for use in process control.

First, the knowledge representation must be able to express the endpoint condition. In general, the knowledge representation needs to handle the temporal (or time based) behavior of measured values, and preferably allows some statistical processing of the data (over ti~e). Also~ the representation needs to allow decisions made by the expert system to cause control actions or communicate with people.

Second, the interface portion of the environment needs to have access to data from the batch process (and possibly the control systems) which is used in the endpoint knowledge.

The data could be provided by people (process operator), but for wtomatic control, it is desirable to get the data directly from a computer source. It should be noted that the :

': ~

W~ ~0/1236X P(~/U~i9~tO1~5 r ~ J
r ~ 3 4 ~

knowledge representation and interface functions described in the associated applications listed above is one good way of providing these functionsO The interface must also be able to send commands to a control system to implement its decisions.

c. Expert System Modules Referring again to Figures 15 and 17, expert system modules 502 of the present invention contain knowledge base(s) 904 which test for endpoint condition(s~. Each module 502 typically has its own knowledge base 904. The knowledge base 904 may be completely independent, or it may be a subset, which is identified in some way, of a larger knowledge base 904. The expression of the knowledge can be in any suitable form, but it is usually in rules, or object/
rule combinations. Expert system modules 1502 of the present invention can include the capability to send a request via link 1514 to execute to another module.

5. Sequence Cuntroller I

A sequence controller 806 provides a means of defining and implementing automatically some parts of a sequence (recipe) of a batch process 700. The seguence controller 806 stores the changes to be made automatically at the start of each step, and provides some logic control which implements the changas. Often the logic of ~he present invention uses time endpoint definitions~ or is based on logical combina-tions of on/off measurements.
Programmable logic controllers (PLCs) with analog csntrol loop capability are one way of implementing sequence control. 6enerally, they define the sequence ~siny software analogs of drum timers or by building basic ladder logic , ~' , , :
' YVO 90/1236B P~/llS90/018 ~ ? ~i~

functions. They are easy for many plant instrument andcontrol engineers to use, but their functionality is limited.
Distributed batch control systems or general purpose computers running software for batch process control provide more flexible sequence specification at the expense of more complexity. The steps in the sequence are sometimes specified in a general-purpose, high-level language like Fortran, but often the system provides a special purpose batch contrul language. The sequence is expressed by the developer as a series of commands.
The languages generally provide commands that interface with on/off and analog inputs, outputs and parameters; that perform ari~hmetic; that communicate with oper~tors; and that suspend the flow of the sequence based on time or ladder type logic specifications. The values of control objective or control parameter changes that need to be made during the sequence are expressed in the commands. The commands are then either compiled or interpreted to execute the sequence.
If the sequenre controller 806 runs on a general purpose computer system, it may allow the sequence to call out to a subroutine written in a standard computer language like Fortran. This could be used to implement alcomplex endpoint determination. This has the usual disadvantages of programm-ing in procedural languages for automation: difficult programming of time dependence; long development times; dif-ficult maintenance; and it is very difficult to implement complex logic.
Some distributed batch control systems chain sequences in a llnked list. Each item in the list is a sequence with all the time and logic control internal to that list item.
This is different from the modular batch supervisor 1500 of the present invention as described below, because in the batch supervisor 1500, the linked list contains step endpoint changes, and the time control is handled by the supervisor, , W~:) 90/123$~ P~/US9~ 54 .
~ . . ; ", , and complex logic control is provided by expert system modules 1502.

III. Modular Batch SuperYisor A modular batch supervisory process control system (which is referred to herein as a batch supervisor) 1500 is the preferred way to implement the present invention. When these techniques of the pr~sent invention are applied to automate a sequence, the collection of functlons for that sequence is called an application. The person who builds the application is called the application developer. Applica-tions are built in the batch supervisor 1500 of the present invention by combining general function pieces called modules 1502, 1504, 1506, 1508. A simple application using the present invention would typically include several event ohange modules 1504 and at least one expert system module 1502.
The batch supervisor 1500 is a supervisory control system. The batch supervisor 1500, in general, is not connected directly to process sensors or actuators. Lower level regulatory control systems 1S16 provide the direct process connections, and also provide regulatory control.
Regulatory control maintains basic process conditions such as temperature(s), pressure(s), and flow rate(s) to match objectives 802, and to control the on/off states of valves, sw~tches, etc. While the batch supervisor 1500 defines the objectives 802, the regulatory control system(s) 1516 seek to attain them.
The key component of the batch supervisor 1500 is a real-time control program whioh carries out the module functions, ;ncluding any expert system 1502 functions. It is preferred to use a build-supervisor program to set-up the basic control functions, and a build-expert program to :. ' ~ . .

WO 9t)/12368 PCr/US90/01854 , ,, simplify the bu;lding o~ expert systems. A shared memory area for storing setup information makes it easier for the build programs to work with the real-time control program. A
procedure library is used to collect custom procedures and expert systems.

1. Modules The batch supervisor 1500 is modular because its control functions are implemented in basic units called modules.
Modules can be generic, which means they implement a general control function, which is customized for each implementa-tion. Batch step changes, statistical tests, etc., are examples of generic module functions.
Modules can also be custom, which means their function is unique. Expert system modules 1502 and user-written program modules are custom module types. The application developer completely specifies the function that a custom module will perform.
To build a module, its function must be defined and stored where the real-time control program can access it.
The developer can use the build-supervisor program to do this.
To create a module, a module function is selected from the set of functions provided by the batch supcrvisor 1500.
This allocates storage are~ appropriate for that module type, and stores there a pvinter to the procedure for that module function. The module function determines what additional specifications are needed to carry out that function. The build-supervisor allows the developer to specify this information, which is stored in the s~orage area allocated for that module. Finally, r~gardless of its function type, every module needs sp~cifications that determine when it should execute its function.

WO 90/12368 P~/US90/018 -3~-a. Ceneric Modules Generic modules carry out standard functions selected from a set provided by the real-time control program. In the current implementation of the present invention as shown in Figure 18, the generic module types are, for example, event change 1504, feedback control 1802, feedforward control 1804, Shewhart statistical test 1806, and Cusum (cumulative summation) statistical tests 1806.
Each standard module function requires parameters which customize the action of the function for that module. For example, a event change module 1504 might specify that a specific setpoint in a specific control system should be set to a specific value. The procedure by which the setpoint is changed is standard, while the pointer to the specific setpoint and the value to be sent are the parameters which customize the procedure. A generic module is thus only a pointer to a generic function, plus the parameters needed for that function type, plus timing speci~iers.

b. Custom ~odules Some control applications require functions which are too complex to be solved with small, seneric, modular functions. Detecting a complex endpoint condition in a batch process 700 is one such function.
To address these needs, the batch supervisor 1500 provides two ways of integrating customi7ed functions into the overall supervisor system.
First, the developer can write his own program in a language like Fortran, and implement that computer code as a custom user program module 1802 as shown in Figure 18.
Second, the developer can create an expert system which WO 90tl2368 PCT/US90/01854 carries out his function and implement that as an e%pert system module 1502.
User program modules are best for complex computations or highly procedural tasks, and also work well for formatting output data. Expert system modules 1502 are best for logical or decision making tasks.
To build a custom module 1502, 1808, the developer has to develop the entire procedure that the module will carry out. (Procedure as used herein ~eans a general task in the control system. An expert system is a procedure in this sense, even though expert systems in concept are not proce-dural.) This procedure must be available to the real-time control proyram, and the module data must contain a pointer to it. Custom modules 1502, 1808, like all modules, need parameters that specify when they are to execute their function. The pointer to the procedure timing function and the timing parameters are stored in the same way as for generic modules, but custom ~odules 1502, 1808 do not use parameters to customize their functions. .

2. Event Module j -An important module function for batoh process control is called an event change module 1504. An event change module 1504 carries out a one-time event, which can be used to change conditions for a batch process step.
As shown ~n Figure 16, an eYent change module 1504 allows analog or digi~al (on/off) tar~et values to be changed.
Target values for an event module can include setpoints of feedback controls, on~off states of controls, or on/off states ~of physical ~quipment like valves and mo~ors. Changes can be absolute, where the target value is set to a pre-defined absolute value, or incremental, ~n Wh;Ch the target value is W o ~0/1~368 P~T/~s9o/~l854 ", ,. .,. ~ 0-changed by a fixed amoun~. In the preferred embodiment, each event change module 1504 allows up to four such changes.
It should be noted, however, that event change modules 1504 in the present invent;on are not limited to this form.
For example, limits could be allowed on the values that can be set by the changes. This would allow the developer to constrain the resulting value so that changes would not push the target value outside of a desired operating range. Also, a different maximum number of ch~nges could be allowed for each event change module 1504. Also, other types of changes could be allowed, such as transferring a value from a stored location to the target.

3. Expert System Module Expert system modules iso2 of the present invention implement expert systems (as described above) which make decisions based on process data. In the associated patent applications listed above, expert systems were called from user program modules. In the present invention, it is preferred to use a module dedicated to each expert system.
It is believed that this is easier for developers to under-stand and use.
Unlike interactive, eonsultative expert systems, expert systems used în expert system modules 1502 of the present invention preferably obtain all their data directly from process data collection and con~rol systems. For the present invention, the knowledge in an expert system module 1502 is built to test for an endpoint condition of a step of the batch process 700. The knowledge base 904 may be a subset of a larger knowledge base 904 which îs iden~ified in some way.
The knowledge base in the pref~rred embodiment is expressed as rules, but it should be understood that the present WO 90/1236~ PCI'/US90/0~8~
,~ .-. ,. ,, ,,;

invention cont~mplates all present and future developed knowledge representations.
For example, objects or frames could be used to group rules and data. These knowledge representations would allow the knowledge contained in an object or frame to be applied to more than one real world object. This is very useful when a batch process 700 includes more than one nearly identical equipment unit. An object representation would allow multiple instances to be created, so that the same knowledge can be customized to apply to many pieces of similar equipment.
However, a better way to do this which preserves the modular-ity of the batch supervisor 1500 is ~o allow multiple instances of the whole rule base as separate expert system modules 150~, as described below.

4. Other Module Types The batch supervisor 1500 of the present invention may be used to supervise not only regulatory control oF, for example, temperatures, pressures, switches9 etc., but it also can supervise continuous supervisory controls, like those described in the associated patent applications listed above.
It is preferred to include the continuous supervisory control function in the batch supervisor of the present invention, since these functions can be implemented as modules in the supervisor. Continuous control functions can be used to maintain conditions during a step in a batch process.
For example, it might be des~rable to maintain a product composition from a distillation column under statis-tical control during a step in the batch process 700. 0r, for example, the "process" might be mainly continuous with sequence regeneration. In this case, the continuous controls would be used during the normal continuous operation, and the batch controls could be used for the sequence steps.

w o 90/l2368 Pcr/u59r~/o~ss4 Referring aga;n to Figure 18, the module types that are used for this approach are feedback control 1802, feedforward cnntrol 1804, Shewhart statistical test modules 1806, and custom cumulative summation statistical (CUSUM) test modules 1806. The first three are described in the associated patent applications listed above. The CUSUM module 1806 performs very much like the Shewhart module 1806, but it uses a dlfferent algorithm.
The statistical test modules 1806 can be used to keep repeat batches in a batch process 700 under statistical control. The test would be applied to a measure of the product properties at the end of each batch. A shift identified by the statistical test means that a change needs to be made in the batch process 700 to move the property back to aim on subsequent batches. This means that the recipe of the batch process 700 must be changed.
The change in the recipe of the batch process 700 can be made by a feedback control module 1802. The feedback action could change a setpoint, like a temperature setpoint, in a step of the batch process 700 by changing the absolute val~e set by an event change module 1504. The feedback action might also change the time duration of a step in the batch process 700 by changing the execution time interval of a -~
module in the sequence.

5. Real-Time Control Program The real-time control program carries out the control functions. It is called real-time since its operation must be fast enough to respond to the batch process 700 changes and to the recipe for the batch process 700. Like most real-time programs, it is primarily non-interactive: it does not communicate with pesple directly while it operates. It does interact with the batch process 700 via control and data .

Wl~ 90/123~8 P~/U~90/~1854 collection systems 1516. The real-t;me control program stores infor~ation about its past and current state in the shared memory area.
The real-time control program of the present invention implements a set of module timing and sequencing functions 1512 which control the execution of modules 1502, 1504, 1506.
The real-time control program runs through a base cycle at a fixed base cycle interval. During each base cycle, the real-t;me control program scans all modules 1502, 1504, 1506 in the batch supervisor 1500. For each module, it checks the timing function and parameters, and the history of that module's execution to determine if it is time for that module to execute. If so, it executes the functions of that module.
After all modules have been checked and executed (if needed), the real-time control program waits until the scheduled time of the next base cycle.
The base cycle interval of the real-time control program of the present invention determines the granularity of time for the control applications which it implements. The fastest process event handled by an application in the batch supervisor 1500 normally determines the base cycle interval.
The base cycle interval normally is short enough that the fastest process event can be responded to adequately in one base cycle. This means that on most of the base cycles, no modules will execute. However, a shorter base cycle interval is desirable since passage of time or occurrence of events in the batch process 700 can only be resolved to the frequency of the base cyele interval.
The base cycle could be run continuously without waiting between cycles. And since computer systems are able to simultaneously carry out multiple tasks, this would not preclude other useful work to be done on the computer. Such an approach may be desirable for batch processes 700 which w o ~o/l2368 p~ so/01~s4 are fast relative to the operation of the batch supervisor 1~00.

a. Timing and Sequencing Functions Timing and sequencing functions 1512 provide a number of ways (see block 1902 for example) to specify when a module 1502, 1504, 1506 should execute in accordance with the present invention. In essence, module timing is specified in the same way as module function.
Each module specifies a timing function from a set provided by the batch supervisor 1500, and provides appropriate parameters which customize that timing function.
One common timing function is to execute a module repeatedly at a fixed time interval 1910. This function requires the execution time interval as its only parameter. Other timing functions with special batch usefulness allow modules to be executed in sequence with specified time intervals between modules 1906, 1908, or to be executed only when an explicit request to execute is received 1912.
Among the timing functions provided by the batch supervisor 1500 of the present invention is a set of batch timing functions 1906, 1908. These allow standard time sequence batch control with which a series of modules can be set up to execute in series with pre-defined time intervals between modules.
To illustrate this aspect of the present invention, consider a line of dominoes as an analogy. The module which starts the chain of dominoes falling uses the first domino timing function 1906, which uses one parameter: the execution time interval. Modules using this timing function execute their module function when the module is turned on. The module stays on for the specified execution time interval.
Then, the module turns itself off. Note that the module can .

' .

- ~ . .
' WO 90/1236~ P~/U~90/~185 be turned sn manually, using the build supervisor program.
It can also be turned on by any program or expert system 900 running on the computer, which allows a user-written program or an expert system 900 to conditionally initiate a sequence of modules.
The following domino timing function 1908 is used for all the succeeding dominoes in the time sequence. This timing option uses two parameters: the pointer to the module that precedes it in the sequence, and an execution t;me interval. Modules using this t;m;ng function execute their module function when the specified preceding module turns off. The module stays on for the execution time interval, and then turns off (for one base cyclP only).
The fixed interval timing function 1910 executes a module repeatedly at a fixed time interval until the module is turned off.
The program request timing function 1912 executes only when a request is made programmatically. These requests oan be made from any program or expert system 900 running on the computer. The most common use of this timing function 1912 is to allow a user-written program module 1808 or an expert system module 1502 to conditionally initiate a module function or a sequence of modules.
The combination of these timing functions is important to the use of the present invention. In addition to prov;d-ing basic time sequence control capability, these timing functions provide the framework which allows modular expert system logic to be inserted into a sequence to make endpoint determinati~ns. The expert system module 1502 can then start the remainder of the sequence.

.
' .,~
' ' ' . ,, WO 90~12368 P(~/U59~/018~

'~ ., ~, .

6. Shared Memory Area Modules are defined by storing the information that defines their actions in a shared memory area. To create a module, storage space must be allocated for the module. The information, usually in the form of parameters which define what the module will do, is put into the storage area.
Typical parameters are, for example, numbers, character data, or pointers in the form of a number. For each module function, a parameter map defines what is stored in the module storage area, and where each parameter is located in that area.
The shared memory area preferably should be non-vola-tile, so that its contents are preserved even if the computer system is shut down or fails. This non-volatile stora~e not only preserves the definitions of the module functions, but it also preserves the execution history of the real-time control progra~ and of each module. In the prefsrred embodiment, this shared memory area is kept in fast ~emory, while still maintaining a disk copy of the shared memory area. The disk copy is loaded into memory when the batch supervisor 1500 is first started.

7. Build-Supervisor The build-supervisor program of the present invention helps the developer enter module specification data. The build-supervisor also allocates module storage and ensures that module specifications are correct and complete before modules can be executed. The build-supervisor can specify generic modules. The build supervisor can define the ~odule function and the timing parameters for custom modules, but it relies on the build-expert and build-user-program functions to specify the procedures these modules execute.

-~ . -w o 90/12368 PCT/~90/01854 In the preferred embodiment of the present invention, form (or template or "functional structure") entry for setting up modules in the build-supervisor is used. The inventor has found that forms allow a collection of informa-tion to be displayed in way that makes it easier for the developer to understand what has been entered and what still needs to be entered.
The general forms (functional structure3 entry of module information is described in detail in the associated patent applications listed above. The present invention extends this approach with the addition of the event change module (see Figure 20) 1504 and the expert system module 1502 (see Figure 21). These modules use the methods for specifying input information shown in Figures 20 and 21.
As stated above, another advance of the present inven-tion is the addition of an expert system module 1502. The expert system module setup form is shown in Figure 21. It -~includes timing specifiers. The expert system modu~e setup form also includes a key definition, which allows the developer to directly enter the build-expert program. The knowledge the developer enters is added to the knowledge base for that module 1502, and is automatically built into a runnable expert system 900 for use by that module 1502. The inventor has found that this simplifies the task of building expert systems and linking them to module timing functions.

8. Build-Expert The build expert program of the present invention allows the developer to enter knowledge into a knowledge base 904, and to implement the knowledge base 904 as an expert system module lS02. The build-expert program was dPscribed in the associated patent applications listed above. In the present invention, it is preferred to use the three pre-defined rule .,: ' ' ~'' :, ' ~YO 90/12368 P~/US90/01 B54 ,, ,~ ~, , ` , . .J

structures entered through forms (functional structures).
This is an easy paradigm for developers to understand, and it standardizes the representation of batch process knowledge.

9. Temporal Knowledge Representations Some add;tional temporal (or time dependent) knowledge representations have been added to the build-expert. When an expert system is run repeatedly to monitor a batch process, it is important to be able to identify changes in the state of the batch process 700. For example, the batch process 700 may be running normally on one monitoring cycle, but is in an upset condition on the next cycle. If the expert system 900 can only identify the current state of the batch process 700, it can send a warning message or take a corrective action.
However, since the expert system 900 is running repeatedly, it would repeat the message or action on every cycle. This means a corrective action might be repeated too many times, or a message issued repeatedly.
It is useful for the expert system 900 to be able to detect the one cycle in which ~he batch process state changed from normal to upset. It can then issue a message only on the cycle when that change of state is detected. If the batch process stays in an upset state for a long time, the expert systcm gon would not send messages on subsequent cycles. The knowledge representation in the expert system 900 in accordance with the present invention has been enhanced to allow this to be done as describPd below.

a. Is/Was in Ana7ysis Rules A significant development in accordance with $he present invention is the addition of the parameter is/was in the analysis rules. Referring now to figure 28, IS refers to the ' ~
'' ' ' WO 90/12368 P~/US~V/01854 -49- .

current state as determined by the rulebase. WAS refers to the state that was determined the last time the expert system module ran or was run.
These two is/was states are stored internally in the expert system module 1502. This location allows an analysis rule to compare the current state of the batch process 700 to the state the last time the expert system module 1502 ran.
A rule which detects a change tn state can easily be built? and can be easily understood, by the developer.

b. Last Cycle Time The last cycle time parameter is another significant development in accordance with the present invention.
Referring now to Figure 27, it allows reference to data corresponding to the time the expert system module 1502 last ran, which is called the last cycle time. The last cycle time can be used to refer to data in a historical database.
It should be understood the last cycle time does not require the rulebase developer to know how far in the past the last cycle time will be. EYen if the module uses a timing option that causes the module to execute at irregular time intervals, the last cycle time will always correctly reference the last time the expert system module 1502 ran.

10. Build User Program The build-user program function is described in the associated patent applications listed above. The build user program allows the developer to write his own computer code (currently Fortran is utilized, but it should be understood that any currently available or future developed compatible language could be used). It alss allows the developer to incorporate this computer code either as a user program WO 9~/1236~ P~/lJs3o/o1854 ~ ^~ , ' -module I808~ or as a user routine which executes immediately after any of the other types of modules.
lI. Procedure Library Both the build expert program and build user program generate procedures. Thes~ procedures must be made av~ilable to the real-time control program so that they can be executed when the modules 1502, 1808 which point to them are executed.
In the preferred embodiment, the bu;ld expert program and the build user program are implemented by generating and compil-ing computer code. A procedure library is used to hold a store all the compiled procedures.
The compiled computer code of the procedures generated by the build expert program or ~he build user program is integrated into the real-time control program by relinking the real-time control program.
12. An Example Application in the Batch Supervisor The following example illustrates the use of the present invention. For simplicity, we show how only one control objective can be changed, using one expert system to detect a step endpoint. Commercial applications would normally involve many steps and many batch process control objectives.
It shsuld be noted that this embodiment does not constitute a best mode application of the present invention.
The batch process 700 in the example is a high tempera-ture reactor to which both hydrogen and a liquid reactant are fed. Some hydrogen passes through without reacting and is recycled back to the feed. Some of the liquid feed is also recycled. The recipe for this pro ess is:
Step 1 conditions: Reactsr heater temperature setpoint 200 degrees.

WO 90/123~8 P~/USg~/0~854 . .

Step 1 endpoint condition: Average reactor inlet temperature over 30 minutes greater than 195 degrees, and the ratio of recycle hydrogen to recycle liquid greater than 20.
Step 2 (end of recipe) conditicns: Reactor heater setpoint set to 15 degrees. This effec-tively turns off the heater, since room temperature is about 18 de~rees.
The reactor heater temperature in this example is controlled by an analog control loop in a programmable loop controller called a PM550 made by Texas Instruments of Dallas, Texas. Most of the measurements of the batch process 700 are collected in a historical database system called Vantage from E.I. DuPont of Wilmington, Delaware. The batch supervisor is called PACE from E.I. DuPont of Wilmington, Delaware. The PACE system used to implement this example application is connected to one Vantage system and seven PM550 controllers. In PACE, modules are called bloc~s. The two terms are interchangeable in this context.
Figure 20 shows an event change module 1504, called a fixed event block in PACE, which is configured to set up conditions for step 1 of the example batch process 700.1 The block uses the first domino timing option 190~, which means ;t will execute its event when it is first turned on. The block has two e~ents configured. The first event sets the setpoint of the reactor heater control loop to 200 degrees.
The second event turns on PACE block 161.
Figure 21 shows PACE block 161. This is an expert system block 1502 which monitors for the endpoint conditions in the example batch process recipe. This~block uses the fixed interval timing option 1910 with an execution time interval of 2 minutes. Once turned on by block 160, this module will execute its exp~rt system knowledge base 904 ~' W O 90/12368 PC~/US90~01854 every 2 minutes until the block is turned off. The knowledge base 904 is described below.
Figure 22 show event block 162 which sets conditions for the end of step 1 of the batch process 700. If another step followed in the recipe, this block would set up conditions for step 2. Since this example only has one recipe step, th;s hlock simply shuts the batch process 700 down. Block 162 uses the program request timing option 1912, which means it will only execute its events when explicitly requested by a program call. It has one event which changes the setpoint of the reactor heater contro1 loop to 15 degrees.
This block7 which is activated by the expert system block 1502 to continue the batch process, could also have used a first domino timing option 1906. This would be appropriate if other steps followed step 1 and the recipe contained a time endpoint definition far s~ep 2. Also, block 162 could include an event to turn off the expert system block 161. In this case, the rulebase in block 161 would not need to contain a rule to turn off block 161. The result is equivalent, so the choice is arbitrary.
Figures 23 and 24 show the help screens from which the developer can select control objective types to change using the event block. The available options are specific to control and database systems available at this batch sup*r-visor installation.
Figures 25 through 30 show the knowledge base 904 used to detect the endpoint and trigger the change to the next step. The knowledge in this rulebase is based on the three rule types and use predefined rule structures provided as templates.
Figures 25 and 26 show a calculation rule which classifies the current value of the ratio of hydrogen (H2~
recycle flow in standard cubic centimeters per minute (sccm) to the liquid recycle rate in milliliters per minute WO 90tl2368 P~/US~0~0185 (ml/min). The ratio ;s HIGH ENOUGH if it is greater than 20, otherwise it is STILL LOW.
Figure 27 shows a variable rule which classif;es the 30 minute time weighed average of reactor inlet temperature. It is OK FOR 30 MINUTES if the value is greater than 195, otherwise it is NOT READY YET.
Figure Z8 shows an analysis rule which checks for step 1 endpoint conditions. If AVERAGE REACTOR TEMP (as defined by the variable rule) ;s OK FOR 30 MINUTES and REACTOR RECYCLE
RATIO (as defined by the calculation rule) is HIGH ENOUG~, then STEP 1 is defined to be AT ITS ENDPOINT.
Figures 29 and 30 show action rules which cause block 162 to execute and turn block 161 off. Block 161 is the block to WhiCh this rulebase belongs, so this stops this expert system 900 from further endpoint monitoring. In Figure 29, a call to a PACE utility function TOGGLE-BLOCK is used. In Figure 30, another PACE utility function is used which causes blocks to execute WhiCh have the program request timing option. This action causes block 162 to execute its event, thus ending step one (and for this example, the recipe).
The application operates through the following sequence.
Event block 160 is turned on by a person using the block toggle on/off functions in the build supervisor (shown as keypad 7 in Figure 20). This sets the reactor heater setpoint to 200 and turns on expert system block 161. Since event block 160 uses the first domino timing functlon 1906, it will turn itself off and will not execute until turned on again.
Expert system block 161, when turned on, runs every two minutes until its rulebase detects the endpoint conditions.
This will cause the action rules in the rulebase to turn expert system blo~k 161 off and cause event block 162 to execute. When event block 162 executes, it sets the reactor heater setpoint to a low val~e, effectively turning the .
: ;

:

U'O g~ 368 PC~/~JS90/~354 ' ? ~
r; i . . . ~

heater off and ending the process. Since it executes on prosram request only, it will not execute again until requested by the expert system block. The recipe is now finished, and all the blocks are ready to repeat the recipe.
Commercial use of the batch supervisor 1500 typ~cally requires much more complex applications. HoweYer, this example illustrates the basic functions of the batch super-visor needed to practice the invention.

IV. SOFTWARE TECHNIQUES FOR IMPLEMENTING THE BATCH SUPER-VISOR

The batch supervisor 1500 can be implemented as follows.
The methods descr;bed in this section are the preferred way to implement the present invention, but other software development techniques could be used to achieve the same result. In the following discussion, we use the term block to mean the same thing as a module.
The techniques described below apply to VAX computers using the VMS operating system from Digital Equipment Corporation of Maynard, Massachusetts. Almost all of the batch supervisor is coded in Fortran computer language.

1. Shared Memory Area The shared memory area (SMA) is the foundation on which the batch supervisor 1500 rests. For best utility and robustness, the SMA should be accessible by many independent programs, called processes, running on the computer. The SMA
shou1d also be non-volatile so that its contents are pre-served through all types of computer outages and failures.
For most flexibility, the 5MA should be dynamically sized.
This is difficult in Fortran, and the memory requirements are small, so we prefer to use a fixed size SMA.

.

w o ~O/1236~ ^ P~T/US90tOlg54 -5~-The global section feature of VMS is used, since it forms a sharable memory area with a shadow copy on disk. The global section is created in Fortran by declaring storage for the SMA in one or more Fortran named common blocks in a block data subprogram. We prefer to use arrays for real, integer and charact.er data sized for the number of blocks supported.
The block data subprogram is compiled and then linked using the share parameter of the link utility to form a shareable image of the common block on disk. To map the disk copy into memory and make it accessible to many processes, the shareable image file must be installed using the share, open, and write options in the install utility.

2. Cont~nts of the Shared Memory Area The SMA is used to store data about the batch supervisor 1500 and about its blocks. It includes batch supervisor constants like the base cycle time, and dynamically updated status information, like the status of the system, the time the next cycle is scheduled, etc. For each block, the SMA
includes the parameters that define the block action, and dynamically updated status information such as the block status, last execution time, a record of the most recent actions, etc.

3. Shared Memory Services We prefer to get and put data into the SMA using a comprehensive set of service subprograms which can be called by any application program which needs access to data in the SMA.
The services are Fortran subroutines which accept requests to get or put information from the SMA. The servioes test all requests to be sure they provide valid information.

, ~. . ... .. ~ .

~YO 90~12368 P~/US90/~)1854 They also issue appropriate error and warning messages when incorrect g2t or put requests are made. The services contain code which defines what SMA requests are legal. Some services contain only definitions of what data references are legal on the current installation of the supervisor. If the service routine accepts a re~uest, then data is entered into or read from the SMA.
The services gain access to the SMA by declaring the same named common blocks in the source code. Programs using the services are linked against the ~MA shared image file using the share option.

4. Retrieval Services We prefer to make all access to input and output data using a set of data retrieYal services. Any calls to get or put data in external control systems, databases, etc., are placed in this collection of routines. The shared memory services also use these routines to test re~erences to external systems, like control loop numbers, to ensure they are valid.
i 5. Shared Service Image We prefer to link the SMA services and retrieval services together in an overall service shareable image. This shareable image is not executable by itself, since it contains no main entry point. However, the image can be linked into other main programs. This makes the services available to the programs without relinking all the computer code in the service shareable imay~. The servic@ shareable image can also be installed using the install utility. This adds efficiency when multiple programs run simultaneously using the image.
When installed, the image is kept in memory at all times, and ' " ' . :. '' : '' ' ~

WO 90/1236~ , P~/US9~ 185 the same copy of the image can be executed by more than one program. Programs that use the image need not copy the image from disk when they are started, and memory is not consumed keeping multiple copies in memory.

6. Site Specific External System Support The general data specif~cation used in the batch supervisor 1500 and its supporting build programs allows flexibility in communicating with many external sources of data. However, each installation of the batch supervisor 1500 preferrably should restrict the data requests to those external systems which are accessible to that installation.
For example, an installation on a site with no historical database must not allow dewlopers to make module specifica-tions that point to data in a historical database.
We prefer to establish the definitions of the supported systems at an installation using the logical name capability.
Logical names are essentially variables which can be created and are accessible to all programs on the computer system.
We define at computer startup logical names which spec;fy the external data sources which are available on the installa-tion. The service routines check these logical name defini-tions, and only allow the developer to access data in systems indicated by the logical names. This allows the same code to be used on installations with different external data sources.

7. Block Types and Ti~ing Function Types Because we use a static memory allocation, the SMA
contains the same storage spaces for each block. The type of block determines what parameters need to be in the SMA for that block. Similarly, the timing ~unction specified deter-W~ 9l~/12368 PCI/US90/038~4 ,,,, ,. .: ~I

mines what timing parameters need to be in the SMA for that block.
When a block storage space in the SMA is first used, the first parameter that must be specified is the bloc~ type.
~his is the basic parameter which determines the meaning of all other data in the SMA for that block. The block type is stored as a character value, although an integer code would work equally well.
The block type cannot be changed, except by completely freeing the block storage and clearing the old block type.
Once the type is specified, the service routines know what parameters are allowed and where in the SMA they should be stored. Similarly, the timing function for a block is specified by storing an integer code in the SMA, which then determines for the SMA services which timing parameters are needed.

8. Block Status A block status is maintained in the SMA for all blocks.
The block status indicates whether a block is properly configured, and whether the block is on, o ff,l etc. The block status is stored as a character value. This allows some flexibility in indicating special cases of block status by developers. For example, a developer can change an "ON"
status to "ON ~ special info" without affecting the block's action, where "special info" is character data useful to the developer.

~. Real-ti~e Control Program ~ -The real-time control program carries out module functions. It comprises a main loop routine, and a number of subroutines for carrying out the various module functions as ;
.
: .

', ', ' : , :-~o 90/~3~8 ~ ; P~tUS~t~1854 well as timing functions. The loop repeats continuously until interrupted. The program contains lsgic to repeat its cycle at a time interval which is stored ;n the SMA, allowing it to be changed.
On each cycle, the program scans all blocks. Blocks which are not properly configured cannot be executed. For blocks which are configured and have any active status, the timing function is checked. If the timing function indicates that the block is due to execute, the corresponding routine for that type of block is cal7ed, and it is passed the identifier of the block.
The routine executes the block's function. The program then calls the user program for that block, which is the way we prefer to generate messages about block actions.
(Initially, the batch supervisor 1500 is installed with all null user programs, which can be replaced by the developer using the build-user program environment.) When all blocks have been checked, the program performs some housekeeping tasks, such as copying the SMA contents out to the disk. It then waits in an idle state until the scheduled time of the next cycle.
The program contains only one copy of the procedure to execute the function for each module type and each timing function. When a block is scanned, the block type/timing function parameter in the SMA ;ndicates which of these procedures to use. The procedures which carry out the block/timing functions retrieve the parameters stored in the SMA for use in carrying out the function. They use the service routines to access the SMA data. They also use the retrieval services to access data in external systems.
For cust~m block types -- expert systems and user proyrams -- the control program calls a routine whose name is deri~ed from the block identifier. Initially, null routines are provided for all blooks. When a developer builds a .
., , .

WO 5`û/12~8 P(~tlJS~)/OI~

custom module, a custom procedure is created and substituted for the null pro~edure for that block. The program must be rel;nked to use this new procedure.
The program uses shared event flags to control its idle time between cycles. If any ev~nt flag is set, the program restarts from its idle state. The program sets a timer to trip one event flag. Other event flags can be set by other programs. When the timer flag is set, the program repeats its cycle. If any other event ~lag ;s set, the program branches and does a specific action for that flag, such as stopping in an orderly way. This prevents the program from being interrupted in mid-cycle.

10. Build-Supervisor Program The build-supervisor program provides a template interface for the developer to enter module specifications into the SMA. The build-supervisor presents a different template to input data for each block type.
The templates are generated using the Forms Management System (FMS) software from Digital Equipment Corporation.
Places on the form where data can be entered are called fields. The forms have a field for each parameter used by that block type. When data is entered into a field, the corresponding put function from the SMA services is called.
If the request fails, the error message is displayed on the bottom of the form.
The build-supervisor also has functions which allow the developer to monitor both the supervisor and individual blocks in real time. The monitoring function retrieves the static and dynamic information from the SMA and displays it in continuously updating displays. The infDrmation displayed includes the relevant external data values used by the block, the time history o~ the block execution, relevant block ,, ., , . .
- , . , -' ' , : :

W~ 90/123~8 - . - PC~/US90/V185~
, , i parameter constants, and a short history of significant block actions.
The build-supervisor also has functions which allow the developer to branch out of the forms interface to build user programs or to build an expert system rulebase.

11. Build-Expert Program The build expert program is different from the build-supervisor. The build expert program generatss code to implement a developer-specified rulebase, while the build-supervisor puts data into the SMA. The build-super-visor uses the pre-defined rule representation as described in our associated patent applications listed above.
The data entered into the rule forms for each rule type is stored in an indexed file. Each rule is one record in the file and can be directly accessed by referring to the rule name in the read request to the file. The build-expert also uses FMS software. Because rules are integral units, the rule input data is checked as a whole when rule entry is complete. Rule parameters are checked against the defini-tions of other rules in the rulebase files to avoid conflicts or unresolved references. The rule data is then written as a new or revised record into the ~ndexed file.
~ hen rulebase editing is complete, the indexed files are read and computer code is generated for each rule. We presently generate a single subroutine in Fortran. This works well for small and moderate size rulebases, and the ~odular natur~ of the supervisor encourages sm~ller rule-bases. For larger rulebases, additional efficiency could be achieved by generating the code for the rulebase in an object language 1ike C~ (which is commercially available). Each rule could be coded as an instance of an object implementing the function for that rule type.

.

WO 90J12368 P(~/US9~/01~4 5 2 ~

The rulebase computer code is compiled and replaces the null rulebase provid~d in the initial supervisor system.
Compiled rulebase computer code is kept in a user object llbrary. The realtime control program must be relinked to include this new rulebase procedure from the library.

12. Build-User Program Environment The build-user program environment allows the developer to write code in Fortran and to imp1ement it as either a stand-alone user program block, or as a follow-on user program to any other block type. Fortran is provided since most developers using the supervisor I500 know this languaye, but any other compiled language would work.
The build-user program environment is much less struc-tured than the other setup functions in the supervisor, so it does not use a forms in~erface to the developer. Instead, procedures running at the opera~ing system command level (DCL) are used to provide menu driven access to standard text editor, compiler, librarian functions, and the link pro-cedures needed to implement the user code. Compiled user code is kept in the user object library. I

13~ User Sharable Image We prefer to link all user wr~tten computer code and expert systems into a separate sharable image file. This image cannot be executed by itself9 since it has no entry point, but the real-time control program can be linked against it and can call the routines in it. A new user shareable image can be linked without relinking the whole ;

' ' ; .

.

~YO ~0~123~8 - j PCr/US90/01854 real-time control program. The real-time control program will load the latest vers;on of this image when it is started.
Thus, to implement new user code, the user shareable image is relinked and the control program restarted. This reduces the turnaround time for implementing new user code and expert systems.

Claims (7)

I claim:

1. An expert system based batch process control method, comprising the steps of:
(a) initiating the batch process;
(b) monitoring, using the expert system, for an endpoint condition in the batch process; and (c) changing a control objective of the batch process when the expert system detects said endpoint condi-tion.

2. A batch process control system, comprising:
(a) control means for controlling process condi-tions of the batch process, so as to maintain said process conditions at pre-defined objectives; and (b) expert system means, responsive to said control means, for causing said control means to change said pre-defined objectives when an endpoint condition is detected by said expert system means.

3. A batch process control system, comprising:
(a) control means for controlling at least one process condition of the batch process, in accordance with a desired objective; and (b) expert system means, responsive to said control means, for causing said control means to change said desired objective when an endpoint condition is detected by said expert system means.

4. A batch process control system, comprising:
(a) first event module means for changing a first condition of the batch process;

(b) expert system module means having a plurality of rules and responsive to data from the batch process for detecting an endpoint condition of the batch process; and (c) second event module means, responsive to said expert system means, for changing a second condition of the batch process, upon detection of said endpoint condition by said expert system means.

5. The process control system of claim 4, wherein said first condition of said first event module means comprises:
a desired process control objective.

6. The process control system of claim 4, wherein said first condition of said first event module means comprises:
a parameter used to control the batch process.

7. The batch process control system of claim 4, wherein said expert system means comprises:
means for running said expert system means until said endpoint condition is detected.