A Self-Organizing Architecture for Traffic Management - CiteSeerX

A Self-Organizing Architecture for Traffic Management R. Z. Wenkstern, T. Steel, G. Leask MAVs Lab Department of Computer Science University of Texas at Dallas Richardson, TX, USA {rmili, steel, gml013000}@utdallas.edu

Abstract—In this paper we discuss the use of self-organizing architectures for traffic management systems. We introduce Soteria, a multi-layered, integrated, super-infrastructure for traffic safety enhancement and congestion reduction. We highlight Soteria’s use of micro- and macro-level models and its hybrid top-down/bottom-up strategy for traffic management. We then present a generic architecture that can be used to develop simulation systems for real world self-organizing systems. Lastly, we describe how this generic architecture can be instantiated to create the architecture of Matisse, a tailor made distributed simulation system for Soteria. Keywords-multi-agent systems; traffic management; simulation;

I. I NTRODUCTION Traffic congestion is a major problem in most large cities throughout the world and several strategies have been defined to address this problem [1]. Transportation technologies known as Intelligent Transportation Systems (ITS) have been considered as possible solutions. ITS are defined as ”the application of advanced sensor, computer, electronics, and communication technologies and management strategies in an integrated manner to increase the safety and efficiency of the surface transportation system” [2]. In this paper we discuss Soteria, an ITS based multilayered, integrated, super-infrastructure for safety enhancement and congestion reduction. Soteria’s architecture was recently developed by a team of researchers at the University of Texas at Dallas [3]. At this stage, the architecture has been baselined, and several components are in the process of being implemented. Soteria is based on the following premises a) the traffic model consists of micro- and macrolevel components; b) traffic is a bottom-up phenomenon that is the result of individual decisions at the micro-level (vehicles, traffic control devices, etc); c) traffic management is a top-down activity that is the result of decisions taken at the macro-level. In this paper, we also discuss the architecture of Matisse (Multi-Agent based TraffIc Safety Simulation systEm), a tailor-made large scale distributed multi-agent based simulation system designed to support Soteria. In Matisse, The MAVs Lab is supported by Rockwell Collins under grant number 5-25143

micro-level entities are modeled as software agents that continuously self-organize. The macro-level components are special types of agents called controllers that inform, monitor, and guide micro-level agents to ensure that, at some level, micro-level behaviors and interactions are consistent with the global system behavior. The rest of this paper is organized as follows: in Section II, we give an overview of Soteria. In Section III, we describe a generic architecture for simulation systems designed to model self-organizing systems. In Section IV, we discuss Matisse’s high level architecture. In Section V, we discuss a model execution using a case study, and in Section VI we describe some related works. II. C OMPONENTS OF A S ELF -O RGANIZING C YBER -P HYSICAL S YSTEM : T HE S OTERIA S UPER -I NFRASTRUCTURE Soteria is a novel, large-scale, decentralized cyberphysical infrastructure [4], [3] for improving safety and reducing congestion on roads and highways. This infrastructure aims at enforcing communication, interaction, and collaboration between all the stakeholders at the micro- and macro-levels. The proposed super-infrastructure is based upon two underlying concepts. • In order to manage the traffic environment efficiently, it is necessary to partition the physical space into smaller defined areas called cells. • Each cell is assigned a physical entity called a controller. A cell controller is responsible for 1) autonomously managing and controlling a portion of the physical environment (i.e., cell) including vehicles and traffic lights, and 2) notifying other controllers of changes that may affect their cells. As shown in Figure 1, our proposed super-infrastructure consists of three components. The purpose of the Cell Controller Infrastructure is to keep the Vehicle Infrastructure and the Traffic Flow Infrastructure up to date with respect to traffic and safety information. It consists of cell controllers, i.e., interactive devices responsible for keeping the vehicles and selected traffic devices aware of local traffic information. As such,

Figure 1.

Figure 2.

Super-infrastructure

Hierarchical Structure of the Cell Controller Infrastructure

a cell controller is required to be: 1) autonomous; 2) aware of the vehicles and the traffic devices located in its defined physical area; 3) able to communicate with the vehicles and the traffic devices; 4) able to communicate with other cell controllers to inform them of external events and their effect. In order to manage traffic information efficiently, it is necessary to organize the cell controller infrastructure as a hierarchy (see Figure 2). This approach is particularly important for congestion caused by an accident, when microlevel information is insufficient for vehicles to determine the best exit route. In this case, a cell controller (e.g., C11) will communicate with a higher level controller (e.g., C1) to obtain a broader image of the traffic situation, determine the best vehicle routing scheme, and pass the information on to its local vehicles. The Context-Aware Intelligent (CAI) Vehicle Infrastructure consists of vehicles equipped with devices that allow them to 1) monitor the driver’s behavior in order to prevent possible accidents, 2) communicate with other vehicles, and 3) interact with cell controllers to obtain traffic information and guidance in real time. The purpose of the Traffic Flow Infrastructure is to improve safety and traffic flow on roads and highways by providing information about the physical traffic infrastructure and congestion condition. This infrastructure consists of three types of stationary traffic devices: traffic lights, traffic collection devices, and relay units. Traffic lights are equipped with systems that allow them to

Figure 3.

Agent architecture

1) interact with cell controllers to obtain traffic information in real time, and 2) communicate with other traffic light controllers to improve traffic flow when necessary. They are also equipped with autonomous adaptive systems that allow them to independently determine the best course of action when unexpected events occur. Traffic collection devices are used on highways (e.g., toll units) to collect information about traffic, and communicate the information to cell controllers for further analysis (e.g., identification of a drunk driver on the highway). Relay units are used to pass on information between the various communicating entities when the physical distance is too great. III. C OMPONENTS OF A G ENERIC A RCHITECTURE FOR S IMULATING S ELF -O RGANIZING S YSTEMS Software architectures for simulating self-organizing systems, such as those used for traffic management, must accommodate bottom-up and top-down objectives, and should therefore incorporate the concepts of micro- and macro-level components. We recommend that micro-level components be modeled as agents, and macro-level components as cell controllers. We have identified several architectural patterns that can be applied to model and integrate these micro- and macro-level concerns. These patterns are discussed in the rest of this section. A. The Agent Pattern The agent pattern [5], [6] is used to design and implement autonomous entities that have individual goals, perceive and have knowledge of their environment, exhibit organizational behavior through collaboration with other agents, and influence their environment as a result of their decisions. The agent pattern establishes the general software architecture of an agent and consists of interaction modules, information module, a task module, and a planning and control module (see Figure 3). Interaction Modules. The interaction module handles an agent’s interaction with external entities and separates environment interaction from agent interaction. An agent is

able to interact with cell controllers through the environment perception module and communicates with other agents through the agent communication module. Information Module. This is partitioned into the External Information Module (EIM) and Internal Information Module (IIM). • The EIM serves as the portion of the agent’s memory that is dedicated to maintaining knowledge about entities external to the agent. It consists of the Environment Model and the Acquaintance Model. The Environment Model is maintained according to the agent’s perception of its surroundings while the Acquaintance Model is maintained according to the agent’s collaboration with other agents. • The IIM serves as the portion of the agent’s memory that is dedicated for keeping information that the agent knows about itself. This module consists of the agent’s Self Model and the Constraint Model. The Self Model maintains the essential properties of the agent while the Constraint Model maintains the agent’s physical and collaborative limitations. Task Module. This module manages the specification of atomic tasks that the agent can perform in the domain in which it is being deployed. Planning and Control Module. This serves as the brain of the agent. It uses information provided by the other agent modules to plan, execute tasks, and make decisions. B. The Cell Controller Pattern The cell controller pattern [5], [6] applies to autonomous entities that manage and store information about a dedicated region of the environment, participate in satisfying global system goals, inform local agents about changes in their surroundings, and exhibit organizational behavior through interaction with neighboring cell controllers. These characteristics reveal a strong correlation between the cell controller and the agent architectures; thus, it is clear that a cell controller can be modeled as a special type of agent, as depicted in Figure 4. Similar to the agent pattern, the cell controller pattern consists of interaction modules, information module, a task module, and the planning and control module. Interaction Modules. These modules handle asynchronous communication among cell controllers as well as synchronous communication between cell controllers and agents. Information Module. This module contains the data a controller needs to function. It is composed of the • Agent Model. This model contains minimal information about the agents within the cell’s environment region, such as identifiers and locations. • Linked Cell Model. This model maintains a list of neighboring cells whose graphs share a path with this cell’s graph. Information such as cell identifiers and

Figure 4.

• •

•

Cell controller architecture

path identifiers of all shared paths are included in this model. Graph Model. This model contains information regarding the nodes and edges contained within the cell. Self Model. This model contains information regarding the essential characteristics of the cell such as its identifier and region boundaries. Object Model. This model includes information detailing physical entities that are situated within the cell region but are not actual agents.

C. Homogeneous Agent Platform Pattern Agents of a self-organizing software system can typically be classified into types or species based on similarities in perception, behavior, knowledge, abilities, and constraints. Since agents of the same type often interact differently with other agents of their own type than with agents of another type, separating homogeneous and heterogeneous interaction at an architectural level allows greater control over intraagent collaborative behavior. Hence, software architectures for self-organizing systems should exploit this characteristic by managing agents of the same type with a single homogeneous agent platform. The homogeneous agent platform pattern is applied for each type of agent in the system and manages only that type of agent. The homogeneous agent platform pattern consists of an Agent Management System and an AgentAgent Message Transport Service. The Agent Management System is responsible for creating and managing agents of a specific type. The Agent-Agent Message Transport Service provides a dedicated communication medium between agents of the same type, allowing intra-species collaboration. The Agent-Agent Message Transport Service is exclusively limited to agents of the same type, therefore no outside communications are sent via this service. D. Cell Platform Recalling from Section III-B that cell controllers can be modeled as specialized agents, we are able to clas-

sify them as their own type and manage them with a single, specialized, homogeneous agent platform. The cell platform is similar to the agent platform except it uses a Cell Management System instead of an Agent Management System. The Cell Management System (CMS) not only creates and manages cell controllers, but organizes them into a hierarchy. The CMS dynamically assigns cell controllers to manage corresponding regions of the environment. In large environments it becomes difficult to maintain the level of integrity necessary to achieve macro-level objectives due to the increased amount of required collaboration between cell controllers. In this case, the CMS creates several parent cell controllers to coordinate the efforts of the lower-level controllers. As the environment scales, the CMS maintains a hierarchy suitable for achieving global system goals. The hierarchy, which is conceptually a tree, allows decomposition of global objectives, distributing the responsibility of achieving those objectives to cell controllers in a divideand-conquer fashion. E. Communication Between Heterogeneous Platforms A software architecture for self-organizing systems should allow communication between the various platforms to accommodate interaction and collaboration among different types of agents and cell controllers. A dedicated Message Transport Service (MTS) exists for each pair of platforms that have the need to communicate directly. Since the means of communication between platforms may be specialized, they are separated according to the platforms they service. IV. M ATISSE As mentioned in Section I, Matisse (Multi-Agent based TraffIc Safety Simulation systEm) is a ”tailor made” simulation framework1 designed to specify and execute simulation models for Soteria. More precisely, it allows the simulation of various traffic safety improvement and congestion reduction scenarios under nominal and hypothetical conditions. The rest of this section describes how the Matisse architecture implements the self-organizing architecture concepts described in Section III. A. Matisse’s Agents Matisse identifies two types of agents: Vehicle Agents and Traffic Device Agents. Both types of agents exhibit the essential characteristics of autonomy and micro-scale behavior that is best modeled using the agent pattern. Vehicle Agents. These agents, which simulate the behavior of human drivers, have individual goals (e.g. arriving at some destination in a reasonably short time), influence other agents (e.g. turn signals and changing lanes), are governed by environmental norms and constraints (e.g. speed limits and traffic signals), and may not be directly aware of global objectives. 1 The

term framework refers to a system of systems

Traffic Device Agents. These agents are aware of and influence nearby vehicles, are able to perceive and adapt to changing conditions, and collaboratively work to achieve certain objectives. Section V contains an example of this organizational cooperation. B. Matisse’s Agent Platforms The two types of agents identified by Matisse are natural candidates for the agent platform pattern. Context-Aware Intelligent Vehicle (CAI) Platform. This application of the homogeneous agent platform pattern manages mobile agents that represent vehicles. Within this simulation system, vehicle agents are created by the Vehicle Agent Management System. The CAI Vehicle Platform also provides and manages the Vehicle-Vehicle Message Transport Service which handles communication between vehicle agents. Traffic Device Platform. This homogeneous agent platform manages stationary agents that represent traffic lights and information collection devices. The Traffic Device Agent Management System creates traffic device agents within the simulation while the Device-Device Message Transport Service handles communication between traffic lights, collection devices, and other stationary traffic agents. C. Matisse’s Cell Platform The Environment Platform uses the Cell Platform described in Section III-D to create and manage cell controllers. The Environment Agent Management System creates cell controllers, assigns them to a dedicated region of the environment, and additionally maintains the cell controller hierarchy for the simulation. The Controller-Controller Message Transport Service handles communication between cell controllers. D. Matisse’s Agent-Environment System The agent platforms and cell platform described above are connected by several heterogeneous Message Transport Services which handle communication among the various types of agents. Collectively, these components make up the Matisse Agent Environment System (AES) as shown in Figure 5. The AES is responsible for creating the simulation using the components described above. E. Matisse’s High Level Architecture In order to increase the effectiveness of Matisse, several other subsystems are used to provide visualization and data analysis (see Figure 5). The Data Management System (DMS) stores and processes information collected from the AES; and the Visualization Framework receives information from the DMS to create 2D or 3D images of the simulation.

Figure 6.

Figure 5.

Matisse high level architecture

Accident scenario

VI. S URVEY This section contains a survey of related works.

V. C ASE S TUDY - M ODEL E XECUTION In this section, we consider the accident scenario depicted in Figure 6. An accident (shown as a red ’X’) has occurred in cell 12, and the vehicle onboard Collision Avoidance System informs cell controller C12 of the accident. Under this scenario, C12 immediately performs the following steps: 1) Informs all the vehicles in the cell of the accident. The C12 cell controller achieves this by broadcasting an accident notification over the cell controller-to-vehicle MTS to all vehicle agents currently stored in the cell’s vehicle agent model. 2) Informs the traffic light controllers of the accident. The C12 cell controller broadcasts an accident notification over the cell controller-to-traffic device MTS to all traffic light controller agents currently stored in the cell’s traffic light controller agent model. 3) Informs adjacent cell controllers of the accident. The C12 cell controller sends accident notifications over the cell controller-to-cell controller MTS to neighboring cell stored in the linked cell model. 4) Communicates with higher level controllers to obtain broader traffic information. This information is used to determine general directions as to the best exit routes for vehicles (to avoid creating congestion on secondary streets, and maintain the global system stability). All vehicles in the cell make use of the broader traffic information and directions to avoid the accident. Traffic Lights communicate with other traffic lights to optimize traffic flow (e.g., approaching cars are not allowed to enter the cell) and may decide to turn green to allow traffic to flow. The adjacent cell controllers, upon receipt of the accident notification, act in a similar manner as C12 to notify vehicles, traffic light controllers, and adjacent cell controllers of the accident.

A. Cyber-Physical Infrastructures There have been several ITS initiatives and large-scale projects to address the congestion problem. MIT Intelligent Transportation Systems Program has developed a real-time computer system, DynaMIT [7], to effectively support Advanced Traveler Information System and Advanced Traffic Management Systems. DynaMIT is able to estimate network conditions and generate traveler information to guide drivers. DynaSMART-X [8] offers the same capabilities as well as interactions with multiple sources of real-time information (e.g., vehicle probes, roadside sensors). Although very successful, neither DynaMIT nor DynaSMART-X are able to handle non-recurrent congestion, i.e., congestion due to an unpredicted accident. Both systems approach traffic management in a top-down fashion although traffic information is collected bottom-up. Research and Innovative Technology Administration (RITA) has several major initiatives, including the Cooperative Intersection Collision Avoidance Systems (CICAS), the Integrated Corridor Management Systems (ICMS), and IntelliDrive [9]. CICAS includes autonomous vehicles and cooperative communication systems aimed at intersection collision problem. ICMS targets underused parallel routes (train, metro, bus) for corridor management rather than intra-network optimization. IntelliDrive combines advanced wireless communications, on-board computer processing, advanced vehicle sensors, and GPS to provide the capability for vehicles to identify threats. Each of these systems addresses a particular aspect of the traffic management problem, and follow a bottom-up approach. The unique features of Soteria are its integrated, multilayered structure as well as its hybrid top-down/bottom-up strategy for traffic management. B. Traffic Simulation Systems Two models have emerged to simulate traffic scenarios. Macroscopic models [10], [11], [12], [13], [14] use a top-

down approach, focusing on the overall behavior of the system. The systems are seeded with initial conditions where traffic entities follow predefined behavioral models. In order to simulate traffic congestion, these models use metrics such as: average speed, traffic density, probability distributions, traffic light frequency, and ramp-merge messages. By varying the models, the overall behavior can be analyzed and optimal traffic control can be implemented. Microscopic models [15], [16], [17], [18], [19] use a bottom-up approach where every entity in the simulation is modeled as an agent and given a set of behavioral characteristics. This includes vehicles, roads, traffic signals, and signs which all interact. Agents control their own destiny thereby giving a realistic behavior to the simulation. Our research enhances the conventional traffic simulation as we present the design of a hybrid system that implements both a macroscopic and microscopic approach. From a macroscopic view point, the cell controllers define initial conditions, monitor and guide the global system behavior in a decentralized fashion. At a microscopic level, each autonomous agent influences and adapts to changes while interacting, cooperating, and coordinating actions with other agents. This results in a simulation where micro-level agent behaviors are connected with the macro-level system behavior. VII. C ONCLUSION In this paper we discussed Soteria, a multi-layered, integrated, super-infrastructure for safety enhancement and congestion reduction. Soteria’s unique features are its use of micro- and macro-level models, and its hybrid topdown/bottom-up strategy for traffic management. We presented a generic architecture that can be used to develop simulation systems for real world self-organizing systems, and finally described how this generic architecture can be instantiated to create the architecture of Matisse, a tailor made distributed simulation system for Soteria. Matisse is in its early stage of development. Distributed versions of AES components have been implemented with basic functionality, including all message transport services. Working prototypes for the distributed Visualization Framework and Data Management Systems have been developed and integrated with the AES. Future efforts will include development of a distributed cell controller hierarchy, enhancement of the Visualization Framework, and further definition of agent behavior. R EFERENCES [1] “The congestion problem,” US Department of Transportation, accessed August 2009. [Online]. Available: http://www.ops.fhwa.dot.gov/publications/bnprimer/02congestion prob.htm [2] M. Meyer, “A tool box for alleviating traffic congestion and enhamcing mobility,” Institure of Transportation Engineers, US Department of Transportation, Federal Highway Administration, Technical Report, 1997.

[3] P. Boyraz, O. Daescu, A. Fumagalli, J. Hansen, K. Trumper, and R. Wenkstern, “Soteria: An integrated macro-micro transportation super-infrastructure system for management and safety,” Erik Jonsson School of Engineering and Computer Science, University of Texas at Dallas, Dallas, USA, Technical Report, 2009. [4] R. Z. Wenkstern, T. Steel, O. Daescu, J. Hansen, and P. Boyraz, “MATISSE: A large scale multi-agent system for simulating traffic safety scenarios,” in Proceedings of IEEE 4th Biennial Workshop on DSP for In-Vehicle Systems and Safety, Dallas, USA, June 25-27 2009. [5] R. Z. Mili, R. Steiner, and E. Oladimeji, “DIVAs: Illustrating an abstract architecture for agent-environment simulation systems,” Multiagent and Grid Systems, Special Issue on Agentoriented Software Development Methodologies, vol. 2, no. 4, pp. 505–525, 2006. [6] R. Z. Mili, E. Oladimeji, and R. Steiner, “Architecture of the DIVAs simulation system,” in Proceedings of Agent-Directed Simulation Symposium ADS06, Huntsville, Alabama, April 2006. [7] “Dynamit,” MIT Intelligent Transportation Systems Program. [Online]. Available: http://mit.edu/its/dynamit.html [8] “Dynasmart-x,” University of Texas accessed August 2009. [Online]. http://mctrans.ce.ufl.edu/featured/dynasmart/

at

Austin, Available:

[9] “Rita,” Research and Inovative Technology Administration, Department of Transportation, accessed August 2009. [Online]. Available: http://www.rita.dot.gov/ [10] H. Lieu, A. J. Santiago, and A. Kanaan, “Corflo: an integrated traffic simulation system for corridors,” in Proceedings of of the Engineering Foundation Conference, Palm Coast, Florida, April 1-6 1991. [11] M. Broucke and P. Varaiya, “A theory of traffic flow in automated highway systems,” Transportation Research, Part C: Emerging Technologies, vol. 4, pp. 181–210, 1995. [12] D. Helbin, A. Hennecke, V. Shvetsov, and M. Treiber, “Microand macro simulation of freeway traffic,” Mathematical and Computer Modelling, vol. 35, no. 6, pp. 517–547, 2002. [13] W. Jin and H. M. Zhang, “The information and structure of vehicle clusters in the payne-whitham traffic flow model,” Transportation Research, Part B: Methodological, vol. 37, pp. 207–223, 2003. [14] “Contram: Continuous traffic assignment model,” TRL and Mott MacDonald, accessed August 2009. [Online]. Available: http://www.contram.com/ [15] R. Rasche, R. Naumann, J. Tacken, and C. Tahedl, “Validation and simulation of decentralized intersection collision avoidance algorithm,” in Proceedings of IEEE Conference on Intelligent Transportation Systems (ITSC97), Boston, Massachusetts, 1997.

[16] K. Erol, R. Levy, and J. Wentworth, “Application of agent technology to traffic simulation,” Department of Transportation, Federal Highway Administration, USA, Technical Report, 1998. [17] D. A. Roozemond, “Using intelligent agents for urban traffic control systems,” in Proceedings of International Conference on Artificial Intelligence in Transportation Systems and Science, 1999.

[18] K. Dresner and P. Stone, “Multi-agent traffic management: An improved intersection control mechanism,” in Proceedings of the Fourth International Joint Conference on Autonomous Agents and MultiAgent Systems, Utrecht, The Netherland, July 2005. [19] A. L. C. Bazzan, “A distributed approach for coordination of traffic signal agents,” Autonomous Agents and Multi-Agent Systems, vol. 10, no. 2, pp. 131–164, March 2005.