Intelligent Monitoring and Control

1 The Problem

Intelligent monitoring and control involves observing and guiding the behavior of a physical system toward some objective, with real-time constraints on the util­ ity of particular actions. Control theory([Bollinger and Duffie, 1988],[Hale, 1973]) is useful for tasks that permit a straightforward mapping between sensed data values and appropriate control actions . By contrast, we are con-

*This research was supported by grants from DARPA and NIH and by gifts from Rockwell International Corp. and FMC Corp. The Palo Alto VAMC supports Adam Seiver's participation in the project. We gratefully acknowledge con­ tributions by Reed Hastings and Nicholas Parlante to an early version of Guardian and to Adnan Darwiche, who recently joined the project. We have benefitted from discussions with Lawrence Fagan and his students, who are working on a re­ lated ICU monitoring system, called 'QQ.' We thank Edward Feigenbaum for sponsoring the work at the Knowledge Sys­ tems Laboratory.

Adam Seiver

Palo Alto Veterans Administration Medical Center 3801 Miranda Avenue

Palo Alto, California 94304

cerned with tasks that require a more "intelligent" ap­ proach, including: interpretation and prediction of sys­ tem behavior, diagnosis of exceptional events, explana­ tion of causal mechanisms, reactive response to urgent events, reasoned response to other events, and planning of longer-term courses of action. Such tasks occur in a variety of domains, for example: process control, cri­ sis management, construction management, equipment monitoring, tutoring, and medical monitoring([Fagan, 1980], [Fagan et al., 1980], [Hayes-Roth, 1989],[Pardee and Hayes-Roth, 1987], [Raulefs et al., 1987]).

Our goal is to develop a generic AI architecture for intelligent monitoring and control, suitable for applica­ tion in multiple domains. In addition to its potential practical utility, this research addresses fundamental AI issues, including: reasoning methods, knowledge repre­ sentation, resource allocation, distributed intelligence, and real-time performance. In this paper, we propose an architecture and illustrate it in the domain of pa­ tient monitoring in a surgical intensive care unit (SICU) . Section 2 identifies important generic requirements for intelligent monitoring and control and illustrates them for the SICU monitoring task. Section 3 presents the proposed architecture, illustrates it with an experimen­ tal SICU monitoring system called "Guardian" , and dis­ cusses how the architecture addresses the requirements. Section 4 illustrates Guardian's performance on a char­ acteristic scenario. Sections 5 and 6 discuss the general­ ity and limitations of the architecture.

2 Requirements

We aim to address generic AIS requirements for: integra­ tion of perception, reasoning, and action; integration of multiple reasoning activities; reasoning about complex, time-varying systems; coordination of multiple response modes; and dynamic allocation of limited computational resources.

Consider SICU monitoring. Patients in the SICU have had major surgery and suffer temporary failure of one or more organ systems. Therefore, life-support devices as­ sume the fundamental functions of the ailing organ sys­ tem until it can heal and resume its normal function . For example, a ventilator is an artificial breathing machine. Most life-support devices have sensors that measure rel­ evant parameters of physiological function and settings to determine how much assistance the device provides .

The ventilator has sensors that measure gas pressures and flows in the patient-ventilator system. It has set­ tings that determine the number of breaths delivered to the patient per minute, the volume of air blown into the lungs on each breath, and the percent oxygen used to enrich the breathing mixture. In addition to these automatic measurements and controls, SICU monitor­ ing involves other regular observations (e.g., chest xrays, taken once or twice a day), discretionary observations (e.g., laboratory tests of blood gases), and therapeutic actions (e.g., adjustment of a ventilator tube).

Because life-support devices injure as well as sustain patients, one objective of SICU monitoring is to wean the patient from the device as rapidly as is possible and consistent with other therapeutic objectives. Based on a model of the patient's physiological impairment and expected rate of recovery, the physician orders an ini­ tial configuration of device settings that substantially augment the patient's own function, followed by a pro­ gram of modifications to those settings that gradually (over a period of days or weeks) reduce the level of assis­ tance to zero, followed by device withdrawal. Given the complexity of the biological system, the characteristic instability of post-surgical patients, and the duration of the weaning period, however, the patient model may be imprecise or incorrect. Accordingly, SICU staff monitor the patient closely so as to validate the assumptions un­ derlying the weaning plan, refine the plan to coordinate with the detailed progress of the patient's physiological function, modify the plan when the underlying assump­ tions prove incorrect, and perform additional actions to diagnose and correct other unanticipated problems.

SICU monitoring instantiates the above requirements as follows . It requires integration of perception of patient data; reasoning about the patient's condition, progress, and therapy; and actions to implement or recommend therapeutic interventions. It requires integration of rea­ soning activities for: interpretation of patient data, di­ agnosis of observed signs and symptoms, prediction and explanation of the patient's progress, reaction to urgent patient conditions, and planning of longer-term therapy. It requires reasoning about the behavior of an impaired biological organism, partially sustained by physical de­ vices, over a period of days or weeks. It requires coordi­ nation of: immediate reactive responses to emergencies, prompt associative responses where clinical knowledge is applicable, and deliberate reasoned responses to complex or evolving patient conditions. It requires dynamic al­ location of limited computational resources among com­ peting monitoring activities presenting variable and un­ certain resource requirements.

3 Proposed Architecture

Figure 1 illustrates the proposed architecture, as cur­ rently implemented for Guardian . The following sections describe the top-level system organization, reasoning ar­ chitecture, reasoning skills, and knowledge representa­ tion.

3.1 Top-Level System Organization

To enable a monitoring system to interact with a dy­ namic environment, our top-level system organization ([Hayes-Roth, 1987b], [Hayes-Roth, 1989], [Hayes-roth et a/., 1989]) provides several types of loosely-coupled subsystems: (a) a central reasoning system performs all knowledge-based reasoning; (b) a communication interface mediates 1/0 between the reasoning system and all perception/ action subsystems via shared 1/0 buffers[Hewett and Hayes-Roth, 1989]; (c) each of sev­ eral perceptual subsystems comprises sensors and an as­ sociated preprocessor that interprets and filters sensed data according to instructions from the reasoning sys­ tem [Washington and Hayes-Roth, 1989]; and (d) each of several action subsystems comprises effectors and an associated driver that interprets and executes action pro­ grams according to instructions from the reasoning sys­ tem. For example, in Guardian, a single preprocessor handles inputs from all sensors associated with a patient­ ventilator-laboratory simulation. Several drivers handle graphical displays and user interactions on different deVICeS.

Different subsystems and their constituent processes operate concurrently, enabling a monitoring system to perform each of its three basic functions-perceive events in the environment, perform actions that affect the en­ vironment, and reason about its monitoring activities­ without interrupting or otherwise interfering with one another. The results of these activities influence one another asynchronously. For example, Guardian simul­ taneously perceives new patient data, conducts its ongo­ ing reasoning, and performs intended user interactions. It incorporates newly perceived patient data into its rea­ soning as those data appear in its input buffers and per­ forms newly intended actions determined by its reason­ ing as they appear in its output buffers.

The proposed organization also provides complexity­ management functions. Preprocessors shield the reason­ ing system from the mass of non-critical data generated in the environment . For example, Guardian's patient simulation produces values for twenty variables, each sensed up to ten times per second, and its laboratory simulation produces values for several other variables, as requested, and returns them with realistic time delays. By contrast, the reasoning system currently incorporates at most one input per second. Guardian's preprocessor protects it from data overload, while insuring that it no­ tices important data, by abstracting sensed data (e.g., as critical values, averages, or trends) and filtering the abstract values according to Guardian's current focus of attention. Conversely, drivers relieve the reasoning system of the details of action execution. For example, Guardian's drivers handle programs that explain reason­ ing activities and results.

Finally, this organization supports immediate reactive response modes by permitting a tight coupling of sensory input to action execution within perception/action sub­ systems. For example, Guardian's display drivers con­ duct low-level user interactions-e.g., menu-driven elabo­ rations and explanations-without mediation by the rea­ soning system. We discuss architectural support for other response modes below.

3.2 Reasoning Architecture

We adapted the dynamic control architecture[Hayes­ Roth, 1985], implemented as BB1 [Hayes-Roth and Hewett , 1988], for the reasoning system. As shown in Figure 1, all reasoning operations occur in a global mem­ ory that contains all of the facts, inferences, events, plans, etc. known to the system. The architecture it­ erates a three-step reasoning cycle. First, the agenda manager identifies reasoning operations enabled by re­ cent perceptual events appearing in the input buffers and cognitive events produced by prior reasoning op­ erations. Second, the scheduler chooses as the next op­ eration the one that best matches the current control plan. Third, the executor executes the chosen operation, changing information in the global memory-possibly the control plan itself-and recording a corresponding cogni­ tive event.

This architecture supports the several different reason­ ing skills required by a monitoring system (discussed be­ low) and enables it to integrate execution of those skills by interleaving their constituent reasoning operations. (We are investigating parallel execution of distributed reasoning tasks [Hayes-roth et al., 1989].) More impor­ tant, concurrent reasoning activities can influence one another asynchronously by recording and inspecting re­ sults in the global memory. For example, Guardian has reasoning skills for classifying input data and diagnos­ ing problems. By performing these tasks concurrently, it can reason about problems in dynamic biological sys­ tems, classifying relevant new data as they occur and immediately incorporating them into its ongoing diag­ nosis.

The architecture also enables a monitoring system to allocate its limited computational resources among competing monitoring activities. By interleaving con­ trol planning operations with other reasoning operations, the system incrementally constructs and modifies con­ trol plans for its own behavior in real time. Control plans may describe intended behavior at variable lev­ els of specificity and for variable time intervals. At each point in time, the system behaves in accordance with its current control plan. Thus, a system can in­ tegrate opportunistic responses to unanticipated events with carefully planned courses of action ([Hayes-Roth, 1987a], [Johnson and Hayes-Roth, 1987]) . For example, given an observed problem, Guardian decides which of two diagnostic methods to use. If the problem is not serious or occurs at the same time as many other prob­ lems, Guardian respoads reactively and moves on to the next problem. However, if the problem is potentially se­ rious or occurs during an uneventful period, Guardian might undertake its more analytic, but computationally expensive model-based reasoning.

3.3 Reasoning Skills

As discussed above, intelligent monitoring and con­ trol requires multiple reasoning skills. Guardian has domain-independent skills for: (a) determining appro­ priate perceptual filters, based on the system's avail­ able resources and ongoing tasks[Washington and Hayes­ Roth, 1989]; (b) abstracting perceived data as temporal episodes of defined value categories; (c) diagnosing the most likely causes of commonly observed problems based on Bayesian belief networks[Pearl, 1988]; (d) explain­ ing the causal mechanism underlying a diagnosis based on explicit structure/function models [Hayes-Roth et al., 1988]; (e) generating plausible diagnoses for unfamiliar problems or those for which the most likely diagnosis is incorrect based on structure/function models [Hayes­ Roth et al., 1988]; and (f) identifying standard actions for commonly diagnosed problems based on association networks.

In developing these reasoning skills, we emphasize a monitoring system's need to coordinate multiple re­ sponse modes. As discussed above, tight coupling of sen­ sory input to action execution in perception/action sub­ systems provides an immediate reactive response mode. Reactive response is appropriate for critical events or those that do not merit more careful situation assess­ ment and planning. Guardian's reactive management of low-level user interactions falls in the latter cate­ gory. Although some investigators argue for exclu­ sively or primarily reactive response modes([Agre and Chapman, 1987], [Brooks, 1985], [Firby, 1987], [Nils­ son, 1988]j [Rosenschein and Kaelbling, 1986], [Schop­ pers, 1987 ), we believe that many monitoring and con­ trol tasks require reasoned response modes as well[Hayes­ Roth, 1987a].

For example, our belief-network operations for diag­ nosing common problems and identifying standard cor­ rective actions are associative. By performing instances of these two operations in succession, Guardian responds quickly, on the order of seconds in the current implemen­ tation, performing the standard corrective action for the most likely diagnosis of an immediate problem. We could further reduce the associative response time by combin­ ing diagnosis and action in a single operation. However, the current response time is satisfactory in Guardian's domain and the interruptability between diagnosis and action is useful. Associative response is appropriate for situations that require knowledge-based reasoning­ though not very deep-and prompt response.

By contrast, our model-based methods for diagnosis and planning (the latter is not yet implemented) are ana­ lytic. By exploiting these skills, guardian responds more slowly, on the order of minutes in the current implemen­ tation. It develops an explicit model of the causal mech­ anism underlying the observed problem, plans a course of action-in some cases, coordinated with the patient's changing condition-based on that model, and instanti­ ates that planned course of action in real time. Model­ based response is appropriate for unfamiliar problems, problems that require a precise or longer-term course of action, or problems that require actions synchronized with external events.

The explicit control provided by our reasoning ar­ chitecture allows a system to choose among alternative reasoning activities and to interleave multiple activites. Thus, Guardian can instruct perception/action subsys­ tems to react in specified ways to specified input data. Given a problem that requires reasoning, Guardian can decide between associative and model-based responses. Alternatively, it can combine associative diagnosis with model-based action or combine model-based diagnosis with associative action. In some cases, it may respond to a problem reactively or associatively, and then plan a longer-term course of action.

3.4 Knowledge Representation

As discussed above, our reasoning architecture presumes a globally accessible memory. For this purpose, we use a conceptual network representation[Sowa, 1984], with predefined architectural concepts (for example, percep­ tual and cognitive events, control plans, reasoning opera­ tions). We have begun to develop an ontology of generic monitoring concepts and conceptual respresentations in three areas. Reasoning knowledge includes generic op­ erations and control strategies for component reasoning skills, such as those discussed above. Domain knowl­ edge includes both associative knowledge and factual knowledge. For example, Guardian's associative knowl­ edge currently includes: networks relating semantic cate­ gories to value ranges for each measured patient variable; Bayesian belief networks[Pearl, 1988] relating commonly observed signs to likely underlying faults; and associ­ ation networks relating likely faults to standard treat­ ments. Its factual knowledge currently includes explicit structure/function models of the normal anatomy and physiology of the respiratory, circulatory, pulmonary ex­ change, tissue exchange, and tissue metablism systems and a similar model of the ventilator. First-principles knowledge includes domain-indendent knowledge of the physical world. Guardian currently has knowledge of the normal and abnormal structure and function of generic flow, diffusion, and metabolic systems, which it uses to diagnose or explain problems in particular organ systems[Hayes-Roth et al., 1988].

4 Illustrative Performance

4.1 Guardian Implementation

Guardian is a prototype SICU monitoring system. It is designed within the architecture described above, im­ plemented in CommonLisp, and runs on a configuration of TI Explorers, (see Figure 1). Guardian can handle a growing variety of SICU scenarios. In this section, we discuss its performance on a scenario that illustrates how the underlying architectu.re enables Guardian to meet the generic requirements introduced in section 2.

Before discussing the scenario, we make a few obser­ vations. First, all of the capabilities discussed below are implemented except as noted in the text. Second, the references to real time are approximately correct, with . accumulated error on the order of minutes, due to un­ controlled variability in network communications times. Third, although Guardian can exercise closed-loop con­ trol over the patient-ventilator simulation, it would be allowed to act only in an advisory capacity in the hos­ pital. In this scenario, we model the hospital situation, with the assumption that SICU personnel promptly exe­ cute all actions recommended by Guardian. Fourth, for brevity, we omit the details of communications between the reasoning system and perception/action subsystems. However, in every case of perception, the perceptual sub­ system relays input data to the communication interface, which inserts it in the appropriate input buffer in the reasoning system. Conversely, in every case of action, the reasoning system places an action description in an appropriate output buffer, from which the communica­ tion interface retrieves it and relays it to the appropriate action subsystem. Finally, also for brevity, we omit dis­ cussion of Guardian's extensive graphical displays and user interactions. In fact, Guardian displays all of its observations, inferences, and recommendations as they occur.

4.2 Overview of the Scenario

In this scenario, Guardian monitors a ventilator-assisted SICU patient who has just returned from the operating room. The physician has ordered standard ventilator set­ tings, including a breathing rate of 8 breaths per minute and a tidal volume of 1200cc.

As we shall see, the scenario includes two errors. The first is the physician's error in ordering standard venti­ lator settings. Post-surgical patients typically are cold upon their return from the operating room. Because a low temperature slows down metabolism, patients need to breath more slowly-lower rate or tidal volume or both-than patients with normal temperatures. Other­ wise, they will exhale too much C02 , causing a low par­ tial pressure of C02 in the arterial blood, a condition known as 'hypocapnia.' Of course, a post-operative pa­ tient will warm up to normal temperature during the next two hours. Therefore, the physician should order a low initial breathing rate (say 6 breaths per minute), gradually raised to the normal 8 breaths per second as the patient's temperature rises to normal. Although physicians understand such relationships very well, it is not unusual for this kind of error to occur in communi­ cations with SICU staff. The second error is Guardian's error in failing to notice that the standard ventilator settings are inappropriate, given the patient's temper­ ature . Again, it is not unusual for SICU staff to make this kind of error, either by oversight or because they are busy elsewhere. Although Guardian could easily avoid making this particular error, we allow it to occur in the scenario to illustrate how Guardian can recover from its own errors or those made by others.

4.3 Getting Started

Beginning at 1:00, Guardian decides to follow standard set-up procedures for monitoring a newly post-surgical patient. It sends its preprocessor a standard initial fil­ ter for each patient variable: 'send a newly sensed value only when (a) it differs by at least p% from the previ­ ously sent value; or (b) at least m minutes have elapsed since the last value was sent.' Guardian begins classify­ ing the filtered patient data as they arrive and organiz­ ing them in temporal episodes of known value categories. During the first few minutes, Guardian adjusts filters for individual variables to approximate the maximum data rate it can handle in real time without overflowing its input buffers. Guardian also requests an initial analysis of blood gases from the laboratory simulation. It decides to inspect the lab results when they return in approxi­ mately 20 minutes. During the remainder of this time period, Guardian interprets input data. All twenty vari­ ables remain normal, except for the patient's tempera­ ture, which is low. Because this is not critical, Guardian ignores it .

4.4 Reactive Response

At 1:20 when the requested lab result returns, Guardian classifies it as 'low PaC02-hypocapnia.' Although both associative and model-based response modes are possi­ ble, Guardian chooses the associative mode by default. It diagnoses 'hyperventilation' as the most likely cause of the observed hypocapnia and determines that 'decrease the breathing rate to 6' is the most appropriate action. Guardian advises SICU staff to take that action and de­ cides to request another lab test in twenty minutes to confirm the effect of its action. It continues to interpret input data.

At 1:40 Guardian requests another lab test and decides to evaluate it-expecting a normal result-when it returns. It continues to interpret input data.

At 2:00 the lab test returns and Guardian confirms the expected normal PaC02. It decides to request another lab test and to evaluate the result when it returns. It continues to interpret input data.

At 2:20 when the lab test returns, Guardian classifies it as 'high PaC02-hypercapnia.' Responding associa­ tively, it diagnoses 'hypoventilation' as the most likely cause and determines that 'increase the breathing rate to 7' is the most appropriate action. It advises SICU personnel to take that action and continues to interpret input data.

4.5 Model-Based Reasoning

At 2:22, given the patient's two successive PaC02 prob­ lems, Guardian decides to analyze the causal mechanism underlying these problems more carefully. Because its knowledge of model-based reasoning methods specifies high computational requirements, Guardian conserves resources by adopting stronger perceptual filters: 'send sensed values only when (a) they differ from previously sent values by at least twice the current change thresh­ old; or (b) at least twice the current allowed time interval has elapsed since the last value was sent .' As a conse­ quence, Guardian continues to interpret new input data, but spends less of its computational resources doing so. In a distributed implementation , Guardian could assign its model-based reasoning task to a remote processor. However, any system having limited computational re­ sources will encounter situations in which it has a re­ duced capability for reasoning about new inputs and, therefore, should adopt different perceptual filters.

Guardian uses its domain knowledge and first­ principles knowledge to construct models of alternative hypothetical faults that could cause the observed prob­ lems. Among its several hypotheses are these two. 'Hy­ pothesis A: Decreased PaC02 is caused by high breath­ ing rate. Decreased partial pressure of C02 in the ar­ teries is caused by decreased partial pressure of C02 in the pulmonary exchange system, which is caused by de­ creased amount of C02 in the respiratory system, which is caused by increased delivery of other gases from the ventilator, which is caused by high breathing rate set at the ventilator.' 'Hypothesis B: Decreased PAC02 is caused by low temperature. Decreased partial pressure of C02 in the arteries is caused by decreased delivery of C02 from the tissue exchange system, which is caused by decreased delivery of C02 from the tissue metabolism system, which is caused by decreased production of C02 by the tissue metabolism system, which is caused by de­ creased consumption of 02 by the tissue metabolism sys­ tem, which is caused by low temperature.'

Guardian distinguishes these two hypotheses from oth­ ers it constructs for different reasons. Hypothesis A pro­ vides a causal rationale for Guardian's reactive diagno­ sis, 'hyperventilation,' and corrective action, 'lower the breating rate to 6.' Hypothesis B identifies a previously observed (and ignored) problem, 'low temperature,' as a causal factor in hypocapnia.

Guardian constructs and distinguishes the correspond­ ing two hypotheses to explain the patient's subsequent hypercapnia. 'Hypothesis C: Increased PaC02 is caused by low breathing rate.' 'Hypothesis D: Increased PaC02 is caused by high temperature.'

Now Guardian observes that the patient's tempera­ ture was lower at 1:00 (when the blood sample showing hypocapnia was taken) than it was at 1:40 (when the blood sample showing normal PaC02 was taken, and lower then than it was at 2:00 (when the blood sam­ ple showing hypercapnia was taken). Given these ob­ servations, Guardian should build a more encompassing model relating the patient's temperature, its own set­ tings of breathing rate, and the resulting variations in arterial C02 throughout the monitoring period. Given its knowledge that the patient's temperature will return to normal, Guardian should predict that its recent in­ crease in the breathing rate will eliminate the patient's present hypercapnia only temporarily. Indeed, Guardian should have predicted that its original lowering of the pa­ tient's breathing rate would eliminate the patient's orig­ inal hypocapnia only temporarily, leading eventually to the present hypercapnia. (Note: We are now implement­ ing this prediction skill.)

4.6 Planned Response

Although Guardian could eventually stabilize the pa­ tient's arterial C02 at a normal level with a normal breathing rate and temperature by continuing to respond associatively, the resulting alternation of normal PaC02 and hypercapnia episodes would be a suboptimal route to that goal. Instead, Guardian should plan to coordi­ nate changes in breathing rate with changes in temper­ ature, so as to maintain a normal PaC02 throughout: 'Increase breathing rate by 10 percent for every 1 de­ gree increase in temperature, expected to occur every half hour.' Having done so, it should follow this plan, reinstate its original perceptual filters, and resume its original rate of interpreting input data. It should inter­ leave planned operations to confirm expected increases in temperature and make associated increases in breath­ ing rate. (Note: We are now implementing this planning skill.)

5 Generality

To maximize the generality, extensibility, and reusabil­ ity of the proposed architecture, we designed it in lay­ ers. The system organization and reasoning architecture are application independent. The reasoning skills, first principles, and domain knowledge apply to successively narrower classes of applications. By modifying their con­ tents, we can extend a given application or develop a new one. For example, we are extending Guardian's exper­ tise incrementally at all three levels. With its original reasoning skills (data classification, associative diagno­ sis, and model-based diagnosis), first-principles knowl­ edge (generic flow systems), and domain knowledge (the respiratory system), Guardian classified respiratory data and performed associative and model-based diagnosis of certain respiratory problems. With new knowledge of the circulatory system, Guardian handled similar prob­ lems in the circulatory system. Given a new reasoning skill for model-based explanation, Guardian explained the causal mechanisms underlying diagnosed problems in both systems. With addititional reasoning skills (reac­ tive response), first-principles knowledge (diffusion and metabolic systems), and domain know ledge (the tissue exchange and metabolic systems), the current version of Guardian handles a range of problems arising within each system or from interactions among systems. By replacing Guardian's knowledge at particular levels , we could create new monitoring systems. For example, a power plant monitor might combine Guardian's reason­ ing skills and generic flow models with new knowledge of the structure and function of power plants. Simi­ larly, a materials processing monitor might incorporate Guardian's reasoning skills with new generic models for heating, cooling, and compaction processes and new do­ main knowledge of particular materials processes.

6 Limitations

In addition to obvious limitations on the amount of knowledge currently implemented, the proposed archi­ tecture has (at least) two more fundamental limitations.

First, like all AI techniques, the proposed architecture must pass the test of scalability. There are many rele­ vant scaling factors, including: number of data variables, sensed data rates, number of alternative diagnoses, num­ ber of co-occurring and interacting problems, complexity of physical models, and number and complexity of alter­ native responses. We need to investigate how a system's performance degrades as we increase its complexity along these dimensions.

Second, intelligent monitoring and control is a real­ time task, imposing hard and soft time constraints on the utility of observations, conclusions, and responses. The proposed architecture includes features designed to give a monitoring system knowledge-based control over its resource allocations in order to address real-time con­ straints. These features are its programmable perceptual preprocessors and action drivers and its dynamic con­ trol of reasoning behavior . However, we have not yet provided an explicit representation of time or a quanti­ tative basis for making time-constrained resource alloca­ tions. In addition, the BB1 execution cycle involves un­ bounded computation times, which can undermine even the most "intelligent" resource allocation behavior . We are attempting to address both of these limitations in ongoing research.