Hierarchical Organizations for Decentralized Traffic Monitoring Robrecht Haesevoets, Danny Weyns, Lieven Christiaens Fried Meulders, Tom Holvoet, Wouter Joosen DistriNet Labs, Katholieke Universtiteit Leuven, Belgium Email:
[email protected]
Abstract The use of floating car data is an interesting method to monitor traffic. Vehicles act as local traffic sensors and data from individual vehicles is aggregated into higher-level information. We propose a number of reusable organization abstractions and a software architecture to support a multi-agent approach for floating car data. The abstractions are based on the idea of hierarchical organizations which are used as units of data aggregation. In this approach, an agent is deployed on each vehicle. At the lowest level, nearby vehicle agents collaborate to aggregate individual traffic data and distribute it to local clients such as traffic light controllers. At higher-levels, organizations are built up from lower-level organizations and represent specific aggregation interests such as the total congestion level in a specific area. This decentralized approach avoids the bottleneck of a centralized control center and makes the system more robust and scalable. A prototype was built, supporting a two-level organization structure, and is used in a simulated traffic environment as initial validation.
1
Introduction
In our dynamic society traffic congestion is an ever growing problem. A first step to address this problem is to monitor the traffic. Traditional approaches often involve static road sensors such road-side cameras and radars. A central traffic information center is typically used to collect all raw data coming from road sensors. This data is processed and aggregated into high-level traffic information. The traffic information is then distributed to interested parties such as traffic light controllers or driver assistance systems. These centralized approaches, however, have several drawbacks [22]. They often lack coverage in larger networks and can suffer from potential single-point failures. The required infrastructure is expensive to deploy and to maintain. As the number of highways equipped with sensors increases, the central traffic information center quickly
becomes a bottleneck. Distributing traffic data through a central traffic center, also causes a serious delay (claimed to be in the range of 20-50 minutes [23]), which makes it unsuitable for real-time applications such as emergency systems and smart highway merging [21]. Recent technological advances, such as onboard car computers, GPS devices and inter-vehicle communication, allow us to explore new approaches for traffic monitoring. A promising approach is the use of floating car data in which vehicles are transformed into traffic sensors and monitor local traffic data, such as the local congestion level. Individual data from vehicles is then aggregated to get higherlevel aggregation such as the congestion level on a road. A number of decentralized approaches for traffic monitoring have been proposed [4, 19]. This paper considers a multi-agent approach for floating car data. An agent is deployed on each vehicle, which has access to sensors installed on the vehicle. This allows the vehicle agent to get local context information such as GPS location, speed, driving direction, etc. Vehicles are also equipped with a wireless communication unit which allows local interaction between vehicle agents. Nearby vehicle agents collaborate to aggregate individual traffic data and distribute it to interested clients. This decentralized approach avoids the bottleneck of a centralized control center and makes the system more robust and scalable. However, the large amount of interacting vehicle agents and the dynamic nature of the problem, in which vehicles constantly come and go, lead to complex interaction and coordination problems. In order to deal with these complexities we offer a number of organization abstractions and a supporting software architecture. The organization abstractions presented in this paper build upon earlier work [10] in which we proposed a distributed coordination infrastructure based on the concepts of organization and role. Agents are grouped together in organizations in which they play roles. The coordination infrastructure is responsible for the evolution of the organizations. This results in the separation of two concerns: (1) the evolution of dynamic organizations and (2) the actual
functionality provided by the agents playing roles. Separating these two concerns reduces the complexity of the agents making it easier to understand, design, and manage organizations in multi-agent systems. These advantages hold for the coordination infrastructure presented in this paper as well. However, the approach presented in this paper contrasts with the approach described in [10] in two ways:
O rg A 0 ..1
O rg a n iza tio n
d e sc rib e s th e e v o lu tio n o f
0 ..*
O rg B
1 c o n s is ts o f
Key
1 ..*
is
O rg a n iz a tio 0n..* 0 ..*
0 ..*
R o le 1 ..*O rg D
O rg A
• The software architecture described in [10] is deployed on a static platform (road side cameras) whereas the software architecture presented in this paper is deployed on a dynamic mobile platform (moving vehicles). This is reflected in a more lightweight and adapted organization model and supporting architecture.
Car
p la y s
d e s crib e s th e e vo lu tio n o f
E vo lu tio n L a w 0 ..* uses
O rg E
1
1 0 ..*
1 O rg a n iza tio n M em ber O rg C O rg B 0 ..1 m e rg e m e rg e is
has
1
C o n te x t
s p lit
0 ..1
• The organization model presented in this paper extends the model described in [10] with support for hierarchical organizations. Hierarchical organizations are used as units of data aggregation which is important with respect to scalability.
O rg A
A g e nOt rg D
O rg F O rg G
Figure 1. Overview of the conceptual organiO rg a n iz a tio n K e ymodel. C a r zation
A prototype of the software architecture was built and is used in a simulated environment to evaluate the proposed organization abstractions.
O rg J
Overview of the paper The next section introduces the organization abstractions. Section 3 presents a software architecture supporting these abstractions. Section 4 describes how the software architecture uses the abstractions to concretely evolve the organizations. We describe the prototype and evaluation in Sect. 6. Section 7 discusses related work. Finally, we draw conclusions and outline issues for future research.
2
Organization Abstractions
Hierarchical organizations are the main idea behind the abstractions presented in this paper. They are used as units of data aggregation. At the lowest level, organizations consist of small groups of agents, for example, nearby vehicle agents in the same traffic situation. At higher-levels, organizations are built up from lower-level organizations and represent specific aggregation interests, for example, all vehicles in a traffic jam or the total congestion level on an important highway. Within organizations, agents play roles to fulfill the requirements of the organization, for example, monitoring the traffic, aggregating data, etc. An overview of the organization abstractions is given in Fig. 1.
Key
O rg a n iz a tio n
Figure 2. Lower-level organizations merged into one higher-level organization.
lowing hierarchical organizations. At the lowest level, organizations can only consist of agents. At higher-levels, organizations are built up from lower-level organizations. Evolution laws describe the evolution of organizations using the current context as input. Figure 2 shows an example of organization in decentralized traffic monitoring. A software agent is deployed on each vehicle and vehicle agents are grouped in organizations. Using the concept of organization has a number of benefits: (1) it offers a higher-level abstraction to application developers; (2) it allows to limit information flooding to only those entities interested in the information, namely the organization members, and (3) it increases the granularity of data and the scalability of data aggregation.
2.2 2.1
Car
A
C O bs
O rg M ed fu lfills
Roles
Organizations
Organizations consist of organization members. Both agents and organizations can be organization members, al-
Within organizations, a number of roles are defined. Roles are played by organization members and represent a coherent set of functionalities which need to be performed
Key
ge
O rg C
s p lit
O rg A O rg F
Agent
O rg G
O rg B Agent
Agent
M e d ia to r
O rg a n iz a tio n
Agent M e d ia to r
M e d ia to r fo r e a ch m em ber
O rg a n iza tio n C O rg a n iz a tio n
O rg a n iza tio n A
O rg a n iza tio n B
Agent A
Agent B
Agent C
C o n te xt M a n a g e r R o le
C o n te xt M a n a g e r R o le
C o n te x t M a n a g e r R o le
O rg a n iz a tio n M e d ia to r R o le fu lfills
O rg a n iza tio n M e d ia to r R o le
fu lfills
fu lfills
C o n te x t O b s e rve r R o le
C o n te x t M a n a g e r R o le
O rg a n iza tio n M e d ia to r R o le
Key
Agent
R o le
Agent B
Agent C
O rg a n iza tio n M em ber
O rg a n iza tio n M em ber
O rg a n iz a tio n M em ber
O rg a n iza tio n M em ber
O rg a n iza tio n M em ber
O rg a n iz a tio n M em ber O rg a n iza tio n M em ber
O rg a n iz a tio n M em ber
O rg a n iza tio n
O rg a n iz a tio n M em ber
O rg a n iza tio n M em ber
Agent D
A g g re g a within tio n R o le
A g g reand g a tio n organizations the organization. Both agents R o le can play roles. The available roles in an organization and a g g reof g a teroles d d a ta to organization members the possible assignment A g g re gand a tio n the current context. are defined by the evolutions laws R o le Apart from a set of application specific roles, such data agtra ffic d a ta gregation roles or distribution roles in the traffic monitoring D is trib u tio n case, a number ofa ndefault roles areR oneeded to support the orle O rg iza tio n C ganization structure. Currently, there are two default roles: D a taThe context context organization A g e n t manager R o and le O rg a n iza tiomediator. n flo w manager role is played by each organization member and is responsible to keep its own context consistent with the context of the other organization members. There is one organization mediator role in every organization. This mediator is responsible for playing or delegating the roles the organization has to play as an organization member in higher-level organizations. An example is shown in Fig. 3 in which organization A plays two roles in organization C and organization B plays one role in organization C. These roles are played by the organization mediator of each organization.
2.3
E vo lu tio n C a n d id a te s (c a n d id a te []): - ID - le v e l - e v o lu tio n D a ta - n b O fA g e n ts - m e d ia to rID
O rg a n iz a tio n M em ber
lo w -le v e l d a ta
lo w -le ve l d a ta
Key
O rg a n iza tio n (o rg ): - ID - le v e l - e v o lu tio n D a ta - n b O fA g e n ts - m e d ia to rID - p la ye d R o le s
if m e m b e r is m e d ia to r o f a n o rg a n iza tio n
Figure 4. The context of an organization member. O rg a n iza tio n M em ber
Figure 3. Agents playing roles in low-level whichO rgina n iza turn O rg a norganizations, iz a tio n A tio n Bplay roles in higher-level organizations.
Agent A
M e m b e r (m e m ): - ID - le v e l - e v o lu tio n D a ta - n b O fA g e n ts - p la y e d R o le s
if m e m b e r b e lo n g s to a n o rg a n iz a tio n
Context
Each organization member has an associated context representing the current state of its local environment and organization. An overview of the context of an organization member is shown in Fig. 4. This context contains data on the member itself and the organization it belongs to. If the member is mediator of its organization, it also contains a list of evolution candidates. Evolution candidates are other organizations this organization can cluster with, for example, by merging or joining, as explained in Sect. 2.4. For decentralized traffic monitoring, the evolution data
O rg a n iz a tio n C o n tro lle r
Figure 5. Fundamental diagram of traffic flow. m e d ia to r E
m e d ia to r C
O rgcurrent E consists of the velocity, traffic state and location. At or vehicle Olevel, the velocity is the vehicles velocity, O rgagent D rg C the trafficO state is undefined, and the location the current rg A O rg B ... gps location. At higher levels the velocity and location are calculated as the average of the individual velocities and locations of all members. The traffic state has three possible m e d ia to r A m e d ia to r B values, free flow (green), bound flow (yellow), and congestion (red), as shown in Fig. 51 . The traffic state is calculated from the average velocity (V) and density (D). The density is calculated as the number of vehicles per length unit, which is derived from the individual locations of the members. A hysteresis curve can be used to avoid rapid fluctuations.
boolean isValidCandidate = (higherOrg == null && candidate.higherOrgID == null) || (higherOrg.orgID == candidate.higherOrgID); boolean mergeCondition = orgLevel == candidate.orgLevel && state.equals(candidate.state) && inRange(position, candidate.position, orgLevel) && nbAgents + candidate.nbAgents < maxSize(orgLevel) && hasInitiative(nbAgents,candidate.nbAgents, orgID, candidate.orgID); boolean joinCondition = orgLevel < candidate.orgLevel && state.equals(candidate.state) && inRange(position, candidate.position, candidate.orgLevel) && nbAgents + candidate.nbAgents < maxSize(candidate.orgLevel); boolean creationCondition = orgLevel maxSize(candidate.orgLevel); Boolean splitCondition = higherOrg.nbAgents > maxSize(higherOrg.orgLevel) || !state.equals(higherOrg.orgLevel) || !inRange(position, higherOrg.position, higherOrg.orgLevel);
2.4
Evolution Laws
Evolution laws define how organizations should evolve, based on the current context. There are currently five types of laws: a merge law defining how organizations of equal levels can merge, a join law defining how a lower-level organization can join a higher-level organization, a creation law defining how an organization can create a higher-level organization, a split law defining how organization members can split from their current organization, and a role law defining which roles should be played by a member. These 1 Source: Hendrik Ammoser, Fakult¨ at Verkehrswissenschaften, Dresden, Germany
} //join law: if((org == null || org.level - level > 1) && level < candidate.level && splitCondition(org.evolutionData, candidate.evolutionData)){ org.ID = candidate.ID; org.mediatorID = candidate.mediatorID; }
t1
t2
D
t3
//creation law: (initalization || merging/joining impossible) if((org == null && level == 0) || ( ( o r g = = n u l l | | o r g .m l eevdeialto r- Bl e v e l > 1 ) & & m e d ia to r D m e d ia tonr bAA g e n t s + c a n d i d a t e . n b A g e n t s > m a x S i z e ( c a n d i d a t e . l e v e l ) & & level 0 && org != null && sp lit (org.nbAgents > maxSize(org.level) || m e d ia to r D s p l i t C o n d i t i o n ( e v o l um t ieodniaDtoa rt aB, o r g . e v o l u t i o n D a t a ) ) { m e d ia to r Ar e m o v e C o n t e x t L e v e l ( o r g ) ; O rg E org = null; } O rg B //role law: C D f orgr (Ar o l e : p o s s i b l e R o l e s ) { O if(role.startCondition(playedRoles, org.playedRoles, org.evolutionData)) m e d ia to r C m e d ia to r E startRole(role); if(role.stopCondition(playedRoles, org.playedRoles, m e rg eo r g . e v o l u t i o n D a t a ) ) m e d ia to r D stopRole(role); m e}d ia to r A O rg E
O rg
C
A
m e d ia to r C
D
Key
te
m e d ia to r E
O rg a n iz a tio n
Figure 6. Examples of how organizations can evolve, as defined by the evolution laws.
D
D
Car
D
laws are chosen as a minimal set to support hierarchical organizations. Figure 6 shows an example of splitting and merging organizations. A simplified version, in pseudo code, of the merge, split fo r e a ch m e m b e r b e lo n g s if m e m b e r is m e d ia to r and role are iftogiven in m e m blaws er a n o rgin a n izFig. a tio n 7. The conditions o f a n o rg a nprinted iza tio n italics are application specific and should be defined by the M em ber O rg a n iza tio n (o rg ): E vo lu tio n C a n d id a te s (ca n d id a te []): application developer. These conditions (m e m ): - ID - ID take the application - ID ve l as input. An example - le v e l specific evolution- ledata of a merge and - le ve l - e vo lu tio n D a ta - e vo lu tio n D a ta split case. The - e vocondition lu tio n D a ta is- ngiven b O fA g efor n ts the traffic- nmonitoring b O fA g e n ts - n b O fA g e n ts - m e d ia to rID - m e d ia to rID role conditions also take the roles the member is currently - p la y e d R o le s - p la ye d R o le s playing and the roles that are currently being played in the organization as input. The role conditions for the mediator and context manager role do not need to be provided by the M e m b e r: application developer. O rg a n iz a tio n : - ID = O rg B - ID = O rg E how the - Section tra fficS ta te =4b owill u n d F loshow w - tra fficS ta te evolution = co n g e stio n laws, together ... .. with the context, are used. by the coordination infrastructure (Sect. 3) to concretely evolve the organizations.
3
Supporting Software Architecture
Figure 8 shows an overview of the software components deployed on each vehicle. Vehicles are connected by a wireless communication network. The software on each vehicle consists of the Host Infrastructure, the Coordination Infrastructure and the Agent. The host infrastructure offers access to the operating system and other low level services, and is used by the coordination infrastructure. As in [10], the coordination infrastructure is responsible for the evolution of
//merge law: if(org.level == candidate.level && org.nbAgents + candidate.nbAgents < maxSize(org.level) && hasInitiative(org.nbAgents, candidate.nbAgents, org.ID, candidate.ID) && mergeCondition(org.evolutionData, candidate.evolutionData){ informLowerMembers(candidate.ID, candidate.mediator); endMediatorRole(); } //split law: if(level > 0 && org != null && (org.nbAgents > maxSize(org.level) || splitCondition(evolutionData, org.evolutionData)){ removeContextLevel(org); org = null; } //role law: for(role : possibleRoles){ if(role.startCondition(playedRoles, org.playedRoles, org.evolutionData)) startRole(role); if(role.stopCondition(playedRoles, org.playedRoles, org.evolutionData)) stopRole(role); } boolean mergeCondition(EvolutionData org, EvolutionData candidate){ return org.trafficState == candidate.trafficState && inRange(org.location, candidate.location, org.level); } boolean splitCondition(EvolutionData member, EvolutionData org)){ return member.trafficState != org.trafficState) || !inRange(member.location, org.location, org.level); }
Figure 7. Evolution laws in pseudo code (upper part), and merge and split conditions for the traffic monitoring case (lower part).
the organizations and offers organizations and roles to the agent. The abstractions of organization and role allow to separate the evolution of dynamic organizations from the actual functionality provided by the agents playing roles. Agents can communicate and perceive the world through the roles they play. The core of the coordination infrastructure consists of the organization controller. This controller uses the context in the Local Context repository as input, to evolve the organizations, based on the Organization Laws. Organizations are managed by updating the local context. Roles are managed through the role life cycle interface, which allows to add and remove roles from the Role Pool. All roles have access to the perception and communication module and can update and view the local context. Agents have to play the roles in the role pool and have access to communication and perception services through the role interfaces of these roles.
Context Management The context of each organization member is maintained in a local context repository. The context of an agent is maintained in the local context repository on the node it is deployed on (e.g. a vehicle). The context of an organization is maintained in the same repository as its mediator’s con-
M e m b e r: ... m e d ia to r A
m e d ia to r B
m e ssa g e
RRRooolelele v ie w / u p d a te
M e m b e r: - ID = o rg B - le v e l = 1 - tra fficS ta te = b o u n d flo w ...
ro le in te rfa ce
R o le P o o l
O rg a n iza tio n C o n tro lle r
vie w / u p d a te
P e rce p tio n
re a d E v o lu tio n Laws
C o m m u n ica tio n
O rg a n iz a tio n : - ID = o rg E - le v e l = 2 - tra fficS ta te = c o n g e s tio n ...
E vo lu tio n C a n d id a te s: ...
Figure 9. Extract of the context of organization B as member of organization E at t1 .
ro le life cycle in te rfa ce
L o ca l C o n te xt
E v o lu tio n C a n d id a te s : - ID = o rg A - le v e l = 1 - tra ffic S ta te = b o u n d flo w - lo c a tio n = (x _ A , y _ A ) - n b O fA g e n ts = 3 - m e d ia to r = m e d ia to rA ...
c o n te x t o rg a n iz a tio n B
Agent
p e rc e p t
O g ra n iz a tio n : - ID = o rg B - le v e l = 1 - tra fficS ta te = b o u n d flo w - lo c a tio n = (x _ B , y_ B ) - n b O fA g e n ts = 2 - m e d ia to r = m e d ia to rB ...
4
Organization Evolution
C o o rd in a tio n In fra s tru c tu re lo w -le ve l d a ta
lo w -le ve l m e ssa g e
H o s t In fra s tru c tu re
Key
Com ponent
D a ta F lo w
D a ta R e p o s ito ry
P ro v id e d In te rfa ce
R e q u ire d In te rfa ce
Figure 8. Components of the supporting software architecture on one vehicle.
text2 . The context of an organization member is kept up to date by the context manager and the organization mediator roles. Context manager roles send out periodic context messages to each other within the organization. Organization members receive all context message from within their organization. With these context messages, each member can calculate the aggregated evolution data and the number of agents for its organization. Depending on the application, specific aggregation policies have to be provided. All context items have a time stamp, indicating the last time it was updated. Organization mediator roles send context messages to both the members of their organization and the mediators of other organizations within a certain range (e.g. hopcount). Messages towards their members, contain info on the current id of the organization and possible changes in who the mediator is. Messages towards other mediators, contain info on the organization itself and are used to maintain the list of potential evolution candidates. In the example of Fig. 6 at t1 , the mediators of organizations B, C and D search for evolution candidates within organization E, mediators A and E search within a certain range of their organization. We use a multi-cast communication system, based on the organization id and the physical location to distribute the context messages.
2 The mediator of an organization can be another organization, but at the lowest level it is always an agent.
The organization controller on each vehicle uses the local context and the evolution laws, to evolve the organizations3 . The evolution laws are executed locally, meaning, there is no direct negotiation between different controllers to decide what to do4 . The execution of a law is first reflected locally in changes of the local context, and subsequently in context messages that are sent out. The eventual structure of the organization emerges from the context messages received by other organization members. The mediator of an organization is responsible for reporting the changes to its lower-level organization members. Two examples, a split and a merge, are now explained in detail for the traffic monitoring case. The merge and split law are applied to the example that was given in Fig. 6, in which organization E is split up and organizations A and B are merged together. Splitting At t1 (Fig. 6), the traffic state of organization B is bound flow and the traffic state of organizations C, D and E is congestion. As shown in Fig. 9, this is reflected in the context of organization B, which is a member of organization E. The traffic state of the member (organization B/bound flow) is different from the traffic state of its organization (organization E/congestion). When the organization controller of mediator B applies the split law to the context, the conditions are satisfied and the split is executed. As a result the controller removes part of the context (the context of organization B as member of organization E, shown in Fig. 9) and organization B no longer sends or receives context messages from the members of organization E. The result is shown at t2 , organization B is no longer part of organization E. 3 Currently the laws are evaluated sequentially in random order on all evolution candidates. The creation law ensures an agent is always in an organization. 4 Evolution laws are defined to avoid or correct from inconsistent states, caused by the concurrent execution of certain laws. For example, in absence of a mediator, a new mediator is elected, as defined by the role law, or when too many members are playing the same role, the stop condition of that role defines which member has to stop.
m e d ia to r A
m e rg e
O rg A
K e y Election C a r Mediator
O rg a n iz a tio n
co n te xt m e d ia to r B M e m b e r: ...
After the split, however, organization B is also no longer the m e d ia toof r A organization E. As a result, the m e d iamembers to r B mediator of organization E no longer receive context messages from their mediator. This is reflected in the context of these members, which keeps track of the roles played within the organization (see Fig. 4). Context info on the mediator role will no longer be updated, indicated by its timestamp. When the role law is applied to the context by the organization controllers of mediators C and D, they notice the absence of the mediator role for organization E. The new mediator is chosen based on the id of the remaining members (e.g. the largest id). Again this law, is executed locally. The start and stop condition of the mediator role state whether an individual member should play the role of mediator depending on its own id, the id’s of the other members, and whether there already is a mediator in the organization. Each involved organization controller will concurrently evaluate the start and stop conditions. In the example, organization D has the largest id and becomes the new mediator of organization E, as shown at t2 .
O g ra n iz a tio n : - ID = o rg B - le ve l = 1 - tra ffic S ta te = b o u n d flo w - lo ca tio n = (x _ B , y_ B ) - n b O fA g e n ts = 2 - m e d ia to r = m e d ia to rB ...
E vo lu tio n C a n d id a te s: - ID = o rg A - le ve l = 1 - tra ffic S ta te = b o u n d flo w - lo ca tio n = (x_ A , y _ A ) - n b O fA g e n ts = 3 - m e d ia to r = m e d ia to rA ...
c o n teof xt o the rg a n izcontext a tio n B Figure 10. Extract of mediator MBe mat b etr: . O rg a n iz a tio n : E vo lu tio n 2 - ID = o rg B - ID = o rg E C a n d id a te s: - le ve l = 1 - le ve l = 2 ... - tra ffic S ta te = b o u n d flo w - tra ffic S ta te = c o n g e s tio n ... ..y O rg a n iza tio n H ie ra.rch D a ta A g g re g a tio n le ve l 3 le v e l 1 le v e l 2
le ve l 1 le v e l 2
le v e l 3
Key
Car
O rg a n iza tio n
A g g re g a tio n D a ta
Figure 11. An example of an hierarchical organization, used for data aggregation.
Merging Figure 10 shows an extract of the context of mediator B at t2 (the context of mediator A is similar). In this context, organization A is an evolution candidate for organization B. This is used by the organization controller of mediator B, which evaluates the merge law for organization A as candidate. Organization A has the same level as organization B, the same traffic state and is within range of organization B. The merge law can thus be executed if the initiative condition is satisfied. Because organization B has less agents than organization A, the initiative condition is satisfied for organization B, but not for organization A. Therefore, the organization controller of mediator B initiates the merge and a concurrent merge of the controller of mediator A is avoided. To execute the merge, the context of mediator B is adapted by the controller, stating a new organization id, organization A, and a new mediator, mediator A. This context change is propagated to the lower organization members, through context messages sent out by mediator B. The lower organization members update their context and start sending context messages to mediator A and the other members of organization A. Soon, the new organization structure emerges in the context of all members of organization A, as shown at t3 .
5
Data Aggregation
Organizations can be used as units of data aggregation, in which agents can perform more specific aggregation tasks.
Organizations increase the granularity of data and the scalability of data aggregation. An example is shown in Fig. 11. At the lowest-level (level 1), organizations consist of nearby vehicles. In these organizations, individual traffic data (e.g. traffic state) is aggregated into traffic data for the whole group of vehicles. At higher-levels organizations can be used to further increase the granularity of the data (level 2), or they can represent specific aggregation interests, such as all traffic data for a certain region (level 3). At each level of the organization, there can be a number of distribution roles. These roles are responsible for distributing the aggregated traffic data to interested clients, such as traffic light controllers, driver assistance systems or emergency services.
6
Prototype and Evaluation
As an initial validation, a prototype of the software architecture was built and applied to decentralized traffic monitoring. The prototype currently supports a two-level organization structure. The evaluation focuses on the validation of the hierarchical organization concepts, whether the concepts work, and its bandwidth usage for different traffic scenarios. Evaluation of the quality of the traffic monitoring itself, is currently outside the scope of the evaluation. In the prototype, the host infrastructure and wireless network are replaced by a traffic and communication network simulator. This simulator simulates a wireless network to which the vehicles are connected and the sensor data generated by
Figure 12. A screenshot of the prototype, showing three second-level organizations in three different traffic states.
individual vehicles. The traffic simulation is based on an existing traffic simulator5 .
Figure 13. The average amount of messages to be processed per vehicle agent in function of the number of vehicles on the highway.
Evaluations In the evaluations the prototype was used on a simulated two-lane highway of 1000 meters, shown in Fig. 12. There are two types of vehicles, cars with a free flow speed of 120 km/h and trucks with a free flow speed of 90 km/h. Communication between vehicles is limited to 150 meters. Each data point in the experiments, represents the average of 600 individual measurements, together with a 95 percentage confidence interval. In a first experiment, the range of the first-level organizations is 150 meters, while the number of vehicles on the highway varies. The range of an organization defines its maximum size. Figure 13 shows the average amount of messages to be processed per vehicle agent as a function of the number of vehicles on the highway. Apart from the total number of messages, the number of messages related to context are also shown. These messages are split up in messages related to individual vehicle context, first-level organization context, and second-level organization context. A linear relationship can be observed between the amount of messages to be processed and the number of vehicles on the highway. In a second experiment, the total number of vehicles on the highway is kept at 80, while changing the range of the first-level organizations. Figure 14 shows the average amount of messages to be processed per vehicle agent in function of the range of first-level organizations. As the range of the first-level organizations increases, the number of vehicle agents per first-level organization also increases. This is reflected in an increase in the number of messages related to vehicle agent context. The amount of messages related to first-level organizations decreases, be5 M.
Treiber, http://www.traffic-simulation.de
cause as their size increases, the number of first-level organizations decreases. This also results in a decrease of firstlevel organizations in second-level organizations, which is reflected in a decrease of messages related to second-level organizations. The test results show that different levels of hierarchical organizations are created, as defined by the evolutions laws, and indicate that the system scales well with respect to bandwidth usage for an increasing number of vehicles on the highway and a wide range of distances of first-level organizations.
7
Related Work
This section first discusses related work on inter-vehicle communication and its use in traffic applications. We then contrast our work with the more traditional traffic monitoring approaches. Next we discuss organizations in MultiAgent systems, and finally we discuss the use of organizational concepts in mobile settings. Inter-Vehicle Communication Inter-vehicle communication and car networks are an important component of intelligent transportation systems and an active research domain [17]. Car networks are typically conceived as vehicular ad hoc networks [25]. Specialized routing protocols are used to avoid flooding in the dynamic network. [16], for example, describes a multi-hop broadcast protocol for inter-vehicle communication in urban areas. But also in the area of wireless sensor networks, many routing protocols have been proposed for a mobile setting [2].
interest in the traffic monitoring research community for multi-sensor fusion [1]. In multi-sensor fusion, data from possibly unsynchronized sensors and delayed observations is aggregated into data of higher quality and reliability. In contrast to approaches based on inter-vehicle communication, these approaches assume a static road infrastructure, which is often more expensive to maintain and will more likely lead to a central bottleneck. Organizations in Multi-Agent Systems
Figure 14. The average amount of messages to be processed per vehicle agent in function of the range of first-level organizations.
There are even a number of hierarchical protocols, which aim at clustering sensor nodes and aggregating data to reduce communication and save energy [11, 18]. These clustering methods, however, are mostly based specific sensor related data such as the remaining battery power or signal strength. The focus of our work, is not on specific communication or routing protocols but on using a mobile communication infrastructures to support higher-level coordination structures, such as hierarchical organizations. Typical applications of inter-vehicle communication include traffic safety applications and local traffic monitoring. A number of international projects, such as Cartalk [21] and Fleetnet [7], work on using inter-vehicle communication for traffic safety application. A lot of research has been done on using inter-vehicle communication to enhance the local safety and comfort of vehicles, through collision avoidance systems and early obstacle warning systems [24, 19]. Another approach is the use of peer-to-peer networks for intervehicle-communication. Works like [4] use a peer-to-peer approach in car networks for traffic safety application such as collision avoidance. In contrast to our work, these approaches typically focus on local traffic situations within a limited area, for example nearby cars at intersections or areas around an obstacle. By using hierarchical concepts, our approach tries to enhance the scalability of the data aggregation and distribution.
Roles and organizations are generally acknowledged as valuable abstractions to build multi-agent systems [13, 9]. An interesting overview of different types of organizations in agent-based systems is given in [12]. A particular line of related research are computational institutions [8, 3]. Using laws and norms, a middleware structure defines the currently permitted actions of agents. A number of approaches exist to support organizational evolution. In AGRE [6] (Agent Group Role Environment), groups are grouped together into worlds, which offer primitives for agents to join groups and play roles. Agents are responsible to decide which group to join or leave, and which role to play. This differs from our approach in which the dynamic evolution of organizations is actively managed and driven by the coordination infrastructure instead of the agents themselves. AGRE also offers no explicit support to model evolutional changes at the inter-organization level. TuCSoN [20] offers programmable tuplespaces, encapsulating coordination rules between roles. It supports the description and enacting of organizational models. Organizational settings can be inspected and changed by agents, by reading and modifying the tuple contents. This allows agents, for example, to add or delete roles from the organization. Reorganizations on the inter-organizational level are not explicitly supported. [5] explores how and why organizations change and how reorganization can be done dynamically. A distinction is made between emergent organizations and designed social structures. Reorganization is inherent in emergent societies where little intelligence and communication is required, while in designed social structures, dynamic change implies the need for highly intelligent and communicative agents (at least some of them) that can reason about and negotiate change. In our work, we show how a coordination infrastructure enables to separate the management of organization dynamics for the functionality associated with the roles played in the organization, spreading the complexity over the coordination infrastructure and the agents.
Traditional Traffic Monitoring Traffic monitoring is an extensively studied field of research. Traditional approaches typically consist of visionbased traffic surveillance [14]. There is also an increasing
Organizations in Mobile Applications [4] describes a communication system for traffic safety systems. Nearby vehicles are grouped in peer spaces which
represent vehicles interested in the same local safety issues. Peer spaces can be created based on the proximity of vehicles or based on fixed points, such as intersections. [15] defines proximity groups, which stresses the importance of explicit support for local awareness in mobile applications. Proximity groups take both location and functional aspects into account, which is also possible with our organization concepts. Entities join proximity groups based on their location and their functional interests. SOTIS [23], which is part of the FleetNet project [7], proposes a system in which vehicles monitor local traffic data and distribute this data to other nearby vehicles. In contrast to our approach, the data distribution of individual vehicles relies on the notion of fixed road segments. Vehicles driving in the same segment send each other periodic reports containing local context data, which are used for local traffic analysis. The analysis is broadcasted along the highway network to inform other vehicles of traffic jams. In contrast to our work, approaches supporting organization concepts in mobile applications, typically focus on local organizations and short ranged safety information. We offer support for both local and larger organizations by using the notion of hierarchical organizations.
scales well with respect to bandwidth usage. The amount of messages to be processed by individual agents can be minimized by choosing an optimal size for the low-level organizations.
8
Acknowledgement
Conclusions and Future Work
In this paper we presented a number of organization abstractions and a supporting software architecture, based on the idea of hierarchical organizations. These organizations can be used as units of data aggregation. At different organization levels, the individual data of organization members can be aggregated, hiding the details of individual data and improving scalability. The presented coordination infrastructure offers higher-level abstractions to application developers of hierarchical organizations. The coordination infrastructure is responsible for the evolution of the organizations. The abstractions of organization and role separate the evolution of dynamic organizations from the actual functionality provided by the agents playing roles. Separating these two concerns reduces the complexity of the agents making it easier to understand, design, and manage organizations in multi-agent systems. In most of the existing approaches, supporting organizations in multi-agent systems, agents themselves are responsible for managing the organizations and roles. Approaches supporting organization concepts specifically in mobile applications, typically focus on local organizations. We offer support for both local and larger organizations by using the notion of hierarchical organizations. We presented a prototype, supporting a two-level organization structure, and we used it in a simulated traffic environment for evaluation. Experiments show the creation of hierarchical organizations and indicate that the approach
Future Work In the current approach, several assumptions were made about the vehicles in our system and their environment. Because the communication range of individual vehicles in practice is limited, empty roads will cause a problem. This issue has not yet been studied in detail. It could be solved with a hybrid approach in which some static road infrastructure supports the mobile vehicles agents in their tasks. A related issue is the current assumption that a vehicle agent is deployed on every vehicle. Relaxing this assumption will cause similar problems, but also requires extrapolating data for vehicles with no vehicle agent. Our current prototype only supports two levels of organizations. This could be increased and optimized, further enhancing the scalability of our approach. Formalization of the organization model and evolution laws can be interesting to optimize the clustering behavior of the agents and organizations.
This research is partially funded by the Interuniversity Attraction Poles Programme Belgian State, Belgian Science Policy, and by the Research Fund K.U.Leuven. Danny Weyns is supported by the Foundation for Scientific Research in Flanders (FWO-Vlaanderen).
References [1] Iyad Abuhadrous, Fawzi Nashashibi, and Claude Laurgeau. Multi-Sensor Fusion (GPS, IMU, Odometers) for Precise Land Vehicle Localisation Using RTMAPS. In 11th International Conference on Advanced Robotics (ICAR 2003), 2003. [2] K. Akkaya and M. Younis. A survey on routing protocols for wireless sensor networks. Ad Hoc Networks, 3(3):325–349, 2005. [3] C. Castelfranchi, F. Dignum, C. Jonker, and J. Treur. Deliberative normative agents: Principles and architecture. In Agent Theories, Architectures, and Languages, pages 364–378, 1999. [4] L. Chisalita and N. Shahmehri. A peer-to-peer approach to vehicular communication for the support of traffic safety applications. Intelligent Transportation Systems, 2002. Proceedings. The IEEE 5th International Conference on, pages 336–341, 2002.
[5] V. Dignum, F. Dignum, and L. Sonenberg. Towards Dynamic Reorganization of Agent Societies. Proceedings of Workshop on Coordination in Emergent Agent Societies at ECAI, 2004. [6] J. Ferber, F. Michel, and J. Baez. AGRE: Integrating environments with organizations. In D. Weyns, V. Parunak, and F. Michel, editors, First International Workshop on Environments for Multi-Agent Systems, volume 3374 of Lecture Notes in Computer Science, New York, NY, USA, 2005. Springer-Verlag. [7] W. Franz, R. Eberhardt, and T. Luckenbach. FleetNetInternet on the Road. Proc. 8th World Congress on Intelligent Transport Systems, 2001. http://www. fleetnet.de. [8] A. Garca-Camino, P. Noriega, and J .RodrguezAguilar. Implementing norms in electronic institutions. In AAMAS ’05: Proceedings of the fourth international joint conference on Autonomous agents and multiagent systems, New York, NY, USA, 2005. ACM Press. [9] L. Gasser. Organizations in multi-agent systems. In 10th European Workshop on Modeling Autonomous Agents in a Multi-Agent World (MAAMAW-2001), 2001. [10] R. Haesevoets, B. Van Eylen, D. Weyns, A. Helleboogh, T. Holvoet, and W. Joosen. Managing Agent Interactions with Context-Driven Dynamic Organizations. In D. Weyns, S. Brueckner, and Y. Demazeau, editors, Engineering Environment-Mediated Multiagent Systems, Lecture Notes in Computer Science. Springer-Verlag, 2007. [11] WR Heinzelman, A. Chandrakasan, H. Balakrishnan, and C. MIT. Energy-efficient communication protocol for wireless microsensor networks. System Sciences, 2000. Proceedings of the 33rd Annual Hawaii International Conference on, page 10, 2000. [12] B. Horling and V. Lesser. A survey of multi-agent organizational paradigms. Knowledge Engineering Review, 19(4):281–316, 2004.
mobile participants. Proceedings of the 1st ACM Workshop on Principles of Mobile Computing (POMC 2001), pages 75–82, 2001. ¨ uner, and U. ¨ uner. ¨ Ozg¨ [16] G. Korkmaz, E. Ekici, F. Ozg¨ Urban multi-hop broadcast protocol for inter-vehicle communication systems. Proceedings of the 1st ACM international workshop on Vehicular ad hoc networks, pages 76–85, 2004. [17] J. Luo and J.P. Hubaux. A Survey of Inter-Vehicle Communication. EPFL, Lausanne, Switzerland, Tech. Rep, 2004. [18] A. Manjeshwar and DP Agrawal. TEEN: a routing protocol for enhanced efficiency in wireless sensor networks. Parallel and Distributed Processing Symposium., Proceedings 15th International, pages 2009– 2015, 2001. [19] T. Nadeem, S. Dashtinezhad, C. Liao, and L. Iftode. TrafficView: traffic data dissemination using car-tocar communication. ACM SIGMOBILE Mobile Computing and Communications Review, 8(3):6–19, 2004. [20] A. Omicini and A. Ricci. Reasoning about organisation: Shaping the infrastructure. AI* IA Notizie, 16(2):7–16, 2003. [21] D. Reichardt, M. Miglietta, L. Moretti, P. Morsink, and W. Schulz. CarTALK 2000: safe and comfortable driving based upon inter-vehicle-communication. Intelligent Vehicle Symposium, 2002. IEEE, 2, 2002. http://www.cartalk2000.net. [22] L. Wischhof, A. Ebner, and H. Rohling. Information dissemination in self-organizing intervehicle networks. Intelligent Transportation Systems, IEEE Transactions on, 6(1):90–101, 2005. [23] L. Wischoff, A. Ebner, H. Rohling, M. Lott, and R. Halfmann. SOTIS-a self-organizing traffic information system. Vehicular Technology Conference, 2003. VTC 2003-Spring. The 57th IEEE Semiannual, 4, 2003.
[13] N. Jennings. On agent-based software engineering. Artificial Intelligence, 177(2):277–296, 2000.
[24] X. Yang, J. Liu, F. Zhao, and N.H. Vaidya. A Vehicleto-Vehicle Communication Protocol for Cooperative Collision Warning. Emergency, 3(6):N8.
[14] Y.K. Jung, K.W. Lee, and Y.S. Ho. Content-based event retrieval using semantic scene interpretation for automated traffic surveillance. ITS, 2(3):151–163, September 2001.
[25] S. Yousefi, MS Mousavi, and M. Fathy. Vehicular Ad Hoc Networks (VANETs): Challenges and Perspectives. ITS Telecommunications Proceedings, 2006 6th International Conference on, pages 761–766, 2006.
[15] M. Killijian, R. Cunningham, R. Meier, L. Mazare, and V. Cahill. Towards group communication for
