ISSN 1055- 1425
May 2010
This work was performed as part of the California PATH Program of the
University of California, in cooperation with the State of California Business,
Transportation, and Housing Agency, Department of Transportation, and the
United States Department of Transportation, Federal Highway Administration.
The contents of this report reflect the views of the authors who are responsible
for the facts and the accuracy of the data presented herein. The contents do not
necessarily reflect the official views or policies of the State of California. This
report does not constitute a standard, specification, or regulation.
Final Report for Task Order 6324
CALIFORNIA PATH PROGRAM
INSTITUTE OF TRANSPORTATION STUDIES
UNIVERSITY OF CALIFORNIA, BERKELEY
CARTESIUS and CTNET - Integration
and Field Operational Test
UCB- ITS- PRR- 2010- 28
California PATH Research Report
Michael G. McNally, Craig R. Rindt
CALIFORNIA PARTNERS FOR ADVANCED TRANSIT AND HIGHWAYS
CARTESIUS and CTNET -
Integration and Field Operational Test
Final Report for PATH Task Order 6324
Michael G. McNally ( mmcnally@ uci. edu)
Craig R. Rindt ( crindt@ uci. edu)
Institute of Transportation Studies
University of California, Irvine
Irvine, CA 92697- 3600
STATE OF CALIFORNIA DEPARTMENT OF TRANSPORTATION
TECHNICAL REPORT DOCUMENTATION PAGE
TR0003 ( REV. 10/ 98)
1. REPORT NUMBER
CA10- 6324
2. GOVERNMENT ASSOCIATION NUMBER
3. RECIPIENT’S CATALOG NUMBER
5. REPORT DATE
March 2010
4. TITLE AND SUBTITLE
CARTESIUS and CTNET -
Integration and Field Operational Test
6. PERFORMING ORGANIZATION CODE
7. AUTHOR( S)
Michael G. McNally ( mmcnally@ uci. edu)
Craig R. Rindt ( crindt@ uci. edu)
8. PERFORMING ORGANIZATION REPORT NO.
UCB- ITS- PRR- 2010- 28
10. WORK UNIT NUMBER
193
9. PERFORMING ORGANIZATION NAME AND ADDRESS
Institute of Transportation Studies
University of California, Irvine
Irvine, CA 92697- 3600
11. CONTRACT OR GRANT NUMBER
65A0208
13. TYPE OF REPORT AND PERIOD COVERED
Final Report
June 2005- September 2009
12. SPONSORING AGENCY AND ADDRESS
California Department of Transportation
Division of Research and Innovation, MS- 83
1227 O Street; Sacramento CA 95814
14. SPONSORING AGENCY CODE
15. SUPPLEMENTAL NOTES
None
16. ABSTRACT
This report describes the conclusion of PATH Task Order 6324: CARTESIUS and CTNET--- Field
Operational Test. We describe the results of the multi- year project focused on integrating Caltrans
primary signal management system, CTNET, with a major product from the Caltrans ATMS Testbed:
the Coordinated Adaptive Real- Time Expert System for Incident management in Urban Systems, or
more simply, CARTESIUS. The major products of this research include numerous software products for
integrating CTNET with field devices, simulation software, with other traffic management systems in
general, and with a streamlined re- implementation of the CARTESIUS incident management system. The
report details the development of the various software components necessary for external systems with
CTNET using both the AB3418e protocol and Tent’s own custom socket- based communications
protocol for communications between CTNET clients and the CTNET Commerce. The use of these
software components to link CTNET to various systems is described, including a non- standard field
infrastructure, the Paramics microsimulation, and the CARTESIUS incident management system. The
resulting system is used to evaluate a more deployable re- implementation of CARTESIUS connected to
the simulation via CTNET. The results of the evaluation demonstrate that the reimplementation
produces performance similar to the original system for a restricted evaluation subset. Further work is
necessary to lead to complete deployment, particularly defining requirements that are compatible with
existing TMC processes. Nonetheless, the work described in this project represents a step toward a
deployable next generation architecture for multi- jurisdictional incident management using existing
Caltrans assets.
17. KEY WORDS
Cartesius, CTNET, traffic control, incident
management
18. DISTRIBUTION STATEMENT
No restrictions. This document is available to the
public through the National Technical Information
Service, Springfield, VA 22161
19. SECURITY CLASSIFICATION ( of this report)
Unclassified
20. NUMBER OF PAGES
90
21. PRICE
N/ A
Reproduction of completed page authorized
DISCLAIMER STATEMENT
This document is disseminated in the interest of information exchange. The contents of this
report reflect the views of the authors who are responsible for the facts and accuracy of the data
presented herein. The contents do not necessarily reflect the official views or policies of the State
of California or the Federal Highway Administration. This publication does not constitute a
standard, specification or regulation. This report does not constitute an endorsement by the
Department of any product described herein.
For individuals with sensory disabilities, this document is available in Braille, large print,
audiocassette, or compact disk. To obtain a copy of this document in one of these alternate
formats, please contact: the Division of Research and Innovation, MS- 83, California Department
of Transportation, P. O. Box 942873, Sacramento, CA 94273- 0001.
Abstract
This report describes the conclusion of PATH Task Order 6324: CARTESIUS and CTNET--- Field
Operational Test. We describe the results of the multi- year project focused on integrating
Caltrans primary signal management system, CTNET, with a major product from the Caltrans
ATMS Testbed: the Coordinated Adaptive Real- Time Expert System for Incident management
in Urban Systems, or more simply, CARTESIUS . The major products of this research include
numerous software products for integrating CTNET with field devices, simulation software, with
other traffic management systems in general, and with a streamlined re- implementation of the
CARTESIUS incident management system. The report details the development of the various
software components necessary for external systems with CTNET using both the AB3418e
protocol and CTNET’s own custom socket- based communications protocol for communications
between CTNET clients and the CTNET CommServer. The use of these software components to
link CTNET to various systems is described, including a non- standard field infrastructure, the
Paramics microsimulation, and the CARTESIUS incident management system. The resulting
system is used to evaluate a more deployable re- implementation of CARTESIUS connected to the
simulation via CTNET. The results of the evaluation demonstrate that the reimplementation
produces performance similar to the original system for a restricted evaluation subset. Further
work is necessary to lead to complete deployment, particularly defining requirements that are
compatible with existing TMC processes. Nonetheless, the work described in this project
represents a step toward a deployable next generation architecture for multi- jurisdictional
incident management using existing Caltrans assets.
Keywords: CARTESIUS, CTNET, traffic control, incident management
i
Executive Summary
In 2005, Caltrans released an RFP seeking to integrate two of its assets--- one functional and in
wide deployment, and one moving through its research program as a possible solution for
corridor management. In CTNET, Caltrans has a functional traffic signal management
subsystem that can connect engineers’ desktop computers to operational traffic signal controllers
using an interface that mimics that offered at the cabinet. This capability for remote control of
intersections simplifies the engineer’s tasks and offers an excellent means for tracking the status
of Caltrans traffic signal controllers. In funding the development of CARTESIUS via the ATMS
Testbed and PATH programs, Caltrans has previously developed advanced concepts for dealing
with the complex issues of multi- jurisdictional incident management using a set of software
agents that use distributed problem solving approaches for sharing local information and action
plans across jurisdictional boundaries to produce globally superior response plans. The RFP
proposed integrating the two systems and running a field- operational test of the combined system
to establish its performance and determine its feasibility for broader deployment.
Task Order 6324 is the third of three research projects focused on this effort ( the prior two being
TO- 5313 and TO- 5324). The results of the series of projects have been mixed. On the positive
side we established a clear understanding of the relative roles of CTNET and CARTESIUS.
CTNET is a robust traffic signal management system with a well- defined functional role that fits
into the broader National ITS Architecture. It is a standalone system with well defined interfaces
that use ( and indeed pioneer) accepted standards for center to field element communications. Its
user interface, while somewhat dated, still offers useful functionality to engineers charged with
managing remote traffic signals. CARTESIUS’ functional role is more varied, but its primary
contributions can be distilled into ( a) a unique approach for representing transportation system
disruptions abstractly that ( b) can be shared across jurisdictional boundaries and ( c) used into
local optimization algorithms that ( d) produce collections of control actions whose impacts can
( e) also be shared across jurisdictions and ( f) used to find local responses that are compatible
with global constraints.
ii
The project has led to the successful development of two custom libraries ( Jab3418e and
JCTNET) that allow external programs to connect to CTNET and act as authenticated clients in
order to obtain system state information and to send new timing plans to signals in the field.
These libraries were used to develop a simulation platform that can simulate CTNET Compatible
field controllers interacting with the Paramics microsimulation. More generally, the libraries
open CTNET for further integration in any traffic management system that needs read/ write
control to traffic signals. These libraries were used to connect CTNET and a simplified re-implementation
of the CARTESIUS system that focuses on generating control response
recommendations that can eventually be integrated into Caltrans TMC processes. The
CARTESIUS re- implementation satisfies a subset of the requirements defined in the final report for
PATH TO 5324. In particular, the multi- agent features were deferred for later development due
to challenges related to expanding the original algorithm beyond two agents. Additionally, the
development of a graphical user interface was deferred because it became clear in this and in
related research that interfaces for TMC operations must be highly specialized to fit into
prevailing TMC processes. Instead, the system was designed to provide analysis and
recommendations using an Enterprise Service Bus platform to implement a Service Oriented
Architecture that could be integrated into existing TMC interfaces as they evolve. A simulation-based
evaluation of the combined system shows that with proper pre- specification and tuning,
the CARTESIUS system can identify response strategies that improve performance versus the
status- quo.
The research also identified a number of areas that require further research or changes in
strategy. The project fell short of its original goal to carry out a complete field operational test of
the combined CARTESIUS/ CTNET system. The reasons for this were both technical and
institutional. The report includes recommendations for avoiding similar problems in the future
that center on the use of better Systems Engineering practices. We also found that some of the
components necessary to deploy a fully functional CARTESIUS are still missing. One notable
missing feature is the unavailability of an effective near short- range demand estimator that can
feed into CARTESIUS’ response algorithms. There are promising tools still under development by
Caltrans that may meet this need. Another critical issue is the development of a general purpose
approach to translating potential response actions into estimated impacts on the system. Finally,
it has been clear in this project and on other projects related to the Testbed, that Caltrans TMC
ii i
processes have evolved over time to achieve certain levels of efficiency with available human
and technical resources. Altering these processes with new software and analytical tools is not a
trivial task. Development of clear processes for achieving such transformations could help speed
the integration of new technologies into Caltrans operations.
iv
Table of Contents
Abstract....................................................................................................................... .................... i
Executive Summary ........................................................................................................................ ii
Table of Contents....................................................................................................................... .... v
List of Figures ............................................................................................................................... vii
List of Tables ............................................................................................................................... viii
Chapter 1 Introduction .................................................................................................................... 1
1.1 A Brief History of CARTESIUS and CTNET ..................................................................... 1
1.1.1 TO- 5313 .................................................................................................................. 2
1.1.2 TO- 5324 .................................................................................................................. 3
1.2 TO- 6324: Revised Project Scope...................................................................................... 4
1.2.1 CARTESIUS Response Formation and Strategy Translation..................................... 4
1.2.2 Path to Deployment................................................................................................. 5
1.3 CARTESIUS and the modern TMC..................................................................................... 6
1.4 Overview of this Document.............................................................................................. 7
Chapter 2 CTNET.......................................................................................................................... 9
2.1 Overview....................................................................................................................... ... 9
2.2 Functional Role............................................................................................................... 10
2.3 Use Cases........................................................................................................................ 11
2.4 CTNET Communications ............................................................................................... 13
Chapter 3 CARTESIUS .................................................................................................................... 17
3.1 CARTESIUS as a theoretical system ................................................................................. 17
3.2 Traffic Management through Distributed Problem Solving........................................... 17
3.2.1 Local Problem Solving.......................................................................................... 19
3.2.2 Information Sharing for Distributed Problem Solving.......................................... 21
Chapter 4 Integration Strategy...................................................................................................... 25
4.1 Alter CARTESIUS ............................................................................................................. 25
4.1.1 Legacy Software.................................................................................................... 25
4.1.2 The Way Forward.................................................................................................. 27
4.2 Leveraging Existing Software: CTNET ......................................................................... 32
4.3 Link Related Modules..................................................................................................... 32
Chapter 5 CARTESIUS Development.............................................................................................. 34
5.1 Overview....................................................................................................................... . 34
5.2 Initial Design Choices..................................................................................................... 34
5.2.1 Development platform........................................................................................... 35
5.2.2 CARTESIUS as a bundle of services........................................................................ 37
5.2.3 Database requirements and abstractions................................................................ 38
5.3 Implementation, and Component Verification ............................................................... 40
5.3.1 Core functional requirements ................................................................................ 40
5.3.2 User Interface Requirements................................................................................. 47
5.3.3 External Interface Requirements........................................................................... 47
v
5.3.4 Security, Compatibility, and Reliability................................................................ 50
5.4 Verification and Validation of Integrated System .......................................................... 50
Chapter 6 Accessing CTNET........................................................................................................ 52
6.1 Background..................................................................................................................... 52
6.2 Jab3418e ......................................................................................................................... 52
6.2.1 Design.................................................................................................................... 53
6.2.2 Implementation...................................................................................................... 53
6.2.3 Verification............................................................................................................ 55
6.3 JCTNET......................................................................................................................... 56
6.3.1 Design.................................................................................................................... 56
6.3.2 Implementation...................................................................................................... 58
6.3.3 Verification............................................................................................................ 60
Chapter 7 Creating the Evaluation Environment .......................................................................... 62
7.1 Background..................................................................................................................... 62
7.1.1 City of Irvine Controllers unavailable................................................................... 62
7.1.2 Testbed shadow 2070s incompatible..................................................................... 63
7.1.3 IAS bridge ............................................................................................................. 64
7.2 Improvements to Paramics ............................................................................................. 66
7.2.1 Paramics Plug- in Architecture............................................................................... 66
7.2.2 Ab3418e Paramics Plug- in.................................................................................... 67
7.2.3 ATMS Testbed Paramics Plug- in.......................................................................... 68
7.3 The Complete Evaluation System .................................................................................. 69
Chapter 8 Evaluation of the CARTESIUS/ CTNET system ............................................................. 72
8.1 Study Network ................................................................................................................ 72
8.2 Evaluation ....................................................................................................................... 73
Chapter 9 Conclusion.................................................................................................................... 79
References..................................................................................................................... ............... 81
Appendix: CARTESIUS Requirements............................................................................................ 84
vi
List of Figures
Figure 2.1 The CTNET communications infrastructure. .............................................................. 16
Figure 3.1 Message passing in a three agent CARTESIUS system.................................................. 19
Figure 5.1 Relationships between the different classes of requirements for CARTESIUS.......... 41
Figure 5.2 The four types of core requirements ( shaded) used in the redesign of CARTESIUS. 42
Figure 7.1 Structure of the CARTESIUS/ CTNET evaulation environment................................. 70
Figure 8.1 The CARTESIUS study network. ................................................................................... 73
Figure 8.2 Typical severe incident scenario in CARTESIUS evaluation suite. ........................... 75
Figure 8.3 Typical CARTESIUS search tree for severe I- 405 incident ........................................... 76
Figure 8.4 Typical response strategy for an incident on I- 405 N. ................................................ 77
vii
List of Tables
Table 5.1 Scores of the CARTESIUS development platform alternatives................................... 36
Table 5.2 Relative merits of ESB platforms for CARTESIUS deployment..................................... 38
Table 7.1 Connection status of Testbed shadow controllers in the City of Irvine........................ 65
viii
Chapter 1
Introduction
This document reports on the research and development carried out under PATH Task Order
6324: CARTESIUS and CTNET— Integration and Field Operational Test. The goal of this
multiyear project has been to move the research- based CARTESIUS incident management system
closer to deployment by integrating it with Caltrans’ CTNET arterial traffic management system.
This project is the third of three task orders funded for this purpose.
1.1 A Brief History of CARTESIUS and CTNET
CARTESIUS— the Coordinated Adaptive Real- Time Expert System for Incident management in
Urban Systems— arose from the California Advanced Traffic Management System ( ATMS)
Testbed program at the University of California, Irvine ( UCI) during the 1990s that developed a
unique proving ground for traffic management technology. The Testbed links a real- world,
multi- jurisdictional transportation system with research laboratories at UCI to facilitate the
testing and evaluation of cutting edge Intelligent Transportation Systems ( ITS) technologies.
CARTESIUS is arguably one of the most important products of the first generation of the Testbed.
It was developed with the realization that traffic management in urban corridors is complicated
by jurisdictional as well as operational problems. Traffic in a freeway/ arterial corridor requires
coordinated management that optimizes corridor traffic while preserving the various levels of
authority, data control, and decision- making power inherent in a multi- jurisdictional
environment. CARTESIUS approaches this problem by employing advanced cooperation and
conflict resolution methodologies for coordinated traffic management operations among multiple
jurisdictions using a multi- agent architecture to represent the diverse interests and needs of each
agency. On the whole, CARTESIUS refers to both a philosophy regarding how to manage traffic
under the constraints inherent to multi- jurisdictional transportation systems using a Distributed
1
Problem Solving ( DPS) approach and an implementation of that philosophy in a working two-agent
prototype that demonstrates the efficacy of the philosophy.
CTNET is a distributed software system for integrated management of traffic signals that allows
operators to remotely manage, view, and log real- time traffic signal field data. The system uses a
client/ server architecture in which a CTNET CommServer acts as a proxy server for a traffic
master in the field and its associated traffic signals. CTNET clients connect to the CommServer
to gain access to monitoring and management functions provided by the CommServer. The
clients provide a convenient user interface to the user using TIGER- line maps to display
geographically accurate maps of the managed traffic signals.
The natural synergy between these two systems led to the funding of this research and
development effort, which was carried out under three PATH task orders: 5313, 5324, and 6324.
We briefly discuss each in the sections below.
1.1.1 TO- 5313
The original purpose of this TO 5313 was to test CARTESIUS, the implementation, as a precursor
to developing a deployable version of CARTESIUS for general use in California. The research plan
originally identified three broad issues for this test:
• Architectural issues related to moving the software from the relatively homogeneous
laboratory setting at UCI to a heterogeneous field environment and usability issues
associated with the use of CARTESIUS by Transportation Management Center ( TMC)
operators in practical, mission- critical settings.
• Verification and validation of embedded knowledge and agency policy regarding control
and interagency- coordination strategies.
• Protocols for testing developing technology in the field to resolve legal and institutional
barriers to field testing a comprehensive traffic management system
To address these issues, the research plan called for a test of CARTESIUS in two evaluation
modes. In the first mode, the system was to process real- time data coming from sensors in the
field and was to provide advisory management strategies and control actions for the
2
consideration of Caltrans and local traffic management center personnel. This mode of
evaluation was to provide on- line, risk- free verification and limited validation of CARTESIUS.
The second evaluation mode was to involve usability and stress testing of the CARTESIUS system
with the CARTESIUS agents remotely connected to the Paramics traffic simulator at the UCI
laboratories. In this mode, TMC operators/ personnel were to be asked to respond to the scenarios
using CARTESIUS to implement control strategies in Paramics.
During the course of TO- 5313, numerous problems arose related to the deployment of
CARTESIUS even in the limited on- line roles envisioned for the tests. As a result, the scope of the
project was revised several times to accommodate these problems. At the same time, work on
PATH Task Order 5324/ 6324— intended to explore integrating CARTESIUS with Caltrans CTNET
traffic signal management system— provided additional incentive to revise the functional role of
CARTESIUS to be more compatible with existing technology and standards. Coupled with the
identified difficulties with the existing prototype, the management team of both this research
effort and the CTNET effort collaborated to develop a revised plan for TO 5313 with a focus on
enhancing the deployability of CARTESIUS with a first effort being the CARTESIUS/ CTNET
integration effort in TO 5324/ 6324.
The results of TO- 5313 was that the follow on task orders 5324/ 6324 should carry out the
following steps for the continued development of CARTESIUS to meet the needs of Caltrans and
other stakeholders.
• Development of a set of functional requirements for the new CARTESIUS software
implementation that meets the needs of all stakeholders and, in particular, seeks to put the
CARTESIUS project on a path toward eventual deployment in California’s TMCs.
• Development of a software design that efficiently satisfies these requirements
• Implementation of that software design for the Testbed sub- network involving Caltrans–
District 12 and the City of Irvine.
1.1.2 TO- 5324
Following the recommendations of TO- 5313, the scope of task order 5324 was revised to focus
on the development of a complete set of requirements for the implementation of a new version of
3
CARTESIUS to overcome problems of the original prototype and to improve its compatibility for
integration with CTNET. Similarly, task order 6324 was restructured to implement a new
version of CARTESIUS according to these requirements, integrate it with CTNET, and evaluate
the integrated system’s operation.
1.2 TO- 6324: Revised Project Scope
As a result of the above modifications, the revised work plan for TO- 6324 differed significantly
from the original work plan— its approach to evaluating CARTESIUS/ CTNET in particular. This
evaluation focuses primarily on the use of simulated data from the 405 corridor ( 405 freeway and
parallel Alton Parkway arterial) to evaluate the performance of the coupled system. The
evaluation framework, however, is structured to use CTNET’s standard communications
interfaces for communicating with simulated field devices. The evaluation procedures used are
similar to those described in the original work plan, with the main modifications being the data
sources used for the evaluation and the degree to which operating agencies will be involved in
the evaluation.
Also, to help ensure that the product of the research would be useful to the customers, the
research and development has been carried out with the intent of eventually integrating the
adaptive signal control module being developed in PATH TO- 6323 as a control action provider
for CARTESIUS. This approach would ultimately enable the convergence of work being done on
PATH TO- 6324 and that on PATH TO- 6323. The approach would also allow the integration of
the adaptive control model to be incorporated as a module in the CARTESIUS implementation in
CTNET.
1.2.1 CARTESIUS Response Formation and Strategy Translation
CARTESIUS response formation is the product of a heuristic search through the problem space
defined by estimated traffic conditions and estimated incident impacts in terms of demand and
capacity disruptions. The search is driven by an agency- specific set of response strategies and
related control actions that can be used to implement those strategies. These agency- specific
configurations comprise a knowledge base that constrains the possible solution space to solutions
that are consistent with local traffic control policies. Any evaluation of the CARTESIUS/ CTNET
4
system will be governed by this knowledge base and the particular set of possible strategies and
control actions available in the knowledge base. For the remaining research, two types of control
actions will be added to the knowledge base. The first will use predetermined timing patterns
accessible from the controllers using CTNET to provide coordinated signalization strategies to
the search algorithm. This will permit CARTESIUS to interoperate effectively with typical
installations currently in use. We will also consider adding a control action to the knowledge
base that uses the adaptive control system being developed in PATH TO- 6323. This control
subsystem solves the corridor ramp- metering and traffic signal control problem using a multi-objective
formulation that produces solutions for optimal control that specify the set of non-dominated
corridor control options. CARTESIUS can explore this set using its search algorithm to
find the solution that is acceptable to all participating agencies.
1.2.2 Path to Deployment
The integration of CARTESIUS and CTNET offers a significant step toward deploying true
corridor control of non- recurrent congestion. The use of existing timing patterns provided by
CTNET improves the deployability of CARTESIUS by using control actions that have already
been vetted by traffic engineers rather than trying to dynamically determine new strategies.
Consequently, a completion of the final year of this project will move CARTESIUS significantly
closer to potential real- world deployment.
Toward this ultimate end, the CARTESIUS/ CTNET evaluation is being conducted on the I- 405
corridor network in the City of Irvine ( COI). This location has been chosen because we have at
least limited authority to conduct tests involving closed- loop control. On the arterial, we have
installed a system of Type 2070 controllers at all signalized intersections that operate
independently from the local COI system. Research already completed as part of this project has
connected these controllers to CTNET; a secondary system based on state- of- the- art Siemens
ACTRA Central Traffic Control System with custom- designed Input Acquisition Software is in
place as a backup, should the CTNET configuration prove problematic. Software has been
developed, and laboratory tested, that permits real- time adaptive control of Caltrans District 12
ramp meters in the study area ( a feature not currently possible under Caltrans District 12 ATMS).
We have established real- time communication with these control devices and also receive real-time
raw data streams from loop detectors within the study area. We have memoranda of
5
understanding with both the COI and Caltrans District 12 that permit the research team to
conduct closed- loop control experiments in the study area.
These existing efforts will ultimately allow us to connect the CARTESIUS/ CTNET system to real-world
data streams in order to evaluate the strategies recommended by CARTESIUS. Toward this
end, the CARTESIUS/ CTNET system will be configured to interoperate with the I- 405 corridor
network, including all available traffic signals, ramp meters, and information systems. We will
evaluate this deployment configuration using our Paramics simulation of the corridor using
custom plugins already written as part of this research to allow the simulation to interoperate
with CTNET, and ultimately CARTESIUS. The system will also be connected in a read- only
manner to the real- world data feeds described above to evaluate its recommendations as
compared with actual operations. In the final analysis, we expect to assess the degree to which
constraining the control actions available to CARTESIUS ( e. g, by using only pre- vetted signal
timing patterns stored in CTNET) impacts the quality of the system’s response to incidents.
1.3 CARTESIUS and the modern TMC
During the course of this research, and the research in related projects on the Testbed, the
research team has had the opportunity to evaluate the core processes of the modern Caltrans
TMC at District 12. The operations in the TMC are dominated by engineers and staff whose
primary roles are to
• identify disruptions in the system,
• communicate to relevant parties about that disruption
• dispatch traffic management and maintenance teams to the site,
• disseminate incident details to the traveling public
• monitor and react to changing conditions on the ground as appropriate
To carry out these functions, the operators rely on well defined processes centering around
particular software tools:
• The ATMS system for monitoring traffic conditions and controlling changeable message
signs ( CMS)
6
• The CHP CAD system for monitoring emergency response.
• The district's radio communications system for dispatching teams.
• The TMC activity logging system for recording all actions taken by the TMC and
qualitative assessments of the performance of the system.
Additional tools are available, such as an event management system whose role is to provide
specific information to the regional 511 information system as well as various tools for
controlling CCTV, highway advisory radio ( HAR), and a multitude of other systems. At the
same time, Caltrans statewide continues to develop the ATMS system, new activity logging tools
( TMCAL), and its surface street operator interface ( CTNET) in parallel to the efforts in local
districts.
Put together, this collection of software tools and interfaces make defining a realistic use- case for
a new incident management system that fits into existing processes challenging at best, and
ultimately beyond the realistic scope of this project. As such, efforts in this research focused less
on creating new interfaces and shifted instead toward processing available data into high- level
system assessments and response suggestions that can more feasibly be integrated into TMC
processes by eventually incorporating them into existing and new interfaces already under
development. Not only does this approach bring the promise of CARTESIUS closer to actual use
by Caltrans, it also is consistent with the new philosophy of the Caltrans ATMS Testbed of
which CARTESIUS has always been a central component.
1.4 Overview of this Document
Given the above backdrop, we continue in this report by discussing the features of both CTNET
( Chapter 2) and CARTESIUS ( Chapter 3). We then discuss the problems and solutions to
integrating these components into a functioning system in Chapter 4. In Chapter 5, we turn to
the design and re- implementation of CARTESIUS as a background traffic management service
instead of a top- level traffic management application that would compete for space in the ever-congested
set of TMC processes. Chapter 6 describes the development of the required
communications libraries to allow CARTESIUS and other Java- based programs to act as clients to
the CTNET system, thus obtaining read/ write capabilities to any traffic signal subsystem under
7
CTNET management. In Chapter 7, we describe the evaluation strategy for the combined
system. This includes a discussion of how the strategy was gradually downgraded from a full-blown
closed- loop field operational test to a more limited evaluation using simulation. We also
describe the development of customized simulation platform that was used as well as its features
and limitations. Chapter 8 discusses the evaluation results for integrated system on the Testbed
study network. Finally, Chapter 9 offers some conclusions and recommendations for
CARTESIUS, CTNET, the ATMS Testbed, and future corridor field operational tests.
8
Chapter 2
CTNET
2.1 Overview
CTNET is a distributed software system for integrated management of traffic signals that is
widely deployed by Caltrans and some municipalities across the state. CTNET allows operators
to remotely manage, view, and log real- time traffic signal field data. The system uses a modular
client/ server architecture in which a CTNET CommServer acts as a proxy server for one or more
Traffic Responsive Field Masters ( TRFMs) in the field ( see Figure 2.1). The masters, in turn,
control a subset of traffic signals, which can be managed by either Caltrans C8, version 4
software ( type 170 controllers) or TSCP version 1.02 software ( type 2070 controllers). The
TRFMs support both synchronized traffic responsive and time of day traffic signal coordination
schemes.
CTNET clients connect to the CommServer to gain access to monitoring and management
functions provided by the CommServer. Access privileges are controlled on a per- user basis,
allowing the system to limit specific functions to authorized users only. The existing CTNET
client provides a user interface which uses TIGER- line data to display geographically accurate
maps of the managed traffic signals. An open ( non- proprietary) communications protocol is used
between CTNET clients and the CTNET server so that third party clients can be developed to
work with the system.
By itself, CTNET does not provide automated, globally coordinated incident response. The
existing CTNET client software allows TMC operators to manually alter timing plans to
implement control responses determined outside the CTNET architecture. These responses may
come from any source, but are most likely to be derived on the fly by TMC operators with expert
knowledge of the system. Thus, CTNET could benefit from the integration of the global incident
management capabilities that are fundamental to CARTESIUS.
9
2.2 Functional Role
CTNET is a solution to the Surface Street Control market package ( ATMS03) as defined by the
National ITS Architecture ( Iteris, Inc, 2002). This market package provides the central control
and monitoring equipment, communication links, and the signal control equipment that support
local surface street control and/ or arterial traffic management. A range of traffic signal control
systems are represented by this market package ranging from fixed- schedule control systems to
fully traffic responsive systems that dynamically adjust control plans and strategies based on
current traffic conditions and priority requests. This market package is generally an intra-jurisdictional
package that does not rely on real- time communications between separate control
systems to achieve area- wide traffic signal coordination. Systems that achieve coordination
across jurisdictions by using a common time base or other strategies that do not require real time
coordination would be represented by this package. This market package is consistent with
typical urban traffic signal control systems.
This market package consists of 6 equipment packages
• Roadway Basic Surveillance: This equipment package connects the TMC to fixed traffic
sensors. CTNET satisfies the functional requirements for this equipment package for loop
detectors that are part of the managed arterials.
• Roadway Equipment Coordination: This package provides for direct communications
between field controllers to facilitate coordination without requiring direct intervention
by the center. CTNET provides this functionality through its Field Master Program.
• Roadway Signal Controls: This package provides the fundamental equipment for signal
control. By itself, CTNET only provides a subset of the functionality defined for this
equipment package: connectivity between field controllers and the TMC. It is, however, a
critical part of a standard Caltrans signal deployment that does satisfy the functional
requirements for this equipment package.
• Collect Traffic Surveillance: This package provides the TMCs with remote monitoring
and control capabilities for traffic sensors, making data accessible to TMC processes, and
to other TMCs. This equipment package describes CTNET’s core functionality. It
provides these capabilities, including inter- TMC access, using its client/ server
10
architecture. Furthermore, CTNET provides a dynamic map interface for monitoring
traffic performance and device status as well as for updating signal control parameters.
• TMC Signal Control: This package provides the TMCs with remote management
capabilities of signalized intersections. As above, CTNET’s client/ server architecture
provides these capabilities.
• Traffic Maintenance: This package monitors the status of field devices and notifies
operators of faults. CTNET provides these capabilities as an integrated part of the client
interface.
2.3 Use Cases
CTNET is a traffic signal management system that allows operators to remotely control arterial
traffic detection and control devices as if they were accessing them directly at cabinet in the
field.
The system is designed to greatly simplify the maintenance and operation of a large set of traffic
signals by allowing one or more operators to remotely monitor signal status and operation, log
traffic detection and control data, and modify traffic signal timing plans. A set of typical use
cases are described below for an operator working with a CTNET client. These cases all assume
that a CTNET data file has already been created for a managed arterial, and that a CTNET
CommServer processes is deployed and operational.
Basic flow- system monitoring: An operator in the TMC is tasked with ensuring the system is
operating normally. She opens the datafile for the arterial network of interest using the CTNET
client application. She clicks on the connect button to login to the CTNET CommServer
managing the arterial network. She then selects the pre- saved view of the network that shows the
status of all the managed intersections on a map, including current phasing, vehicle calls,
pedestrian calls, and cabinet alarms. The operator uses the mouse to move over system detector
icons to view flow, occupancy, and speed data for particular sections that she knows to be
congested during this time of day. She confirms them to be within acceptable ranges according to
her experience.
11
The operator then clicks the display alarms toolbar button to view the preemption and alarm logs.
She notes several emergency vehicle preemptions have occurred, but that their durations were
within normal operating parameters.
Having finished her monitoring task, she adds a note to the operations center log that everything
appears normal and continues with her other tasks until her next scheduled check.
Alternative flow- device failures: After opening the saved view of the system, the operator
notes a number of problems. First, the loss of signal ( LOS) icon is displayed for the cabinet
associated with one of the intersections. She makes a note, knowing that this indicates a
communications failure between the master controller and the intersection’s local controller.
Second, after musing over what is usually a particularly busy intersection, she notices that the
reported volume is zero for the system detector on the busiest leg. Surmising that this is likely
due to a detector fault, she checks a previously configured detector report within CTNET to see
if the detector is bad. She makes a second note for maintenance after confirming it is.
Finally, when viewing the alarm logs, she notices a cabinet flash alarm on a minor intersection
has occurred in the past hour. Checking the maintenance and police logs, she finds no mention of
an incident at the intersection and adds a last note to explore the reason for the intersection being
going to flash mode.
Having finished her preliminary analysis, the operator phones the maintenance department to
dispatch a technician to troubleshoot the connectivity problem and system detector problems she
noted. She then contacts other operations personnel to identify the cause of the flash alarm,
which she finds was due to a maintenance operation that had not been properly logged in the
ATMS system. She adds the log and goes about her duties.
Alternative flow- uncharacteristic flow: While reviewing system detector flows, the operator
notes unusually high occupancy and low volume at a major intersection in the network. She uses
the Tic’s CCTV system to view what is happening at the intersection and discovers that a
collision has occurred in the middle of the intersection, causing a severe congestion on all
approaches. She consults incident logs and, finding no mention of the accident, calls emergency
operations to report the accident and initiate an appropriate emergency response.
12
Because the TMC is a participant in such emergency responses, she begins to follow her
agency’s standard operating procedures for managing traffic in this situation.
Alternative flow- updating timing plans: Engineers at the operations center have produced
updated planning model using a new regional model and recent counts obtained using the
CTNET reporting functions. The new model includes significant changes in daily traffic
demands along two major arterials managed by CTNET. After performing network- wide re-timing
and coordination using standard agency engineering practice, a TMC operator is tasked
with updating the timing plans in the field.
He begins, as above, by opening data file for the network of interest using the CTNET client and
clicking on the connect button to login to the associated CTNET CommServer. Referring the
updated timing plans produced by the engineers, he right clicks on the cabinet of the first
intersection he needs to update to get the cabinet menu and selects the “ get timing” item, which
is active because the CommServer has determined that the operator has permission to view and
update timing data. This opens up the time data sheet with the timing data uploaded from the
field master.
The operator proceeds to enter in the first new timing plan. Most parameters are the same, but
the maximum extensions have changed to reflect the changed demands in the system. Clicking
the coordination tab, he also updates coordination parameters that have changed due to shifting
prevailing flows predicted for the system. After finishing this task, he clicks the upload button,
sending the new timing data to the controller.
He performs these tasks for each intersection with an updated timing plan, then disconnects his
CTNET client from the CommServer and closes the application.
2.4 CTNET Communications
As we’ll discuss in Chapter 6, the project team made a design decision in the CTNET/ CARTESIUS
integration to not alter CTNET and instead to have CARTESIUS act as a CTNET client to interact
with the traffic signal subsystem. Understanding the underlying communications protocols used
by CTNET was therefore a central task. We summarize those protocols here.
13
The client/ server architecture of CTNET is based upon two distinct sets of communications links
as shown in Figure 2.1. The first set ( CI- 1) connects the CTNET CommServer to the field
masters, which in turn forward messages to and from local controllers as appropriate.
Communications at this level use an extended version of California’s AB3418 protocol
( Caltrans, 1995) that was specifically developed to allow central- to- master communication. The
AB3418 extended ( AB3418E) protocol adds messages for obtaining current 8 phase operation,
presence, system detector measurements, as well as the ability to get, set, and manage controller
time data. The AB3418 specification is defined for the complete network stack, detailing the
physical data- link, network, and application layer requirements. The lower layers ( physical,
data- link, and network) are generally structured to support serial line communications ( RS- 232)
between the CommServer and the field master--- typical of connections provided over telephone
lines or similar. However, it is notable that CTNET supports addressing using the TCP/ IP stack
that is the backbone of the broader Internet. It should be noted that the TCP/ IP connections
break some of the assumptions in the AB3418 protocol about the ability of the stack to convey
real- time Application Layer messages. As such, use of the TCP/ IP link for real- world operations
may need further vetting. Nonetheless, the undocumented TCP/ IP support made it possible to
link CTNET to Paramics without any modifications to the former. Since this is only used for
simulated analysis, the real- time implications are unimportant ( this is discussed in greater detail
in section 7.2).
The Application layer specification is the most relevant aspect of the protocol for the purposes of
this research as it defines the structure of the message packets that are used to transmit data
between the controllers and the CommServer. Very simply, the specification defines how
application message frames must be structured to pass data between the server and the field
controllers. The first byte of the message defines the message type using standards from the
National Transportation Communications for ITS Protocol. The following bytes contain the
appropriate payload for the defined message type. AB3418 protocol defined only a few basic
message types for interacting with field controllers. AB3418e expanded this to support the more
advanced get/ set features need to meet the needs of CTNET, which in turn, uses AB3418e as its
core protocol for communicating the status of the system to CTNET clients.
The second set of communications links ( CI- 2, CI- 3, …, CI- n) connect CTNET desktop clients
to the CTNET server and, by proxy, to the field controllers. Two protocols are used in this
14
infrastructure. First, the CTNET client/ server application is built atop a set of messages passed
between the Client and the CommServer using simple socket- based communications over
TCP/ IP. These messages are used to for user authentication, CommServer configuration, and to
send commands to the CommServer to request and set field element parameters from the server.
( Note that once a client is connected to the CommServer, it can also send messages directly to
field elements using the AB3418e protocol.) The CTNET application messages are passed as
fixed- length packets in which the first byte identifies the message type and the remaining bytes
store to a tab- delimited string of parameters for the message. In addition to the CTNET
application messages, CTNET clients also receive AB3418e packets via UDP from the
CommServer once they have connected. These packets are generally status messages forwarded
by the CommServer from the field elements so that the Client can display the system status on
the user interface.
15
Figure 2.1 The CTNET communications infrastructure.
16
Chapter 3
CARTESIUS
3.1 CARTESIUS as a theoretical system
The core goal of the original CARTESIUS research was to develop a new Distributed Problem
Solving ( DPS) approach for the provision of real- time decision- support to TMC personnel in
multi- jurisdictional, network- wide management of non- recurring congestion. The approach is
based on the Functionally Accurate/ Cooperative ( FA/ C) approach to DPS ( Lesser and Corkill,
1981).
3.2 Traffic Management through Distributed Problem
Solving
The core features of the CARTESIUS philosophy permit conforming distributed systems to:
• reflect the jurisdictional distribution of traffic problem- solving expertise,
• provide local management of data sources, and
• reduce synchronization delay and communication overhead.
The main goals of the architecture are to allow:
“ a set of agents to interact in order to produce an efficient and conflict- free global
solution in an environment that is inherently distributed. Their interaction is constrained
by the lack of complete information that results from the data and control knowledge
being distributed according to geographical and administrative criteria. Input data
available to the TMC operator, such as detector data describing traffic conditions, visual
data coming from CCTV cameras installed at key locations, and incident reports or
confirmations, are normally partitioned according to the institutional organization of the
management agencies, which must administer the information in their possession as
17
efficiently as possible, avoiding the transmission of irrelevant or ill- timed data. Another
constraining factor is the need of each agency to preserve dedicated control over its
jurisdiction, maintaining its decisional power, and applying local criteria and guidelines.
At the same time, the agencies, as interacting components of a regional, integrated
management organization, must attempt to converge towards a common goal, that of
ameliorating network- wide traffic conditions, and can do so by effective collaboration
and resolution of potential conflicts ( Logi, 1999).”
To meet these goals, CARTESIUS uses the FA/ C DPS framework. This paradigm organizes
effective cooperation among DPS agents in order to produce an acceptable solution in reasonable
time by assuming that individual agents need not always have all the information about the
global problem to completely and accurately solve their sub- problems. In particular, in some
applications
“ there exist inter- agent constraints among subproblems that can be exploited to resolve
the inconsistencies that may arise due to the lack of accurate, complete and up- to- date
information. Agents can produce tentative, partial results based on local information and
then exchange them with other agents to resolve local uncertainties and global
inconsistencies ( Logi, 1999).”
The CARTESIUS formulation maps these concepts to the multi- jurisdictional traffic management
domain by describing a problem solving agent for each jurisdiction that is solely responsible for
controlling its subnetwork. Each jurisdictional agent can first focus on its local problems, then
exchange high- level information about its local candidate solutions with other agents. This
exchanged information allows each agent to identify and remove local solutions that are at odds
with the collection of management actions proposed by remote agents.
A key theoretical contribution provided by CARTESIUS is its definition of the features of the
traffic management problem domain in a manner that is consistent with the FA/ C DPS
formulation. Toward this end, CARTESIUS leveraged an existing problem solving approach for
traffic management, the Traffic Congestion Manager ( TCM) ( Logi, 1995), which used
methodologies similar to those employed in existing FA/ C systems.
Figure 3.1 shows the event processing that occurs in a three- agent CARTESIUS system when an
incident is reported somewhere in the managed network. The event notification causes each
18
Figure 3.1 Message passing in a three agent CARTESIUS system.
agent to begin a two- stage analysis. During the Problem Analysis stage each agent characterizes
all problems in its jurisdiction and attempts to identify their causes.
Information is shared between agents to allow causation to be determined across jurisdictional
boundaries. During the Problem Response stage, each agent searches for strategies and the local
control actions that implement them. The assumptions underlying these local control actions are
propagated to other agents as constraints that those agents are requested to consider in a global
solver step. At this point, each agent has its own copy of all feasible local solutions that conform
to globally propagated constraints. A given agent’s copy of this solution set contains detailed
information about local actions to be taken for each solution and high- level information about the
remote plans that are consistent with these local actions.
3.2.1 Local Problem Solving
The CARTESIUS approach is based upon the concept that each agent solves any problems local to
its jurisdiction subject to limited information shared between the agents, which may include new
potential problems caused by actions taken in neighboring jurisdictions. Thus, a problem solving
19
agent can simply focus on mitigating a given set of problems using a local algorithm. The core
features of the local problem solving algorithm that makes up the CARTESIUS philosophy are
discussed below.
3.2.1.1 Knowledge Representation
CARTESIUS characterizes problems in the system using problem- specific frame- driven
recognition techniques ( Charniak and McDermott, 1985). At their core, these techniques depend
on a “ hierarchical database of knowledge packets,” or frames ( Minsky, 1974; Winston, 1975),
that represent expert knowledge regarding the causal origins of problems in the transportation
system as problem frames defined in terms of network topology and qualitative characterizations
of sensor data. The database of problem frames are systematically compared to individual
network objects— discrete partitions of the traffic network with particular operational
characteristics ( e. g., freeway on- ramp, freeway off- ramp, intersection approach, etc.). Each
jurisdictional agent must therefore create and maintain this database of problem frames and
network objects representing the network it manages. Specific knowledge about neighboring
jurisdictions networks, control systems, particular problem types, and real- time data is not
required. This partitioning satisfies the need for the system to preserve local autonomy and
greatly simplifies data management.
3.2.1.2 Problem Characterization
The identified problems output from the local frame matching procedures, using real- time
measurements from the system, collectively form a problem state. Each problem in the problem
state identifies a critical section in the network for which the estimated demand exceeds the
estimated capacity and, depending on the problem frame that matched to the current conditions,
provides an assessment of the cause and general characteristics of the disruption based upon
local expert knowledge embedded in the system’s problem frame database.
The characterization process also recognizes the fact that a problem at a particular location in the
network can lead to secondary congestion at other locations in the network ( e. g., on- ramp
spillback onto the arterial network). The local problem characterization works to identify derives
from relationships between problems. These relationships are used in the logic that determines
responses recommended by the CARTESIUS system.
20
3.2.1.3 Problem Response
To mitigate the identified problem state, the CARTESIUS is structured around a planning
approach, in the Artificial Intelligence ( AI) sense, to generate a sequence of local control actions
that can change the estimated state of the transportation system to a more favorable outcome.
The approach uses a heuristic Breadth First Search ( BFS) algorithm that starts from the identified
problem state, identifies subgoals that aim to move the system to a more desired state ( e. g., a
state in which demand and capacity are balanced), and finds concrete control actions that can
achieve these subgoals. This general formulation is implemented for the traffic management
problem by defining subgoals ( with corresponding strategies) as follows:
• increase capacity at a congested location by signalization,
• decrease flow at a congested location by traffic diversion, and
• decrease flow at a congested location by upstream metering.
Defining concrete actions to implement these strategies, and algorithms to estimate those effects
is a location and implementation- specific task because the available strategies and associated
control actions will vary with each deployment— every jurisdiction is likely to employ different
control subsystems that have distinct characteristics that are difficult to generalize.
3.2.1.4 Problem Monitoring
The type of high- level traffic management tackled by CARTESIUS inherently must deal with large
degrees of uncertainty regarding knowledge of the state of the system and the effectiveness of
implemented control strategies. Toward this end, CARTESIUS includes problem monitoring
functions whose role is to track the performance of given control solution— in an absolute sense
as well as whether the evolution of the system under that solution is consistent with expectation.
The secondary function of the problem monitor is to filter out redundant information ( such as the
re- reporting of existing problems) to reduce the need for unnecessary analysis of problems that
have already been considered.
3.2.2 Information Sharing for Distributed Problem Solving
The jurisdictional partitioning of traffic management described above can effectively isolate the
management of problems to a single jurisdiction in the system as long the effects of those
21
problems are contained in one jurisdiction. The existence of spillback effects across
jurisdictional boundaries, and the fact that some control strategies ( such as diversion) can place
operational burdens on portions of the network outside the jurisdiction of the diverting agency,
requires a means for sharing information between jurisdictions regarding such effects.
It is here that CARTESIUS DPS philosophy provides benefits by defining the specific types of
information that need to be shared across jurisdictions in order to ensure that the collective of
local responses to a given problem state produce a global solution that is acceptable to all
jurisdictions.
The CARTESIUS adaptation of FA/ C methods to this problem defines three distinct stages during
problem solving when distributed agents should exchange information, and also what type of
high- level information should be exchanged at those points. In each case, the general approach is
to locally perform detailed analysis, then to create and post an abstraction of that analysis that
can be used by other agents that then leverage the abstraction to refine their analysis. The process
can be iterative and each instance must be carefully analyzed to ensure tractability and the
avoidance of race conditions in the distributed system.
3.2.2.1 Problem Analysis: Spillbacks and derived problems
The characterization of traffic problems is complicated in a distributed system because of the
potential relationship between problems as discussed above. Since such propagation can cross
jurisdictional boundaries, the local problem characterization process described above must be
augmented to handle information regarding the possible relationship between problems across
jurisdictional boundaries.
CARTESIUS handles this problem by identifying all spillback effects and posting their
characteristics to other agents for them to identify possible links between them. This information
sharing allows agents whose jurisdictions are involved to compute derives from relationships
between problems that cross these boundaries and to share those determinations with the agent
collective.
3.2.2.2 Problem Response
The nature of partially decoupled DPS for complex, large- scale systems invariably leads to
uncertainty and imperfect knowledge that makes the use of heuristic algorithms the only
22
tractable approach. Any exact or heuristic optimization algorithm requires specification of an
objective that can be evaluated in reasonable time ( as dictated by the constraints of the algorithm
and available computing power). Furthermore, the algorithm needs a means for determining how
to reach the objective ( i. e., a search direction).
CARTESIUS uses a problem solving heuristic that seeks to both avoid the spread of congestion that
may lead to oversaturation and secondarily, to achieve a balanced ratio between network
capacity and traffic demand. The CARTESIUS traffic management agent uses problem solving
algorithm that incrementally searches a space of problem mitigation strategies, each of which can
be translated by a corresponding control action or set of control actions.
Thus, a strategy to reduce critical section demand through diversion might be realized by setting
a collection of Changeable Message Sign ( CMS) to reroute traffic around the problem.
The expansion of the solution search tree through strategy and control actions generates new
nodes representing an estimate of the state of the system if the control actions on the path from
the root node to the target node are applied.
The selection of given strategy or the specific control actions that translate that strategy may
require the satisfaction of particular conditions that define dynamic constraints that must be met
for those strategies or actions to achieve their anticipated effects. These constraints may only
apply to the local jurisdiction, but often, as in the case of diversion strategies requiring sufficient
network capacity, they may propagate to remote jurisdictions.
CARTESIUS propagates such constraints as conditions that the remote agent must meet. The
remote agent translates these conditions into strategies that have the goal of meeting the
condition. These strategies are used to expand the search tree by branching from existing nodes
to generate new portions of the search tree that will satisfy the conditions broadcast by other
agents.
The process continues until no more conditional strategies are being broadcast by any agents.
This indicates that the global search has been exhausted and the existing candidate solutions in
the tree represent global collective of candidate solutions under consideration, including the
extent to which each solution meets any broadcast constraints. The task of selecting a single
global solution from among the set of candidates is one of removing solutions that are
23
inconsistent with local or remote constraints. Since each agent has the same list of the available
feasible solutions, it is now possible for the agent collective to jointly select a single global
solution consisting of a combination of locally acceptable control actions.
24
Chapter 4
Integration Strategy
In Task Order 5313, we laid out recommendations for moving the CARTESIUS system closer to
deployment ( Rindt and McNally, 2006). These were based on findings from a detailed analysis
of CARTESIUS, its theoretical capabilities, its practical capabilities, and our assessment on
feasible directions for the system and where it fit into the future of traffic management in
California. This chapter summarizes these findings in the context of integrating the system to
work with CTNET.
4.1 Alter CARTESIUS
4.1.1 Legacy Software
4.1.1.1 Barriers to Deploying the Prototype
The original CARTESIUS prototype proved difficult to deploy in even very limited capacities
involving in laboratory testing. The reasons for this difficulty were numerous and cross cutting,
but collectively they severely limited its potential for real- world deployment in the near to
medium term. This led to a number of key recommendations that shaped the course of this
project:
• Re- implementing the CARTESIUS traffic management prototype using appropriate general
purpose languages and communications protocols to free it from costly vendor lock- in
that ultimately restricts its development.
• Exploring modern, service- oriented messaging architectures that allow individual
components to be loosely coupled using event- driven methodologies to achieve
coordination as necessary.
25
• Reworking of the CARTESIUS traffic management agent design that separates analytical
functionality from interface functionality.
• Adoption of an out- of- the box service- oriented messaging architecture for information
sharing between CARTESIUS agents and between those agents and external data sources
and control subsystems.
• Redefinition of the CARTESIUS data model that focuses on leveraging data standards and
software tools and libraries that operate on those standards. Furthermore, to facilitate
broader use of CARTESIUS- related data, we recommended the use of a general- purpose
relational database that can expose core data used by CARTESIUS to multiple sources.
• Focusing CARTESIUS on the problem of estimating the implications of anticipated control
actions given currently deployed control algorithms. The problem of actively adjusting
control ( or advising local controllers) to mitigate non- recurrent congestion using
customized control algorithms can be investigated where necessary, but preference
should be given to existing research focusing on those problems independently.
4.1.1.2 Aging Priorities: Functional Redundancy in CARTESIUS
The shortcomings discussed in 4.1.1.1 can be considered as a failure to properly bound the
functional role of the CARTESIUS management agent. In a practical sense, however, they are
primarily the result of shifting the CARTESIUS project’s priorities. The history of the original
CARTESIUS prototype led to its implementation as a “ Swiss Army knife” of traffic management
that ultimately sought to optimize all components of the transportation system on the basis of
estimation models contained within CARTESIUS itself. This development was largely driven by
the need to create a functional prototype that could demonstrate the efficacy of the core
CARTESIUS algorithms for finding solutions to non- recurrent congestion for a given set of
potential control actions. Unfortunately, this development path also resulted in CARTESIUS
assuming responsibility for functions outside its mandate. Thus, the CARTESIUS prototype
became a system for optimizing traffic signals, ramp meters, and variable message signs using its
own internal algorithms.
Assuming responsibility for all of these functions makes maintenance of the system challenging
and makes a particular CARTESIUS traffic management agent’s implementation susceptible to
26
obsolescence since it is difficult to incorporate newly available technologies and algorithms into
a monolithic agent. Furthermore, such feature concentration limits the scalability and fault-tolerance
of the system. Finally, developing standards in the industry ( Iteris, Inc, 2002) put the
CARTESIUS prototype at odds with current and likely future of traffic management systems.
In an age when the deployment of research projects is a primary goal of sponsors, researchers
would be well served to plan accordingly from the early stages of research. This is particularly
true for research that ultimately targets one or more functional roles that exist in mature, complex
operating environments such as ITS.
Based on these findings, we made the following recommendation:
• Continuing CARTESIUS research be guided by a well defined set of functional
requirements derived from the known capabilities of the CARTESIUS approach and from
the realities of the real- world technical and institutional landscape.
4.1.1.3 Finding Synergy
As has been suggested in earlier sections, the existing CARTESIUS prototype suffers from a lack
of focus that can be alleviated by clearly defining CARTESIUS’s role in traffic management. A
side effect of proper tasking of CARTESIUS is that it will make it easier for CARTESIUS to find
synergy with existing traffic management technologies, and more importantly, with developing
research that has the potential to broadly impact the quality of traffic management systems.
4.1.2 The Way Forward
4.1.2.1 Simplification and Openness
The core CARTESIUS philosophy is a powerful conceptualization of the multi- jurisdictional traffic
management problem. However, the findings of chapter 3 argue that the current prototype is a
dated realization of this philosophy that must be revised. This begs the question of whether the
revision should entail a modification to the existing prototype, or whether a complete
reimplementation is warranted.
In our judgment these points support reimplementation primarily because it is clear that the
existing CARTESIUS prototype attempts to do too much in incident management given its
capabilities. This makes the benefits of reimplementation greatly outweigh the benefits of
27
revision— particularly since the latter most revolve around the value of an existing code base that
solves problems outside its appropriate functional role.
As a result, we recommend focusing on CARTESIUS core strength as a system for managing
conflicts between the potential actions of different jurisdictions and negotiating alternative
strategies to mitigate those conflicts. This does not preclude using a CARTESIUS management
agent to perform optimization, but the most feasible course of action for deployment is to
emphasize CARTESIUS monitoring and general advisory role regarding multi- jurisdictional
conflicts.
4.1.2.2 CARTESIUS as an Organizing Principle
That the CARTESIUS approach to multi- jurisdictional traffic management via DPS is a promising
management strategy should not be in question; the results of the original research demonstrate
the power and potential of the underlying concepts. The challenge lies in transforming these
concepts into incrementally deployable components that are compatible with existing systems.
The real- world landscape is one of existing traffic management subsystems, each using a variety
of variably standards- based approaches to managing traffic. For most jurisdictions, the emphasis
is on strategic optimization of control settings ( on roughly annual timescales) to match
prevailing demands. Top- down management of non- recurrent congestion is generally limited to
rapid deployment of emergency and operations services ( to clear disruptions) and information
provision ( to notify travelers of disruptions). Locally adaptive control schemes that obviate the
need for centralized re- optimization are in limited deployment but are likely to increase in the
future.
Whether more aggressive top- down management is warranted in operational contexts remains an
open question. CARTESIUS research has certainly shown promise for centralized management
through active re- optimization of field controllers and diversion- oriented information provision
under varying assumptions and a variety of system failures. But no comparisons have been made
to truly adaptive systems that rapidly respond to changing demand patterns.
Assuming such systems continue in development and eventually see broader deployment, what is
the future role of top- down management approaches such as that used by the current CARTESIUS
agent prototype? We believe that the answer lies in the strength of viewing multi- jurisdictional
28
traffic management as a DPS process. Regardless of the local algorithms employed, multi-jurisdictional
traffic management is inherently an instance of DPS. Each controller, or control
subsystem takes action on the basis of local knowledge to achieve some local goal ( e. g.,
minimizing delay for the managed subsystem). The extent to which these local goals assist or
hinder system- wide goals is ignored for the most part.
For instance, virtually all adaptive traffic signal algorithms are based on dynamic programming
approaches to estimating prevailing demands and adapting the control parameters of local
controllers to best service those demands. These demand estimation procedures, however, will
have difficulty responding rapidly to discontinuous changes is demand caused, for instance, by
massive re- routing of freeway traffic to the arterial system. Foreknowledge of such rapid demand
shifts could reasonably be added to local adaptive control algorithms to rapidly respond to
demand shifts and prevent the oversaturation and queuing that can cripple arterial control
systems.
The CARTESIUS philosophy offers an organizing principle for traffic management systems that
lends itself to unobtrusive information sharing that can be leveraged by control subsystems,
when feasible and/ or desired. It also provides a mechanism for distributed diagnosis of
interconnected problems in the system. In short, CARTESIUS becomes an organizing principle
about how to conceptualize control resources in the transportation system.
The degree to which a given jurisdiction participates in the CARTESIUS system could vary from
the most abstract level of information sharing down to detailed participation of each controller in
the global problem solution. This flexibility makes CARTESIUS simpler to deploy incrementally
by allowing managers to minimize the risk they take in participating with other CARTESIUS
components.
4.1.2.3 CARTESIUS as an Information Sharing Protocol
Adopting the CARTESIUS DPS philosophy requires a protocol for sharing high- level information
related to traffic management between jurisdictions. We propose transforming the information
sharing techniques used in the original CARTESIUS two- agent implementation into a general-purpose
collection of messages that can be leveraged by any CARTESIUS aware component as it
sees fit. We propose that this can be a model for general purpose TMC to TMC traffic
29
management communication that may have relevance to developing standards in the National
Intelligent Transportation Systems Architecture ( NITSA).
As discussed in section 2.1.2, CARTESIUS was originally designed using a hierarchical frame-based
representation of possible problems in the system that relied upon representing the
transportation network as a collection of network objects whose dynamic state can be compared
with the problem frame database. This is a somewhat unconventional approach to network
representation that may or may not be convenient to a particular jurisdiction.
This highlights the broader problem of defining data representations for sharing information
across jurisdictions. Any collection of jurisdictions that agree to participate in a collaborative
management system must ultimately agree on how common knowledge across jurisdictions is
represented. If CARTESIUS is implemented as a monolithic agent that acts to control all resources,
this problem is mitigated to the extent that a custom, CARTESIUS- compatible network
representation can be built for each implementation. This creates a higher cost for participation,
however, that may not be palatable to potential participants.
Ideally, a deployable CARTESIUS system would play nicely with a broad range of network
representations that may be in use by existing management systems. One approach is to simply
perform data transformations on- the- fly as information is exchanged between CARTESIUS
components and external management systems.
With the above caveats in mind, the knowledge partitioning approach endorsed by the
CARTESIUS philosophy is a good one that minimizes the need for a given jurisdiction to maintain
datasets representing the assets of neighboring jurisdictions. This, in turn, supports the goal of
allowing jurisdictions to control access to possibly sensitive data about their systems.
The level of common knowledge needed is ultimately dictated by the types of information
sharing required for CARTESIUS to perform its function. For CARTESIUS, the critical information
falls into three areas:
• Messages related to the problem state,
• Messages related to strategy- based problem solving, and
• Messages related to problem monitoring.
30
4.1.2.4 CARTESIUS as a TMC Operator’s Tool
From the perspective of the TMC, a CARTESIUS agent should be viewed as a high- level advisory
system that listens to CARTESIUS- related messages and offers operators insights as to
• the state of the transportation system as a whole as it relates to the local jurisdiction,
• the role of a particular agency’s jurisdiction in the performance of that system, and
• the collection of possible mitigation actions, given available resources, that are consistent
with ( do not conflict with) neighboring jurisdictions actions
The advisory role reduces the core operational responsibility of the system, taking it out of the
direct control loop. The CARTESIUS agent’s role as a direct controller of the system would be a
jurisdiction- dependent decision and would require CARTESIUS to become an authenticated client
to existing control subsystems.
In this perspective, the role of the CARTESIUS agent is to offer view of the system from a DPS
perspective. Its role would be to highlight potential conflicts given that perspective and, where
mechanisms have been installed, broker solutions to those conflicts. What this means in a
practical sense is that the entire system need not be re- architected to adopt the DPS view of
traffic management for CARTESIUS to be useful. Furthermore, it would remove significant
burdens from the CARTESIUS prototype to take active management of the system and instead
would offer monitoring, advisory, and post analysis capabilities that leverage the features of the
DPS viewpoint to offer a high- level view of conflicts in the global management of disruptive
events in the transportation system.
This is a reworking of the original CARTESIUS agent’s role, which sought to actively manage
non- recurrent congestion in a jurisdiction from the top down. In place of the former “ heavy-controller”
approach adopted for the original agent, the reimplementation would be a lighter-weight
tool that could more easily interoperate with existing or future systems. The CARTESIUS
approach to monitoring problems could also make the agent useful for evaluating the
performance of various TMC strategies and different levels of inter- jurisdictional coordination
used during incident management.
An additional finding that has arisen in related research into TMC Performance Evaluation
conducted under the Testbed ( Rindt and Recker, 2007) is that the processes used in TMC
31
operations are highly tuned for efficiency and speed. Adding additional software tools to the
TMC processes is challenging because it must be tightly integrated into an already busy process.
Software that fails in this integration is often ignored and therefore fails in its purpose. The
broader lesson of this finding is that attempts to build new interfaces for the TMC are probably
doomed to fail unless they are part of a broader systems engineering effort that involves all
stakeholders from the beginning. Given this finding, the research team decided to de- emphasize
the development of the CARTESIUS GUI in favor of focusing on generating advisory information
that can be integrated into TMC process through proper systems engineering on the time scale
dictated by TMC managers rather than the research process. In short, CARTESIUS was recast as
more of a data- centric product than an interface centric product. We believe this increases the
odds that the system will find its way into deployment in Caltrans operations.
4.2 Leveraging Existing Software: CTNET
Within the context of the prior discussion, the importance of the CARTESIUS/ CTNET integration
becomes clearer. The desire to focus CARTESIUS on tactical management means that CARTESIUS
must be increasingly dependent upon other components of the transportation management
system to provide direct operational control of the traffic system. In the domain of arterial traffic
management systems, Caltrans CTNET software fills this niche very well— providing direct,
two- way access to traffic controllers, including the ability to collect live system detector data and
to alter the timing plans or active timing patterns associated with field masters and the local
controllers they manage.
In this relationship, it’s clear that CARTESIUS must function as a client within the CTNET
client/ server architecture. Otherwise, the functional roles of the components become muddied,
with either CARTESIUS moving into the realm of operational control or CTNET moving up into
tactical and strategy control policies involving portions of the transportation system beyond the
scope of an arterial traffic management subsystem.
4.3 Link Related Modules
Because of its global emphasis, CARTESIUS must interact with traffic management subsystems
beyond CTNET. Because of the capabilities available in the Testbed, the original prototype was
32
more closely integrated with the information and control systems of the Caltrans District 12
TMC. The Testbed’s subsystems provide direct access to the D12 ATMS, which provides
detector data as well as current control settings for changeable message signs and ramp metering
subsystems. This connectivity continued to evolve through during the project, spurred by
parallel efforts to foster better information sharing between Caltrans districts and between
Caltrans and external entities.
Beyond direct measurement of traffic states, CARTESIUS is also dependent upon predictions of
future traffic states. The original prototype used embedded models to obtain these predictions,
but it was always assumed that the targeted research would produce better predictive models that
CARTESIUS could tap as external modules. Indeed, the development of several path- flow
estimators in the Testbed vindicated this assumption, and the new implementation of CARTESIUS
was developed with eventual connectivity to these systems in mind, event though they were not
ready for integration during the course of this project.
33
Chapter 5
CARTESIUS Development
5.1 Overview
This chapter details the design, implementation, and component verification of the CARTESIUS
re- implementation carried out during this project. The design was tailored to satisfy the
requirements for the next- generation of CARTESIUS detailed in the final report of PATH Task
Order 5324 which are summarized in the Appendix and referenced by their labels. FR- prefixes
refer to functional requirements, IR- prefixes refer to user interface requirements, ER- prefixes
refer to external interface requirements, and DR- prefixes refer to database requirements. Unless
otherwise noted, all references to the original version of CARTESIUS refer to the original thesis
describing the work ( Logi, 1999). After describing some of the broad design choices made in the
re- implementation, we detail the design of the various software components that make up the re-implemented
CARTESIUS and discuss how we verified these components meet or do not meet the
specific requirements from TO- 5324.
5.2 Initial Design Choices
The re- implementation process began with the original CARTESIUS source code, which was
exported from the G2 expert system shell ( Gensym, 1995) in which it was originally deployed.
The code was analyzed and mapped into a collection of rough flow charts indicating how the
original CARTESIUS processed input data through its internal algorithms and arrived at a response
strategy. Based upon these charts, we set out to achieve a number of modifications to the code in
order to meet the above collections of requirements.
34
5.2.1 Development platform
Among the early design choices made involved the platform for development. As we noted in
our earlier analyses ( Rindt and McNally, 2008) the original implementation’s use of the G2 shell
tightly integrated user interface objects and underlying code. This commingling of interface
code and core logic hampered maintainability of the system. Furthermore, the per- seat cost of
G2 and related software licenses create a potential barrier to uptake of the system by potential
users. Based upon these factors, we chose to explore development using a general- purpose
programming language that offered platform portability, substantial availability of libraries to
meet the detailed requirements for the system, and general ease of development and
maintainability.
At the time of development, a wide range of potential programming languages, toolkits, and
frameworks were available ranging from low- level general- purpose programming languages like
C and its descendents to high- level scripting languages such as perl. To simplify the choice, the
team used some broad judgments regarding the suitability of various solutions. Generally, these
judgments were made by identifying whether systems similar to CARTESIUS had been developed
using a particular programming language. This reduced the choice set to a C/ C++- based solution
( similar to CTNET), a C# solution using Microsoft’s . NET libraries, a Java solution using the
wide range of available Java libraries, or a Python scripting solution that would interface with
core C++ libraries.
Given these alternatives, we developed a set of needs for the development platform and used
these to score available platform alternatives. First, we considered the portability of the
alternative--- particularly whether the system could easily be moved between Windows- based and
UNIX/ Linux- based systems. The increasing prevalence of Linux- based servers and their
relatively low cost of maintenance increased the importance of portability--- as did the
consideration that the system may one- day be deployed in embedded settings.
Next we considered the relative performance characteristics of the alternatives. CARTESIUS is an
analytical platform that performs heuristic searches of complex problem spaces making
performance an important issue. That being said, the performance criterion was less important as
the existing implementation was able to solve relatively complex search problems using older ( ca
35
Table 5.1 Scores of the CARTESIUS development platform alternatives
Criterion ( weight) C/ C++ C# Java Python
Portability ( 2) 2 0 2 1
Performance ( 0.5) 3 2 2 2
Ease of use ( 1) 1 2 2 1
Libraries ( 2) 2 2 3 1
Composite Score 1.9 1.3 2.4 1.1
1998) hardware and the initial screening described above removed any alternatives that we
deemed too slow.
We also considered how easy the alternative would be to use for development. There are many
factors to consider in this case, including the features of the language, the developer’s familiarity
with it and its associated libraries, and the availability of integrated development environments
( IDEs) that support the language. Ultimately this is a subjective measure, but is important for
determining potential success of the project.
Finally, we considered the availability of libraries for modeling, communications, database
access, and other features. Given the dependence of CARTESIUS on external data, analysis tools,
and its need to interact with other systems, this feature was critically important.
We then scored each alternative for each criterion and developed an average score for each using
weighting specified by the developers as shown in Table 5.1. The resulting choice was a Java-based
solution using available analytical, communications, and database libraries to speed
development. Java’s maven build system also simplifies portability and deployment to diverse
platforms. This combination can be developed using a variety of interchangeable IDEs to
maximize developer flexibility.
36
5.2.2 CARTESIUS as a bundle of services.
The original CARTESIUS was developed in the mid- 1990s, during the early stages of the Internet
and modern middleware technologies. The system relied on a combination of proprietary inter-process
communication ( IPC) and error- prone, low- level socket- based communication to share
data between CARTESIUS agents and external data sources. In the intervening years, a number of
middleware technologies have matured that fit the communications needs of CARTESIUS. These
include general- purpose solutions such as the Common Object Request Broker Architecture
( CORBA) ( Pope, 1997) to various web- based technologies such as the Simple Object Access
Protocol ( SOAP) ( Gudgin et. al., 2007) and XML- RPC ( St. Laurant et. al, 2001).
In analyzing the requirements for CARTESIUS specified by PATH TO 5324 ( A complete listing of
these requirements are reproduced in the Appendix), the design team recognized that CARTESIUS
could be viewed as a loosely coupled bundle of services that each perform specific tasks to
independently operate on data to produce new information that can be used by other services.
This view is consistent with Service- Oriented Architecture ( SOA) design principle. CARTESIUS
fits this model in the sense that the events that drive the need for incident management can be
injected into a chain of processing constructed from a collection of core logic that comprises
CARTESIUS functions. The output from this processing is response recommendations that can be
integrated into incident management processes at the TMC--- either by providing a new operator
interface supplying the guidance, or by integrating the guidance into existing interfaces.
Additionally, the flow- oriented structure of processing imagined for CARTESIUS suggested that
using an Enterprise Service Bus ( ESB) architecture ( Chappel, 2004) might be the best approach
for realizing the system as a SOA. An ESB is a collection of middleware for realizing SOA by
providing message routing and transformation services on top of a general- purpose
communications bus to which multiple data sources ( coming via multiple communications
protocols) and service components can send and/ or receive messages. Very simply, an ESB
simplifies the stitching together of SOA components by providing a means for specifying how
information should flow between them. Designing this type of system focuses on clearly
defining the data to be exchanged, making the processing logic atomic, and specifying the
information flows using the tools of the particular ESB software employed.
37
Table 5.2 Relative merits of ESB platforms for CARTESIUS deployment
Service Mix JBOSS ESB Mule ESB
Features 2 2 3
Ease- of- use 1 2 3
Stability 1 2 2
Support 2 3 3
Composite 1.5 2.25 2.75
In analyzing ESB software alternatives, the team considered a number of alternatives with a bias
toward Java- based solutions given our earlier analysis favoring that language. The most
accessible, free software solutions were Apache Service Mix, JBOSS ESB, and Mule Soft’s
Mule ESB. We scored the relative merits of these systems on features, ease of use, stability, and
the activity of the support community using an equal weighting. The results, shown in Table 5.2
favored the Mule ESB, which provides an excellent and easily configurable feature set along
with good documentation and a vibrant user base offering support.
The Mule ESB offers additional advantages, most notably its use of the Spring Framework
which offers configuration advantages such as Inversion of Control--- in which configuration
settings are used to inject dependencies into the application at runtime making it simple, for
instance, to switch between database implementations.
The choice to structure CARTESIUS as a SOA using an ESB platform structured the design of the
remainder of the system by providing clear guidelines on how to decompose the system into
smaller reusable components that are easier to develop, test, and deploy. The design of the
various components of CARTESIUS is described in detail in Section 5.3.
5.2.3 Database requirements and abstractions
Since Java is a well- known object- oriented programming language, it naturally leads to the use
of object- oriented data abstractions. The development team considered a number of data
abstraction models but settled on the use of the Data Access Object ( DAO) design pattern, which
38
is a foundation of Java development ( Sun Microsystems, 2007). Among the advantages of this
approach are that the core business logic of the application can be insulated from the details of
the data source. Instead of worrying about low- level access details, the logic is coded to an
interface that specifies the type of data that will be made available from some DAO that is
instantiated at run- time and subsequently used to obtain the necessary data during execution.
This not only simplifies development of the core business logic for ESB components, but allows
the system to easily use alternative data sources as they become available by simply creating
implementations of the DAO interface for the new sources.
The domain model for CARTESIUS is, in many ways, very specific to CARTESIUS. The core
objects in the system include:
• A traditional network graph representing the traffic network as a collection of nodes and
links with various attributes detailing their performance characteristics ( number of lanes,
free flow speed, etc.)
• The network as a collection of NetworkObjects for the purposes of problem diagnosis
( discussed later). NetworkObjects are classified into 5 basic types:
o RoadPiece ( a uniform section of roadway)
o Capacity Reduction ( such as a section of roadway with a lane drop)
o Merge ( where two road join into a single facility)
o Diverge ( where two roads split off from a single facility)
o Intersection approach
The network graph is partitioned into a finite set of NetworkObjects where are used in the
event diagnosis process ( discussed later).
• The demand in the system is specified as hourly flows along an enumerated list of paths,
each specified as a list of network links.
• A collection of sensors mapped onto a subset of the network links, which provide
occupancy and speed information for the purposes of estimating the current state of the
system
39
• A collection of traffic control and information devices including traffic signals, ramp
meters, and changeable message signs as well as their various control plans.
These basic objects are used by CARTESIUS to model the transportation system for the purposes
of incident analysis and response. The details of these processes and their implementation
follow in the next section.
5.3 Implementation, and Component Verification
The software requirements for CARTESIUS that were specified in the PATH TO- 5324 final report
( Rindt and McNally, 2008) were organized into a set of atomic software components designed to
operate atomically. Each of these was then designed, implemented, and verified versus the
relevant components as detailed in the next section.
5.3.1 Core functional requirements
The core functional requirements describe how the basic functions of CARTESIUS as an incident
management system should be organized. These requirements broken into 4 major areas whose
relationships are shown in Figure 5.1:
1. Core functional requirements, which spelled out what the core models should do in terms
of traffic analysis and response computations;
2. User interface requirements, which described expectations for how users should interact
with the CARTESIUS system;
3. Database requirements, which described how data related to CARTESIUS operation and
analysis should be stored and maintained; and
4. External interface requirements, which focused on how CARTESIUS should interact with
data sources, other models, and with other CARTESIUS agents.
40
Figure 5.1 Relationships between the different classes of requirements for CARTESIUS
The core functional requirements for the system are further divided into four primary functions
as shown in Figure 5.2. The System Monitoring function is responsible for tracking the state of
the system to identify when disruptions occur that CARTESIUS should attempt to manage. The
Event Analysis function must produce a problem characterization that analytically describes the
disruptions and serves as CARTESIUS’s representation of all the problems in the system. When the
active problem characterization is modified the Problem Response function finds a problem. The
design of the system created distinct software packages for each of these clusters of
requirements. We discuss the designs of each in the following sections.
41
Figure 5.2 The four types of core requirements ( shaded) used in the redesign of
CARTESIUS.
5.3.1.1 System Monitoring
The system monitoring package was developed to perform two sub- functions: state measurement
and state forecasting. The state measurement function provides CARTESIUS with access to state
measurements obtained from field devices or other third party sources ( such as the TMC), while
the state forecasting function provides CARTESIUS with access to estimates of the future state of
the system based upon current and historical data. Since both these measurements and estimates
come from external sources, this requirement was met by defining a set of DAOs specifying the
interface for accessing the necessary system monitoring data. In particular, DAO interfaces were
specified for the following data types.
42
• VDS, VDSStateData: These classes and their associated DAOs provide access to VDS
data collected from sensors in the roadway. In the Testbed, these data are provided by
Caltrans sensors and made available via PeMS and/ or the ATMS FEP data feed. The
VDS class specifies a VDS station and it’s associated metadata ( id, location, lane
geometry, etc) while the VDSStateData class represents volume and occupancy data
collected over some time period ( 30- seconds, 5- minute, 1- hour). The VDSStateData
class can be used to represent raw or processed VDS data as needed. Thus, if the
implementation supports it, the VDSStateData can also provide speed and capacity
estimates for the VDS section.
• IntersectionController, IntersectionControllerState: These classes and their associated
DAOs provide abstract representations of intersection controllers and their associated
states--- including system detector measurements. The ability to adjust timing plans is
currently limited to adjustment of green minimums, maximums, and extensions. This
limitation is driven by the Capabilities of the CARTESIUS logic and can be relaxed as
needed. Note that the CARTESIUS connection to CTNET is provided as an
implementation of the DAO using custom Java libraries described in Chapter 6.
Collectively, the above data types and their DAO implementations satisfy functional
requirements 1 and 2 ( FR 1 and 2) as specified by TO- 5324. State measurements and estimates
can be obtained by accessing available live data streams or databases ( e. g., Testbed databases).
Furthermore, forecasts about future states are available by accessing aggregated historical data
and applying those estimates to determine near- term demands. This satisfies FR 3.
Verification that FRs 1- 3 were met at the component level was achieved by testing using
VDSStateData implementations to Paramics ( via a DAO implementation using Testbed plug- in
described in section 7.2). Similarly, we implemented the IntersectionController DAO using the
JCTNET library and verified its operation using simulation ( see section 6.3.3).
The above inputs provide the necessary data for the monitoring functions, which are carried out
by the Monitor class. The Monitor class provides a checkStatus method to evaluate the current
state of the system. The state is assumed to be constant unless an event triggers the monitor to
run its checkStatus method. The purpose of this method is to determine whether any of the
43
existing events in the system are severe enough to warrant mitigation efforts ( this task is
specified by FR 4). In this implementation, the system uses an Event class to such occurrences:
• Event: An externally specified event that might impact the performance of the
transportation system. Typically this would be mapped to CHP and TMC logs of
incident activity.
Events are passed to the monitor externally via the ESB, which calls the monitor’s checkStatus
method to initiate event processing. A change may be the addition or deletion of an event from
the active event set, or it may be a change in the characteristics of a particular event in that set—
for instance a modification in the expected duration of a lane closure that is input by the operator.
Whenever this happens, the checkStatus method considers all Events by accessing the
EventDAO in addition to the Event passed by the ESB. For each such event, the monitor
determines whether the demand exceeds the estimated capacity of the section following the
original CARTESIUS implementation. If so, the Event is translated into a CARTESIUSEvent using
a transformation class that implements a doTransform method taking an Event object and
returning a CARTESIUSEvent object. The implementation is designed to allow any number of
transformations to be applied to produce the CARTESIUSEvent object. The current
implementation, however, is limited to a single transformer that computes the estimated
reduction in capacity on the basis of the number of lanes closed by the event. No transformer is
currently available for demand- related impacts ( such as special events).
• CARTESIUSEvent: The CARTESIUS representation of a system disruption ( see the Event
data type above) that results in demand/ capacity imbalance or “ significant” deviation
from normal operations in either the demand or the capacity of the system with respect to
historical demand and/ or capacity. A CARTESIUSEvent differs from an Event by
including a list of DemandEffects and/ or CapacityEffects associated with the event.
CARTESIUSEvents are the target of CARTESIUS responses, which seek to reestablish the
balance between demand and capacity by selecting set of control actions.
• CapacityEffect: Effects of this type represent estimated capacity reductions caused by an
event in question ( e. g., due to a lane being closed). They are specified as a network
location ( e. g., a freeway section) and a capacity reduction ( or increase).
44
• DemandEffect: Effects of this type represent estimated demand increases caused by an
event in question ( e. g., due to a special event). They are specified as deviations from
prevailing demands on given paths through the network.
It is possible that an Event has already been observed and processed by the system and that
therefore a CARTESIUSEvent already exists. If so, this instance is modified instead of a new
CARTESIUSEvent instance being created. Note that the translation of the Event into a
CARTESIUSEvent satisfies FR 4, requiring CARTESIUS to estimate the impact of a particular event
on traffic operations, and FR 5, requiring CARTESIUS to implement a function that can identify
the onset of an event in the system--- in this case using the threshold model.
The resulting collection of CARTESIUSEvents is returned from the checkStatus function and
dispatched by the ESB for event analysis. Here, the ESB is used to implement FR 6, that
requires identified events be sent to any components that have requested event notifications.
5.3.1.2 Event Analysis
The event analysis package was developed to update the CARTESIUS problem characterization
based upon analysis of prevailing events. This function is controlled by a top- level Analyzer
class that exposes an analyzeEvents method to the ESB. When the ESB passes an updated set of
events to the analyzer, it carries out event diagnosis using a distinct style of event
characterization. The purpose of the event diagnosis step is to identify the location of event and
what type of event it is, which is later used to select appropriate response strategies. The
location is specified as a critical section, which is basically the facility and a post mile or cross
street where demand exceeds capacity. Following the original implementation, the type of the
event is assumed to fall into one of three classes: an accident, insufficient capacity at a signalized
intersection, or a bottleneck at a freeway on- ramp.
The original CARTESIUS event diagnosis implementation used a frame matching technique to
classify events. While we had some questions about the general portability of the method used,
we determined that modifying the system to use an alternative would require a greater level of
redesign than was warranted for this project. The general procedure in the method is to loop
over all network objects possibly affected by an event ( as specified in the CARTESIUSEvent
instance) and compare them to a given database of general ProblemFrames representing
conditions that would be consistent with particular problem types. The conditions are generally
45
specified as thresholds on sensor data for particular groups of sensors on adjacent facilities.
These groupings are specified a priori as a set of NetworkObjects that represent the system ( see
section ). The purpose of the Frame Matching method is to transform the specific traffic
data observed with a particular problem into one particular qualitative representation from a
finite set of such representations. This allows the response algorithm logic to distill the infinite
state space into a searchable subspace.
5.2.3
We implemented the original frame matching algorithm using Java reflection techniques using
the original implementation as a reference. In this case, a Frame is defined as a collection of
Slots, each of which refers either to attributes with which candidate objects attributes are
compared. Java’s reflection capabilities are used to implement a general algorithm whereby the
attribute names in the ProblemFrame definitions are used to obtain the necessary methods to
access the related data in the candidate object.
The re- implementation used a direct dump of the original CARTESIUS ProblemFrames to generate
the Java source code to recreate them in a compatible format. Details of the knowledge base can
be found in the original CARTESIUS reference. The library of problem frames are structured such
that all events will be matched with a ProblemFrame by including default ProblemFrames
representing cases with unknown causes. In this manner, all events are diagnosed with a cause.
For each event matched with a ProblemFrame representing an imbalance in the system with a
known cause, the algorithm generates a Problem object that includes the type of problem
identified, its cause, and the NetworkObject and critical section affected. The Problem object
also provides problem- specific methods for computing supply- demand changes at the critical
section, which follow the logic of the original CARTESIUS implementation. Events that match to
ProblemFrames without causes are logged for later analysis so that the problem frame database
can be improved. These features satisfy FR 7- 11 from the requirements. They were verified by
using a test dataset designed to match with all ProblemFrames in the library, which confirmed
that the library classified all cases it was presented with, including outliers. The problem
diagnosis algorithm does not currently consider spillback effects from neighboring jurisdictions
and therefore does NOT satisfy FR 12.
Because CARTESIUS assumes that Problems in the system may be related, a given set of Problems
are collectively represented by a ProblemDescription object that represents the “ global” problem
46
that CARTESIUS must seek to mitigate through response options. If the state of any of the sub-problems
changes, the corresponding global ProblemDescription must change accordingly.
5.3.1.3 Event Response
The event response function is designed to be triggered by the ESB when a new
ProblemDescription is produced. The event response is focused on formulating local response
sets from available control actions and collaborating with other agents to develop a consistent
global strategy with non- conflicting actions across jurisdictions.
5.3.2 User Interface Requirements
During the course of development, a decision was made to drop the development GUI interface
in favor of designing CARTESIUS to run as a service that offers recommendations based upon a
set of pre- defined configurations dictated default responses that would normally have been
required by the operator. This approach is intended to focus on the delivery of information
rather than to initiate control actions, and is consistent with the philosophical shift discussed in
section 4.1.2.4 of making CARTESIUS a data- centric product rather than an interface centric one.
As a result all interface requirements ( IR 2- 17) were deferred for later development except for IR
1, which required that core analytical functions be separated from the GUI. This requirement
was met in the transition to a data- centric system. This will ease the later integration of
CARTESIUS products into existing and new TMC processes.
5.3.3 External Interface Requirements
5.3.3.1 Distributed Problem Solving Interfaces
The challenges in re- implementing CARTESIUS as a deployable system were most evident in the
implementation of the distributed problem solving interface. The promise of the original
implementation and its theoretical underpinnings remain. However, the details of practical
implementation proved beyond the scope of the current project. The reasons for this are varied
but center on translating the original implementation, which was hardcoded to interface two
CARTESIUS agents into a prototype, into a general purpose implementation that can share data
across N agents. The constraints of this project made pursuing this general purpose goal
unrealistic.
47
As a result, the re- implementation was designed as a single agent system, with hooks to allow for
the later incorporation of a multi- agent information. Thus, requirements ER 1- 4 were not met by
this re- implementation. It is notable that this development mimics that of the original CARTESIUS
implementation, which began as a single agent system and was later extended for multi- agent
purposes.
5.3.3.2 External Data Interfaces
The specific data required by CARTESIUS from these subsystems is described by the core
functional requirements. They include data from:
• Event/ incident notification systems
• Measurement subsystems
o Current flow, occupancy, and possibly speeds
• Control subsystems
o Traffic signals
o Ramp meters
o CMSs
The ability to receive events regarding disruptions to the system from external sources was
implemented by creating customized transformers to translate event data from the CHP CAD
feed and/ or the District 12 Activity Logs into Event objects that are placed on the ESB to trigger
action by the CARTESIUS monitor described in section 5.3.1.1. This functionality satisfies
requirements ER 5- 7 and was verified using data from both the live CHP CAD XML feed and
D12 activity log data pushed from a postgresql database to the ESB. Both sources and their
associated transformers were able to trigger event notifications that activated the monitor and
generated CARTESIUSEvents objects that drove further processing.
The requirements specify that CARTESIUS be able to obtain current demand estimates from an
external model. The project team had hoped that the Testbed’s path flow estimator would be
available for their purpose, but this software was not available on time. Instead, the system was
structured to use DAO to obtain demand estimates from static sources pushed to the database.
This approach effectively deferred the integration of the demand model to a later date. The
48
default implementation is to use the results of a regional planning model or the demand inputs to
a site- specific traffic microsimulation model to obtain demand estimates ( this is the approach
taken in the evaluation described in Chapter 8.) The result is that the system has a limited
implementation of requirements ER 13- 15. Since there is no live demand model, the ability to
request a new demand estimate was not included so ER 16 was not satisfied.
Like the demand requirements, CARTESIUS needs capacity estimates to drive its core models.
The original implementation used commonly accepted engineering factors to estimate capacities
on the basis of facility type, number of lanes, and prevailing conditions. The requirements for
the re- implementation suggested that more data- driven capacity estimates might be obtained
from external models but the re- implementation current relies upon the same internal estimates
of the original. As a result, ER 17 was not satisfied.
Similarly, the idea that intersection capacities might be highly depended upon external control
systems led to a suggested requirement that the CARTESIUS be structured to query those systems
for capacity estimates. At the time of development, however, no systems capable of providing
such estimates existed so the re- implementation used the original CARTESIUS approach of
estimating intersection capacities using Akcelic’s intersection delay model. Thus, ER 18 was not
satisfied.
Finally, the CARTESIUS is general enough that is can access historical data about prevailing
system performance, demand, and events as easily as it can access current data. The system is
not currently making use of this capability, but the capacity exists and thus ER- 19 is partially
satisfied.
5.3.3.3 Logical Database Requirements
As noted earlier, the core CARTESIUS algorithms were designed to the DAO design pattern to
shield the implementation from later changes in the back- end data sources. Development and
testing of the system was performed using a Postgresql database backend ( Postgresql Global
Development Group, 2008). Postgresql is one of the leading open source relational database
management systems. Postgresql is known for its speed with complex data structures and also
boasts a spatial extension that implements advanced geographical information system ( GIS)
functionality within the database. The developers experience with Postgresql and its broad
acceptance in the industry was used to justify its use for CARTESIUS.
49
Software access to the database from CARTESIUS and other components of the ESB were coded
using the Hibernate Relational Persistence system for Java ( King, 2004). Hibernate offers a
well- support system for object- relational mapping whereby storage of software objects to various
backend database systems is configured automatically from plain Java source code. The
Hibernate system greatly simplifies object persistence by handling the bulk of transactional
issues that typically would have to be coded by hand. Hibernate also natural integrates with
Spring and the Mule ESB and is generally the de facto standard for object persistence when
using these systems.
The combined use of the off- the- shelf database and persistence tools coupled with the data
models specified in the above sections allow for complete persistence of all data and activity
carried out by CARTESIUS. As such, all database requirements from TO- 5324 ( DR 1- 8) have
been met in the reimplementation
5.3.4 Security, Compatibility, and Reliability
For security, CARTESIUS relies on the Spring security features that come bundled with the Mule
ESB. Spring security provides the ability to require:
• user authentication for any access to live system data.,
• layered security using a role- based system that limits access to sensitive data or control
functions to sub classes of users, and
• full logging of all actions taken to support security auditing.
The re- implementation, however, is not backward compatible with the original CARTESIUS
version. Providing such backward compatibility would have significantly limited the re- design
to legacy technologies. Given that CARTESIUS has no current deployments, maintaining such
compatibility did not seem necessary.
5.4 Verification and Validation of Integrated System
We integrated the complete CARTESIUS system, consisting of the components described above,
using the Mule ESB for message transformation and routing. The resulting system is driven by
event and sensor data passed from any sources for which connectors to the ESB have been
50
created. The results of processing are sent to any destinations that have connected to the ESB
and requested the results. The current implementation of the integrated system has only been
validated using simulation connected to the ESB and CTNET. The details of this validation are
the subject of Chapter 8. Prior to considering those issues, however, we first discuss how
CTNET was connected to the CARTESIUS system and then how the simulation- based evaluation
environment was developed.
51
Chapter 6
Accessing CTNET
6.1 Background
The integration strategy outlined in Chapter 4 requires that CARTESIUS be capable of acting as a
client to CTNET. Because CTNET development proceeds independently from that of
CARTESIUS, the project team made a design decision to not alter CTNET and instead to have
CARTESIUS act as a CTNET client to interact with the traffic signal subsystem. To achieve this,
we needed a new communications library for CARTESIUS that could communicate directly with
CTNET using its own communications APIs. Because CARTESIUS was developed in Java, this
meant we needed Java libraries that implemented the core CTNET protocols. These libraries
were, in turn, used to develop specific Data Access Object ( DAO) implementations in
CARTESIUS to allow it and its upstream data providers to access traffic signal data from CTNET.
The following sections discuss the design of these libraries.
6.2 Jab3418e
As discussed in section 2.4, CTNET uses an extended version of the AB3418 standard protocol
for communication with field elements, which are forwarded to CTNET clients when they are
connected. We developed the Java AB3418e library ( Jab3418e) to allow Java applications in
general and CARTESIUS in particular to send and receive these messages. The two use- cases for
the library were ( 1) to allow CARTESIUS to interact with the CTNET CommServer to receive
AB3418e messages and ( 2) to allow simulation developers to implement the AB3418e protocol
to create simulated field devices with which CTNET can communicate. Note that these use cases
did not require the ability to send and receive messages over serial connections, as is required in
the original specification. This is because the library will only be used over TCP/ IP connections.
Modifying