Freeway Performance Measurement System ( PeMS), PeMS 7.0:
Final Report for CCIT TO 20
Pravin Varaiya
University of California, Berkeley CA 94720
Department of Electrical Engineering and Computer Science
Tel: ( 510) 642- 5270, Fax: ( 510) 643- 2356
varaiya@ eecs. berkeley. edu
March 27, 2007
Executive summary
Under development and operation since 1999, PeMS now is the de facto repository for all
Caltrans fixed- location detector data. The system is used to investigate everything from
the characteristics of individual loop detectors to highly aggregated performance trends
across Caltrans districts. PeMS usage has grown continuously and it now supports 3000-
4000 reports per day ( plots, tables, etc). It distributes data to 55 registered Value Added
Resellers, 20 of which actively retrieve real- time data.
PeMS is located on the U. C. Berkeley campus. During the past few months, a copy of
PeMS has been installed at Caltrans. Caltrans is currently determining the steps to
transition that instance of PeMS to active service. Once it goes live, Caltrans PeMS will
be a 24×7 production facility. UCB PeMS will then become a platform for developing
new algorithms and features.
The PeMS 7.0 effort completed six tasks.
1. Maintain Development Prototype
This task was to maintain and support the current version of the PeMS system which is
running at UC Berkeley.
2. Replace Obsolete Disks on Original Server
The PeMS system has been in deployment since 1998. Some of the original disks that
were purchased then were still in production use – well past the industry recommended
lifetime of 5 years. We’ve replaced all of these with newer, cheaper disks.
3. Detailed Maintenance Screens and Training Development
This task involved developing screens to assist maintenance personnel by creating web
pages that are tailored to their needs. During the course of this project this task was
substituted for support on the installation of PeMS inside of Caltrans. We detail the steps
taken below.
4. Enhanced Diagnostic Screens
This task was to implement two specific diagnostic features: 1) roll up the current
diagnostics and apply them to the controllers and communication lines and 2) associate a
measure with each detector and then allow users to sort the broken detectors according to
this measure.
2
5. Enhanced Freeway Configuration
With this task we added the ability to identify freeway locations in the state that have
reversible directions. This information isn’t included in the configuration files that we
receive from Caltrans and had to be coded by hand.
6. Time of Data and HOV Lanes
In this task we extended PeMS to be able to list the locations where there are time- of- day
HOV lanes. Previously we could only list locations where the detectors in the HOV
locations are identified in the district- supplied configuration files. We’ve now folded in
the HOV information from Caltrans HQ and we display that on various web pages. This
includes locations that are time- of- day- based HOV facilities.
7. Configure and Monitor Freeway Segments
Since PeMS 6 we’ve had the ability to predefine freeway segments and to compute
performance measures on them. With this task we’ve defined a number of additional
segments in other districts and placed them on the dashboards.
8. Enhance Map User Interface
The PeMS map has traditionally used simple dots to represent the measured quantities at
each location. But other visualization techniques are possible. The enhancement that we
did for this task is to represent the measured quantities by coloring the freeway instead of
just drawing dots. We now provide users with the option of viewing the data on the maps
in this manner.
9. Development of a Decision Support Tool for TMS Action Plan
The TMS Action Plan proposes a variety of operational improvement strategies. The
objective of this task was to investigate the development of PeMS- based tools to specify
such strategies, quickly evaluate the resulting benefits and develop a detection plan to
implement and monitor the strategies. The research led to the proposal of TOPL— Tools
for Operations Planning.
Introduction
PeMS 7.0 is the latest of eight task orders devoted to research, development, and
maintenance of the PeMS system ( there was one mid- year task order, PeMS 6.5).
PeMS collects, processes, stores, and makes available online data from nine Caltrans
districts ( D3- 8, 10- 12). The data are obtained from 23,871 loops1, grouped into 9,306
vehicle detector stations ( VDS). These loops cover 3,495 out of 30,572 directional- miles
of interstate and state highways in California.
We now describe the accomplishments under the nine tasks that constitute the PeMS 7.0
project.
Task 1 Maintain Development Prototype
The PeMS system has grown over the years in many dimensions. The number of
machines that are participating in the data collection and processing as well as providing
1 Some of these ‘ loops’ are microwave radar detectors that act like loops.
3
a platform for researchers to access the data has grown. The security requirements for
these machines have been strengthened for the current deployment environment. The
number of data feeds has expanded to nine district detector feeds, one CHP incident feed,
and one batch TASAS accident feed. The level of interaction with the districts has
increased as we’ve socialized the need to actively supply current configurations to PeMS.
Concomitant with the increase in the size and complexity of PeMS has been the increased
amount of administration activity required to keep it running. This task was to provide
all of the necessary support to keep PeMS running at UCB as well as supporting the use
of PeMS inside of Caltrans. This involved the following types of support and activities:
1. Networking support. This includes all aspects of networking, including within the
PeMS instance, between the PeMS instance and the Caltrans districts, and
between the PeMS instance and the outside world ( i. e.: users on the Internet).
Typical tasks include troubleshooting loss of connectivity to a district, assessing
performance issues on the LAN, and working with the Caltrans WAN team when
configuring new data feeds.
2. Operating system support. This covers the Solaris operating system on the
machines running in the PeMS instance. Typical tasks include upgrading and
patching the operating system as needed. Checking for security issues. Resolving
bugs with Sun when they arise.
3. Database support. This covers the Oracle database on the data warehouse server
inside of the PeMS instance as well as the client libraries on the other servers in
the PeMS instance. In a manner similar to the operating system, this involves
upgrading and patching as necessary. But it also involves managing all of the
database objects for growth including backing up the data.
4. 3rd party application support. These are applications that are used by PeMS.
From time- to- time we need to upgrade these to leverage different features or to
fix bugs that we can’t program around.
5. PeMS application support. These are the programs that comprise PeMS itself.
These include daemons that run continuously collecting the data as well as
periodic jobs that process and aggregate the data. This is involves monitoring
these processes and restarting them when they are wedged. It also involves
upgrading the application in response to new feature deployments as well as
troubleshooting and fixing bugs.
6. PeMS data support. This includes all of the operational details related to keeping
PeMS running in Caltrans. This category of support deals with the relationship
between PeMS and the configuration and data from the districts ( in other words,
this is not the administration of the processes themselves but the interpretation of
the data).
All of this was provided during the course of the year to support the research and
development effort at UC Berkeley.
Task 2 Replace Obsolete Disks on Original Server
This task was to upgrade the disks being used by certain PeMS applications. PeMS has
been in deployment since 1998. We’ve bought disks each year to expand the amount of
4
storage available as the system has grown. The initial set of disks that were purchased at
the start of the project are now quite old and were well past their expected lifetime. As a
result, we were in a rather dangerous position of having to operate on old disks that are
no longer made. Finding replacements is difficult. In this task we wanted to replace
these disks with the new disks as well as switch to the new enterprise storage paradigm in
the industry which is SAN- based storage.
A SAN, or storage array network, is a network that is attached to a collection of storage
devices and servers. A SAN allows for quite a bit of flexibility in terms of deploying
storage. It allows for the logical association of storage devices with servers without
changing the physical topology. There is no need to move cables – everything is done in
software on the servers. The new equipment that was added with this project is the SAN
switches and the disk storage devices. We have two SAN switches in our fabric for
redundancy. Each server is connected to each SAN switch and each storage device is
also connected to each SAN switch. Hence if any single switch or link fails there is a
redundant path from each server to each storage device. This is the typical configuration
for high availability applications.
In Figure 1 we provide a snapshot of the resulting PeMS network and disk storage
devices. Note that in addition to the new SAN disks we have a few non- SAN disk arrays
that were purchased recently ( in the last two years). We haven’t replaced those and we’re
still using them. In the figure below these are connected to the machines via SCSI links.
5
UCB Network ( 128.32.48/ 32)
184 Soda Hall
PeMS Private LAN ( 172.16.53/ 32)
Caltrans
Wide Area Network
( WAN)
Main database
( pemsdb, V880)
SunFire V240
SAN Fabric Sun
2 x Qlogic 5200
SCSI Ultra320
Disk Arrays
Two from pemsdb,
Two from transacct
( 9x181GB),
7.0TB raw
FC Disk Arrays
Two current ( 14x146GB),
Three new ( 14x300GB),
One new ( 14x146GB)
18.7TB raw
Old Direct Attach
Storage Links
Ultra320 SCSI
Web frontend
( pems, Linux)
Cisco 1721
Internet and
PeMS Users
PeMS SAN
T1 Line
McBasic Media Converters
SunFire V240
Sun
Raw data collection
( pemdc, X4200)
Figure 1. New PeMS deployment topology including SAN, new disks and new data collection server.
In the above figure the detector data flows to PeMS from the districts over the Caltrans
WAN via a point- to- point link which is terminated at our Cisco 1721 router that sits in
Soda Hall. The data is transferred ( transparently to all of the applications) over a fiber
link to the machine pemsdc. The machine pemsdc and the rest of the PeMS equipment
all reside in Cory Hall. The data is stored in a raw database that is managed by pemsdc.
The data is then aggregated and stored in a database managed by pemsdb, the main data
warehouse server for PeMS. The storage for both of these databases is contained on the
disks that are attached to the SAN.
The project to replace the old disks involved not only purchasing the SAN switches, but
also purchasing the SAN disk arrays. These are labeled in the above figure as FC Disk
Arrays. As we mentioned, these have been configured and are now in use storing the raw
and aggregated PeMS data.
6
Task 3 Detailed Maintenance Screens and Training Development
This original task was a series of steps intended to help the district personnel use PeMS to
maintain their sensor networks. This included meeting with district personnel in order to
determine the gaps in PeMS as well as to develop training material to guide them through
the current features. In the time between when this task was proposed and when the
project actually started two developments took place. First, a formal PeMS training
project was undertaken through CCIT. The training covered many aspects of PeMS,
including general navigation, performance measurements, corridor analysis, census
computations, system configuration and detector diagnostics. These training courses
encompassed all of the aspects that we were proposing to teach as part of this task.
Hence it didn’t quite make sense to develop an additional training class. Second,
Caltrans was able to proceed with its deployment of PeMS inside of Caltrans. This
required quite a bit more assistance than what was generally expected. Hence it was
decided that we would substitute the originally proposed task with providing assistance
during the installation of PeMS at Caltrans.
The installation of PeMS at Caltrans involved us performing the following tasks:
• Software Installation
o Install all PeMS software.
o Install all third party software packages required by PeMS.
o Install Oracle database.
• Configuration
o Configure Oracle database.
o Create Oracle database objects to hold PeMS schema.
o Configure PeMS software for installation.
o Setup streaming server for Photolog files.
o Debug the LAN networking environment so that the machines could talk
to each other.
o Assist in debugging the WAN networking environment so that the districts
could talk to PeMS.
• Data
o Export detector data from UCB version of PeMS
o Transfer detector data to Caltrans version of PeMS
o Assist in the loading of the data at Caltrans
o Copy user accounts from UCB system to Caltrans system
o Export and transfer detector configurations to Caltrans
o Export and transfer TASAS and CHP incidents to Caltrans
• Initiate Processes
o Start running the data collectors.
o Start running the PeMS data aggregators.
o Start the PeMS web application.
o Configure and start the monitoring system.
7
This installation process was stretched out over many months and involved interacting
with many Caltrans personnel. It finally culminated in a fully operational system at
Caltrans. In addition to the above tasks, we also provided a training course for the
Caltrans personnel that are going to take over the system administration of the Caltrans
PeMS system.
Task 4 Enhanced Diagnostic Screens
This task had two parts. The first part was to aggregate the diagnostics along the physical
data collection path so that we can assign failure modes more intelligently. The
canonical data collection infrastructure is given below in Figure 2.
District Traffic Management Center ( TMC)
Data
distribution
process
Front End Processor ( FEP)
170/ 2070
170/ 2070
Modem
170/ 2070
170/ 2070
Modem
Database
Display
...
170/ 2070
170/ 2070
Figure 2. Canonical data collection infrastructure.
The data from the field starts at the individual detectors on the freeway. From there it is
collected by a controller along the side of the road. The controller communicates back to
the TMC, typically, in Caltrans, along a fixed, leased telephone line. The line is typically
a shared among many controllers in the field. In some districts this communication is
done via wireless modems. In almost all cases, there is a “ line” that’s associated with the
controller, whether it’s logical or physical. Finally the data from the controllers is
aggregated in the Front End Processor ( FEP) and then sent downstream to PeMS.
8
The PeMS diagnostic approach has always been to assign failure modes to the individual
loop detectors. When PeMS receives data samples it can test the samples for
reasonableness and deduce a number of different types of errors. But when PeMS
receives no data samples it’s not possible to tell if the detector itself is bad. For example,
it could be that we aren’t receiving any data samples from any detector simply because
the FEP is down. For situations like this we mark the detector as bad with a reason of
communication down. But in reality this failure category has always been a catch- all
category that simply represents that we didn’t receive any data samples.
It turns out that we can do better than this if we know the physical data collection
infrastructure. By physical data collection infrastructure we mean knowing which
detectors are connected to which controllers, and which controllers are connected over
which lines to the FEP. For example, if we know that all of the detectors that are
connected to a single controller are not sending any data samples, in other words, we’re
not receiving any data from the controller, then it’s likely that the controller itself is
broken. For example there could be no power at the controller, or it could have been
damaged in an accident ( or removed during construction). In a similar manner, if we’re
not receiving any data from any of the controllers on a line then it’s likely that the line
itself is bad rather than every controller is bad.
For this task we implemented this new assignment scheme. Essentially this scheme is
simply breaking down the old communications down category into three new categories,
as illustrated in Figure 3 below.
Figure 3. Standard district diagnostic page with new diagnostic categories of Line Down, Ctlr Down,
and No Data.
9
There are a number of locations in PeMS where we’ve reflected this change. Figure 3
above is the first. That web page is the summary diagnostic web page for a district. It
shows at the top two pie charts that indicate the percentage of detectors that are good
versus bad on the left, and the breakdown of the suspected causes on the right. The table
below the pie charts shows the detector health grouped by freeway and direction. As we
mentioned above, we’ve taken out the column according to communications down and
we’ve substituted in the columns of controller down, line down and no data. If we don’t
receive any samples from a line then the line is considered to be down and all of the
detectors on the line are marked as line down. If we receive samples from some
controllers on a line but not others then the controllers are considered to be down and the
loops belonging to those controllers are marked as controller down. And if we receive
samples from some detectors but not others for a single controller then the non- reporting
detectors are considered to be down but not the controller and are marked as no data. It
should be pointed out that we’re assuming that the line and/ or the controller is the
problem if we don’t receive data samples from the detectors underneath them. But it
could be that all of the individual loops are broken ( we consider this to be unlikely,
though).
The locations where this scheme doesn’t work are the districts where we don’t have the
physical topology of the data collection infrastructure, or the data collection infrastructure
is just a star. District 4 doesn’t provide us with their data collection infrastructure and
District 10 has only wireless modems that are sending data back to a centralized point. In
the D10 case the rollup algorithm still works but the results are blank for the line level.
There are two other ways that we represent this diagnostic information about lines and
controllers. The first is on the Comm tab at the district- wide detector health section of
PeMS. A sample of this table is given below.
Figure 4. Table showing the % of expected samples for each communication line.
This table is showing the listing of communication lines and drops for a district. A drop
corresponds to a single controller. In each cell we give the percentage of data samples
received from the controller during the course of the day. We also color code them with
red being zero samples received and green being 100% of the data samples received. We
10
refer to this type of encoding as a Heat Chart. This display gives a quick overview of the
status all of the lines – it’s easy to pick out which lines are completely down by simply
looking at the summary column on the right. But this display isn’t that good if you’re
trying to get a list of controllers to go fix. If you hover your mouse over one of the cells
there’s a little tooltip window that pops up showing you the controller ID. Hence if you
wanted to construct a list of controllers to fix you’d have to hover your mouse over each
red cell and then write down by hand the broken controller ID. To avoid this tedium we
developed another table which is essentially just a listing of the results given in the Heat
Chart. This table is called the Line Detail table and an example is given below.
Figure 5. New table that clearly shows which controllers are not reporting samples.
Figure 5 shows a screen shot of the table in PeMS that provides a line- by- line listing of
each controller and the number of samples that it’s reported over the course of the day.
With this table the user can export it to excel and then sort by the % of Expected column
to get a concise list of the controller that aren’t working.
The second part of this task was a small project to prioritize the detectors that need to be
fixed. We did this on a district- by- district basis in a relatively straightforward way as
shown in the figure below.
11
Figure 6. Table for D3 showing priority ordered list of detectors to fix.
In Figure 6 we give a sorted list of detectors to fix in a district. The criterion for
determining which detectors have the highest priority is based on two factors. First, we
determine how many days the detector has been down over the last two weeks. We call
this the Reliability Score. Second, we compute the density of surrounding detectors that
are working ( including the ones at the current location but in adjacent lanes). We call
this the Working Neighbor Score. For both of these scores, a high value is good and a
low value is bad. We then take these values and subtract them from 100. The result is
the Total Severity Score which is used to order the detectors in the district. The thought
behind these two numbers is that it makes sense to first fix detectors that have been down
for a while that don’t have any working neighbors. Detectors that have working
neighbors can be compensated for in the imputation algorithms. Isolated detectors can’t.
Task 5 Enhanced Freeway Configurations
PeMS receives configurations indicating where the detectors are located on the freeway
from the districts. In some districts these come in the form of a dump of a few of the
12
Oracle tables from the ATMS application. In other districts they come in a custom
format that pre- existed the integration with PeMS ( D4) or was developed specifically to
communicate the configuration to PeMS ( D10). In all cases, the configuration consists of
the list of data collection devices on the freeway and the metadata about them. The
metadata includes things like freeway- direction- postmile, the type of roadway the sensor
is covering ( mainline versus ramps) and which controllers are connected to which
individual loops.
Unfortunately, none of the metadata descriptions are rich enough to describe more
complex situations. Specifically, none of the metadata schemas have the structure to
support the description of any freeways where there is a reversible lane. For example, on
the Golden Gate Bridge just north of San Francisco the center lane switches from
southbound to northbound during the course of the day in response to daily commute
patterns. There are currently four locations around the state that have reversible facilities
like this: two in northern California, on SR101 and SR24, and two in southern California,
on I5 and US75. Since some of these facilities have detectors on them it’s confusing to
not be able to represent which direction of travel they belong to. This is something that
we wanted to represent in PeMS.
Our first proposed solution was to have the metadata schemas in each district expanded
so that they could capture the description of the reversible lanes accurately. It turned out
that approach was infeasible. As an alternative, for this task we encoded the different
sections by hand and incorporated them into the PeMS schema. The figure below shows
one of the locations where we display the results.
Figure 7. Table showing reversible facilities for the entire state.
Figure 7 shows the list of reversible freeways in the entire state. You can see that we
have a listing for each freeway and direction that’s affected. We provide the metadata
that we typed in by hand giving the postmile range as well as the description. We
provide this table at the state- wide level inside of PeMS. In addition to this type of listing
we also show the results in a few other places. On the freeway level we typically show
the list of detectors and freeway crossings by direction. For the reversible facilities we
13
provide an abbreviated listing showing the detectors that fall within the boundaries of the
reversible section. The figure below provides an example in D11 on I15.
Figure 8. Table showing the detectors that lie on a reversible facility.
In the above figure the table shows the list of detectors that lie on the reversible facility.
In this example we’re looking at I15- N in District 11. The freeway has two detectors on
the reversible freeway facility. To see the details of when the freeway actually reverses
the user needs to click on the station ID to jump to the station configuration page. On
that page we provide the details of the standard schedule of when the traffic shifts from
one direction to the other ( we should point out that we only have the standard schedules
of when the lanes switch direction. If there is ever a special event that causes the lanes to
switch outside of their special schedule we don’t have a facility for recording that).
Task 6 Time of Data HOV Lanes
In a similar manner to the reversible facilities, the HOV metadata that PeMS receives
from the districts wasn’t rich enough to properly capture all of the details. The
information provided in the configurations said one of two things with respect to HOV
facilities. It either said that the detector is on an HOV- only facility, which implied that it
was HOV 24- hours a day, or it said nothing ( i. e.: it gave no indication that there is an
HOV facility at this location). This resulted in a lot of the details of the HOV lanes being
left out of the PeMS interface. For example, a number of HOV facilities in northern
California operate by time of day. The typical pattern is for lane 1 to switch from being a
general purpose lane to an HOV- only lane during the morning or afternoon commute
hours. For example, on I80- W during the afternoon commute hours lane 1 is an HOV
lane from 3pm until 7pm. This information was not encoded in the metadata that we
received from the districts about the detector configurations.
In this task we wanted to encode all of the HOV information throughout the state and to
present it in PeMS in a uniform manner. To do this we received the ground truth of the
list of HOV lanes from Caltrans HQ. This information is stored in a spreadsheet that is
managed by hand. We encoded this spreadsheet into a schema that was able to represent
all of the different types of HOV cases ( different time of day and day of week variations,
different occupancy requirements, etc.). This information is now presented to the user in
14
a variety of different formats. The first format is the district- wide listing of HOV
facilities, as shown below.
Figure 9. Table showing HOV facilities for all freeways in D11.
Figure 9 shows a district- wide listing of all of the HOV facilities. This follows the
standard PeMS paradigm where the information is broken down by freeway and
direction. We provide the headquarters- supplied description and the day of week and
time of day hours of operation. In addition we indicate if there are any occupancy
requirements on the facility or if it’s only for busses. This type of table can be pulled up
for any district or for the entire state. A second type of display is given below.
15
Figure 10. Table showing which detectors are HOV detectors on 210E in D7.
Figure 10 shows the HOV facilities on a single freeway. This particular example is for
I210- E in District 7. This table typically shows all of the detectors and freeway crossings
for a freeway. In this example, for clarity, we’ve restricted it to just show the HOV and
mainline detectors and to not display the freeway crossing streets. You can see in the
middle of the table the column HOV which says either NO, which means it’s not an HOV
detector, or 24H, which means it’s a 24 hour facility. The other option, which isn’t
displayed here, is for the detector to be a time- of- day- based HOV detector, in which case
it’s labeled TOD.
There are a number of potential follow- up projects that we can perform in the area of
HOV reporting and metadata management. For example, some districts mark their HOV
lanes as 24- hour facilities in the configuration that they send to us but they are actually
only time- of- day- based facilities ( the schema that they are using simply isn’t rich enough
to express this). In order to properly decide which source of information to use requires
an additional layer of control in PeMS which would need to be added. In a similar vein,
the current HQ method of storing the HOV information in a spreadsheet isn’t conducive
to programmatic parsing and is susceptible to typographical errors. In addition, it’s
almost impossible to update PeMS based on changes in the spreadsheet. These problems
could all potentially be fixed by providing an interface in PeMS through which
headquarters personnel could manage the HOV information for the entire state ( this
would have the added benefit of providing another way of verifying that the
configurations provided by the districts conform to what headquarters believes is on the
freeway system). Finally, there are a number of reports that we could generate now that
we’ve encoded the HOV information. For example we could provide reports that track
the HOV lane usage versus the mainline lanes during the commute hours over time to see
if they are being utilized or not.
16
Task 7 Configure and Monitor Freeway Segments
In PeMS 6 we added the ability to predefine segments of the freeway system. A segment
is a route through the freeway system from a particular origin to a destination. For
example, it can be a route typically taken by morning commuters from a particular
suburb, like from Walnut Creek on 24W to 580W to 80W to downtown San Francisco.
When a segment is defined PeMS starst computing a number of spatial performance
measures for it. These include delay, VMT, VHT and travel time. The computation of
these performance measures is done in real- time for each 5- minute interval and the
results are stored and rolled up for use in future web queries ( this is why they need to be
predefined instead of done on the fly).
We initially folded in the segment feature for a project that was done with SANDAG. In
that project we defined and created a number of segments in the Caltrans D11 region.
For this task we defined and created a number of segments for each district in Caltrans
and we “ turned the crank” in order to compute the performance measures for these
segments for all of the data available for each district.
We display the results in a number of ways. First, for each segment we provide the
standard timeseries plots showing the various quantities over time, versus time of day and
day of week. Second, we list the segments available for each district in two places.
There is a canonical list of all of the segments for each district which is just a table
showing segment definitions. Third, we also show statistics about the segments on each
District’s dashboard. The dashboards show a number of high- level statistics about the
traffic in the district over different timescales. On these dashboards we provide statistics
about the travel time for a few of the segments as illustrated below.
17
Figure 11. Typical district dashboard. List of some predefined routes are on the bottom row.
Figure 11 is one of the dashboards for District 7 which shows some historical ( long- term)
statistics for the AM travel period ( 5am- 10am). The page is organized into three rows of
information. On the bottom row we have eight predefined segments ( referred to here as
routes). For each segment we give the travel time for the route leaving at 8am on
weekdays during the previous month as well as the previous month and a year ago. We
also track the change in the average travel time between those two months. Finally, we
give statistics of the variability of the travel time for the two months and the change
between them. Each of the colored numbers is a link that allows the user to drill down to
the standard timeseries plots of travel time and variability for the segment.
Task 8 Enhance Map User Interface
In this task we wanted to enhance the PeMS maps to make them easier for users to get a
qualitative feel for the conditions on the freeway system. The original PeMS maps
displayed the quantities from the detectors as dots. There was one dot per VDS and its
color was determined by the quantity that the user selected via the widget area. A better
way of illustrating conditions on the roadway is by coloring the freeway itself. In this
18
task we folded in the option on each map to display the requested quantities as lines
instead of dots.
The figures above illustrate the results. On the left is the new map drawn with lines and
on the right is the old map draw with dots. As we mentioned above, we now let users
view the map either way.
In performing this task we needed to solve a number of small technical challenges. The
largest we encountered was one of representation. The data from the field is from point
locations. The detectors in the lanes on the freeway are recording the flow and
occupancies from the vehicles passing over them during the most recent time period.
Representing these measured quantities as dots is fine because it closely represents how
the values were obtained. But drawing lines on a map is a representation across space. It
gives the illusion when we’re showing speed, for example, that we know the speed at
every point along the freeway. From a mathematical consistency point of view this isn’t
a problem for PeMS because we’re already making the assumption that the speeds are
known and constant across a freeway segment when performing spatial measures. It’s
only a problem for representation purposes – lay persons can easily get confused when
looking at a map where the speeds are drawn as lines.
As far as technical problems, we needed to determine how much freeway to cover with
each sensor measurement and how to select the colors in between sensors. Since we’re
stretching out the value from a single point along the freeway we need to decide how far
we are willing to stretch it before deciding to stop. All of this is done programmatically
and hence the decision reduces to the appropriate choice of thresholds. We picked a
threshold of two miles at the end points and 1 mile in between sensors. The D3 map
above gives a few nice examples of the result of this particular tradeoff. For example, on
I- 5 south of Sacramento there is a section freeway without detectors. The separation of
sensors on this section of road is just past the threshold for connecting them with lines.
19
In addition to representing the sensor measurements as colors on lines, we also let the
users modulate the width of the line with a second quantity. For example a user can
choose to color the line with the measured VMT and size the line with the measured
delay, as pictured below.
Figure 12. Sizing and coloring the lines with two different quantities.
In the above figure the red lines represent areas with a high VMT and the thick lines
represent areas where the average spatial speed is low. Hence the red, thick locations are
where there is a lot of traffic moving slowly.
Task 9 Development of a Decision Support Tool for TMS Action Plan
The Governor’s Strategic Growth Plan calls for a 50% reduction in the projected
congestion in 2025. A large fraction of this reduction will be achieved by short- term
operational improvement strategies, including ramp metering, incident management,
traveler information and demand management.
The objective of this task was to determine the feasibility of a decision support tool to be
used to specify these operational strategies, to rapidly evaluate the resulting benefits, and
20
to develop a detection plan for supporting and monitoring the implementation of these
operational strategies.
The outcome of this research is the formulation of a proposal for developing such a tool,
called TOPL— Tools for Operations Planning. At the core of TOPL is a macro-simulation
of a corridor that can be readily calibrated and validated using data from
PeMS and optimization routines for the design of strategies. TOPL has received initial
funding. The first version of TOPL has been tested for I- 210, and the results are very
promising.
Figure 13. The Strategic Growth Plan projects a 50% reduction in congestion. TOPL will help
achieve this goal through the specification and benefit evaluation of operational improvements.
Conclusion
The collection of work items with this project reflect a number of operational tasks and
feature requests that came up during the course of the year. By quickly implementing
these we are able to keep PeMS up to the standards expected by Caltrans.
Acknowledgements
The research summarized here is the joint effort of the PeMS Development Group,
especially Alexander Skabardonis and Pravin Varaiya of U. C. Berkeley; Jaimyoung
Kwon of CSU East Bay; and the development team at BTS. We have benefited greatly
from the advice, interest and guidance of Fred Dial and John Wolf of Caltrans, Division
of Traffic Operations, and Tarek Hatata of System Metrics Group.
Where TOPL
21
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 of or policy of the California Department of Transportation.
This report does not constitute a standard, specification or regulation.