5

Abnormal Situation Management

Practice
Overview
In modern control systems, expert system technology is playing an everincreasing role in assisting the operator in the detection and management of abnormal situations in a plant. With the introduction of distributed control systems in the late 1970's, the basic control systems of many process plants went through major changes in organization and operation. In many cases, the introduction of distributed control allowed control functions to be concentrated into a few control rooms. The traditional control panels for operator interface to the process were replaced with keyboards and monitors. There were few limits on the amount of information that could be accessed and displayed at these operator stations. These systems allowed an operator to make changes and see the process alarms associated with his area of responsibility. In some cases, the system was designed to allow all information about the plant to be accessed from any terminal within the system [5.1]. As a result of this technology change, and the increasing pressure on companies to increase productivity, the scope of control that an operator was responsible for changed dramatically. In one pulp and paper mill the introduction of a distributed control system allowed three control rooms to be consolidated into one and for one operator to do the job formerly done by three [5.2]. In some process areas an operator is responsible for as many as thousands of measurements and hundreds of motors and control loops in addition to various subsystems in a process area. Thus, it has become increasingly difficult for an operator to be aware of all conditions in the plant. During normal operations, there is insufficient time for an operator to examine all measurements in his area
163

164

Advanced Control Unleashed

to determine if an abnormal condition exists. He depends to a great extent on process alarms to alert him to abnormal conditions. Through the early detection of abnormal conditions using expert systems, it is possible to improve plant operation or to prevent a failure that could cause a process shutdown. Also, during shutdown and startup conditions, expert systems can be used to draw the operator to abnormal situations that might affect plant operation. Some of the areas of abnormal situation management that an expert system can effectively addressed are the following: Alarm screeningpresentation of the root source of an alarm condition so that the operator is not distracted from the critical events that are associated with an equipment failure. Detection of process changeDegradation of equipment performance because of improper equipment setup and wear or buildup in pipes and heat-transfer surfaces may alter the behavior of equipment. The automatic detection of significant process changes helps prevent equipment damage and associated production loss. Detection of abnormal conditionsThe automatic detection of patterns in plant operation that indicate an abnormal condition may bring this information to an operator's attention sooner that process alarms. Expert systems may also be used to automatically initiate corrective action on detection of equipment failure. For example, expert systems are used to prevent a condition known as alarm flooding. Process value alarms have traditionally been used in a control system to alert the operator when a critical measurement has deviated from its normal operating range. Also, deviation alarming is commonly used in control applications to alert the operator when a controlled parameter has deviated from set point. In addition, alarms often accompany the detection of an interlock condition or malfunctions such as high vibration or interlock active in motor control. Under normal plant operations, the operator may easily address the occurrence of individual process alarms. However, the failure of a major piece of equipment that is critical to an operation, such as a motor, may result in hundreds of process alarms being activated at once. With the flood of alarm information, it is difficult for the operator to quickly determine the source of the alarms if, for example, a motor tripped. Also, in this flood of alarms, it is difficult to determine which alarms indicate conditions that need to be immediately addressed to insure safety or to prevent damage to process equipment. If an expert system is monitoring individual events that indicate equipment failure, it is

Chapter 5 - Abnormal Situation Management

165

possible for the expert system to automatically suppress other process alarms that were triggered by the failure. This allows the operator to focus on the fault and more effectively address the source of the problem. A combination of individual events or process conditions may indicate a problem. If an operator misses this relationship, this condition may go undetected. For example, the detection of high discharge pressure on a variable-speed pump in combination with low flow indication may indicate a restriction in the downstream line, e.g., a blocking valve is closed. If an expert system is used to detect this combination or pattern, it can automatically alert the operator that such a condition exists. Through this early detection, it is possible to avoid equipment damage or lost production. Such proactive detection of abnormal conditions is especially helpful during the startup or shut down of a complex process. Under these conditions, the operator has to take a number of manual actions. His job is complicated by the fact that it can be months or years between process shutdowns and startups and thus he must often quickly deal with operation conditions that he seldom sees during normal operation of the plant.

Opportunity Assessment
Expert systems have been successfully applied in a variety of applications. Within the process industry, there is significant benefit in using this technology for abnormal situation management. In assessing the potential benefits of this technology, the following questions should be asked: 1. Are there areas of the plant operation where unscheduled shutdowns commonly occur? Could these shutdowns have been prevented if the operator had taken action on the available information? Is the process characterized by high maintenance of measurements, control valves, or equipment? Would continuous monitoring for abnormal conditions help reduce loss of production or avoid unsafe processing conditions Has the operator's area of responsibility been expanded to the point where he does not have time to proactively look at process conditions? Are there cases where operations could have been improved if the operator had taken advantage of process conditions to increase throughput or improve operating efficiency? During the startup of a process area, does it take longer to get to normal operating conditions that would be expected? Would detection of abnormal conditions during startup help the operator reduce the time to complete startup?

2.

3.

4.

166

Advanced Control Unleashed

5.

When a piece of equipment fails, does the operator have difficulty determining the source of the problem? Would automatic screening of alarms help the operator react faster to these situations? Are batch cycles put on hold or new batch cycles delayed because operations has difficulty determining the phase end points or the cause and validity of failure expressions in the batch sequence?

6.

The cost of expert-system software has dramatically decreased since the initial introduction of commercial expert systems in the early 1980's. In most cases expert-system software can execute on a PC that uses a common Microsoft operating system. However, interfacing these software packages to the control system to allow the use of real-time data in abnormal condition monitoring is often a time-consuming and costly adventure. Also, there are wide differences in the ease with which the knowledge associated with an application is entered into the expert system. Often, more effort goes into the design and implementation of the user interface than into the expert system itself. Many of these implementation issues can be addressed by embedding the expert system within the control system. Examples Alarm Screening Expert systems are used in areas of the refining industry for abnormal situation management. One such use is in the prevention of alarm flooding. For example, the regeneration unit of the hydrocracking process is vital to plant operation and production. The interactive nature of the large number of measurements and control loops associated with this unit means that a failure of one piece of equipment may result in the operator being presented with many alarms: the original failure plus the alarms associated with measurements that the equipment affects. Under these conditions, it is of great help to the operator if the alarm associated with the failure is clearly presented and other alarms resulting from this event are only logged, not presented to the operator. An expert system is used to look for specific equipment failures and to automatically suppress other alarms triggered by the failure. Under normal operating conditions, all alarms would be active; the expert system only suppresses alarms when specific operating conditions are detected. As part of the development of an expert system, an expert on the regeneration process needs to define what types of failures on that process will benefit from alarm suppression. For example, one condition that might be identified is the tripping of the blower motor. When the blower motor

Chapter 5 - Abnormal Situation Management

167

trips, a number of other upstream and downstream alarms are also generated that would make it difficult for the operator to quickly identify the problem areas, as illustrated in Figure 5-1.

Figure 5-1. Alarms Following a Regenerator Blower Trip

The regenerator measurements and control loops that support alarming are defined as facts that are available in the expert system. The fact associated with the blower motor includes a slot that reflects the status of the blower motor. This fact is dynamically updated through the interface to the control system. Only two rules are required to automatically change all measurement and control-loop alarm priorities in the control system so they are suppressed at the operator interface when a blower trip is detected. Using the ability to define variables in these expert rules, it is possible to implement rules for alarm suppression independent of the number of measurements or control loops associated with the regenerator unit. Based on this design, alarming of associated measurements and loops alarms caused by the blower trip are automatically suppressed when a blower trip is detected, as illustrated in Figure 5-2.

Fault Detection
An oil field may contain hundreds of wells. The early detection of an abnormal condition such as blocked flow in the wellhead may avoid damage to the associated pump. Because such conditions are often indicated by a combination of measurement values, the traditional value or deviation alarming cannot be used to alert the operator of them. However, by

168

Advanced Control Unleashed

Figure 5.2. Alarm Screening Allows the Source of Failure to be Identified

using an expert system to monitor the wells, the conditions that indicate abnormal operation are detected and brought to the operator's attention. To implement the expert system, facts would be defined for the measurements that are included in a production control system. To detect blocked flow, one rule would be written that examines the conditions that indicate blocked flow; e.g., oil flow and the pump pressure. By using the variable definitions in both the left and right portions of the expert rule, it is possible to monitor all the wells with one rule. As wells are added to or removed from the system, the only change required would be to update the facts; the rule would not have to be modified. When a blocked-flow condition is detected, the rule is designed to write to parameters in the control system that cause the detected condition to be alarmed and displayed at the operator interface. An example of how this would be displayed to the operator is shown in Figure 5-3.

Application General Procedure

1. Identify the areas to be addressed by the expert system: a. Select applications that have significant impact on plant operations. b. Quantify potential benefits based on past operations.

Chapter 5 - Abnormal Situation Management

169

Figure 5.3. Operator Alerted to Condition Detected by Expert System

2.

Develop a cost estimate for an expert system solution a. Cost of equipment and software b. Manpower and expertise required to execute the project

3. 4.

Implement, Test, and Maintain the Solution Focus on the objectives established for the project a. Test initial design concepts before doing full implementation b. Test full prototype with detailed noisy dynamic simulation c. Run full prototype online in computer or configuration room d. Eliminate false diagnostics before installing system in the control room e. Establish procedures to monitor and maintain the system

Application Details
The following details were developed for the application of expert systems for abnormal situation management. To achieve the best results, the user should adhere to the guidelines specified in this section.

170

Advanced Control Unleashed

Selection of the Problem

In selecting a problem to be addressed, the following should be considered: Define objectives to be achieved by the project. If the expert system application is to be successful, the scope of the project should be limited to the requirements of the problem area selected. Quantify the benefits to be expected from implementation of an expert system. The savings should be compared to the cost to initially develop and maintain the expert system. The tools selected for the project will significantly influence these costs. Identify the resources needed to address the application. To develop an expert system for abnormal situation monitoring, it is necessary to have access to a person who is very familiar with the process; i.e., an expert on the process.
Define Process I/O Requirement

A more detailed project plan based on the project objectives allows the scope of the project to be further refined: Define I/O for the process areas and units of equipment that are addressed by the project. Analyze the best grouping of this information into facts to support the pattern-matching requirements. Test the fact design by addressing portions of the application in the first iteration of the implementation. Modify the fact slot definitions as required based on testing with this initial implementation.
Capture Expert Knowledge

Interview experts on the process for the target application and express their input as rules to be implemented in the system. Avoid rules that are too fine-grained; they will make maintenance of the system difficult. Seek narrow, well-defined problems. Expert systems involve a lot of implicit knowledge; people often take for granted that assumptions, logic, and limitations are understood [5.8]. Document the user interface requirements as part of the rule definition. Write use cases to test the concepts and screen presentations before attempting to implement them in the expert system.

Chapter 5 - Abnormal Situation Management

171

Test the Expert System

Develop a test plan to verify the operation of the expert system. This document will also be useful in regression testing the system after making changes. Test the behavior of the expert system using the simulation capability of the expert system. Follow the test plan. Connect the expert system to a detailed noisy simulation and exercise the rules for a variety of operating conditions and interactions Maintain the Knowledge Database Document the expert system's database, updating the documentation when facts and/or rules change. Document the expert system objectives and design and the test results. Establish a maintenance support program that closely monitors the use of the expert system for the number of valid, false, and missed diagnostics and conclusions. Define procedures to document and correct errors found in the implementation. Rules of Thumb Rule 5.1. The granularity of rules has impact. Too little definition leads to rules firing that are hard to understand. However, too fine granularity makes an expert system difficult to modify. Rule 5.2. If the problem can be solved by conventional programming, it is not a good choice for an expert system. Expert systems are best suited to applications for which there is not defined algorithm solution. Conventional programs generally expect input to follow a certain pattern. Expert systems deal best with unexpected input that does not follow a predefined pattern, by reacting to such inputs. Expert systems are appropriate when the knowledge is largely heuristic or uncertain. Rule 5.3. The domain must be well bounded for an expert system to work. Effort should be spent in the initial portion of the project to clearly define the objectives that must be met. The project should be tightly managed to achieve these objectives. Rule 5.4. Most real-world heuristics are too complicated to be expressed as rules with just a single pattern. Rules with more than one pattern may be needed to express these conditions.

172

Advanced Control Unleashed

Rule 5.5. When new functionality is added, don't test just the new features. As an expert system is built up in increments of new functionality, it is important to always test the previous knowledge features of the system along with the new ones. Rule 5.6. Make the rules as modular and generic as possible to improve the expandability and maintainability of the expertise. Make sure the fundamental concept is captured rather than a specific representation of a more general rule [5.9]. Rule 5.7. False diagnostics and alerts will quickly destroy operator confidence. Debug the system and bring it online out of view of the operator, in a computer or configuration room [5.9]. Rule 5.8. Base the validation of level and other integrating responses on a rate of change rather than an absolute value to eliminate model drift. The diagnostics for level measurements and the detection of plugged nozzles should be based on a calculated and measured rate of change of level. Rule 5.9. Rate of change, sustained deviation, and dead signal calculations must use filters, velocity limits, and calculation intervals that maximize the signal-to-noise ratio. The signal should be filtered and sent through a dead time block to create a calculation time interval long enough to see a valid change. Velocity limits should screen out changes that are faster than physically possible in the process. Note that a dead time block instead of a large scan time should be used to prevent low-frequency noise and long failure-detection delays. Rule 5.10. Scan time and rule execution time must be fast enough to resolve the proper sequence to avoid picking up on an effect rather than a cause. Often the sequence of events is important to determining the root cause. For fast processes or slow measurements, it can be difficult to decipher what happened first. Rule 5.11. The interface must be integrated into the displays for the operators. Separate computers with special screens decrease the utility and acceptance of the system Rule 5.12. The alerts must not be repetitive or obnoxious. Loud or abusive alerts will lead to loud and abusive replies from the operators. The setting and clearing of alerts should require multiple executions with the same conclusions before the operator is notified. The engineer should be advised of flickers so that the system can be adjusted. Use a manual reset for alerts that cannot be reliably cleared [5.9].

Chapter 5 - Abnormal Situation Management

173

Rule 5.13. Use a sustained deviation from an updated baseline for the detection of batch phase endpoints and a rate of change for the detection of batch trajectory abnormalities to eliminate drift and changes in starting points. A large filter is used to create the baseline. The last good batch trajectory is used as the reference trajectory. Process knowledge must be used to make sure conclusions are reasonable. Rule 5.14. Upgrade the field instruments before installing an expert system. Otherwise it will be giving you information you already know. If you use valves without positioners or orifice meters, the expert system will tell you over and over again that these are stupid. Rule 5.15. Make sure you have access to the original process expertise to tune and maintain the system. The idea that these systems allow you to capture for prosterity expertise that is disappearing is a fallacy. These systems need to be adjusted and updated for unforeseen or changing conditions and mistakes. If the expert leaves, the expert system is not far behind.

Guided Tour
This tour illustrates the potential ease of use and convenience of an expertsystem interface for abnormal situation monitoring embedded in an industrial control system [5.3, 5.4]. The following areas are addressed: The engineering interface Accessing control system I/O Fact configuration Rule configuration Online debug capability Simulation support for check-out

When the expert system capability is embedded in the control system, standard fact templates are provided to access real-time information within the control system. This embedded capability is illustrated in Figure 5-4. Embedding the expert system within the control system makes it possible to use predefined fact templates to access measurement, calculations, events, and historical information in the control system. As part of the I/O processing done outside of the expert engine, dynamic analog values included as slots in the template are automatically compared to limit values to obtain a discrete value. Thus, when the discrete value of a slot changes state, the old fact is automatically retracted and the fact reinserted with the new slot value.

174

Advanced Control Unleashed

Figure 5.4. Embedded Expert System Capability

Through a special function added to the expert engine, a rule can write to any function-block parameter within the control system. A special block is provided in the control system to allow alarms and messages to be activated, as shown in Figure 5-5.

Figure 5.5. Expert Rules May Access Control System Blocks

The fact templates and rule templates provided in the expert system are made visible within the system in a hierarchical tree similar to Microsoft Windows Explorer file presentation. When a fact template is selected, a dialog is automatically presented to the user that can be used to define a fact. An example of the template provided to access parameters of a function block within the control system is shown in Figure 5-6. Rules can be written to meet specific application requirements. With the expert engine embedded in the control system, a rules editor is provided

Chapter 5 - Abnormal Situation Management

175

Figure 5.6. Fact Templates for Accessing Control System Information

that allows the features of the expert engine to be fully utilized. The fact templates can reference control system data in the left side of the rule. In addition, a special function is supported in the action, or right-hand, side of the rule that allows block parameters within the control system to be written. This capability is used to trigger alarms and to write messages to be shown in the operator interface. Also, this capability is used to directly interact with the control system by changing set point, mode of control blocks, etc. An example of the dialog used to define rules is shown in Figure 5-7.

Figure 5.7. Dialog for Configuring Rules

176

Advanced Control Unleashed

Once rules and facts have been assigned to execute on a PC node within the control system, the results of rule evaluation are examined. The expert system includes an option to examine the current state of facts and rules that have fired and are on the agenda, and to access statistics concerning the evaluation of rules. Based on this selection, the information about the rule evaluation is displayed in the right side of the expert system explorer view as shown in Figure 5-8:

Figure 5.8. Examining Rule Evaluation

To support the testing of an expert system, the expert engine has several online debugging features. Through the toolbar selection shown in Figure 5-9, the user may exert the following control over the expert engine's execution: Reset and Refresh Begin execution at a known point. Stop, Run, Run Once, Run to Limit control execution. Set Breakpoint, Remove Breakpoint Stop execution at a specific point. When an expert system is used for abnormal situation management, most of the fact slots are reflections of process measurements, the status of discrete inputs, etc. To check out rules and facts definitions, the user must be able to change the values used for fact slots without affecting the online configuration. This simulation support is built into the view provided to examine fact slots, as illustrated in Figure 5-10.

Chapter 5 - Abnormal Situation Management

177

Figure 5.9. Online Debugging support

Figure 5.10. Simulation Capability Used During System Check-out

When simulation is enabled on a fact, the user may change the value of fact slots. The icon associated with a fact changes, to flag the fact that the real value from the system is not being utilized.

Theory
Introduction to Expert Systems
The architecture of today's expert system is based on work going back to the early 1970's [5.5]. This aspect of artificial intelligence (AI) focuses on techniques to capture and reuse the knowledge of experts to solve difficult problems. Thus, the term "knowledge-based system" is synonymous with the term "expert system." The process of building an expert system is known as knowledge engineering. Since the introduction of commercial

178

Advanced Control Unleashed

expert system products, this technology has been successfully applied by the process industry in a variety of applications. The knowledge of an expert can be represented as rules and facts. If facts exist that match the pattern defined by a rule, then the rule is satisfied and executes its configured action. Unlike procedural program languages, such as C++, in which there is a tight interweaving of data and knowledge, expert systems allow for two levels of abstraction: data and knowledge. An inference engine applies the knowledge to the data and relies on pattern matching to guide execution. The inference engine determines which rules are satisfied by facts and executes these in the order of their assigned priority. There is no specified control flow as with procedural programming. The general structure of an expert system is shown in Figure 5-11.

Figure 5.11. Components of an Expert System

An expert system differs from conventional programming in that the solution relies on inferences rather than an algorithm. Often the human knowledge captured in rules is heuristic in nature; that is, input data can be incomplete, inconsistent or even incorrect. The user interface will typically allow various aspects of the expert system execution to be monitored. The user interface may also be used to enter facts.

Rules
The reasoning capability of the human mind is complex and difficult to fully explain. However, as early as the early 1970's, it was shown that much of human problem solving can be expressed by IF...THEN-type rules [5.6]. This model of human problem solving and inference is the

Chapter 5 - Abnormal Situation Management

179

basis of modern rule-based expert systems. The general structure of a rule is shown in Figure 5-12. The rule consists of a conditions part and a list of actions.

Figure 5.12. Rule Structure

The conditional part, or antecedent, of a rule may consist of one of more conditional elements. The simplest type of element is a pattern consisting of one or more constraints intended to match the fields of a template fact. For example, the format of the rule in the CLIPS expert system software [5.4] is shown in Figure 5-13.

Figure 5.13. CLIPS Rule Format

The expert system attempts to match the patterns of rules to the facts in the fact list. If all the patterns of a rule match facts, the rule is activated and put on the agenda. A rule will fire only once for a specific set of facts. This property, know as refraction, prevents an expert system from being caught in a loop where the same rule continues to fire. One of the most powerful features of expert systems is the capability to define variables that are later referenced in the left-or right-hand portion of a rule. Using this feature, it is possible to implicitly reference all instances of a fact in a single rule. Thus, as more fact instances are added, the same rule can be utilized. This unique feature of an expert system is used to define effective monitoring systems that are easily modified and maintained.

180

Advanced Control Unleashed

In a process control system, it is important that information within files in the control system be accessible by rules. To support this feature, most expert systems include a read function. The manner in which a read function is defined is specific to the expert system. Inference Engine The inference engine is the part of an expert system that matches facts to rules to determine which rule to execute. Expert systems may use several different inference methods. The two most common methods used by commercial expert systems for the inference engine are forward and backward chaining. Forward Chaining: Reasoning from facts to the conclusion resulting from these facts. If a rule has multiple patterns, then all of its patterns must be satisfied for it to be placed on the agenda for execution. Backward Chaining: Reasoning in reverse from a hypothesisa potential conclusion to be provento the facts that support the hypothesis. While some expert systems support both inference methods, others support only one. It is possible to accomplish backward chaining in a forward-chaining expert system by the manner in which the rules are structured. For diagnostic problems, backward chaining may provide the most efficient solution and often fits the way an expert expresses his knowledge. For monitoring applications that deal with abnormal situation management, forward chaining will in most cases provide the most efficient solution and better fits the problem definition. A rule whose pattern is satisfied (matched) is placed on the agenda and activated. Multiple rules on an agenda at the same time are activated or fired in their order of assigned priority. If rules are not prioritized, the order of solution depends on the order in which the rules were defined. After a rule has fired on a fact, the inference engine will not fire on that fact again. Activations are left on the agenda until it is determined that the lefthand side is no longer satisfied. As part of actions taken by a rule, it is possible to remove or add facts. The format of actions is often specific to the expert system. The inference engine normally executes on a period basis during which the impact of changes in facts are evaluated. Even in a small expert system, there are thousands of facts and hundreds of rules that must be constantly evaluated. Thus, the efficiency with which facts and rules are

Chapter 5 - Abnormal Situation Management

181

evaluated is of great importance in a real-time system. To achieve best efficiency, there is a need to be able to know the rules that apply without having to try each one sequentially. The Rete algorithm [5.7], developed in the late 1970's, is used in many expert systems to provide this efficiency in execution. Using this approach, information about rules is stored as a network. When the inference engine runs, it only looks for fact changes and their impact on matches in each cycle. Using this technique, it is possible to achieve dramatic improvements in the speed at which facts are matched. Facts In order for an expert system to solve a problem, it must have data or information for pattern matching. Groupings of this information are known as facts. In general, a fact will consist of a relation name and named slots with their associated values. An example of a fact, as defined in the CLIPS expert system software, is shown in Figure 5-14.

Figure 5.14. Fact Example

In this example, the symbol "Header" is the fact's relation name and the fact contains three slots: name, pressure, and temperature. The value of the name slot is "Steam," the value of the pressure slot is "1200" and the value of the temperature slot is "900." The order in which slots are specified in the fact is irrelevant. To facilitate implementation, groups of facts that share the same relation name and contain common information are described using a Fact template. Also, multi-slot capability is provided that allows multiple values to be defined for one slot. Groups of facts are stored in the expert system in the fact list. New facts may be added to the fact list using an Assert command. Similarly, the Retract command is used to remove facts.
Other Structures

In some cases, other technologies are combined with an expert system to achieve a specific goal. For example, the relationship between process inputs and a process output may in some cases be highly nonlinear. For this case, it is most effective to use a neural network to determine this rela-

182

Advanced Control Unleashed

tionship and then to use the expert system. The neural network output is used as a fact input to the expert system (rather that using the process inputs directly as facts). Such an implementation is illustrated in Figure 5-15.

Figure 5.15. Combining Neural Networks with Expert Systems

As a means of dealing with uncertainty, some systems utilize fuzzy logic. Some expert systems include fuzzy expert-system capability. To make such systems practical, they must also include a threshold in the pattern matching; otherwise the rules will fire for any nonzero antecedent [5.9].

References
1. Deaton, B and Blevins, T., "An approach to Mill Wide Control," ISA Conference, Houston, October 1986. 2. Flynn, J., "G-P Completes First Phase of Upgrade at 1,300-tpd Crossett Pulp & Paper Mill," Paper Trade Journal, August 15,1982, pp 17-22. 3. Tzovla, V. and Zhang, Y., "Abnormal Condition Management Using Expert Systems," ISA Conference, Houston 2001. 4. Giarratano, J. and Riley, G., "Expert SystemsPrinciples and Programming," PWS Publishing Company, 1998. 5. Buchanan, B.G and Mitchell, T. "Model-directed Learning of Production Rules," Pattern Directed Inference Systems, Academic Press, 1978, pp. 297312. 6. Newell, Allen and Simon, Herbert A., Human Problem Solving, PrenticeHall, 1972. 7. Forgy, Charles, "Rete: A Fast Algorithm for the Many Pattern/Many Object Pattern Match Problem," Artificial Intelligence, 19, 1982, pp. 17-37. 8. Fink, Gavin A., "Rules of Thumb for Implementing Expert Systems in Engineering," InTech, April, 1987, pp 33-37. 9. Mertz, Glenn E., "Application of a Real-Time Expert System to a Monsanto Process Unit," Chemical Manufacturer's Association Process Control Symposium, 1990.