When an alarm sounds in an oil refinery, control-room operators may have only minutes to determine what to do: Shut down the process? Let it continue? For how long? The stakes, of course, can be enormous. A typical refinery processes 10 to 15 million gallons of oil every day. Each minute the refinery sits idle, thousands of dollars are lost. Yet the environmental and human costs can be staggering if poisonous, carcinogenic, or flammable substances are released from a plant. (Think Bhopal, 1984.)
In the Laboratory for Intelligent Process Systems, a small room on the second floor of Purdue University's (West Lafayette, IN) Chemical Engineering Building, Venkat Venkatasubramanian leads a top-flight research group toward a goal that is very much within its grasp: an on-line, real-time computer program for chemical and pharmaceutical plant operators that can quickly determine the cause of a process deviation and recommend action.
"We're interested in designing an intelligent control system that can help people figure out what is going wrong and what should be done about it," says Venkatasubramanian. The literature refers to this area of work as abnormal situation management, or ASM. "With ASM, you're reasoning backward from symptoms to causes."
Using the Purdue-developed computer program DKit, or Diagnostic ToolKit, operators will be able to do just that, and with more confidence than before in their decisions. Venkatasubramanian began laying the foundation for DKit in 1985, as he looked at different approaches to ASM. Reasoning backward is not easy, notes the professor: "It's a maze problem."
He worked on neural networks, trend monitoring, causal modeling, analytical modeling, and statistical techniques, each of which has peculiar strengths and weaknesses. No single approach addresses all the complexities of industrial-scale diagnostic problems. So, Venkatasubramanian thought, why not use all of them?
He combined the five approaches into DKit, which he compares to a panel of physicians called in to confer about a patient whose illness is particularly complicated. But just as with medical diagnostics, sometimes the five analytical tools provide conflicting opinions. "That's why DKit is equipped with a moderator, which we've called the scheduler. The scheduler pools recommendations, assesses the strengths and weaknesses that each tool brings to the diagnostic job, applies conflict-resolution algorithms, and comes to a conclusion." If DKit isn't able to offer one definitive answer, it still narrows the possible causes of an abnormal situation for the operator's consideration.
Of the five tools in the toolkit, oneQTA (qualitative trend analysis)was formally licensed by Honeywell in March 1999, for use in the design of its next-generation control system, Aegis. Venkatasubramanian's research team is currently testing QTA on real-time industrial data from an Exxon chemical plant. The tool will be tested at other plant sites this year.
QTA monitors a chemical process and, from a multitude of real-time, noisy data provided by sensors in the plant, extracts significant trends, such as a perturbation in the process that may lead to a runaway reaction. A process malfunction leaves a distinctive trendit's "fingerprint"in the sensors being monitored. QTA analyzes these trends to identify the underlying abnormality in the process. Representing them syntactically (see figures 1 and 2), the tool can relates how a particular sensor in the plant is performing.
Figure 1. QTA extracts data provided by a chemical plant's sensors and identifies process trends, following a grammar created by researchers. Figure 1 shows a set of primitive trends, which constitute QTA's "alphabet." A, for example, depicts no change; B depicts an exponential increase; C depicts a steady increase.
Figure 2. Figure 2a shows raw (noisy) output from a plant's sensors; figure 2b shows that output as a stream of primitive trends, as identified by QTA. Figure 2c shows QTA's conversion of these primitive trends to a smaller number of episodes, and figure 2d presents a trend profile, a "sentence" created by QTA that conveys the type and length of each episode.
Toward Safer Design
While DKit is designed to help plant operators with already established plants and processes another Purdue-developed computer program, HazopExpert, will help engineers design safer plants from the ground up.
"HazopExpert is the flip side of the coin: it goes from cause to consequence," says Venkatasubramanian. "Here, when people come up with designs for proposed plants, I should be able to evaluate all the potentially hazardous scenarios. What are the things that can go wrong in this plant? Are we protected against them? If not, what can we do about it?"
Traditional Hazop (hazard and operability) analysis, which is time- and expertise-intensive, seeks to identify every conceivable deviation from design intent and then identify all possible abnormal causes and adverse consequences that can occur in a chemical plant. A typical Hazop study takes a five- or six-member team of experts one to eight weeks to complete, at a cost of about $10,000 a week.
Up until 1992, says Venkatasubramanian, chemical engineers performed Hazop analysesporing over a plant's piping and instrumentation drawingsbecause it was simply a smart idea. In 1992, though, OSHA began requiring process hazard analyses for plants that are at the design stage or are being retrofitted, and at periodic intervals after a plant is up and running. Some 25,000 plant sites in the U.S. fall under the OSHA regulation; the chemical industry spends more than $2 billion a year on the analyses.
"The law resulted from Bhopal and other accidents," Venkatasubramanian notes. "Suddenly, industry became more interested in the Hazop work we were doing at Purdue."
Venkatasubramanian began trying to automate the routine aspects of Hazop analysis ten years ago. "Seventy percent of the analysis that Hazop teams do is routine," he says. "All plants have valves and pumps and controllers, for instance, so the failures and consequences are similar. They may not be identical, because of what is actually flowing through them, but the reasoning is similar." The remaining 30% of the analysis is specific to the particular plant design being reviewedand that's where human experts can most productively spend their time.
When he started work on the program, Venkatasubramanian immediately ran into a problem: "If you make the computer program very specific to a given plant, then you won't be able to use it for another plant. If you make it generic, then you won't have anything useful for a specific plant. How do you pull these two things together?" His answer: separate the kinds of knowledge required into process-specific and process-general.
Using HazopExpert, a human expert can supply process-specific informationthe plant's piping and instrumentation drawings, the names of the materials used in the processand draw on built-in models of reactors, distillation columns, tanks, and other components whose operations are fairly generic (see figure 2). Algorithms in the computer program make the specific and the general bodies of information "talk" to each other, and the human expert can view the resulting spreadsheets that identify potential hazards.
Figure 3. A digraph of a tank. This digraph and others form a HazopExpert library containing models of generic components. Blue rectangles represent abnormal-cause nodes; red rectangles represent adverse-consequence nodes. Working from the process diagram, a user can select a component (such as a tank), see the resulting digraph that appears, and determine potential hazards.
"Before the Hazop team meets," says Venkatasubramanian, "the leader can get an organized tour of potential problems in the plant and highlight the hazards. The software can condense a week's work to an hour, and free the team to apply its expertise to the most complex problems."
Created for the petrochemicals industry, HazopExpert has a variation, Batch HazopExpert, that is designed for manufacturers of pharmaceuticals and specialty chemicals. "We're in the process of commercializing these things," says Venkatasubramanian. "Batch HazopExpert is being tested now by G. D. Searle and Company (a division of Monsanto) in Chicago."
Ideally, says Venkatasubramanian, you'd like to have one comprehensive system that's both diagnostic, like DKit, and predictive, like HazopExpert. "It's the same problem," he notes, referring to the two programs. The Laboratory for Intelligent Process Systems' research group is taking up the challenge: "We're working on bringing the two sides together."
For more information: Venkat Venkatsubramanian, Professor, Purdue University, Chemical Engineering Bldg., West Lafayette, IN 47907. Tel: 765-494-0734. Email: firstname.lastname@example.org.
Adapted from Purdue Engineering Extrapolations, Spring 1999.