Multi Agent Systems for Decision Support A Case study in the transportation domain

Citation preview

Applied Artificial Intelligence, 18:779 795, 2004 Copyright # Taylor & Francis Inc. ISSN: 0883-9514 print/1087-6545 online DOI: 10.1080=08839510490509018

u

MULTI-AGENT SYSTEMS FOR DECISION SUPPORT: A CASE STUDY IN THE TRANSPORTATION MANAGEMENT DOMAIN SASCHA OSSOWSKI Department of Computer Science, Universidad Rey  stoles (Madrid), Spain Juan Carlos, Mo

JOSEFA Z. HERNA´NDEZ Department of Artificial Intelligence, Universidad Polite´cnica de Madrid, Boadilla del Monte (Madrid), Spain

MARI´A VICTORIA BELMONTE tica, Universidad de Ma laga, ETSI Informa laga, Spain Ma

JOSE´ MASEDA Information Society Unit, LABEIN Technological Centre, Zamudio (Vizcaya), Spain

´ NDEZ ALBERTO FERNA Department of Computer Science, Universidad Rey  stoles (Madrid), Spain Juan Carlos, Mo

ANA GARCI´A-SERRANO Department of Artificial Intelligence, Universidad Polite´cnica de Madrid, Boadilla del Monte (Madrid), Spain

Work supported by the Spanish Ministry of Science and Technology (MCyT) under grant TIC20001370-C04. The authors would like to thank the Public Works and Transport Department of the Regional Government of Bizkaia (DFB) as well as the Malaga Local Transport Consortium (EMT) for their cooperation. Address correspondence to Sascha Ossowski, Department of Computer Science, Universidad Rey Juan Carlos, Calle Tulipan s=n, 28933 M ostoles (Madrid), Spain. E-mail: [email protected]

779

780

S. Ossowski et al. FRANCISCO TRIGUERO tica, Universidad de Ma laga, ETSI Informa laga, Spain Ma

JUAN MANUEL SERRANO Department of Computer Science, Universidad Rey  stoles (Madrid), Spain Juan Carlos, Mo

JOSE´ LUIS PE´REZ-DE-LA-CRUZ tica, Universidad de Ma laga, ETSI Informa laga, Spain Ma

This article describes how agent and knowledge technology can be used to build advanced software systems that support operational decision making in complex domains. In particular, we present an abstract architecture and design guidelines for agent-based decision support systems. We illustrate our approach with a case study in the transportation management domain.

Decision support systems (DSS) provide assistance to humans involved in complex decision-making processes. Early DSS were conceived as simple databases for storage and recovery of decision relevant information (Silver 1991). However, it soon became apparent that the key problem for a decision maker is not to access pertinent data, but rather to understand its significance. Modern DSS help decision makers explore the implications of their judgments, so as to make decisions based on understanding (French 2000). Knowledge-based DSS (Klein and Methlie 1995) are particularly relevant in domains where human operators have to make operational decisions regarding the management of complex industrial or environmental processes (Hern andez and Serrano 2001; Hern andez et al. 2002). Due to the inherent (spatial, logical, and=or physical) distribution of these domains, a distributed approach to the construction of DSS has become popular (Cuena and Ossowski 1999). Decision-support agents are responsible for parts of the decision-making process in a (semi-)autonomous (individually) rational fashion: They collect and facilitate decision relevant data, but also provide advanced reasoning services to analyze the meaning of this information (Ossowski et al. 2002). However, despite recent advances in the field of agent-oriented software engineering (see Iglesias et al. 1999, or Hoa Dam and Winikoff 2004, for an overview), a principled approach to the design of knowledge-based multi-agent systems for decision support is still to come. This article reports on an attempt to address this shortcoming. The next section introduces an abstract multi-agent DSS architecture, and outlines how it is used to guide the construction of agent-based DSS. We then describe its application to a problem of road traffic management in the greater Bilbao district, as well as its use for bus fleet management scenarios

Systems for Decision Support

781

pertinent to the town Malaga. We conclude this article summarizing the lessons learned and pointing to future work.

AGENT-BASED DECISION SUPPORT: THE SKADS APPROACH In this section, we describe the social knowledge agents for decision support (SKADS) approach for the design and application of DSS. In line with the mainstream in agent-oriented software engineering (e.g., Wooldridge et al. 2000), SKADS first models agent-based DSS in terms of organizational concepts (Ferber and Gutknecht 1998; Zambonelli et al. 2000), which are then further refined, so as to give rise to an agent-centerd model. SKADS is particularly concerned with issues of agent interoperability, so it follows closely the standard of the Foundation for Intelligent Physical Agents (FIPA), paying special attention to FIPA’s agent communication language (ACL) and its abstract architecture. In the sequel, we first outline the social and communicative roles that need to be supported by a DSS so as to cope with typical decision support interactions. Then, classes of agents are identified that should be present in any knowledge-based DSS. Finally, we come up with an abstract multi-agent architecture and outline support for its implementation as DSS for particular domains.

Organizational Model The key point in modern DSS is to assist the decision maker in exploring the implications of her judgements, so we first analyze typical ‘‘exploratory dialogues’’ between her and the DSS. Based on their (macro-level) functionality, we have identified the following types of social interaction involving DSS: information exchange, explanation, advice, and action performing (Serrano et al. 2003). In DSS with multiple decision makers, additional brokering and negotiation interactions are often present, which identify potential partners to solve a given problem, and establish the conditions under which a certain action is performed, respectively. Roles usually describe different types of (micro-level) functionalities for classes of agents, so we introduce the concept of communicative role to describe the communicative competence of agents in social interactions. Communicative roles are characterized by the communicative actions (CA) (Austin 1962) that they can perform (e.g., an information seeker or informee role is characterized by the FIPA CAs query-if, query-ref, and subscribe), and may take part in one or more interaction protocols. We have analyzed FIPA ACL on the basis of these concepts, and determined the generic types of social interactions that it supports (Serrano et al. 2003). As Table 1 indicates, the majority of social

782

S. Ossowski et al.

TABLE 1 Organizational Concepts for Decision Support Type of social interaction

Communicative role

Action performing

requester, requestee

Information exchange

informer, informee

Explanation Advice Negotiation (or open action performing)

explainer, explainee advisor, advisee negotiation requester, negotiation requestee

Brokering

brokering requester, broker

Protocol FIPA-request-protocol FIPA-request-when-protocol FIPA-query-protocol FIPA-subscribe-protocol Explanation-protocol Advisory-protocol FIPA-Propose-protocol, FIPA-CNET-protocol, ... FIPA-brokering-protocol FIPA-recruiting-protocol

interactions relevant to DSS, together with their respective communicative roles, are supported directly by FIPA. Still, roles in agent-based DSS require domain competence as well, so we specialize communicative roles into social roles based on the elements of a domain ontology of which they inform, or that they explain. A minimum domain competence of a DSS will be centered on the following concepts: . System problems: Identify situations with decision-making options (classification). . Problem causes: Express system problems in terms of causal features of the situation (diagnosis). . Control actions: Represent the various decision alternatives (action planning). . Foreseeable problems: Simulate potential consequences of decisions (prediction). Figure 1 summarizes our organizational analysis of knowledge-based multiagent DSS in UML notation.

Agent Model Social roles need to be mapped onto types of agents that will eventually play these roles in the DSS. Especially for knowledge-based agent systems, it is important that this process adequately reflects the a priori distribution present in the particular DS domain (Ossowski 1999). Usually, both of the following cases are present: . One role several agents: In complex domains, it is often necessary (or desirable), to let different agents play the same role, but in different

Systems for Decision Support

783

FIGURE 1. Communicative and social roles in DSS.

‘‘parts’’ of a system. In this way, the agent model may better reflect a human organization, reduce communication requirements, or simply decrease the complexity of the necessary reasoning processes. . One agent several roles: Knowledge-oriented design approaches, such as KSM (Cuena and Molina 1997), suggest that some types of domain knowledge can serve a number of purposes, and therefore may be used by agents to play different roles. Obviously, it would make no sense to replicate such knowledge bases among different agents. Based on the social roles that we have identified previously, we have come up with the following agent types for DSS: . Data agents (DA): DAs play the informer role with respect to the current state of a certain part of the system. As such, they are in charge of information retrieval from different information sources such as sensors or databases and its distribution. . Management agents (MA): MAs play the remaining informer roles as well as the advisor and explainer roles. By consequence, they need to be endowed with knowledge models that allow them to report on (and justify) problems, causes, potential future states, etc., as well as to suggest potential management actions. . Action implementation agents (AIA): These agents play the requestee role and are in charge of actually executing the actions that the decision maker has chosen to take.

784

S. Ossowski et al.

. User interface agents (UIA): UIAs play the remaining roles (informee, requester, etc.) on behalf of the user. Note that by conveniently sequencing and=or interweaving conversations, they are capable of answering a variety of questions (e.g., ‘‘What is happening in S?’’, ‘‘What may happen in S if event E occurs?’’, etc). Furthermore, notice that the finer the level of decomposition of social informer roles, the bigger the space of potential conversations that the UIA can engage in (Ossowski et al. 2002). The SKADS approach requires at least one instance of these agent types to be presented in the DSS but, due to different a priori distributions in corresponding problem domains (see above), often several instances of the aforementioned agent types will coexist. In DSS that support multiple decision makers, additional coordination facilitators (CF) are present, which provide negotiation and matchmaking (recruiting, brokering) support (Decker et al. 1997; Klusch and Sycara 2001).

SKADS Abstract Architecture and Platform Figure 2 shows the resulting abstract agent-based DSS architecture according to the SKADS approach. Notice that, depending on the level of detail in the definition of social roles (e.g., informer for problems, diagnosis, prediction, etc.) and their subsequent mapping to agent types, the MAs may be subdivided into several agents. Also note that the abstract architecture shown in Figure 2 comprises a set of so-called peripheral agents: This includes directory facilitators (DF) and an agent management systems (AMS) as required by the FIPA abstract architecture, but may also include third-party peripheral agents (PA) that supply added value services (Fern andez et al. 2004). We provide support for implementations of agent-based DSS for particular domains through extensions of the FIPA-compliant JADE agent

FIGURE 2. SKADS abstract architecture.

Systems for Decision Support

785

platform (Bellifemine et al. 1999). Most notably, we have encapsulated many of the inference schemes of the KSM knowledge modeling environment (Cuena and Molina 1997), so as to allow for a diverse representation and adequate instrumentation of the different types of decision-relevant domain knowledge.

DSS FOR TRANSPORTATION MANAGEMENT In this section, we illustrate the instrumentation of our approach by a case study in the transportation domain. In particular, we describe the architecture of two real-world DSS prototypes for road traffic management and bus fleet management, respectively.

The Road Traffic Management Domain The first application of the SKADS architecture refers to the domain of road traffic management. More precisely, we are concerned with a part of the high-capacity road network in the Bilbao area, comprising the town’s ring road as well as four of the main accesses to the metropolitan area. Regular information about the traffic state in this highly used area, registered by loop detectors, is received in the Mobility Management Center located at Malmasin, near the city of Bilbao. On the basis of this data, traffic operators have to make decisions on the control actions to apply in order to solve or minimize congestion. These actions include: . Displaying messages in Variable Message Signal (VMS) panels installed above the road to warn drivers about traffic problems or recommend alternative routes. . Asking local authorities to send appropriate people to manage the situation. As the traffic control infrastructure becomes more complex, there is an increasing need to assist operators in their management tasks, helping them to configure consistent control plans for the whole road network, and exploiting adequately the available signal devices from a global perspective. This is precisely the purpose of the DSS prototype described in the following sections. When applying the SKADS approach to the problem of road traffic management in the greater Bilbao district, we had to take into account that operators conceive the road network in terms of so-called problem areas, defined according to geographical criteria and the one-way direction of traffic. As a result, the relation between the abstract architecture and the actual structure of the DSS prototype is as follows:

786

S. Ossowski et al.

. As many DAs as problem areas: Every DA is responsible for collecting the state information of the VMS panels and the data recorded by the loop detectors. It may complete and=or filter noisy data (e.g., due to transmission problems) making use of historical data series and transform the quantitative values observed into qualitative data (e.g., high speed, low occupancy). . Two kinds of MAs: Problem detection agents (PDA) are responsible for monitoring the traffic flow in a problem area, understanding the traffic behavior, and detecting problems. If a problematic situation is detected from the analysis of the data sent by the corresponding DA, the PDA requests a control agent (CA) to resolve it. Every CA is responsible for solving=minimizing problems detected by one or several PDAs, and with this aim it can communicate with other PDAs to get information about the state of their problem area and diagnose the congestion. From the information obtained in the areas surrounding the congestion, the CA generates control proposals. A control proposal consists of a collection of messages to be displayed on VMS panels with warnings or recommendations for alternative routes for drivers approaching the congestion. When several areas of congestion are detected and two or more CAs compete for the use of the same VMS panels, the corresponding CAs communicate to reach an agreement on a consistent joint proposal. . One UIA that interacts with the traffic operators in the control center with respect to traffic problems, control proposals, etc. . One AIA that executes the operators’ decisions: Once a traffic operator accepts a control proposal, the AIA displays the corresponding messages on the VMS. The two types of management agents (PDAs and CAs) are the key components of our DSS for traffic management. They are endowed with knowledge bases that use either JESS rules (Friedman-Hill 2003; JESS 2003) or KSM frames (Cuena and Molina 1997). In particular, PDAs require two kinds of knowledge (see Figure 3): . Physical structure: Knowledge representing both static and dynamic information about the network. The static information is a physical description of the problem area (nodes, sections, position of the sensors, etc.). The dynamic aspects allow the PDA to have abstract information derived from the basic data (e.g., traffic excess). . Traffic problems: Knowledge about detection and diagnosis of the traffic state of the area. A problem is seen as an imbalance between capacity and traffic demand in a road, being the quantitative value of this imbalance the so-called traffic excess. The severity of the problem is a qualitative value obtained from traffic excess.

Systems for Decision Support

787

FIGURE 3. Problem detection agent (left) and control agent (right).

Each CA subscribes to certain PDAs, so as to be informed about the location and severity of traffic problems. As indicated in Figure 3, it is endowed with the following four types of knowledge to generate coherent control proposals: . PDAs’ interdependence: The causes of a congestion notified by a PDA can be related to the traffic state in surrounding problem areas that send the incoming flow to the congested section. The PDAs’ interdependence knowledge represents the relationship between problem areas and allows the CA to know which areas can be involved in the generation of the problem. Using this knowledge, the CA asks the corresponding PDAs for a description of the general state of their problem areas. . Control actions: Once the control agent has received all the necessary information from the different PDAs, it generates control proposals. It uses its control actions knowledge base to determine coherent sets of VMS messages, and their expected impact on the drivers’ behavior. This makes it possible to rank alternative control proposal in terms of the estimated reduction of traffic excess in the problem area. . Conflict detection: Each CA knows, for every VMS panel that it uses, which CAs it has to communicate with in order to agree on the use of the panel. . Conflict resolution: Every CA involved in the agreement process sends and receives from the other CAs the panels they want to use and the severity of the different problems they are trying to solve. Conflict resolution rules assign priorities for the use of the panels based on the location and the severity of problems.

788

S. Ossowski et al.

The road network of the Bilbao metropolitan area has been subdivided into 12 problem areas, so the prototype DSS application comprises 12 DAs and 12 PDAs. In addition five CAs have been defined: . Atena: Solves problems for PDAs 2 and 6 and communicates with PDA 11. . Briseide: Solves problems for PDAs 1, 4, and 8. . Cassandra: Solves problems for PDAs 5, 7, and 10 and communicates with PDA 1. . Demetra: Solves problems for PDA 11 and communicates with PDAs 7 and 2. . Elena: solves problems for PDAs 3, 9, and 12 and communicates with PDA 7. Note that the association between PDAs and CAs is induced by both topological and traffic behavior criteria. Figure 4 summarizes the different management agents of our DSS prototype for traffic control and outlines their interrelation. The prototype has been evaluated successfully on the basis of several congestion scenarios. In particular, we have artificially generated data corresponding to traffic problems that simultaneously occur in different problem areas (see Figure 5), which underlines the adequacy of CA coordination and the underlying knowledge models.

The Bus Fleet Management Domain A second application of the SKADS architecture refers to the domain of bus fleet management (BFM). In many major cities, urban buses are equipped with radio and GPS devices that provide operators in a BFM center with up-to-date information on bus locations, and allow them to communicate with the drivers. A typical task of a BFM operator is to detect incidents (delays, advances, breakdowns, etc.) by comparing bus schedules with current location data, and sending orders to bus drivers (increase=reduce speed, change timetable regulation to frequency regulation, etc.) to maintain or re-establish an acceptable quality of service.

FIGURE 4. Management agents of the road traffic DSS prototype.

Systems for Decision Support

789

FIGURE 5. Road traffic management evaluation scenario.

In the Spanish town of Malaga, BFM operators of the local transport consortium (EMT, Empresa Municipal de Transporte) use an exploitation support system that presents information related to the status of the buses with regard to the scheduled services. For each line there is an operator who makes decisions in order to adjust services to unforeseen circumstances. In the following, we report on the architecture of a prototype DSS that extends the functionality of the exploitation support system, engaging in dialogues with EMT operators respecting the causes of problems and the best control actions to take. Our prototype faithfully reproduces the real operating conditions of the EMT bus lines that cover a sector of western Malaga. BFM data agents (DA) indicate the state of the bus lines as part of information exchange interactions. In particular, when a bus arrives at a stop or an incident takes place, the DA forwards this information to any agent that previously subscribed to this service by means of the FIPA-Subscribe protocol. BFM action implementation agents (AIA) simply forward commands to bus drivers via radio. One way to implement the domain competence of BFM connection agents is to provide a wrapper for the EMT exploitation support system,

790

S. Ossowski et al.

which collects information on the actual state of the buses in real time by means of GPS technology. However, as we were not allowed to establish such an online connection, for our prototype, we implemented a simulator based on the actual EMT bus schedules. The simulator emulates the EMT exploitation support system, but provides additional functionalities that allow us to artificially generate complex problem scenarios (concurrent delays, advances, saturations, breakdowns, etc.), which calibrates and evaluates our prototype. Line management agents (LMA) are the direct counterpart to MAs in the BFM domain. They are in charge of bus line supervision and, in accordance with the actual conceptual and organizational structure in EMT’s management center, there is one LMA for each line. An LMA’s main purpose is to participate in information exchange interactions respecting incidents, problem causes, and control recommendations. As Figure 6 indicates, LMAs use the following interaction protocols: . FIPA-Subscribe: The LMA plays the initiator role to obtain information about arrivals and incidents from the DA, and plays the participant role to facilitate information about problems, causes, and control recommendations of the line to the UIA. . FIPA-Brokering: An LMA may need a reinforcement (reserve) service and try to find other lines willing to hand over a vehicle. The LMA initiates this interaction with a coordination facilitator (CF) agent (see the following), who is in charge of locating adequate LMAs by means of a FIPA-query sub-protocol.

FIGURE 6. Bus fleet management interactions.

Systems for Decision Support

791

. FIPA-Query: Before starting a negotiation with others to obtain a reinforcement service, an LMA asks its operator (through the UIA) for authorization. In addition, an LMA may need to reply to the CF’s query as to whether it is willing to accept a certain service transfer deal. . FIPA-Request: LMAs use this protocol to actually execute an agreement to shift a vehicle from one line to another. The instrumentation of LMA domain competence requires a knowledge model that allows them to identify or diagnose problems, suggest or recommend sets of management actions, and predict future behavior of the line. In fact, several elicitations interviews have been performed with the EMT operators in order to extract the knowledge and logs of real situations, and have been analyzed in order to simulate and solve real problems. LMA knowledge has been represented by a set of JESS production rules (Friedman-Hill 2003; JESS 2003), and its corresponding reasoning services are carried out by forward chaining inference. Figure 7 show parts of the ontology used, which has been modeled and instrumented by means of the PROTEGE-II tool (Noy et al. 2001). A coordination facilitator (CF ) supports the coordination among lines. More precisely, it acts as a mediator in the negotiation among LMAs to obtain a reinforcement service. When a line needs a reinforcement service (e.g., when the corresponding LMA detects the breakdown of a bus, or the

FIGURE 7. Bus fleet management ontology.

792

S. Ossowski et al.

frequency of the services in the line is too low), the LMA asks its operator (by means of UIA) for permission to negotiate a reinforcement service. If she accepts, the LMA requests negotiation support from the CF by means of the FIPA-Brokering protocol. So, the CF takes on the broker role and additionally plays the informee (initiator) role in the FIPA-Query subprotocol. So, the CF’s domain competence at least requires a model of the spatial relation of bus lines and their head stops. User interface agents (UIA) display selected information to the BFM operators at the control center. They show the status of a line, inform about incidents or problems, and notify control recommendations or proposals coming from the LMAs. For this purpose, a UIA subscribes to the service offered by the DAs to obtain information about arrivals and incidents of each line. Besides, it initiates a FIPA-Subscribe protocol with LMAs in order to obtain diagnostic information and control recommendations for each line. In addition, the UIA plays the participant role in interactions, driven by the FIPA-Query protocol, to authorize negotiations for reinforcement services. The UIA graphical interface is shown in Figure 8. Line 12 has been selected for visualization: The schematic layout of this line appears on the left. Six buses are supposed to serve the line, which appear in the scheme together with their computed delays. In this case, five buses are delivering their service on time, while another one has suffered a breakdown. At the right of the window, a decision support dialogue is shown: In the example, the DSS recommends to ask line 3 for a reserve vehicle. Finally, the bottom part of the window contains status information about the line and its simulator.

FIGURE 8. Bus fleet management UIA.

Systems for Decision Support

793

The results of an independent evaluation of the prototype, carried out by EMT, are encouraging. Warnings issued and decisions made by the system are correct and similar to those taken by senior operators. Furthermore, the system adds new capabilities such as the dynamical assignation of buses to lines in order to solve severe incidents. EMT stresses that, after a process of refinement, these new capabilities should be integrated into their daily routine.

CONCLUSIONS In this article, we have shown how multi-agent technology can be successfully applied to build DSS for real-world traffic management problems. In particular, we have put forward design guidelines for the construction of agent-based DSS, leading to an abstract multi-agent architecture. Furthermore, we have shown in detail how this abstract architecture has been used to design DSS prototypes for the domain of road traffic management in the greater Bilbao area, as well as bus fleet management scenarios pertinent to the Spanish town Malaga. This enterprise has provided us with empirical evidence respecting the adequacy of our design approach. The implementation of the DSS prototypes, which required the integration of various software technologies and tools (JADE, KSM, JESS, Prote´ge´-II), has been initially complex but required a reasonable amount of programming work. In particular, the agentification of the KSM knowledge representation and inference schemes and their subsequent integration into JADE went surprisingly smooth. By contrast, the effort necessary to integrate the different ontologies (and the representations used in the different tools) was rather high, so we see a need for standards and tools that facilitate this kind of task. Furthermore, we found that some communicative roles and interactions are not adequately supported by FIPA. In order to remain FIPA compliant, for instance, in our prototypes we had to implement advisory interactions by means of information exchange interactions (using FIPA-query or FIPA-subscribe protocols). As a result, we have developed a method to build principled extensions to ACLs (and FIPA ACL in particular), as well as a set of software components that encapsulate the corresponding dialogical behavior for its use by JADE agents to be used in future applications (Serrano 2004). Future work comprises the integration of additional peripheral agents (e.g., supply services of traffic management agents to the BFM system), and the use of mobile devices (e.g., onboard driver information systems). In a nutshell, taking the trouble to move our agent-based design method and architecture for DSS some way down the technology transfer chain has been quite an instructive enterprise. We feel that, in general, work in the field of agent-oriented software engineering may gain important insights by addressing domain-specific issues in sectors like transportation management, mobile workforce automation, enterprise-wide collaboration, and others,

794

S. Ossowski et al.

which are most likely to benefit from the strengths of the agent-oriented approach.

REFERENCES Austin, J. L. 1962. How To Do Things with Words. Oxford: Clarendom Press. Bellifemine, F., A. Poggi, and G. Rimassa. 1999. JADE A FIPA-compliant agent framework. In Proceedings of the 4th International Conference on Practical Applications of Intelligent Agents and Multiagent Systems (PAAM-99), pages 97 108. Belmonte, M. V. 2002. Formacion de Coaliciones en Sistemas Multiagente Una Aproximacion Computacionlmente Tratable Basada en Teorı´a de Juegos. Ph.D. Thesis, Univ. de Malaga. Cuena, J. and M. Molina. 1997. KSM An environment for design of structured knowledge models. In Knowledge-Based Systems, Advanced Concepts, Techniques & Applications, ed. S. G. Tzafestas, 217 246. World Scientific. Cuena, J. and S. Ossowski. 1999. Distributed models for decision support. In Multi-Agent Systems—A Modern Approach to DAI, ed. Weiß, 459 504. Cambridge, MA: The MIT Press. Cuena, J., J. Z. Hernandez, and M. Molina. (1996). Knowledge-oriented design of an application for real time traffic management. In Proceedings of the European Conference on Artificial Intelligence (ECAI96), 217 245. Wiley & Sons. Decker, K., K. Sycara, and M. Williamson. 1997. Middle-agents for the Internet. In Proceedings of the International Joint Conference on Artificial Intelligence (IJCAI), pages 578 583. Morgan Kaufmann. Ferber, J. and O. Gutknecht. 1998. A meta-model for the analysis of organizations in multi-agent systems. In Proceedings 3rd International Conference on Multi-Agent Systems (ICMAS’98), 128 135. IEEE Press. Fern andez, A., S. Ossowski, and A. Alonso. (2004). Multiagent service architecture for bus fleet management. International Journal on Integrated Computer-Aided Engineering 11(2):101 115. FIPA. 2003. The Foundation for Intelligent Physical Agents. http:==www.fipa.org= French, S. 2000. Decision Analysis and Decision Support. John Wiley & Sons. Friedman-Hill, E. 2003. Jess in Action: Java Rule Based Systems. Manning Publications. Hern andez, J. Z., S. Ossowski, and A. Garcı´a-Serrano. 2002. Multiagent architectures for intelligent traffic management systems. Transportation Research C 5(10):473 506. Hern andez, J. Z. and J. Serrano. 2001. Environmental emergency management supported by knowledge modelling techniques. AI Communications 14(1):1 10. Hoa Dam, K. and M. Winikoff. 2004. Comparing agent-oriented methodologies. In Agent-Oriented Information Systems, eds. Giorgini et al., 79 94, LNAI 3030. Springer-Verlag. Iglesias, C. A., M. Garijo Ayestaran, and J.C. Gonzalez. 1999. A survey of agent-oriented methodologies. In Intelligent Agents V, 317 330, LNAI 1555. Springer-Verlag. JESS. 2003. http:==herzberg.ca.sandia.gov=jess= Klein, M. and L. Methlie. 1995. Knowledge-Based Decision Support Systems. John Wiley. Klusch, M. and K. Sycara. 2001. Brokering and matchmaking for coordination of agent societies A survey. Coordination of Internet Agents: Models, Technologies, and Applications (Omicini y otros). 197 224. Springer. Noy, N. F., M. Sintek, S. Decker, M. Crubezy, R. W. Fergerson, and M. A. Musen. 2001. Creating semantic Web contents with Protege-2000. IEEE Intelligent Systems 16(2):60 71. Ossowski, S. 1999. Coordination in Artificial Agent Societies. LNAI 1535. Springer-Verlag. Ossowski, S., J. Z. Hernandez, C. A. Iglesias, and A. Fernandez. 2002. Engineering agent systems for decision support. Engineering Societies in an Agent World III, ed. Petta, Tolksdorf, and Zambonelli, 234 274. Springer-Verlag. Serrano, J. M. 2004. Pragmatica de los Agentes Software Analisis y Dise~no de los Lenguajes de Comunicacion Artificiales. Ph.D. Thesis, Department of Computer Science, Univ. Rey Juan Carlos. Serrano, J. M., S. Ossowski, and A. Fernandez. 2003. The pragmatics of software agents Analysis and design of agent communication languages. Intelligent Information Agents The AgentLink Perspective, eds. Klusch et al., 234 274, LNAI 2586. Springer. Silver, M. 1991. Systems That Support Decision Makers. John Wiley & Sons.

Systems for Decision Support

795

Sturm, A. and O. Shehory. 2004. A framework for evaluating agent-oriented methodologies. AgentOriented Information Systems, eds. Giorgini et al., 234 274, LNAI 3030. Springer. Wooldridge, M., N. Jennings, and D. Kinny. 2000. The Gaia methodology for agent-oriented analysis and design. Autonomous Agents and Multiagent Systems 3(3):285 312. Zambonelli, F., N. R. Jennings, and M. Wooldridge. 2000. Organizational abstractions for the analysis and design of multi-agent systems. Agent-Oriented Software Engineering, eds. Ciancarini and Wooldridge, 235 252. Springer-Verlag.