blackboard structure (agent or specialist) is in charge of the plan design in a certain abstraction level. Therefore, a primitive operation in a blackboard of.
A Control Model for Distributed Blackboard Architecture Based on Task Structures J. Palma, R. Marín, M. Balsa Artificial Intelligence and Knowledge Engineering Group (AIKE) Dpto. Informática y Sistemas. Univ. De Murcia. {jpalma, roque, mbalsa}@dif.um.es
S. Barro, P. Félix Grupo de Sistemas Inteligentes Departamento de Electrónica y Computación Facultad de Física. Univ. de Santiago de Compostela
ABSTRACT
Keywords
Knowledge Based Real-Time Systems for intelligent patient monitoring must present the following characteristics: (a) reactivity and opportunism compatible with goal directed control, (b) domain independent task structures, (c) heterogeneous problemsolving methods, and (d) temporal reasoning. Conventional architectures present these characteristics in a separated way. To build a system that presents all these features, we propose a new architecture, the fractal blackboard architecture . Our proposal consists of a set of distributed blackboard systems organised in a hierarchical way. Each blackboard system is a specialist in charge of a specific domain task. In its more general form, each specialist consists of a control mechanism, a temporal blackboard, a blackboard interface (which include a temporal consistency maintenance system), a communication module and a set of subspecialists. So, the specialists can be recursively decomposed on other specialists with the same internal structure. We call agents to the terminal elements in this hierarchical structure. This decomposition makes possible to carry out a hierarchical planning of tasks in different abstraction levels. In order to achieve the features mentioned above, we must extend the basic control mechanism of the conventional blackboard architecture. In our model, a control mechanism is based on a library of domain-independent task structures. The knowledge necessary for task planning and reactive behaviour can be found in these task structures.
Distributed Blackboard Architectures, Task Structures, Temporal Reasoning. INTRODUCTION
This work is part of a Knowledge-based Real-Time System for Intelligent Intensive Care Unit patient monitoring, focused on those patients presenting Acute Myocardial Infarction. In this intelligent monitoring, we include the electrical signal level monitoring, new pathology diagnosis and new treatment advising and monitoring. For intelligent patient monitoring, the system must present: (a) reactivity and opportunism compatible with goal-directed control, (b) domainindependent task structures, (c) heterogeneous problemsolving methods, and (d) temporal reasoning. In this paper, we present the description of the architecture that allows to design a system with the characteristics mentioned above. Obviously, to make possible for the system to present goal-directed control, we must use some kind of hierarchical planning. Hierarchical planning is a basic technique in Artificial Intelligence [1][2]. But in hierarchical planning, all the plan is designed on the top level, and then plan execution control is carried out level-by-level. Dynamic
and adaptive planning is impossible using this techniques since plan execution cannot be adapted to the new incoming information. Dynamic planning has been used in some systems such as GUARDIAN [3], RESUN [4] y BB1 [5]. In those systems, the planning is carried out by deciding which is the most suitable operator to apply in each step. To make this decision the system must take into account the current state and use the knowledge base that represents the application domain. In the system here presented, we have developed a hierarchical planning through different abstraction levels, that is, more concrete and detailed plans are designed in each planning step. This iterative plan refinement finishes when primitive operators are reached. These primitive operators represent the lowest abstraction level. Compare to other hierarchical planning system, our approach achieves more computational efficiency by reducing the amount of search needed. It also eases the task of knowledge encoding. Similar approaches to hierarchical planning can be found in [6][7]. As in [7], we have decided to use a distributed blackboard architecture, in which each blackboard structure (agent or specialist) is in charge of the plan design in a certain abstraction level. Therefore, a primitive operation in a blackboard of abstraction level i, corresponds to a native operation in a blackboard of abstraction level i+1. On the other hand, the need to combine reactivity with dynamic planning, forced us to introduce deliberative characteristics in system response generation. One of the most important requirements in Real-Time systems is the existence of some kind of event response mechanism (either internally or externally produced). One problem to be taken into account in this kind of system, is event overflow. This problem could be solved either by some filter mechanism or by some priority mechanism [3][8]. However, we have developed two new techniques for solving this problem. First, event overflow is partially prevented by the hierarchical organisation of the domain in different abstraction levels. Therefore, each one of the specialists/agents will only pay attention to the events of its corresponding abstraction level. The second technique we have developed, will be introduced in the following paragraph. The control model, proposed for our hierarchical and distributed planning approach, is based on a library of domain-independent task structures and relies on an extension of the basic control mechanism of conventional blackboard architectures [9]. The task
structure model, introduced by Chandrasekaran [10], differentiates substantially between the concept of task (which is the problem to solve) and method (how the problem must be solved). In other words, a task is a real world problem representation, and a method is the way in which this problem is solved, taking into account that a task can use alternative methods to solve the same problem. Each method represents a possible structure for the resolution process of the problem represented by the task. This task structure specifies its own decomposition into a set of subtasks, a data flow between subtasks and a control flow for the execution of the task. A task structure must be domain independent, so that it can be applied to different instances of the same task class, which can be found in other domains. In our model, we get the reactivity and opportunism characteristics from the blackboard architectures, and from the task structures, we get a way to represent adaptive planning behaviour. In order to integrate these characteristics, we present an extension to the task structure model. In this extension, we add a reactive behaviour to the representation of the adaptive planning behaviour. An important quality of our model, is that by making a dialogue control based on tasks declaratively represented in the task library, we get a clear separation between dialogue control and dialogue knowledge. This extension allows to enable or disable some event response of the system at the moment in which the task is applied, that is, when the systems have decided how to execute the task. Thus, the system will only respond to those events that are important at certain moment. In the following paragraphs, we will described the system architecture, the task structure library and the control mechanism for the task execution.
SYSTEM OVERVIEW
In order to achieve an intelligent monitoring system, we propose a hierarchical multiagent architecture made of a series of co-operative specialists/agents. In our system there is a specialist in charge of each of the main tasks: 1.Therapeutic specialist [11], for new treatment advising and monitoring.
2. Diagnostic specialist , for new pathology diagnosis. The diagnosis is based on electrical, hemodinamic and clinical information.
3.User Interaction specialist, for system and user communication.
KQML [13] based protocol (Knowledge and Query Manipulation Language). (b) Data Blackboard and Blackboard Interface. This module performs the specialist/agent data storage process (for example, in the interaction specialist, the information stored is related to
Figure Error! Unknown switch argument. . Hierarchical Specialist/Agent Architecture. 4. Electrical and hemodinamic signal acquisition specialist [12], for the patient direct perception. Each of these specialists is hierarchically decomposed into other specialists/agents, in order to carry out its function. In this schema, we call agents to the terminal elements of the hierarchy. An important characteristic of this design, is that all the specialists and agents have the same architecture (figure.1). Due to this property, we call this architecture, the fractal architecture .
patient clinical history). This blackboard has to handle temporal information, so it is necessary a blackboard interface to access it, in order to maintain temporal references and data consistence [14]. Thus, this module allows the system to make temporal reasoning over the application domain. Besides, the data blackboard can fired some events as response to data modification.
This architecture is composed of the following modules: (a) Communication Data Module. This module allows co-operation between the system specialists/agents. This co-operation relies on the data and control information interchange using a
(c) Control Mechanism. This is the architecture kernel, since it coordinates the functions which are carried out by the specialists/agents. In other words, it is in charge of the task planning and organisation. This module will be explained in more detail in next sections. In this fractal approach, the system is composed of an hierarchical topology of specialist/agents. This topology allows us two level of parallelism. First, each element
of the hierarchical topology can work concurrently with the other elements (co-operating through their communication modules). Second, several tasks can be executed at the same time in the same specialist/agent. CONTROL MECHANISM
As the system proposed here is to present the functionality described above, its architecture must be able to carry out:
As this figure shows, in task descriptions we need to know the name of the specialist/agent in charge of its execution and the name of the task. The model we propose is adapted to fractal architecture: specialists/agents hierarchical structure with reactive behavior. Apart from this information, a task has more information needed to meet the requirements described in the previous paragraph. This information can be divided into four parts: (a) Task control commands. The control commands
(a) Dynamic plan generation. The architecture must allow the dynamic and intelligent planning of commands received by the specialist. That is, the system must be capable to decide which is the most suitable operator that can be applied in the next planning step, taking into account the information about the other tasks being executed. (b) Reactivity. The system must have the capacity of yielding commands automatically as responses to previously activated events, making it possible for task planning to be adapted to environment change. Reactivity allows the system to automatically changes the focus as a response to some critical situations. One important thing that can be considered is that with this dynamic planning, the system may enable or remove some reactions (making the lists of possible events dynamic), delete some information or suspend other tasks. The rest of the paper will focus on the description of a control mechanism for dynamic plan generation and reactivity. The control mechanism we present, is made of a task structure library, a control blackboard and a control cycle.
Task structure library
This module keeps knowledge about domain tasks. Tasks structures are the basic elements of this library. A task is a process that carries out some activity, the execution of which is controlled by a specialist/agent. In order to make it easier to design this task library, we introduce a graphical representation of tasks. In this representation, a task can be described as in figure 2.
Figure Error! Unknown switch argument.. Generic Task. which the task can perform, are declared in this part. In some way, this part can be considered in the same way as object public methods, following the OOP (Object Oriented Programming) paradigm. In our architecture, tasks have the same control commands: start, stop, suspend and resume. A knowledge module is associated with each of the control commands, and is used to determine whether it is possible to process the control command. These knowledge modules make it possible for the interaction specialist some kind of adaptation, since a control command will only be processed if its associated knowledge module decides to process it. In our system, the dialogue state is taken into account to make this decision. (b) Action schema. In this part, the knowledge required for task execution planning is found. As well as having knowledge to indicate task decomposition, there is another knowledge module which is used to decide what the problem solving methods to be applied are. Thus, we achieve another way of adaptation, that is, the specialist adapts the task planning to the dialogue state by selecting the appropriate problem solving method. In figure 3, we can see how the alternative problem solving methods and task decomposition can be represented.
In our prototype, we have not considered alternative problem solving methods. We have only developed a task planning at a simple tasks decomposition level. Anyway, we are working in another prototype which includes this property. Punch and Chandrasekaran [15] propose a system, called TIPS, that may select amongst different problem solving methods.
(c) Reaction schema. This part allows the agent to show reactive behavior. In order to achieve this behavior, each task structure definition possesses a list of reactions which the task is able to respond to. We consider two kinds of reactions:
One of the most important attributes is the task execution state. From this attribute, the system knows how to handle the task at any given time. Another important attribute is the focus, which is the set of parameters which task structures can be applied to.
This graphical representation of tasks and reactions facilitates the task structure library definitions. This hierarchical task decomposition continues until a terminal task is reached. The execution of a terminal task consists of sending the corresponding control command to the agent in charge of its execution.
(a) Clock event reactions, used for those tasks that need to be fired under some temporal constraints. (b) Data blackboard reactions, for task which need to be fired under some data blackboard changes. The graphical representation of the reaction schema is shown in figure 4. Of course, it is possible for our approach to enable reactions in other agents and to respond locally to events produced in other agents
Figure Error! Unknown switch argument. . Reaction Schema. As can be deduced from the above discussion, three task types can be identified in our system: (a) Native tasks. These are tasks that appear in the roots of task decomposition trees and represent the tasks that can be invoked by other specialists. (b) Intermediate tasks. These are tasks used for the native task decomposition. (c) Terminal tasks. These are the tasks located at the bottom of task decomposition trees. They represent either a primitive task which has no decomposition and can be solved inside the specialist/agent using domain knowledge, or another agent native task. These terminal tasks allow the system to make some events filter, since low level events are isolated by agents in charge of terminal tasks. The higher level events, which can be called metaevents because they have higher semantic meaning, are processed in a specialist of a higher level.
Figure Error! Unknown switch argument.. Action Schema. (d) Task attributes. Here, we include all the information necessary to manage task execution.
As it can be deduced from our approach, terminal tasks in a specialist of level i become native tasks in the specialists/agents of level i+1. This correspondence
allows us to partition the domain in different abstraction levels.
This control mechanism is an extension of the conventional blackboard architectures Our control mechanism has a control cycle composed of four steps which are sequentially executed.
Control blackboard
Up to this point, we have only described tasks that can be processed by the user interaction specialist and how its execution has to be scheduled. But ¿How is the execution control really carried out?. When the specialist or agent receives a control command to execute a task, the first thing to be done is to find it in the task library. Once the task is found, a task instance is created with the same focus of the control command. This focused instance is placed in the control blackboard, becoming a Plan Element (PE). When the PE is created, the control mechanism proceeds with the task execution, that is, it applies its reactions and actions schema. Its reactions schema is placed in an area of the control blackboard in charge of it and enables all the reactions to which the system will be able to respond once the current task is instanced. The application of the action schema rises to the creation of the PEs associated with the root task decomposition. These new PEs are linked to the root PE in a tree structure and create control commands for its execution. It is also possible that new control commands for other PE’s may be created (for example, for stopping some task that is being executed). These control commands will modify the execution state of the other PE according to the new information and the new plan execution state.
1.
New event attention. In this step, control commands for the attention of all pending events are created. Of course, only events that have previously been enabled by a task, can be fired or in a pending state. Also, the first time there are no pending events so this step does not do anything.
2
New control commands attention. Once the pending events have been translated to their corresponding control commands, all pending control commands are attended, not only those produced by events but those produced internally (that is, as a result of same task decomposition) and received from other agents (that is, request for some native task).
3
Agenda updating. This step starts with the selection of those control commands whose knowledge modules verifie the preconditions for processing. Once a control command is selected, its actions and reactions schema are applied. This task execution implies the modification of control blackboard and the interaction specialist state. If a terminal task is reached during task decomposition, a control command is sent to the agent that must accomplish its execution. Of course, the creation and modification of existing EP’s is made in this step, becoming explicit the reasoning state.
4
Control command response attention. Once the selected tasks have been executed, the control cycle processes the responses of the control commands sent to other agents. This response processing can modify the hierarchical PE structure in the control blackboard. For example, if one of these responses indicate that the corresponding task has been successfully finished, it may be possible that the corresponding EP structure will have to be deleted since the task that generated it may be over. In this case, the control cycle will send a control task response to the agent which asks for the task execution.
With all, the control blackboard can be divided in two parts: (a) The planning environment, which manages the PE hierarchy. This dynamic part is used by the knowledge modules. (b) The active reactions list, where the reaction schema will be stored until they are not needed. This part allows the system to react to environment changes and user events. Control Mechanism
This is the module that controls and performs the executions of the task representation described above.
There is another module in the control mechanism that operates concurrently to the control cycle. This module is a reaction manager, the main function of which is to check up on the system clock and the data blackboard changes to produce the corresponding events only if they have previously been enabled.
This work was supported by the Spanish Comisión Interministerial de Ciencia y Tecnología (CICYT) under project TIC95-0604.
REFERENCES
CONCLUSIONS AND FUTURE RESEARCHS
1. Fikes, R. E. and Nilsson, N. J. “STRIPS: A New Approach to the Application of Theorem Proving to Problem Solving” . Artificial Intelligence 2, 189208 (1972).
The main contribution of our work is the extension of the task structure concept to include a reactive behavior, in addition to the active behavior. The inclusion of events and reactions into the task structure, allows the system to pay attention only to events which are important for the current reasoning environment. Conventional blackboard architectures must also be modified to make possible these task structures processing. For it, we have introduced new mechanisms in order to provide the system with the capability for managing a dynamic reaction schema, since the set of events, that the system can respond, may change during tasks execution. This is possible since tasks have knowledge about the events to be enabled or disabled when they are applied. Another important contribution is related to the system architecture. We have proposed a hierarchical distribution of specialists/agents, where each of the elements have the same internal architecture (this is the reason for calling this schema the fractal architecture). This distributed architecture allows specialists/agents co-operations through a communication module located in each specialists/agent. At this moment, we have two open research fields. First, we are developing a second prototype which has the possibility of choosing dynamically between alternative problem solving methods when tasks are applied. This new functionality forces us to modify both the task structure definition and the control mechanism. Second, we are designing a graphical tool that allows to define the task structure library. Finally, this architecture has been successfully proved in an system for temporal abductive reasoning and an adaptive user interface. The next steps are focused on applying this architecture to other application domains.
ACKOWLEDGEMENTS
2. Sacerdoci, E. D. Planning in a Hierarchical Data Structures. Artificial Intelligence 5, 115-135. (1974).
3. Hayes-Roth, B. and Collinot A. A Satisfying Cycle for Real-Time Reasoning in Intelligent Agents. Expert Systems with Applications, vol. 7, pp 31-42, (1994). 4. N. Caver and V. Lesser. A Planner for the Control of Problem Solving Systems. IEEE trans. On System, Man and Cybernetics, vol. 23, no. 6, pp 1519-1536. Nov (1993).
5. Vaughan Johnson Jr. and Hayes-Roth Barbara. Simultaneous, Dynamic Integration of Diverse Reasoning Methods. Blackboard Architecture and Applications. Academic press, Inc. 57-73. (1989) .
6. Michelle X. Zhou, Steven K. Feiner. Top-Down Hierarchical Planning of Coherent Visual Discourse. Proceedings of the International Conference on Intelligent User Interfaces. 129-136. (1997). 7. John F. Gilmore, Stefan P. Roth and Stephen D. Tynor. A Blackboard System for Distributed Problem Solving. B Blackboard Architecture and Applications. Academic press, Inc. 371-401. (1989) .
8. Michael R. Fehling, Art M. Altman and B. Michael Wilber. The Heuristic Control Virtual Machine: An Implementation of the Schemer Computational Model of Reflective, Real-Time Problem-Solving. Blackboard Architecture and Applications. Academic press, Inc. 191-218. (1989) .
9. Iain Craig. Blackboard Systems. Ablex Publishing Corporation. Norwood, New jersey (1995) 10. B. Chandrasekaran and Todd R. Johnson. Generic Tasks and Tasks Structures: History, Critique and Directions. Second Generation of Expert Systems, Springer-Verlag, pp 222-272, 1993.
11. M. Lama et al. Modular Architecture For Therapeutic Advice and Monitoring. Presented at EUROCAST’97.
14. M.A. Cardenas, R. Marin, I. Navarrete, M. Balsa. Resolution principle for temporal constraint fuzzy logic. Accepted in EIS'98.
12. S. Fraga, P. Felix, M. Lama and S. Barro, A Proposal for a Real Time Signal Perception Specialist. Accepted in EIS'98 .
15. W. F. Punch and B. Chandrasekaran. An Investigation of the Roles of Problem-Solving Methods in Diagnosis. Second Generation Expert Systems. Springer-Verlag, 673-688, (1993).
13. Tim Finin et al. An Overview of KQML: A Knowledge Query and Manipulation Language. KQML Advisory Group. 1992
