u MULTI-AGENT SYSTEMS FOR DECISION SUPPORT: A CASE … · ETSI Informaatica, Universidad de M...

u MULTI-AGENT SYSTEMS FORDECISION SUPPORT: A CASESTUDY IN THETRANSPORTATIONMANAGEMENT DOMAIN

SASCHA OSSOWSKIDepartment of Computer Science, Universidad Rey

Juan Carlos, M�oostoles (Madrid), Spain

JOSEFA Z. HERNANDEZDepartment of Artificial Intelligence, Universidad

Politecnica de Madrid, Boadilla del Monte

(Madrid), Spain

MARIA VICTORIA BELMONTEETSI Inform�aatica, Universidad de M�aalaga,

M�aalaga, Spain

JOSE MASEDAInformation Society Unit, LABEIN Technological

Centre, Zamudio (Vizcaya), Spain

ALBERTO FERNANDEZDepartment of Computer Science, Universidad Rey


ANA GARCIA-SERRANODepartment of Artificial Intelligence, Universidad

Politecnica de Madrid, Boadilla del Monte

(Madrid), Spain

Work supported by the Spanish Ministry of Science and Technology (MCyT) under grant TIC2000-

1370-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 Tulip�aan s=n, 28933 M�oostoles (Madrid), Spain. E-mail: [email protected]

Applied Artificial Intelligence, 18:779�795, 2004

Copyright # Taylor & Francis Inc.

ISSN: 0883-9514 print/1087-6545 online

DOI: 10.1080=08839510490509018

779

FRANCISCO TRIGUEROETSI Inform�aatica, Universidad de M�aalaga,

M�aalaga, Spain

JUAN MANUEL SERRANODepartment of Computer Science, Universidad Rey


JOSE LUIS PEREZ-DE-LA-CRUZETSI Inform�aatica, Universidad de M�aalaga,

M�aalaga, Spain

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

Decision support systems (DSS) provide assistance to humans involved incomplex decision-making processes. Early DSS were conceived as simpledatabases for storage and recovery of decision relevant information (Silver1991). However, it soon became apparent that the key problem for a decisionmaker is not to access pertinent data, but rather to understand its significance.Modern DSS help decision makers explore the implications of their judg-ments, so as to make decisions based on understanding (French 2000).

Knowledge-based DSS (Klein and Methlie 1995) are particularly relevantin domains where human operators have to make operational decisionsregarding the management of complex industrial or environmental processes(Hern�aandez and Serrano 2001; Hern�aandez et al. 2002). Due to the inherent(spatial, logical, and=or physical) distribution of these domains, a distributedapproach to the construction of DSS has become popular (Cuena andOssowski 1999). Decision-support agents are responsible for parts of thedecision-making process in a (semi-)autonomous (individually) rationalfashion: They collect and facilitate decision relevant data, but also provideadvanced reasoning services to analyze the meaning of this information(Ossowski et al. 2002). However, despite recent advances in the field ofagent-oriented software engineering (see Iglesias et al. 1999, or Hoa Damand Winikoff 2004, for an overview), a principled approach to the design ofknowledge-based multi-agent systems for decision support is still to come.

This article reports on an attempt to address this shortcoming. The nextsection introduces an abstract multi-agent DSS architecture, and outlineshow it is used to guide the construction of agent-based DSS. We thendescribe its application to a problem of road traffic management in thegreater Bilbao district, as well as its use for bus fleet management scenarios

780 S. Ossowski et al.

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

AGENT-BASED DECISION SUPPORT:THE SKADS APPROACH

In this section, we describe the social knowledge agents for decision sup-port (SKADS) approach for the design and application of DSS. In line withthe mainstream in agent-oriented software engineering (e.g., Wooldridgeet al. 2000), SKADS first models agent-based DSS in terms of organizationalconcepts (Ferber and Gutknecht 1998; Zambonelli et al. 2000), which arethen further refined, so as to give rise to an agent-centerd model. SKADSis particularly concerned with issues of agent interoperability, so it followsclosely 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 socialand communicative roles that need to be supported by a DSS so as to copewith typical decision support interactions. Then, classes of agents are identi-fied that should be present in any knowledge-based DSS. Finally, we comeup with an abstract multi-agent architecture and outline support for itsimplementation as DSS for particular domains.

Organizational Model

The key point in modern DSS is to assist the decision maker in exploringthe implications of her judgements, so we first analyze typical ‘‘exploratorydialogues’’ between her and the DSS. Based on their (macro-level) function-ality, we have identified the following types of social interaction involvingDSS: information exchange, explanation, advice, and action performing(Serrano et al. 2003). In DSS with multiple decision makers, additionalbrokering and negotiation interactions are often present, which identifypotential partners to solve a given problem, and establish the conditionsunder which a certain action is performed, respectively. Roles usuallydescribe different types of (micro-level) functionalities for classes of agents,so we introduce the concept of communicative role to describe the communi-cative competence of agents in social interactions. Communicative roles arecharacterized by the communicative actions (CA) (Austin 1962) that theycan perform (e.g., an information seeker or informee role is characterizedby the FIPA CAs query-if, query-ref, and subscribe), and may take part inone or more interaction protocols. We have analyzed FIPA ACL on the basisof these concepts, and determined the generic types of social interactions thatit supports (Serrano et al. 2003). As Table 1 indicates, the majority of social

Systems for Decision Support 781

interactions relevant to DSS, together with their respective communicativeroles, are supported directly by FIPA.

Still, roles in agent-based DSS require domain competence as well, so wespecialize communicative roles into social roles based on the elements of adomain ontology of which they inform, or that they explain. A minimumdomain competence of a DSS will be centered on the following concepts:

. System problems: Identify situations with decision-making options (classi-fication).

. Problem causes: Express system problems in terms of causal features of thesituation (diagnosis).

. Control actions: Represent the various decision alternatives (action plan-ning).

. Foreseeable problems: Simulate potential consequences of decisions (pre-diction).

Figure 1 summarizes our organizational analysis of knowledge-based multi-agent DSS in UML notation.

Agent Model

Social roles need to be mapped onto types of agents that will eventuallyplay these roles in the DSS. Especially for knowledge-based agent systems, itis important that this process adequately reflects the a priori distributionpresent in the particular DS domain (Ossowski 1999). Usually, both of thefollowing cases are present:

. One role � several agents: In complex domains, it is often necessary (ordesirable), to let different agents play the same role, but in different

TABLE 1 Organizational Concepts for Decision Support

Type of social interaction Communicative role Protocol

Action performing requester, requestee FIPA-request-protocol

FIPA-request-when-protocol

Information exchange informer, informee FIPA-query-protocol

FIPA-subscribe-protocol

Explanation explainer, explainee Explanation-protocol

Advice advisor, advisee Advisory-protocol

Negotiation (or open

action performing)

negotiation requester,

negotiation requestee

FIPA-Propose-protocol,

FIPA-CNET-protocol,

. . .

Brokering brokering requester, broker FIPA-brokering-protocol

FIPA-recruiting-protocol


‘‘parts’’ of a system. In this way, the agent model may better reflect ahuman organization, reduce communication requirements, or simplydecrease the complexity of the necessary reasoning processes.

. One agent � several roles: Knowledge-oriented design approaches, such asKSM (Cuena and Molina 1997), suggest that some types of domain knowl-edge can serve a number of purposes, and therefore may be used by agentsto play different roles. Obviously, it would make no sense to replicate suchknowledge bases among different agents.

Based on the social roles that we have identified previously, we have come upwith the following agent types for DSS:

. Data agents (DA): DAs play the informer role with respect to the currentstate of a certain part of the system. As such, they are in charge of infor-mation retrieval from different information sources such as sensors ordatabases and its distribution.

. Management agents (MA): MAs play the remaining informer roles as wellas the advisor and explainer roles. By consequence, they need to beendowed with knowledge models that allow them to report on (and justify)problems, causes, potential future states, etc., as well as to suggest poten-tial management actions.

. Action implementation agents (AIA): These agents play the requestee roleand are in charge of actually executing the actions that the decision makerhas chosen to take.

FIGURE 1. Communicative and social roles in DSS.


. User interface agents (UIA): UIAs play the remaining roles (informee,requester, etc.) on behalf of the user. Note that by conveniently sequencingand=or interweaving conversations, they are capable of answering a varietyof questions (e.g., ‘‘What is happening in S?’’, ‘‘What may happen in S ifevent E occurs?’’, etc). Furthermore, notice that the finer the level ofdecomposition of social informer roles, the bigger the space of potentialconversations that the UIA can engage in (Ossowski et al. 2002).

The SKADS approach requires at least one instance of these agent types tobe presented in the DSS but, due to different a priori distributions in corre-sponding problem domains (see above), often several instances of the afore-mentioned agent types will coexist. In DSS that support multiple decisionmakers, additional coordination facilitators (CF) are present, which providenegotiation 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 architectureaccording to the SKADS approach. Notice that, depending on the level ofdetail in the definition of social roles (e.g., informer for problems, diagnosis,prediction, etc.) and their subsequent mapping to agent types, the MAsmay be subdivided into several agents. Also note that the abstract architec-ture shown in Figure 2 comprises a set of so-called peripheral agents: Thisincludes directory facilitators (DF) and an agent management systems(AMS) as required by the FIPA abstract architecture, but may alsoinclude third-party peripheral agents (PA) that supply added value services(Fern�aandez et al. 2004).

We provide support for implementations of agent-based DSS for parti-cular domains through extensions of the FIPA-compliant JADE agent

FIGURE 2. SKADS abstract architecture.


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

DSS FOR TRANSPORTATION MANAGEMENT

In this section, we illustrate the instrumentation of our approach by acase study in the transportation domain. In particular, we describe the archi-tecture of two real-world DSS prototypes for road traffic management andbus fleet management, respectively.

The Road Traffic Management Domain

The first application of the SKADS architecture refers to the domain ofroad traffic management. More precisely, we are concerned with a part of thehigh-capacity road network in the Bilbao area, comprising the town’s ringroad as well as four of the main accesses to the metropolitan area. Regularinformation about the traffic state in this highly used area, registered byloop detectors, is received in the Mobility Management Center located atMalmasin, near the city of Bilbao. On the basis of this data, traffic operatorshave to make decisions on the control actions to apply in order to solve orminimize congestion. These actions include:

. Displaying messages in Variable Message Signal (VMS) panels installedabove the road to warn drivers about traffic problems or recommend alter-native routes.

. Asking local authorities to send appropriate people to manage thesituation.

As the traffic control infrastructure becomes more complex, there is anincreasing need to assist operators in their management tasks, helping themto configure consistent control plans for the whole road network, andexploiting adequately the available signal devices from a global perspective.This is precisely the purpose of the DSS prototype described in the followingsections.

When applying the SKADS approach to the problem of road trafficmanagement in the greater Bilbao district, we had to take into account thatoperators conceive the road network in terms of so-called problem areas,defined according to geographical criteria and the one-way direction oftraffic. As a result, the relation between the abstract architecture and theactual structure of the DSS prototype is as follows:


. As many DAs as problem areas: Every DA is responsible for collecting thestate information of the VMS panels and the data recorded by the loopdetectors. It may complete and=or filter noisy data (e.g., due to trans-mission problems) making use of historical data series and transform thequantitative values observed into qualitative data (e.g., high speed, lowoccupancy).

. Two kinds of MAs: Problem detection agents (PDA) are responsible formonitoring the traffic flow in a problem area, understanding the trafficbehavior, and detecting problems. If a problematic situation is detectedfrom the analysis of the data sent by the corresponding DA, the PDArequests a control agent (CA) to resolve it. Every CA is responsible for sol-ving=minimizing problems detected by one or several PDAs, and with thisaim it can communicate with other PDAs to get information about thestate of their problem area and diagnose the congestion. From the infor-mation obtained in the areas surrounding the congestion, the CA generatescontrol proposals. A control proposal consists of a collection of messagesto be displayed on VMS panels with warnings or recommendations foralternative routes for drivers approaching the congestion. When severalareas of congestion are detected and two or more CAs compete for theuse of the same VMS panels, the corresponding CAs communicate to reachan agreement on a consistent joint proposal.

. One UIA that interacts with the traffic operators in the control center withrespect to traffic problems, control proposals, etc.

. One AIA that executes the operators’ decisions: Once a traffic operatoraccepts a control proposal, the AIA displays the corresponding messageson the VMS.

The two types of management agents (PDAs and CAs) are the key compo-nents of our DSS for traffic management. They are endowed with knowledgebases that use either JESS rules (Friedman-Hill 2003; JESS 2003) or KSMframes (Cuena and Molina 1997). In particular, PDAs require two kindsof knowledge (see Figure 3):

. Physical structure: Knowledge representing both static and dynamic infor-mation about the network. The static information is a physical descriptionof the problem area (nodes, sections, position of the sensors, etc.). Thedynamic aspects allow the PDA to have abstract information derived fromthe basic data (e.g., traffic excess).

. Traffic problems: Knowledge about detection and diagnosis of the trafficstate of the area. A problem is seen as an imbalance between capacityand traffic demand in a road, being the quantitative value of this imbal-ance the so-called traffic excess. The severity of the problem is a qualitativevalue obtained from traffic excess.


Each CA subscribes to certain PDAs, so as to be informed about the locationand severity of traffic problems. As indicated in Figure 3, it is endowedwith the following four types of knowledge to generate coherent controlproposals:

. PDAs’ interdependence: The causes of a congestion notified by a PDA canbe related to the traffic state in surrounding problem areas that send theincoming flow to the congested section. The PDAs’ interdependenceknowledge represents the relationship between problem areas and allowsthe CA to know which areas can be involved in the generation of the prob-lem. Using this knowledge, the CA asks the corresponding PDAs for adescription of the general state of their problem areas.

. Control actions: Once the control agent has received all the necessary infor-mation from the different PDAs, it generates control proposals. It uses itscontrol actions knowledge base to determine coherent sets of VMS mes-sages, and their expected impact on the drivers’ behavior. This makes itpossible to rank alternative control proposal in terms of the estimatedreduction 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 ofthe panel.

. Conflict resolution: Every CA involved in the agreement process sends andreceives from the other CAs the panels they want to use and the severity ofthe different problems they are trying to solve. Conflict resolution rulesassign priorities for the use of the panels based on the location and theseverity of problems.

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


The road network of the Bilbao metropolitan area has been subdivided into12 problem areas, so the prototype DSS application comprises 12 DAs and12 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 withPDA 1.

. Demetra: Solves problems for PDA 11 and communicates with PDAs 7and 2.

. Elena: solves problems for PDAs 3, 9, and 12 and communicates withPDA 7.

Note that the association between PDAs and CAs is induced by both topo-logical and traffic behavior criteria.

Figure 4 summarizes the different management agents of our DSS proto-type for traffic control and outlines their interrelation.

The prototype has been evaluated successfully on the basis of several con-gestion scenarios. In particular, we have artificially generated data corre-sponding to traffic problems that simultaneously occur in different problemareas (see Figure 5), which underlines the adequacy of CA coordination andthe underlying knowledge models.

The Bus Fleet Management Domain

A second application of the SKADS architecture refers to the domain ofbus fleet management (BFM). In many major cities, urban buses areequipped with radio and GPS devices that provide operators in a BFM centerwith up-to-date information on bus locations, and allow them to communi-cate with the drivers. A typical task of a BFM operator is to detect incidents(delays, advances, breakdowns, etc.) by comparing bus schedules withcurrent location data, and sending orders to bus drivers (increase=reducespeed, change timetable regulation to frequency regulation, etc.) to maintainor re-establish an acceptable quality of service.

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


In the Spanish town of Malaga, BFM operators of the local transportconsortium (EMT, Empresa Municipal de Transporte) use an exploitationsupport system that presents information related to the status of the buseswith regard to the scheduled services. For each line there is an operatorwho makes decisions in order to adjust services to unforeseen circumstances.In the following, we report on the architecture of a prototype DSS thatextends the functionality of the exploitation support system, engaging indialogues with EMT operators respecting the causes of problems and thebest control actions to take. Our prototype faithfully reproduces the realoperating conditions of the EMT bus lines that cover a sector of westernMalaga.

BFM data agents (DA) indicate the state of the bus lines as part of infor-mation exchange interactions. In particular, when a bus arrives at a stop oran incident takes place, the DA forwards this information to any agent thatpreviously subscribed to this service by means of the FIPA-Subscribe proto-col. BFM action implementation agents (AIA) simply forward commands tobus drivers via radio.

One way to implement the domain competence of BFM connectionagents is to provide a wrapper for the EMT exploitation support system,

FIGURE 5. Road traffic management evaluation scenario.


which collects information on the actual state of the buses in real time bymeans of GPS technology. However, as we were not allowed to establish suchan online connection, for our prototype, we implemented a simulator basedon the actual EMT bus schedules. The simulator emulates the EMT exploi-tation support system, but provides additional functionalities that allow us toartificially 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 theBFM domain. They are in charge of bus line supervision and, in accordancewith the actual conceptual and organizational structure in EMT’s manage-ment center, there is one LMA for each line. An LMA’s main purpose isto 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 informationabout arrivals and incidents from the DA, and plays the participant roleto facilitate information about problems, causes, and control recommen-dations of the line to the UIA.

. FIPA-Brokering: An LMA may need a reinforcement (reserve) service andtry to find other lines willing to hand over a vehicle. The LMA initiates thisinteraction with a coordination facilitator (CF) agent (see the following),who is in charge of locating adequate LMAs by means of a FIPA-querysub-protocol.

FIGURE 6. Bus fleet management interactions.


. FIPA-Query: Before starting a negotiation with others to obtain a reinforce-ment service, an LMA asks its operator (through the UIA) for authoriza-tion. In addition, an LMAmay need to reply to the CF’s query as to whetherit is willing to accept a certain service transfer deal.

. FIPA-Request: LMAs use this protocol to actually execute an agreementto shift a vehicle from one line to another.

The instrumentation of LMA domain competence requires a knowledgemodel that allows them to identify or diagnose problems, suggest or rec-ommend sets of management actions, and predict future behavior of the line.In fact, several elicitations interviews have been performed with the EMToperators in order to extract the knowledge and logs of real situations, andhave been analyzed in order to simulate and solve real problems. LMA know-ledge has been represented by a set of JESS production rules (Friedman-Hill2003; JESS 2003), and its corresponding reasoning services are carried out byforward chaining inference. Figure 7 show parts of the ontology used, whichhas 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 toobtain 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.


frequency of the services in the line is too low), the LMA asks its operator (bymeans of UIA) for permission to negotiate a reinforcement service. If sheaccepts, the LMA requests negotiation support from the CF by means ofthe FIPA-Brokering protocol. So, the CF takes on the broker role andadditionally plays the informee (initiator) role in the FIPA-Query sub-protocol. So, the CF’s domain competence at least requires a model of thespatial relation of bus lines and their head stops.

User interface agents (UIA) display selected information to the BFMoperators at the control center. They show the status of a line, inform aboutincidents or problems, and notify control recommendations or proposalscoming from the LMAs. For this purpose, a UIA subscribes to the serviceoffered by the DAs to obtain information about arrivals and incidents ofeach line. Besides, it initiates a FIPA-Subscribe protocol with LMAs in orderto obtain diagnostic information and control recommendations for each line.In addition, the UIA plays the participant role in interactions, driven by theFIPA-Query protocol, to authorize negotiations for reinforcement services.

The UIA graphical interface is shown in Figure 8. Line 12 has been selec-ted for visualization: The schematic layout of this line appears on the left. Sixbuses are supposed to serve the line, which appear in the scheme togetherwith their computed delays. In this case, five buses are delivering their serviceon time, while another one has suffered a breakdown. At the right of thewindow, a decision support dialogue is shown: In the example, the DSSrecommends to ask line 3 for a reserve vehicle. Finally, the bottom part ofthe window contains status information about the line and its simulator.

FIGURE 8. Bus fleet management UIA.


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

CONCLUSIONS

In this article, we have shown how multi-agent technology can be success-fully applied to build DSS for real-world traffic management problems. Inparticular, we have put forward design guidelines for the construction ofagent-based DSS, leading to an abstract multi-agent architecture. Further-more, we have shown in detail how this abstract architecture has been usedto design DSS prototypes for the domain of road traffic management inthe greater Bilbao area, as well as bus fleet management scenarios pertinentto the Spanish town Malaga. This enterprise has provided us with empiricalevidence respecting the adequacy of our design approach.

The implementation of the DSS prototypes, which required the inte-gration of various software technologies and tools (JADE, KSM, JESS,Protege-II), has been initially complex but required a reasonable amount ofprogramming work. In particular, the agentification of the KSM knowledgerepresentation and inference schemes and their subsequent integration intoJADE went surprisingly smooth. By contrast, the effort necessary to integratethe different ontologies (and the representations used in the different tools)was rather high, so we see a need for standards and tools that facilitate thiskind of task. Furthermore, we found that some communicative roles andinteractions are not adequately supported by FIPA. In order to remain FIPAcompliant, for instance, in our prototypes we had to implement advisory inter-actions by means of information exchange interactions (using FIPA-query orFIPA-subscribe protocols). As a result, we have developed a method to buildprincipled extensions to ACLs (and FIPA ACL in particular), as well as a setof software components that encapsulate the corresponding dialogical beha-vior for its use by JADE agents to be used in future applications (Serrano2004). Future work comprises the integration of additional peripheral agents(e.g., supply services of traffic management agents to the BFM system), andthe use of mobile devices (e.g., onboard driver information systems).

In a nutshell, taking the trouble to move our agent-based design methodand architecture for DSS some way down the technology transfer chain hasbeen quite an instructive enterprise. We feel that, in general, work in the fieldof agent-oriented software engineering may gain important insights byaddressing domain-specific issues in sectors like transportation management,mobile workforce automation, enterprise-wide collaboration, and others,


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

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. Formaci�oon de Coaliciones en Sistemas Multiagente � Una Aproximaci�oon Computa-

cionlmente Tratable Basada en Teorıa de Juegos. Ph.D. Thesis, Univ. de M�aalaga.

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. Hern�aandez, and M. Molina. (1996). Knowledge-oriented design of an application for real

time traffic management. In Proceedings of the European Conference on Artificial Intelligence (ECAI-

96), 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�aandez, A., S. Ossowski, and A. Alonso. (2004). Multiagent service architecture for bus fleet manage-

ment. 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�aandez, 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�aandez, 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 Ayestar�aan, and J.C. Gonz�aalez. 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. andK. Sycara. 2001.Brokering andmatchmaking for coordination of agent societies�Asurvey.

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 sem-

antic 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. Hern�aandez, C. A. Iglesias, and A. Fern�aandez. 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. Pragm�aatica de los Agentes Software � An�aalisis y Dise~nno de los Lenguajes de

Comunicaci�oon Artificiales. Ph.D. Thesis, Department of Computer Science, Univ. Rey Juan Carlos.

Serrano, J. M., S. Ossowski, and A. Fern�aandez. 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.


Sturm, A. and O. Shehory. 2004. A framework for evaluating agent-oriented methodologies. Agent-

Oriented 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.


Date post:	21-Jun-2020
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

u MULTI-AGENT SYSTEMS FOR DECISION SUPPORT: A CASE … · ETSI Informaatica, Universidad de M...

Documents