Decision support for traffic management based on ... - CiteSeerX

Transportation Research Part C 13 (2005) 272–298 www.elsevier.com/locate/trc

Decision support for traffic management based on organisational and communicative multiagent abstractions Sascha Ossowski a,*, Josefa Z. Herna´ndez b, Marı´a-Victoria Belmonte c, Alberto Ferna´ndez a, Ana Garcı´a-Serrano b, Jose´-Luı´s Pe´rez-de-la-Cruz c, Juan-Manuel Serrano a, Francisco Triguero c a

Department of Computer Science, University of Rey Juan Carlos, Calle Tulipa´n s/n, 28933 Mo´stoles, Madrid, Spain b Department of Artificial Intelligence, Technical University of Madrid, Campus de Montegancedo s/n 28660 Boadilla del Monte, Madrid, Spain c Department of Languages and Computer Science, University of Ma´laga, Boulevard Louis Pasteur no 35, 29071 Ma´laga, Spain

Abstract Modern decision support systems (DSS) not only store large amounts of decision-relevant data, but also aim at assisting decision-makers to explore the meaning of that data, and to take decisions based on understanding. In transportation domains, a multiagent approach to the construction of DSS is becoming increasingly popular, because it does not only reduce design complexity, but it also adequately supports a dialogue-based stance on decision support interactions. However, despite recent advances in the field of agent-oriented software engineering, a principled approach to the design of multiagent systems for decision support is still to come. In this paper, we outline a design method for the construction of agent-based DSS. Setting out from an organisational and communicative model of decision support environments, we present an abstract

*

Corresponding author. Tel.: +34 91 664 74 85; fax: +34 91 488 70 49. E-mail addresses: [email protected] (S. Ossowski), phernan@dia.fi.upm.es (J.Z. Herna´ndez), mavi@lcc. uma.es (M.-V. Belmonte), [email protected] (A. Ferna´ndez), agarcia@dia.fi.upm.es (A. Garcı´a-Serrano), [email protected] (J.-L. Pe´rez-de-la-Cruz), [email protected] (J.-M. Serrano), [email protected] (F. Triguero). 0968-090X/$ - see front matter
2005 Elsevier Ltd. All rights reserved. doi:10.1016/j.trc.2005.07.005

S. Ossowski et al. / Transportation Research Part C 13 (2005) 272–298

273

architecture for multiagent DSS. We then show how this architecture is instantiated for real-world problems by means of two prototypes for transportation management.
2005 Elsevier Ltd. All rights reserved. Keywords: Multiagent systems; Knowledge-based traffic management; Agent-oriented software engineering

1. Introduction Decision support systems (DSS) provide assistance to humans involved in complex decisionmaking processes. Early DSS were conceived as simple databases for storing and retrieving decision-relevant information (Silver, 1991). After some attempts at improving the organisation and presentation of such data by means of additional deductive facilities, it soon became apparent that the key problem for a decision-maker (DM) is not such much has to access pertinent data but rather to understand its significance. As French (2000) points out, the fundamental task for modern DSS is to help decision-makers (DMs) to build up and explore the implications of their judgements, and then take decisions based on understanding. Knowledge-based DSS (Klein and Methlie, 1995) are particularly relevant in domains where human operators have to take operational decisions in a continuous and recurrent manner. This is the case of DMs (often also called operators) that need to manage complex environmental or industrial processes. For instance, hydrology engineers responsible for managing the dams in watershed basins continuously need to decide on the opening levels of spill gates (Herna´ndez and Serrano, 2001); engineers controlling chemical plants constantly need actuate valves to adjust the flow of different products (Herna´ndez and Serrano, 2000); the administrators of computer networks have to decide on router configurations, lease lines, repair faulty equipment, etc. (Vlahavas et al., 2002); and, in particular, the managers of transportation systems have to take decisions on the different variables of their network so as to maintain and improve the quality of service for their users. In all these domains, knowledge-based DSS model the expertise of experienced DMs, and can enter into advisory dialogues with operators that are based on a familiar ontology that closely follow the accustomed structure of their decision-making processes. Such DSS are becoming particularly relevant as traffic networks and demands grow, giving rise to increasing volumes of decision-relevant data and a decreasing time horizon for effective management decisions. Due to the (spatial, logical, and/or physical) distribution of all the aforementioned 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 supply decision-relevant data, but also provide advanced reasoning services to analyse the meaning of this information (Ossowski et al., 2002). However, recent overviews by Iglesias et al. (1999) or by Hoa Dam and Winikoff (2003) prove that, despite a number of advances in the field of agent-oriented software engineering, a principled approach to the design of knowledge-based multiagent systems for decision support is still to come. This article reports on the design of two multiagent DSS for real-world traffic management problems. In addition, it shows how the use of an abstract multiagent architecture for DSS

274

S. Ossowski et al. / Transportation Research Part C 13 (2005) 272–298

may provide valuable design guidelines for this kind of systems. Section 2 gives an overview of the design process leading to the definition of this abstract architecture. Section 3, outlines its role in the design and implementation of DSS prototypes for the problems of road traffic management in the greater Bilbao area, as well as bus fleet management scenarios pertaining to the Spanish town of Malaga. In Section 4, we give examples of the dynamics of our systems, and summarise the lessons we have learnt from this case study in Section 5.

2. An abstract architecture for multiagent DSS In this section we describe a design method for knowledge-based DSS based on a multiagent architecture. This method builds upon the RICA (Role, Interaction, Communicative Act) theory, which like the mainstream agent-oriented software engineering (e.g. Wooldridge et al., 2000), conceives multiagent system design in terms of organisational concepts (e.g. Ferber et al., 2000, or Zambonelli et al., 2000). In addition, RICA explicitly models the communicative aspects of multiagent systems, which it relates to organisational abstractions (Serrano et al., 2003). This is particularly suitable for DSS as their functionality is largely dependent on what different types of interactions with the DM the systems support. Additional requirements that guided the development of our design process cover the need to take advantage of current standards, and in particular FIPA specifications (), and to allow for the integration of legacy software for decision support (such as the KSM knowledge modelling tool developed by Cuena and Molina, 1997). In the following, we first outline the organisational model that shapes the functionality of agent-based DSS. We then identify what classes of agents any knowledge-based DSS should include. Finally, we come up with an abstract multiagent architecture and give an example to illustrate its dynamics. 2.1. Organisational model As outlined by Serrano et al. (2003) , it is only natural to set out from an analysis of typical decision support dialogues between DM and DSS to develop a generic organisational model of a DSS. Based on their (macro-level) functionality, we have identified the following types of communicative (primitive) interactions for decision support: • • • •

Information exchange: a conversation about the truth of some proposition. Action performing: a conversation respecting the realisation of some action. Explanation: a conversation about the reasons for the truth of some statement. Advice: a conversation about the (subjective) benefits of some action.

DSS with multiple DMs often include additional brokering and negotiation interactions (Ossowski et al., 2004). Fig. 1 shows an example of a dialogue between a DSS and a DM based on an abstract ontology of a generic decision support domain (for simplicity this dialogue is shown in natural language—DSS usually make use of other modes of interaction). Fig. 1 also depicts how the dialogue can be generated by interleaving the different types of communicative

S. Ossowski et al. / Transportation Research Part C 13 (2005) 272–298

275

(1) DM: What is the status of component C? (2) DSS: Component C has the status S (3) DM: Execute action A1 on component C (4) DSS: This action is not suitable for solving the problem in area Z (5) DM: Can you explain why? (6) DSS: Because component C is affected by the malfunction of component C’ (7) DM: So, what should be done? (8) DSS: There are two appropriate control actions: A2 and A3 (9) DM: Can you explain A2 ? (10)DSS: Because the problem in area Z is P (11) DM: What is the impact of action A2 on the system? (12) DSS: The impact is I (13) DM: Forget the initial control action (14) DM: Take action A2 (15) DSS: Action executed. Action performing interaction Information exchange interaction Advisory interaction Explanatory interaction

Fig. 1. Abstract dialogue between DSS and DM.

interactions: it is initiated by an information exchange interaction, followed by an action performing interaction. The latter is interrupted by an advisory sub-dialogue, which itself is suspended twice for explanatory interactions (the first about the problems with ‘‘action A1’’, and the second about the benefits of ‘‘action A2’’). Several communicative roles participate in the interactions, and are characterised by the Communicative Actions (Austin, 1962) that they perform, and by the Protocols in which they may engage. To identify these elements for our organisational model of DSS, we have as far as possible reused the Communicative Actions and Protocols provided by the FIPA standard (see for their formal semantics). For instance, the information seeker communicative role that takes part in information exchange interactions is characterised by the FIPA query-if, query-ref, and subscribe Communicative Actions, and may take part in FIPA-query and FIPAsubscribe protocols. As Table 1 shows, only explanation and advice interactions are not supported Table 1 Organisational and communicative concepts for decision support Communicative interaction

Communicative roles

Protocols

Action performing

Requester, requestee

Information exchange

Informer, informee

Explanation Advice Negotiation (or: action performing II)

Explainer, explainee Advisor, advisee Negotiation, requester, negotiation requestee

Brokering

Brokering requester, broker

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

276

S. Ossowski et al. / Transportation Research Part C 13 (2005) 272–298

at a high enough level of abstraction (but can be ‘‘simulated’’ by means of action performing or information exchange interactions, as pointed out by Serrano et al., 2003). In the dialogue shown in Fig. 1, the DM plays the role of an informee, requester, explainee and advisee, while the DSS acts as requestee, informer, explainer and advisor. Still, roles in agent-based DSS require domain competence as well. Therefore communicative roles are specialised as social roles based on the elements of a domain ontology. Such an ontology will contain concepts relating to system problems, problem causes and control actions at least. As argued by Ossowski et al. (2002) , a minimum domain competence of a DSS will include reasoning services to: • • • •

Identify situations with decision-making options (classification). Express system problems in terms of causal features of the situation (diagnosis). Generate various decision alternatives (action planning) and Simulate potential consequences of decisions (prediction).

In the example dialogue shown in Fig. 1, the first information exchange interaction (utterances 1 and 2) is about the identification of system problems, while the second such sub-dialogue refers to foreseeable problems. Fig. 2 summarises the result of our organisational analysis of the DSS as a social role model in UML notation. Interaction types are represented by rectangular stereotyped boxes, while role types are depicted as a circle. 2.2. Agent model To develop an agent model for decision support applications, social roles need to be mapped onto types of agents that will eventually play these roles in the DSS. Usually, both of the following cases occur: • One agent—Several roles: This is the usual approach aimed at simplifying the resulting software architecture (and avoiding an unnecessary replication of knowledge). • One role—Several agents: Due to the ‘‘a priori distribution’’ that is typically present in decision support domains, it is usually a good idea to have several agents play the same role, but in different ‘‘parts’’ of a system. In this way, the agent model can better reflect a human organisation, reduce communication requirements, or just simplify the necessary reasoning processes. Based on the social roles that we identified above, we came up with different abstract agent types for DSS. Note that, in order to better reflect the ‘‘a priori distribution’’ of our DSS domains, several instances of the following agent types will coexist: • There are two classes of connection agents that directly interact with the environment: Data agents (DA) play the informer role with respect to the current status of a certain part of the system. As such, they are in charge of the retrieval of information from different information sources, like sensors or databases, and its distribution. Action implementation agents (AIA) play the requestee role and are in charge of actually executing the actions that the DM has chosen to take.

S. Ossowski et al. / Transportation Research Part C 13 (2005) 272–298

277

Fig. 2. Social role model for DSS.

• Management agents (MA) can play the remaining informer roles outlined in Fig. 2, as well as the advisor and explainer roles. Consequently, they need to be endowed with knowledge models that they can use to report on (and justify) problems, causes, potential future statuses, etc., as well as to suggest potential management actions. They may rely on the services of Coordination facilitators (CF) that provide support for negotiation and matchmaking (recruiting, brokering) interactions (Klusch and Sycara, 2001). CF agents are particularly relevant in DSS for groups of DMs. • User interface agents (UIA) play the remaining social roles outlined in Fig. 2 (informee, requester, etc.) on behalf of the user. Note that, as Ossowski et al. (2002) point out questions such as ‘‘What is happening in area S ?’’ or ‘‘What could happen in area S if event E occurs?’’ can be answered by conveniently sequencing and/or interleaving the different informee roles. • Peripheral agents (PA) represent the support infrastructure for the DSS. Directory Facilitators and Agent Management Systems as required by the FIPA abstract architecture () usually constitute PAs, but they may also encapsulate third-party value added services.

278

S. Ossowski et al. / Transportation Research Part C 13 (2005) 272–298

Fig. 2 illustrates the relation between the agent and organisational models. Rectangular stereotyped boxes depict the different agent types; the lines connecting agent types and role types represent the plays relation. 2.3. Abstract architecture Fig. 3 shows the resulting abstract agent-based DSS architecture. Notice that the instantiation of this architecture for a particular domain may induce a further subdivision of abstract agent types (e.g. to allow for more flexible dialogues with the DM). In addition, some abstract agent type may finally need to be implemented by means of a society of agents because of the use of wrapper agents for legacy software. In the following, we will illustrate the dynamics of an instantiation of this architecture based on the example of the abstract decision support dialogue in Fig. 1. In particular, we assume that there is one DA (a1), one AIA (a2), one UIA (a5) and two MA (a3a4). Following component and connector run-time models (Serrano et al., 2005), Fig. 4 represents the MAS execution topology as a graph in which the nodes are the agents and the arcs symbolize social interactions. Connectors represent the social roles that an agent will enact. Agent a3 plays the informer of system problems (I(sp)), explainer of system problems (E(sp)), informer of foreseeable problems (I(fp)), explainer of foreseeable problems (E(fp)) and informee of system state (i(ss)) roles. Links between roles represent conversations. They are labelled with the dialogue messages numbers in Fig. 1. Note that different conversations of the same type are represented by different arcs. The dashed arc between a1 and a3 indicates that the interaction is not included in the dialogue (as the UIA, which represents the DM, is not involved). The interaction between the DM and the DSS concerning the exchange of information about the system being monitored can be subdivided into two separate conversations. The first one refers to system problems (sp). The DM asks the DSS a question, concerning the situation of some component (utterance 1). The second message is the answer to this information query. Utterances (11) and (12) can also be interpreted in terms of an information query, in this case about the

Fig. 3. Abstract DSS architecture.

S. Ossowski et al. / Transportation Research Part C 13 (2005) 272–298

i(ss)

279

I(sp) E(sp)

I(ss)

a3:MA

1,2

I(fp) E(fp)

a1:DA

11,12 i(sp) i(fp) 3,13 R(ca)

a5:UIA

a(ca)

14,15

e(ca)

r(ca) 4

a2:AIA

7,8 5,6 9,10 A(ca) E(ca)

a4:MA

Fig. 4. Example component interaction.

foreseeable problems (fp) of the system if some control action is taken. In both interactions a5 (on behalf of the DM) and a3 play de informee (i) and the informer (I) role, respectively. This is represented in Fig. 4 by two arcs that connect the above two roles (arc labels refer to the utterance numbers in the example dialogue). Two conversations between the DSS (through AIA a2) and the DM (through UIA a5) with regard to action performing can be identified in the dialogue. The first one is initiated by message (3), is then temporally interrupted by an exchange concerning a related but different topic, and concludes with message (13). The second conversation is initiated by message (14) and finishes with (15). In this context, AIA a2 plays the requestee (r) role and performs the control actions (ca) that the DM (through UIA a5), as requester (R), has decided to take. Although both conversations (3–13 and 14–15) involve the same roles (r ca) and (R(ca)), we draw two arcs to express that they constitute different interactions. Utterances ranging from (4) to (10) refer to the advice which the DSS (through MA a4) offers the DM (through UIA a5). By sending message (4), agent a4 reacts to the control action (ca) that agent a5 intends to enact, warning (advisor role, A(ca)) agent a5 (advisee, a(ca)) not to take the action in question. Message (4) is followed by an explanatory sub-dialogue, consisting of messages (5) and (6), about the warning being issued. In particular, the DM (through UIA a5) sends message (5) to request an explanation of why the action is not effective. Message (6) stands for the respective explanation, which simply refers to the information used to infer the conclusion.

280

S. Ossowski et al. / Transportation Research Part C 13 (2005) 272–298

The dialogue continues on with the DM (UIA a5) asking the DSS (MA a4) for advice concerning control actions, and the DSS recommending two different alternatives (utterances 7 and 8 respectively). This latter message is also followed by an explanatory sub-dialogue initiated by the DM to find out why one of the alternatives would solve the problem. It should be noted that this, like the previous, explanatory sub-dialogue is more marginal than messages (4), (7) and (8), which form the core of the advisory dialogue. In both cases, a4 plays the explainer role (E(ca)), while a5 plays the explainee (e(ca)) role.

3. DSS for traffic management In this section we illustrate the instrumentation of our approach using two case studies in the domain of traffic management. In particular, we show how the abstract agent types of our abstract architecture are instantiated in both scenarios. 3.1. The environment 3.1.1. Bilbao demonstrator Problem scenario. The first application of the multiagent DSS architecture refers to the domain of road traffic management. In particular, we are concerned with part of the high-capacity road network in the Bilbao area. Regular information about the traffic situation in this highly used area, registered by loop detectors, is received in the Mobility Management Centre located at Malması´n, in the vicinity of the city of Bilbao. On the basis of this data, traffic operators have to take decisions on what the control actions to take to solve or minimise congestion. These actions include: (1) displaying messages on Variable Message Signal (VMS) panels installed above the road to warn drivers about traffic problems or recommend alternative routes and/or (2) contacting local authorities to send the right people to manage the situation. As the traffic control infrastructure becomes more complex, there is an increasing need to assist operators with their management task, helping them to configure consistent control plans for the whole road network, and making the best use of the available signal devices from a global perspective. This is precisely the purpose of the Bilbao DSS demonstrator described in the following sections. Trial zone. A sizesable part of the high-capacity road network of the greater Bilbao area, comprising the townÕs ring road as well as four of the main accesses to the metropolitan area, were selected as a trial zone for our demonstrator. Local traffic experts advised us to include some planned motorways as well to account for the increased management options in the near future. The whole network was divided into 12 problem areas by both physical location and the logics of traffic flow. Fig. 5 shows a sketch of the trial zone, where arrows identify the problem areas. Based on the above comments, it was clearly impossible to directly access the infrastructure of the trial zone, and we took a simulation approach. In particular, we developed a realistic model of the road network of the trial zone, and used the AIMSUN/2 4.1 () microscopic traffic simulator to replicate the dynamics of the network. AIMSUN models the behaviour of individual vehicles based on sophisticated car brakeing and lane changing models,

S. Ossowski et al. / Transportation Research Part C 13 (2005) 272–298

281

Fig. 5. Trial zone for the Bilbao demonstrator.

which take into account both global and local phenomena influencing vehicle behaviour, and whose quality has been proven in numerous field tests. 3.1.2. Malaga demonstrator Problem scenario. In many big cities, innercity buses are equipped with radio and GPS devices that provide operators in a Bus Fleet Management (BFM) centre with up-to-date information on bus locations, and can be used to communicate with the drivers. A typical task of a BFM operator is to detect incidents (buses that are behind or ahead of schedule, breakdowns,. . .) by comparing a busÕ schedule with its current location data and to send orders or control actions to bus drivers (increase/reduce speed, switch from timetable regulation to frequency regulation,. . .) so as to maintain or re-establish an acceptable quality of service. In the Spanish town of Malaga, control centre operators of the local transport consortium (EMT, Empresa Malaguen˜a de Transporte) use an Operating Support System that displays information related to the status of the buses with regard to the scheduled services. There is a line inspector for each line who takes decisions to adjust services to unforeseen circumstances, and supervisors who are in charge of taking broader and more complex decisions for several lines. In the following sections, we report on the architecture of a prototype DSS that extends the functionality of the Operating Support System by engaging in dialogues with EMT operators concerning the causes of the problems and the best control actions to take. Trial zone. We selected a sector in western Malaga (Spain) as a trial zone for our demonstrator. Three lines of the Malaga urban bus network (EMT) serve this area (lines 3, 12 and 15). Fig. 6 illustrates the trial zone for our demonstrator. The prototype is based on a faithful reproduction of the real operating conditions of the selected lines.

282

S. Ossowski et al. / Transportation Research Part C 13 (2005) 272–298

Fig. 6. Trial zone for the Malaga BFM demonstrator.

In the EMT Operating Support System the actual status/position of the buses is ascertained in real-time by means of GPS technology. As we were not allowed to establish such an online connection, however, we developed a simulator that emulated the EMT Operating Support System and constituted the ‘‘environment’’ for our agent-based DSS. Fig. 7 shows the interface of this simulator. Upon start-up, a line is selected, real data (number of buses and bus timetables) for the actual date and hour is loaded, and the status of the line and its buses is outlined schematically. The position and delay/advance of all services (buses) at any time is shown by a positive/ negative number above the bus. Additionally, it is possible to ascertain other data related to a particular bus or service (next stop, trip number, speed and number of passengers) by selecting the bus. Under normal operation, bus breakdowns, as well as delays, advances, saturations, etc., are generated at random. In addition, we have equipped the simulator with additional functionalities by means of which we can generate more complex problem scenarios easier. In particular, we can generate several incidents for single buses (advance, delay, saturate, cause a breakdown, and recover buttons in Fig. 7) or for entire lines (general advance, general delay and general recovery buttons in Fig. 7). Furthermore, we can configure specific problem situations (advance following

S. Ossowski et al. / Transportation Research Part C 13 (2005) 272–298

283

Fig. 7. Screenshot of the BFM simulator.

service, advance head service start, line head retention, jump stops and help between services options) that we will refer to in the next section. 3.2. Connection agents Bilbao demonstrator. The whole traffic network scenario in Bilbao has been divided in 12 overlapping problem areas to support a better analysis and understanding of the causes and evolution of traffic problems than if performed from a global perspective. A problem area is identified as a section of the network where traffic behaviour can be studied locally and suitably classified. Every Data Agents (DA) in the Bilbao demonstrator are in charge of collecting the information about the traffic situation in a particular problem area, delivered by the loop detectors (i.e. speed, occupancy and flow), and providing this information to any interested agent. This communication is supported by the FIPA-Query interaction protocol playing the DA participant role. Malaga demonstrator. BFM data agents (DA) indicate the status 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 uses the FIPA-Subscribe protocol to forward this information to any agent that previously subscribed to this service. BFM action implementation agents (AIA) simply forward commands to bus drivers via radio.

284

S. Ossowski et al. / Transportation Research Part C 13 (2005) 272–298

In the current implementation, the BFM DA is essentially a wrapper for the simulator described above. Note, however, that even under real operating conditions the detection and initial classification of incidents based on GPS data will also be performed by the Operating Support System. 3.3. Management agents 3.3.1. Bilbao demonstrator General description. Management Agents have been instantiated as a society of agents for the road management demonstrator. First, as we will outline below, the reuse of parts of the KSM knowledge tool (Cuena and Molina, 1997) required the introduction of wrappers called KSM agents. Second, the different granularity at which traffic management engineers conceive problem identification and diagnosis (problem areas), on the one hand, and action planning and impact estimation (control zones), on the other, suggested the use of Problem Detection Agents (PDA), and Control Agents (CA), respectively. Fig. 8 reflects the resulting structure of the Bilbao demonstrator. PDAs are responsible for monitoring the traffic flow in a problem area and detecting congestions. Whenever a problem situation is detected, the PDA asks a CA to generate possible action plans to deal with the situation. A CAÕs control zone comprises several problem areas, so it may have to deal with more than one congestion simultaneously. For this purpose, it asks the PDAs monitoring the problem areas surrounding the congestion for information about their general situation, to generate coherent signal plan proposals for the entire control zone. Such a control proposal consists of a collection of messages to be displayed on VMS panels with warnings or alternative routes recommendations for drivers approaching the congestion. When several problems are detected in different zones, and two or more CAs compete for the use of the same VMS panels, the CAs involved exchange their control proposal and reach an agreement based on conventions that establish (time-dependent) priorities. Knowledge model. The knowledge model supporting this entire process assigns data abstraction knowledge to PDAs to infer additional values that help to evaluate the global situation of a problem area, as well as problem identification knowledge. Periodically, every PDA asks the DA assigned to its problem area for the quantitative data recorded by the detectors in the road (i.e. speed, occupancy, saturation and flow). The abstraction knowledge transforms these data into matching qualitative values and deduces new parameters, like an estimation of the demand and excess traffic in different sections of the problem area. This knowledge is represented by means of JESS production rules. Fig. 9 includes a rule used to calculate the excess traffic in a section where an accident has been detected.

Fig. 8. Problem areas and control zones.

S. Ossowski et al. / Transportation Research Part C 13 (2005) 272–298

285

(defrule calculate-excess ?a_delete1 85%.

Fig. 10. Problem detection frame.

If more than one frame is output by the matching process, then the different signal proposals are sorted by their associated impact, i.e. the excess traffic they may potentially reduce. Fig. 11 shows one of the frames used by the CA Atena when a problem in area 6 (Rontegi direction Cruces) has been detected. Different conflicts often appear between the signal proposals selected by the CAs in the previous phase due to the characteristics of the traffic network and the limited number of variable message panels (VMS) available. Every CA knows with which acquaintances it may come into conflict and

#-------------------------------------------------------------------ATENA: Path Use Frame B1 #-------------------------------------------------------------------SIGNAL PROPOSAL VMS_Tuneles Avanzada Message = Delays at Rontegi direction Cruces. Recommended Eje Norte VMS_Artaza Message = Delays at Rontegi direction Cruces. Recommended Lamiako STATE OF THE PROBLEM AREAS (Rontegi_direction_Cruces) state = with problems, (Corredor de la Avanzada_direction_Bilbao) general state = medium/high severity, (Eje Norte_direction_Bilbao) general state = low severity EXPECTED DIVERSION Rontegi_direction_Cruces = Lamiako_direction_A8 = Eje Norte_direction_Airport =

[-22%, -24%] [+15%, +18%] [+7%, +10%]

Fig. 11. Route use frame.

S. Ossowski et al. / Transportation Research Part C 13 (2005) 272–298

287

therefore, once it has selected a signal proposal, it communicates with the other CAs with which it shares panels to detect and, if necessary, solve possible inconsistencies. Two different knowledge bases are used: one to solve local conflicts between proposals within the same control zone (different for every CA) and another with conventions on how to solve conflicts between different zones (Note, however, that such conflicts can also be solved through mutual agreement based on a multi-party negotiation mechanism, as pointed out by (Herna´ndez et al., 2002). In general, conflicts are solved by looking first at the severity of the problem and second its location. The importance of the location is dynamically estimated and depends on the problem area, the day of the week, and the time of the day. For instance, city accesses have higher priority than the exits in the morning, whereas the opposite is true in the afternoon. Conflict resolution knowledge is represented using JESS production rules. The top part of Fig. 12 shows a rule for assigning priority to a high instead of a medium severity problem. The bottom part of Fig. 12 depicts a rule applied to assign priority to problems with the same severity. In particular, it represents that a problem in area 6 (Rontegi_direction_Cruces) has higher priority than equivalent problems in areas 4 (South_direction_Bilbao San Sebastian), 5 (South_direction_Bilbao Santander) and 12 (Eje Norte_direction_Bilbao) in the morning. Interaction protocols. PDAs use the following interaction protocols: (1) FIPA-Subscribe: whenever a problem is detected the information about it is delivered to the agents subscribed to this service (CAs and UIAs), the PDA playing the participant role; (2) FIPA-Query: the PDA initiates this protocol to request new traffic data from the DA, and it plays a participant role to provide a CA with information about the state of the problem area.

(defrule priority1 (use ?agent1 ?panel ?area1 high ?hour1) ?id (retract ?id))

(defrule priority7 (use ?agent2 ?panel ?area&~"South_direction_Bilbao San Sebastián" ?severity morning) (use ?agent2 ?panel ?area&~" South_direction_Bilbao Santander" ?severity morning) (use ?agent2 ?panel ?area&~"Eje Norte_direction_Bilbao" ?severity morning) ?id (retract ?id))

Fig. 12. CA priority rules.

288

S. Ossowski et al. / Transportation Research Part C 13 (2005) 272–298

Regarding CAs, FIPA-Subscribe is used to support the subscription to the PDAs that should inform the CA about the presence of a problem and to provide the UIA with the description of new signal proposals, the CA playing the initiator and participant roles respectively. FIPA-Query is also used to ask a PDA for information on the traffic state in its problem area, and to exchange signal plan proposals with other CAs in the event of conflict. Both PDAs and CAs interact with their associated KSM agents to request the execution of a pattern matching process using FIPA-Request (to load the frame knowledge base) and FIPAQuery (to get the result of the process), always in the initiator role. For instance, Fig. 10 shows one of the congestion patterns that KSM agents, at the request of the respective PDA, use during the matching process. 3.3.2. Malaga demonstrator General description. Line management agents (LMA) are the direct counterpart of MAs in the BFM domain. They are in charge of bus line supervision and, in accordance with the actual conceptual and organisational structure of the EMTÕs control centre, there is one LMA for each line. A LMAÕs main purpose is to participate in information exchange interactions concerning incidents, problem causes, and control recommendations. A coordination facilitator (CF) supports the coordination among lines. More precisely, it acts as a mediator in the negotiation among LMAs to get a reinforcement service. When a line needs a reinforcement service (e.g. when the respective LMA detects the breakdown of a service or that the frequency of the services in the line is too low), the LMA asks the DM (by means of UIA) for permission to negotiate a reinforcement service. If the DM accepts, the LMA requests negotiation support from the CF. A concrete example of negotiation among LMAs to get a reinforcement service is presented in Section 4.2. Knowledge model. 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 behaviour of the line. Several elicitation interviews have been held with EMT operators to extract the knowledge and logs of real situations, which have been analysed to simulate and solve real problems. During these interviews, the most common incidents and the main control actions taken to minimize them were classified. Table 2 summarises the results. All other relevant features of the problem have been formally represented within a domain ontology. In particular, this ontology contains all the entities identified in the domain (bus, line, service, . . .), together with the above-mentioned information about incidents and control actions (Fig. 13). The ontology has been modelled and instrumented by means of the PROTEGE-II (Gennari et al., 2002) tool. LMA problem-solving knowledge is represented by a set of JESS production rules, and forward-chaining inference is used to instrument the respective reasoning services. Initially, the agent knowledge base contains CLIPS definitions of the ontology objects. When a LMA receives information about an arrival or an incident, it asserts this information in the CLIPS knowledge base as a fact. As a consequence, different cycles of rule firings take place to determine LMA reactions. Fig. 14 gives an example of a simple rule that relates a control action (helpBetweenServices) with a certain problem (servicesTogether).

S. Ossowski et al. / Transportation Research Part C 13 (2005) 272–298

289

Table 2 BFM knowledge model: incidents and control actions Incidents Individual delay. One bus in a line is delayed

Generalised delay. Several buses of the same line are delayed

Multi-line delay. There are delays in several lines

Advance. A bus arrives at a stop before the expected time Saturation. One bus in a line is full and provide service to additional passengers Breakdown of a bus

Service together. Two buses of the same line do not maintain the right temporal distance among them

Control actions • Increase the speed of a bus. It is used when the delay is low • Jump stops. This action is used when a bus has a severe delay and its predecessor in the same line is at its head stop. The delayed bus goes straight to the convenient stop while the predecessor delays its departure several minutes • Change timetable regulation to frequency regulation. Each bus of a line must arrive at a stop every n minutes instead of arriving at a fixed times • Change frequency regulation to timetable regulation. The inverse to the above control action • Timetable re-planning. Decreasing the departure frequency of the buses of a line • help between services. A collaboration between two buses in as far as they interleave the stops they serve • Change timetable regulation to frequency regulation. See above • Timetable re-planning. See above • Reduce the speed of a bus. See above • Advance following service. When a bus is saturated another bus overtakes it (generally the bus behind the saturated one) • Reinforcement service. An additional bus is included in a line. This action is possible when there are reserve buses or drivers available. When this is not possible, a bus needs to be transferred from another line (see Section 4.2) • Advance head service start. The bus at the head stop must start before it is scheduled • Line head retention. When two buses arrive at the head stop at the same time, one of them is told to wait there

Interaction protocols. As Fig. 15 indicates, LMAs use the following interaction protocols: (1) FIPA-Subscribe: the LMA plays the initiator role to gather 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; (2) 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 below), who is in charge of locating adequate LMAs by means of a FIPA-query sub-protocol. (3) FIPA-Query: before starting a negotiation with others to get a reinforcement service, a LMA asks its DM (through the UIA) for authorisation. In addition, a LMA may need to reply to the CFÕs query as to whether it is willing to accept a certain service transfer deal; and (4) FIPA-Request: LMAs use this protocol to actually execute an agreement to shift a vehicle from one line to another.

290

S. Ossowski et al. / Transportation Research Part C 13 (2005) 272–298

Fig. 13. BFM ontology.

(defrule propose-help-between-services ?h (retract ?h) (assert (helpBetweenServices (service1 ?s1) (service2 ?s2))) )

Fig. 14. BFM knowledge representation.

With regard to the CF, this takes on the broker role (participant) in a FIPA-Brokering interaction to select the best line from which to shift a service when a LMA needs a reinforcement service. Additionally, it plays the informee (initiator) role in the FIPA-Query sub-protocol to get information from LMAs about the cost of the loss of the service in the lines concerned.

S. Ossowski et al. / Transportation Research Part C 13 (2005) 272–298

291

Fig. 15. BFM interactions.

3.4. Interface agents Bilbao demonstrator. User interface agents (UIA) show information to the operators (DM) at the Mobility Management Centre. This information includes the status of the traffic flows (problems) and the set of messages to be displayed on VMS panels (control proposal). For this purpose, the UIA initiates FIPA-Subscribe protocols to get information about current problems from PDAs and control recommendations from CAs. The graphical interface generated by the UIA (Fig. 16) allows operators to select different visualisation modes for traffic information. On the left-hand side of the figure, the traffic situation is

Fig. 16. Traffic management UIA.

292

S. Ossowski et al. / Transportation Research Part C 13 (2005) 272–298

shown in relation to a satellite photo of the Bilbao area. The main roads are highlighted, and their colour represents their current status (green, yellow, orange and red states for free as well as low, medium and high congestion levels, respectively). The same information can be displayed as a diagram or in text mode. Details about traffic problems can be obtained by clicking on the respective entities. The right-hand part of the interface shows control recommendations and their justifications. Malaga demonstrator. User interface agents (UIA) display selected information to the BFM operators (DM) at the control centre. This information shows the status of the line, informs about incidents or problems and reports control recommendations or proposals coming from the LMAs. With the goal of displaying this information, a UIA subscribes to the service offered by the DAs to get information about the arrivals and incidents in each line. Besides, it initiates a FIPA-Subscribe protocol with LMAs to get 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 authorise negotiations for reinforcement services. The graphical interface of an UIA is similar to the simulator (Fig. 17). However, it has the added functionality of displaying and the option for DMs to accept or reject the control recommendations (left part of the window). There is a different window or panel for each line. In addition, the bottom part of the window contains status information about each particular service of the selected line (next stop, actual timetable, . . .). In Fig. 17 for example, line 3 has been selected

Fig. 17. Screenshot of the BFM UIA.

S. Ossowski et al. / Transportation Research Part C 13 (2005) 272–298

293

for visualization. The schematic layout of the line with its actual status is displayed in the left part A a generalised delay is therefore detected. A decision support dialogue with the recommendation is shown on the right of the window: the DSS recommends switching to frequency regulation with a 10-minute frequency. 3.5. Peripheral agents Both demonstrators have been implemented on the JADE platform (Bellifemine et al., 1999). For the time being, the only peripheral agents are the Directory Facilitator and an Agent Management System provided by JADE.

4. DSS agent interaction: two examples In this section, we illustrate the dynamics of the demonstrators that we have implemented. For this purpose, we provide traces of DSS agent interactions for different example scenarios. 4.1. Road traffic management The version of the Bilbao demonstrator now running covers five problem areas and two control zones. Therefore, we have 5 DAs, 5 PDAs, 2 CAs, 11 KSM agents (one per problem area and three per control zone), as well as 1 UIA. Suppose we have the scenario shown in Fig. 18, where three congestions happen simultaneously in problem areas 2, 6 and 11. The latter is caused by an over-saturation of the road due to a high volume of traffic in a section with one lane less. The other two are caused by accidents. The respective PDAs detect the problems from the traffic data sent by the DAs and inform the subscribed CAs. Congestions in areas 2 and 6 are reported to CA Arena whereas congestion in area 11 is reported to Demetra. After gathering information on the general situation in neighbouring areas (querying PDA12 and PDA7, respectively), Atena generates potential solutions for the congestions in problem areas 2 and 6, while Demetra configures signal plan proposals for the problem detected by PDA11. Every CA in the DSS knows with which other CAs it is likely to come into conflict. Therefore, once Atena and Demetra have achieved a consistent signal proposal for their control zones (making use of local conflict resolution knowledge), they inform each other about these proposals to identify potential non-local interdependencies. In the first stage of the example scenario, only congestions in areas 2 and 6 are active, so Atena defines appropriate solutions using panels P1, P3 and P4, where drivers are warned about the congestion and recommended to take the route associated with area 8. However, when some minutes later the saturation problem is also detected in area 11, Atena and DemetraÕs best signal proposals happen to be mutually exclusive, since they try to display different messages on the same VMS panel, i.e. panel P3. This conflict is resolved locally by each CA, applying conventions respecting priorities for the use of the VMS panels, based on the severity of the problems and the time of the day when these problems occur. Finally, both CAs send potential signal plans for their control zones to the UIA, which displays them to the DM as a coherent global action proposal. In this example, the severity of the problems to be solved

294

S. Ossowski et al. / Transportation Research Part C 13 (2005) 272–298

Fig. 18. Example congestion scenario.

by Atena is initially higher than the severity of the new congestion in area 11. Therefore, Atena and Demetra agree that panel P3 should be used by Atena. Note that thirty minutes later the opposite may occur, and Demetra will use P3 to divert traffic from area 11. Fig. 19 shows a snapshot of the simulation of the aforementioned scenario. 4.2. Bus fleet management An interesting case of complex agent interactions in the BFM domain is when a vehicle of a certain line suffers a breakdown. As MalagaÕs EMT does not maintain a pool of reserve vehicles, negotiation with other lines is needed to agree on a transfer of a service from one line to the other. As we mentioned above, the CF is the agent in charge of acting as a mediator in the negotiation among LMAs to get this reinforcement service. The goal of the negotiation process is to find a line that transfers or provides a service with the following constraints: (1) the cost of losing the service should be lower for the supplier line than the cost of losing the service for the LMA that initiates the negotiation; and (2) the distance between

S. Ossowski et al. / Transportation Research Part C 13 (2005) 272–298

295

Fig. 19. Simulated congestion in area 6.

the head stops of both lines (provider and receiver) should be as low as possible. This cost is designed to measure the degradation in the quality of service that a line offers to its users due to its bus breakdown, and can be computed from statistics about passengers or, as in our example, just as a function of the reduction in the frequency of services (note that this knowledge is private and not communicated to the remaining agents). In accordance with these conditions, the negotiation is organized in different negotiation rounds. The negotiation algorithm obeys the following pattern: 1. In the first round, the LMA that needs a reinforcement service asks the CF for support to find LMAs with lines sharing its head stop; it also asks whether they wish to transfer a service at a certain price. This value is the price that the initiator LMA would pay the LMA that agrees to provide the reinforcement service. 2. The CF contacts LMAs that share its head stops with the initiator LMA. All these LMAs calculate their cost of losing a service in their line. If this cost is lower than the proposed price by the initiator LMA, they may accept the offer; otherwise they will reject it. The CF reports the results to the initiator. 3. If all the LMAs reject the offer, the initiator tells the CF that a new negotiation round is needed. The CF repeats the same offer but also contacts LMAs whose head stops are located further away.

296

S. Ossowski et al. / Transportation Research Part C 13 (2005) 272–298

4. If all the LMAs at any distance reject the offer, the initiator LMA increases the offered price, going back to the step 2. 5. Steps 2, 3 and 4 are repeated until a LMA agrees to transfer a service or until the price offered by the initiator is equal to its cost for losing a service, and all the LMAs at any distance reject the offer. In this case, the negotiation ends in failure. 6. If a LMA accepts to transfer a service, the CF informs the initiator LMA, which will send a control recommendation to the UIA reporting that the respective line has accepted to transfer a reinforcement service. The DM is in charge of taking the final decision. Suppose LMA12 detects a breakdown of a vehicle serving EMT line 12 in western Malaga, and recommends asking for a reinforcement service. Furthermore, the DM replies positively to the LMAÕs request to initiate a negotiation process. Fig. 20 illustrates the essentials of this negotiation process, which unfolds across three ‘‘rounds’’. In a first round, LMA12 asks the CF for support to find LMAs with lines sharing its head stop (in the example, the only one is LMA3). In addition, it asks whether they are willing to transfer a service at an initial price of 110 (220 being its own cost of losing a service). LMA3 determines its cost of losing a service as 169, so it rejects the offer. Subsequently, LMA12 increases the distance to the head stop up to 1 km, and the CF forwards the same offer to LMA15 (with its head stop located at 1 km), but it also refuses because its cost is 264 (Fig. 20, round 1). At this point, LMA12 initiates a second round of negotiation (there are no more lines to negotiate with), increasing its price to 154. The CF repeats brokering at the new price. Again, LMA3,

Fig. 20. Example negotiation process.

S. Ossowski et al. / Transportation Research Part C 13 (2005) 272–298

297

which shares its head stop with LMA12, rejects the offer because its cost, 169, it is still higher than the offered price. And when LMA12 increases the distance to 1 km, LMA15 also refuses the offer because the cost of losing a service in its line is even higher, 264 (Fig. 20 round 2). Finally, in the third negotiation round, LMA12 offers a price of 198, which is accepted by LMA3 as it exceeds its cost 169 (Fig. 20, round 3). The CF communicates acceptance to the LMA12, which sends a control recommendation to the UIA notifying that line 3 has accepted to transfer a reinforcement service. Again, the DM is in charge of the taking the final decision, before the actual request for shifting the service is forwarded to line 3.

5. Conclusions In this paper we have shown how multiagent 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 multiagent architecture. Furthermore, we have shown in detail how this abstract architecture has been used to design prototype DSS for the domain of road traffic management in the greater Bilbao area, as well as bus fleet management scenarios for the Spanish town of Malaga. The implementation of the demonstrators, which involved the integration of several software technologies and tools (JADE, KSM, JESS, Prote´ge´-II), was initially complex, but required a reasonable amount of programming work. In particular, the agentification of the KSM knowledge representation and inference schemes (Cuena and Molina, 1997) and their subsequent integration into JADE went smoothly. By contrast, the effort it took to integrate the different ontologies (and the representations used in the different tools) was rather high. There is, therefore an evident need for standards and tools to provide assistance for this task. Furthermore, we found that some communicative roles and interactions are not very well supported by FIPA. To stay FIPA compliant, for instance, we had to implement advisory interactions by means of information exchange interactions (using FIPA-query or FIPA-subscribe protocols) in our prototypes. As a result, we have developed a method to build principled extensions to ACLs, and FIPA ACL in particular (Serrano et al., 2003), as well as a set of software components that encapsulate the respective dialogue behaviour for use by JADE agents, for use in future applications. When the knowledge models of the prototypes have been further refined, we intend to run a detailed performance evaluation in collaboration with the Public Works and Transport Dept. of the Local Government of Bizkaia and MalagaÕs Local Transport Consortium (EMT). Future work extends to the integration of additional Peripheral Agents (e.g. traffic management agents supply services for the BFM system), and the use of mobile devices (e.g. onboard driver information systems).

Acknowledgement The work reported in this article has been partially supported by the Spanish Ministry of Education and Science (MEC) under grant TIC2000-1370-C04 and TIC2003-08763-C02.

298

S. Ossowski et al. / Transportation Research Part C 13 (2005) 272–298

References Austin, J., 1962. How to do Things with Words. Clarendom Press, Oxford. Bellifemine, F., Poggi, A., Rimassa, G., 1999. JADE—a FIPA-compliant agent framework. In: 4th International Conference on Practical Applications of Intelligent Agents and Multi-Agent Technology (PAAMÕ99), 97–108. Cuena, J., Molina, M., 1997. KSM—an environment for design of structured knowledge models. In: Tzafestas (Ed.), Knowledge-Based Systems. World Scientific. Cuena, J., Ossowski, S., 1999. Distributed models for decision support. In: Weiss (Ed.), Multi-Agent Systems—A Modern Approach to DAI. MIT Press, pp. 459–504. Ferber, J., Gutknecht, O., Jonker, C., Muller, J., Treur, J., 2000. Organization models and behavioural requirements specification for multi-agent systems. In: ECAI 2000 Workshop on Modelling Artificial Societies and Hybrid Organizations. French, S. 2000. Decision Analysis and Decision Support Systems. The University of Manchester. Gennari, J., Musen, M.A., Fergerson, R.W., Grosso, W.E., Crube´zy, M., Eriksson, H., Noy, N.F., Tu, S.W., 2002. The evolution of prote´ge´: an environment for knowledge-based systems development. Stanford Medical Informatics, Technical Report SMI-2002-0943. Herna´ndez, J., Serrano, J., 2000. Reflective knowledge models to support an advanced HCI for decision management. Expert Systems with Applications 19 (4), 289–304. Herna´ndez, J., Serrano, J., 2001. Environmental emergency management supported by knowledge modelling techniques. AI Communications 14 (1), 13–22. Herna´ndez, J., Ossowski, S., Garcı´a-Serrano, A., 2002. Multiagent architectures for intelligent traffic management systems. Transportation Research C 5 (10), 473–506. Hoa Dam, K., Winikoff, M., 2003. Comparing agent-oriented methodologies. In: Giorgini et al. (Eds.), Agent-Oriented Information Systems. Springer, pp. 78–93. Iglesias, C., Garijo Ayestara´n, M., Gonza´lez, J., 1999. A Survey of Agent-Oriented Methodologies. Intelligent Agents V. Springer, pp. 317–330. Klein, M., Methlie, L., 1995. Knowledge-Based Decision Support Systems. John Wiley. Klusch, M., Sycara, K., 2001. Brokering and matchmaking for coordination of agent societies—a survey. In: Omicini et al. (Eds.), Coordination of Internet Agents—Models, Technologies, and Applications. Springer-Verlag, pp. 197– 224. Ossowski, S., Herna´ndez, J., Iglesias, C., Ferna´ndez, A., 2002. Engineering agent systems for decision support. In: Tolksdorf, Zambonelli (Eds.), Engineering Societies in an Agent World III. Springer, pp. 234–274. Ossowski, S., Pe´rez de la Cruz, J., Herna´ndez, J., Maseda, J., Ferna´ndez, A., Belmonte, M., Garcı´a Serrano, A., Serrano, J., Leo´n, R., Carbone, F., 2004. In: Conejo et al. (Eds.), Current Topics in Artificial Intelligence. Springer, pp. 597–607. Serrano, J., Ossowski, S., Ferna´ndez, A., 2003. The pragmatics of software agents—analysis and design of agent communication languages. In: Klusch et al. (Eds.), Intelligent Information Agents—An AgentLink Perspective. Springer, pp. 234–274. Serrano, J., Ossowski, S., Saugar, S., 2005. Reusability issues in the instrumentation of agent interactions. In: Bordini et al. (Eds.), Proceedings of the 3rd International Workshop on Programming Multi-Agent Systems. University of Utrecht, pp. 65–80. Silver, M., 1991. Systems that Support Decision Makers. John Wiley. Vlahavas, I., Bassiliades, N., Sakellariou, I., Molina, M., Ossowski, S., Futo, I., Pasztor, Z., Szeredi, J., Velbitskiyi, I., Yershov, S., Netesin, I., 2002. expernet—an intelligent multi-agent system for WAN management, IEEE Intelligent Systems 16 (7), 62–72. Wooldridge, M., Jennings, N., Kinny, D., 2000. The gaia methodology for agent-oriented analysis and design. Autonomous Agents and Multiagent Systems 3 (3), 285–312. Zambonelli, F., Jennings, N., Wooldridge, M., 2000. Organizational abstractions for the analysis and design of multiagent systems. In: Ciancarini, Wooldridge (Eds.), Agent-Oriented Software Engineering. Springer, pp. 235–252.