Agent-Based Computer-Aided Process Engineering Zahia Guessoum1, Othmane Nadjemi1,2, Bertrand Braunschweig2, Pascal Roux2, Aidong Yang 3, E. S. Fraga4, Iain D. Stalker4, Daniel Pinol 5, Manel Serra5, Didier Paen6 1
OASIS team, Laboratoire d'Informatique de Paris 6, Paris, France
8, rue du Capitaine Scott, 75015 Paris (
[email protected]) 2
Institut Français du Pétrole, Technology, Computer Science and Applied Mathematics Department 3
4
RWTH Lehrstuhl für ProzessTechnik, Aachen, Germany Department of Chemical Engineering, University College London, London UK 5
Aspen Technology, Barcelona, Spain
6
RSI - Réalisation en Systémique Industrielle
Abstract This paper deals with the design process of component-based simulation. It relies on CAPEOPEN interoperability standard. We first propose an ontology (named OntoCAPE) to represent the domain knowledge. We then introduce an agent-based architecture to support the design of numerical simulation, with a concrete implementation in the process simulation domain.
1. Introduction Object-oriented programming, component software, and ntier architectures are the current paradigm for ComputerAided Process Engineering (CAPE) software development. Although there are other component-based architectures, the CAPE-OPEN interoperability architecture [Braunschweig 1999], based on object orientation and middleware, appears to be the dominant one, being adopted by a majority of players. CAPE-OPEN is now accepted as a standard for communication between simulation software components in process engineering. This leads to the availability of software components offered by leading vendors, research institutes, and specialized suppliers which enable the process industries to reach new quality and productivity levels in designing and operating their plants. The CAPE-OPEN standard facilitates new business models for process simulation software such as application service provision, and can be the foundation for web services in this domain. Our goal in the new COGents 1 IST project is to push this technology further by developing a 1
COGents = CAPE-OPEN aGents. For more information see http://www.COGents.org.
new approach to "e-CAPE". We use cognitive agents to support the dynamic and opportunistic interoperability of CAPE-OPEN compliant process modeling components over the Internet. The result is an environment which provides automatic access to best-of-breed CAPE tools when required wherever situated. For this purpose the COGents project: • defines a framework allowing simulation components to be distributed and referenced on the Internet and intranets; • defines representations of requirements and services in form of an ontology of process modeling (named OntoCAPE) expressed in DAML+OIL, thus developing the CAPE-OPEN standards in the semantic and knowledge-based dimensions; • designs new facilities for supporting the dynamic matchmaking of modeling components with knowledge-intensive middleware agents; • demonstrates the concepts through advanced software prototypes and test cases; • shows how the framework can be applied to other areas of numerical simulation. This paper aims to present some aspects of COGents. It is organized as follows: Section 2 presents OntoCAPE. Section 3 introduces the proposed agent-based organization and Section 4 describes its implementation. Section 5 presents the related work.
2. OntoCAPE In order to allow dynamic and opportunistic interoperability of modeling components, we define knowledge-based representations of modeling requirements and services. These representations are in the form of an ontology of process modeling (technically expressed in an object
model), and of a corresponding language, OntoCAPE, implemented in DAML+OIL. This knowledge-based representation provides semantic content on top of CAPEOPEN standard which is purely syntactic (i.e. consisting of specifications of input-output types allowing the technical interoperability of software components). This is the basis for a matchmaking process between user’s requirements and available services, therefore supporting opportunistic configuration of simulators. OntoCAPE is a conceptualization of process modeling, simulation and design which are the primary concern in COGents. It is used for the construction of the repositories of information characterizing Process Modeling Components (PMCs) which can be accessed by agents to perform process modeling. Furthermore, it is also a shared vocabulary used by the agents to understand the messages communicated to each other.
The part of OntoCAPE that enables the formalization of the problem is Modeling Task specification. It expresses the various requirements to be fulfilled in a modeling task. The main elements of Modeling Task Specification are: the modeled objects, their properties able to be specified/evaluated, and the PME2 in use (see Figure 2).
3. Multi-Agent Organization Several agent models have been proposed. Two main approaches can be distinguished: cognitive and reactive. In the cognitive approach, each agent contains a symbolic model of the outside world, about which it develops plans and makes decision in the traditional (symbolic) AI way. In the reactive approach, on the other hand, simple-minded agents react rapidly to asynchronous events without using complex reasoning.
SoftwareSystem
User
PME
PME
PMC
ProcessModel
1
Personal Assistant Agent
PME Wrapper
SolverComponent
ModelComponent
Library Components 1 ModelSolutionStrategy
Phy.Prop.Component
Internet Components
Figure 1: Process modeling component
From a technical point of view, there are several parts in OntoCAPE to formalize these functionalities. Software System is used to describe process modeling components and environments in term of supported interfaces, software/hardware requirements, selling/buying information, functionality, and usage limitation. Chemical Process System allows the definition of aspects like the realization; behavior and function of a plant being modeled (see Figure 1). ModelingTaskSpec
PME
preselected
(from ProcessModelingSoftware)
PurposeOfModeling
1
n
1 ModeledObject
ModelingRequirement
Robustness
Speed
Intranet Components
Modeling Task Manager Integration Manager Wrapper Agent Wrapper Agent
Match-Maker
DF
Wrapper Agent
Figure 3: Minimal Multi-Agent Architecture
In most existing agent-based systems, the organization is defined as a set of homogenous interacting agents which can be either reactive or cognitive. These homogeneous organizations are not suitable in the case of complex agentbased simulations. Thus, we propose a hybrid multi-agent architecture which combines reactive and cognitive agents. The problem is dynamically defined or adapted by the user to the situation. Figure 3 presents the minimum society of agents that we use to facilitate the design of numerical simulations. Several case studies have allowed to step forward the knowledge acquisition and design of this multi-agent organization: Automated design of Hydrodealkylation of Toluene (HDA) process [Douglas 1988], modeling the leacher unit in polyamide6 and synthesis of the HDA process.
Accuracy
2
Figure 2: Modeling Task Specification
PME (Process Modeling Environment): environments that support the construction of a process model.
3.1
Wrapper Agents
These agents manage the interaction between the existing software and the other agents of COGents. They may be distributed on the Internet or intranets. Their functionalities are represented by services. Each Wrapper Agent holds therefore a set of services that can be provided to the other agents. The first step in COGents was the definition of these agents and the elaboration of a generic design and implementation approach. We associate a Wrapper Agent to each CAPE-OPEN component. Each Wrapper Agent provides the following services: • Request a dynamic connection to component. • Invoke operations on the component. • Query the properties of the component. • Set the parameters of the component. • Manage the state of the component. • Terminate the service. The CAPE-OPEN component-based Wrapper Agents are generic. They can be therefore provided with the library of the various CAPE-OPEN components. These agents are useful to control the simulation. However, other agents are useful to facilitate the design of a simulation. These agents are: • PME Wrapper: manages the interactions between a PME and the other agents. It allows 1) to observe the designer’s actions, 2) to change the model when needed, and 3) to provide helps to the designer. • Library Wrapper: manages the interactions between the agents and an existing local library of components. It has a description of all the components of the associated library; they are described by instantiating OntoCAPE classes. OntoCAPE and these instances are used to process the received requests from other agents. • Internet-Component Wrapper: manages the interactions between the agents and existing library of components on Internet. It is similar to the Library Wrapper agent but it does not use the same tools to communicate with the associated components. These wrapper agents are often reactive. Their goal is to respond to the requests of the other agents (i.e. MatchMaker). For example, the two last ones receive requests with some properties of components. They process the request and send the results to the sender of the request. These results are descriptions of the components that match the requirements of the sender.
3.2
Cognitive Agents
We often consider that the simulation designer is an expert and the problem description is consistent. This designer can
therefore define the model, and then find and select the suitable components to build his solution. This is not always true: • The user does not always have the model, he/she may have only a part of the model or the problem to solve (Inputs/outputs) without the associated model. • The library of components is now very large. So, it is not easy to select the suitable components. • The designer may need a component that is not provided in the library. He has therefore to look for these components on the Internet and/or intranets. • It is not easy to avoid inconsistency. The designer cannot learn all the component characteristics. So, the combination of some components may evolve some inconsistencies. • The problem description is not always consistent and the user can change or update this description at any moment. So, what is right at one moment might become incorrect later. For example, the user can decide to replace one component by two other components to improve the efficiency of his simulation. In this section, we propose examples of cognitive agents that seem very useful: • Personal Assistant Agent: manages the interaction between the system and the designer (user). For each designer there is an associated Personal Assistant Agent which has knowledge of its user preferences and skills with regards to the application. The role of the designer in COGents is to build a simulation. So, the Personal Assistant Agent interacts dynamically with the designer to define the problem or the model. Moreover, it can help novice designer to learn the PME. • MatchMaker: selects the components in the library of components (catalog) or on the Internet and/or intranets that match a given description of the problem or a task specification.
• ModelingTaskManager: interacts with Personal Assistant Agent and uses OntoCAPE to define a consistent specification of the modeling task. • IntegrationManger: Manages the interaction between MatchMaker and PME Wrapper. It Provides extra support, when necessary, for the integration of components identified by the MatchMaker into the PME Wrapper. In particular, it translates the descriptions of selected components returned by the MatchMaker into a form usable by the PME Wrapper.
Another category of cognitive agents allows to observe the execution of this organization to 1) detect run-time inconsistencies, 2) improve the efficiency of the simulator, 3) detect failures of the components, etc. These agents have not been studied yet.
3.3
Examples of interaction diagrams
This section describes two scenarios to illustrate the interactions between the various agents. Figure 4 presents an interaction diagram which illustrates the needed agent interactions to find a suitable component. The user builds a simulation through the PME. PME Wrapper sends the given task description to Personal Assistant Agent. This user has been identified as a nonnovice user by Personal Assistant Agent. The latter sends therefore the given task description to Modeling Task Manager. The latter checks the consistency of this task description. If it is not consistent, it interacts with PME Wrapper to help the user to make it consistent. Otherwise, it sends a task specification to MatchMaker to select the components that match this modeling task specification. To find these components, MatchMaker needs to interact with Library Wrappers. If it has not their addresses, it sends an aPME Wrapper
aPersonal Assistant
aModeling Task Manager
ask-all message to the Directory Facilitator (DF) asking for all the available components libraries. DF provides therefore the addresses of the wrapper agents of the available libraries. MatchMaker sends then a call for proposal message to all these wrappers. The latter perform some reasoning to find components that match the description and propose to MatchMaker these components. MatchMaker selects components that match the task specification and sends these components to Integration Manager. Finally, the new model is sent to PME Wrapper which integrates this new model in the flow sheet. Figure 5 describes an interaction diagram which illustrates the process modeling of a more complex task. The latter requires decomposition in elementary tasks. The first steps are similar to the previous example steps (see Figure 4). But in this example, MatchMaker fails to find suitable components. It sends therefore a request to Modeling Task Manager. The latter interact with the use to decompose the task and sends back the new elementary task specifications to MatchMaker. The latter tries then to find the suitable components for each task specification.
Directory Facilitator
a Match Maker
aLibrary Wrapper2
a Library Wrapper1
1: inform 2: request
3: askAll
4: inform
5: cfp 6: cfp
7: propose
8: match 9: [hasMatchingComponents]inform
10: inform
Figure 4: Example of agent interactions to select a component.
an Integration Manager
aPME Wrapper
aPersonal Assistant
a Task Decomp
A Modeling Task Manager
Directory Facilitator
a Match Maker
aLibrary Wrapper2
a Library Wrapper1
an Integration Manager
1: inform 2: inform
3: request 4: request 5: askAll
6: inform 7: cfp 8: cfp
9: propose
10: match 11: [noMatchingComponent] decompose 12: request
13: newTasks
14: inform
15: cfp 16: cfp
17: propose 18: propose
19: match 20: [hasMatchingComponents] inform
21: inform
Figure 5: Example of agent interactions to decompose a task. relies on the framework DarX3. DarX allows to distribute agent in a very transparent way. In DIMA, agents communicate by using FIPA ACL (Agent Communication Language) [FIPA 1998]. Figure 6 gives an overview of the realized architecture.
4. Implementation
DIMA Agent platform
PME
DarX
KQML messages OntoCAPE ontology
CO interfaces
DarX
DIMA Agent platform
wrapper
PMC
CAPE-OPEN Framework COGents Framework
Figure 6: Architecture Technology
The various agents have been implemented with the platform DIMA [Guessoum and Briot 1999]. The latter provides a set of JAVA classes that have been reused to implement easily agents. The distribution of DIMA’s agents
To use OntoCAPE, DIMA has been enriched to provide agents with: 1) a DAML+Oil ontology and 2) an ontology reasoner (JTP –Java Theorem Prover- [Gleb 1999]). The message content can be described either in DQL (DAML Query Language) or KIF (Knowledge Interchange Format).
5. Related Work Several multi-agent systems have been proposed to support process engineering. A. Struthers [Struthers 1997] proposed an autonomous agent-based solution for the modeling of design processes. This solution is applied for organizing and managing a pressure relief and blowdown study. 3
for more information, see http://www-src.lip6.fr/darx/
R. Batres et al. [Batres et al., 1999] proposed an agent architecture for planning and control of a plant. These agents are based on the concept of controlled group unit (CGU) developed by Naka [Naka 1989]. P. Tichy et al. [Tichy et al., 2002] proposed a 3-tier multi-agent architecture for planning and control of HAVC (Heating Ventilating and Air Conditioning) where the bottom level has physical connection to the hardware and it is responsible for local real-time control, the middle level contains smaller group of agents, and the top level maintains the overall goal of the system and gives strategic decisions. These various agent-based solutions and architectures propose interesting solutions to simulate and to control processes. However, they do not use agents to support process modeling. Moreover, some work has been done in the field of software agents on the Internet. For instance, RETSINA (Reusable Environment for Task-Structured Intelligent Networked Agents) has been successfully applied in several domains such as financial portfolio management, personalized web information management and k-buying auctions [Sycara et al., 2002]. The most important concept in RETSINA is the matchmaking process using middle agents (MatchMaker agents). The use of a matchmaking agent facilitates the search of agents, by advertising and requesting services. This idea is similar to the one used in COGents to select the suitable components. Steven C. Laufmann [Laufmann 1997] provides a good example of the use of wrapper agents to integrate legacy systems into a multi-agent architecture for enterprise applications (see also [Wooldridge et al., 2001]). The use of wrapper agents in COGents facilitates the integration and control of components.
6. Conclusion This paper presented a new approach to facilitate the design of process models. This solution combines several technologies and paradigms to represent this knowledge: components, ontology and agents. It aims to integrate, in the system, the knowledge of several experts. A prototype has been realized to validate the proposed ontology (OntoCAPE) and the proposed agent-based architecture. Several case studies are used to validate the generic agent-based organization and refine the agent knowledge. Our first experiments are based on a local library of components. The next step is the validation of this architecture with several kinds of component libraries (local, Internet, intranets) and its validation on a real world application. Acknowledgments Project COGents, Agent-Based Architecture For Numerical Simulation, funded by the European Community under the
Information Society Technologies Program (IST), under contract IST-2001-34431.
7. References [Batres et al., 1999] R. Batres, S. P. Asprey, T. Fuchino and Y. Naka. A KQML Multi-Agent Environment for Concurrent Process Engineering. Computers & Chemical Engineering, Vol. 23, supplement, pp. S653-656, 1999. [Braunschweig 1999] Bertrand Braunschweig. Global CAPE-OPEN, Delivering the power of component software and open standard interfaces in computer-aided process engineering, European Commission Information Society Technologies Conference, IMS Special Event, Helsinki, Nov. 1999. [Douglas 1988] J. M. Douglas. Conceptual Design of Chemical Processes. McGraw-Hill International Editions, 1988 [FIPA 1998] FIPA 97 Specification. Part 2: Agent Communication Language. www.fipa.org. [Gleb 1999] F. Gleb. A General Interface for Interaction of Special-Purpose Reasoners within a Modular Reasoning System. In: Question Answering Systems. From the 1999 AAAI Fall Symposium, pp. 57-62, 1999. [Guessoum and Briot 1999] Z. Guessoum and J.-P. Briot, From Active Objects to Autonomous Agents, IEEE Concurrency. 7(3): 68-76, November 1999. [Laufmann 1997] S. C. Laufmann, Toward Agent-Based Software Engineering for Information-Dependent Enterprise Applications. IEEE Proceedings on Software Engineering 144(1): 38-50. January, 1997. [Naka 1989] Y. Naka. Operational Design. Process System Engineering Laboratory, Internal Report (in Japanese), Tokyo Institute of Technology (1989). [Struthers 1997] A. Struthers. Use of Intelligent Software Agents in an Industrial Pressure Relief and Blowdown Design Tool. In Comp. Chem. Engng. pp 83-89 1997. [Sycara et al., 2002] K. Sycara, S. Widoff, M. Klusch and J. Lu. LARKS: Dynamic Matchmaking Among Heterogeneous Software Agents in Cyberspace. Autonomous Agents and Multi-Agent Systems, 5, 173-203, 2002. [Tichy et al., 2002] P. Tichy, P. Slechta, F. Maturana and S. Balasubramanian. Industrial MAS for Planning and Control. In V. Marik et al. (EDs.): MASA 2001, LNAI 2322, pp. 280295, 2002. [Wooldridge et al., 2001] M. Wooldridge P. Ciancarini,, Agent-Oriented Software Engineering. First International Workshop, AOSE 2000, Limerick, Ireland, June 10, 2000.
