A
Research Project Report
For
the National ITS Implementation Research Center
A U.S. DOT University Transportation Center
CAPITAL WIRELESS INTEGRATED NETWORK (CapWIN)
Principal Investigators:
WT Scherer
Marc. H. Evans
Capital Wireless Integrated
Network (CapWIN)
UNIVERSITY
OF VIRGINIA
Center
for Transportation Studies
Smart
Travel Laboratory
WT Scherer
Associate Professor
Department of Systems and Information
Engineering
School of Engineering and Applied
Science
University of Virginia
151 Engineer's Way
P.O. Box 400747
Charlottesville, VA 22904-4747
(434) 982-2069 (direct)
(434) 924-5393 (department)
(434) 982-2972 (fax)
wts@virginia.edu
Marc. H. Evans
Transportation Systems Engineer
Smart Travel Lab
Department of Civil Engineering
University of Virginia
Charlottesville, VA 22904
Telephone: (434) 293-1992
Fax: (434) 982-2972
E-mail: marcevans@virginia.edu
A
Research Project Report for the ITS Implementation Center
Center for Transportation Studies at the University of Virginia produces outstanding transportation professionals, innovative research results and provides important public service. The Center for Transportation Studies is committed to academic excellence, multi-disciplinary research and to developing state-of-the-art facilities. Through a partnership with the Virginia Department of Transportation’s (VDOT) Research Council (VTRC), CTS faculty hold joint appointments, VTRC research scientists teach specialized courses, and graduate student work is supported through a Graduate Research Assistantship Program. CTS receives substantial financial support from two federal University Transportation Center Grants: the Mid-Atlantic Universities Transportation Center (MAUTC), and through the National ITS Implementation Research Center (ITS Center). Other related research activities of the faculty include funding through FHWA, NSF, US Department of Transportation, VDOT, other governmental agencies and private companies.
Disclaimer: The contents of this report reflect the views of
the authors, who are responsible for the facts and the accuracy of the information
presented herein. This document is disseminated
under the sponsorship of the Department of Transportation, University Transportation
Centers Program, in the interest of information exchange.
The U.S. Government assumes no liability for the contents or use thereof.
Abstract: This report
documents the efforts of the University of Virginia’s Smart Travel Laboratory
(UVA-STL) in a synergistic sponsored program between the ITS Implementation Center
and the National Institute of Justice for developing mechanisms to provide the
Capital Wireless Integrated Network (CapWIN) participants with meaningful system
awareness through unique applications of data fusion and visualization of the
state their metropolitan public service wide area network. For our research purposes,
the public service network information of interest were the arterial and freeway
traffic flow, and the mechanisms for which we sought to provide information assurance
monitoring included the still theoretical (though simulated) combined technological
components and participants of the Capital Wireless Integrated Network. We describe the overall concept and present
the elements of the system and a sample walk through the system.
I. UVA and CapWIN Prototype Systems
Introduction
By the later half of the 20th century, technological
advances and regional growth led to the establishment of networks to assist in
the monitoring and management of select aspects of social activity within civil
society. This was especially so for within
major metropolitan centers with some level of resource and technological sophistication.
The reasons for this are diverse, however, it is plausible to assume that
one of the reasons included public services seeking to squeeze additional safety
and performance out of their systems without a significant increase in cost. Most of these monitoring and management networks
were designed to monitor and manage a specific public service capability – public
utilities and public safety, developed computer aided dispatch systems to coordinate
response to public needs regarding either physical infrastructure failure or criminal
activities; transportation services developed varying degrees of the transportation
management center to coordinate and assist in the improved movement of people,
goods, and services across the extensive physical transportation networks.
While there were improvements in the operations of these public services,
civic life and national and international affairs demanded more.
The internetworking activities of the U.S. national
defense establishment began to influence internetworking design outside of the
defense domain. Public services began
to perceive that additional potential benefits were possible by internetworking
their monitoring and management networks. This
internetworking continues presently with numerous designs, ranging from simply
the co-location of personnel representatives of various public services in one
facility, to the other extreme of no physical co-location, but rather the technological
integration of existing public service monitoring and management networks to exchange
critical information between operating entities.
The former, that of co-location, resembles early information integration
efforts on the part of the world’s Navies in the combat information center (CIC)
developed during World War II on warships. These
CICs afforded the commander of the vessel to allow different functions of the
ship, or fleet, to combine status information in one place – representatives from
other ships, engineering, various classes of intelligence, navigation, etc., would
all assist in the development of one common picture of the situation, to afford
better planning and response of the ships’/fleets’ (entities’) in performing a
operation – the CIC proved so effective that it became standard practice on warships.
Similarly, in the civic world, public service co-location has proven an
effective means of achieving common situation development and response.
The aforementioned later development, that of technological integration,
is more rare, but appears to be developing where regional complexities are so
significant that physical co-location would prove simply too difficult. One such example is developing in the metropolitan
region of Washington, DC. This region
maintains numerous public service entities including national government level,
three state-level entities, and local-level governments, and each of these maintains
some level of capability to regional public service activity.
For this instance, common co-location for everyday purposes would prove
physically and politically too challenging and costly, therefore, a technological
solution has been sought to integrate the regional public service that wish to
participate – the new technology is now under development and deployment. This new service is the Capital Wireless Integrated
Network (CapWIN).
CapWIN
The intent of CapWIN is to afford participating regional
public service entities the ability to manage their own networks while being able
to access information from other entities. The access to the new information, combined with their own, is believed
to afford an increased awareness of their own management domain relative, and
associated, to the other participating, multi-domain public service networks.
CapWIN focuses on providing regional entities from the public safety, fire,
emergency medical service (EMS), and transportation domains restricted and prioritized
access into each other’s respective information networks.
Key to the system’s continuing development has been to understand what
information existed where, and who wants what information. Initial, pre-deployment, studies demonstrated
that the ‘on-the-ground,’ and center manager, users could be voracious consumers
of information – the list of information wants was extensive, it ranged from knowing
the relative positions of patrolling units, their status, class, etc., to knowing
the weather at a very specific location, and to knowing, given a HAZMAT release,
the plume dispersement, etc.[1]
However, as development continued, it became necessary for CapWIN to prioritize
information exchange based on immediate increases in knowledge – immediate potential
benefits for participating services – focusing on assisting in day-to-day operations.
These initial common critical information elements that each public service
network aspired to share with each other included the following:
Incident Detection and Response
– …information regarding regional incidents…[w]hether this information came from
another transportation agency or a public safety agency, it mattered not; knowing
information about regional incidents would allow transportation center managers
to utilize their systems more effectively.
Resource Utilization Request – Direct/indirect control by responding operational units to an
incident of another regional participating agency’s resources…For example, a popular
feature would be public safety’s interest in requesting, and acquiring, limited
control of transportation’s CCTVs in tactical vicinity to managed incidents –
or even to supplement or replace the need for physical verification of a roadway
incident, as police operations require.
Traffic Flow/Transportation Network Status – … the ability for units to see the status of the transportation network and eventually to identify/map optimal route to incident. Public safety determined that being able to ‘see’ transportations’ system status maps on their system level maps, and their mobile units’ maps, could improve their response time and resource allocation effectiveness.
Emergency/Regional Highest
Priority Event – Regional information regarding extreme, rare,
unique regional transportation or public safety events such as extremely hazardous
material release, terrorist event, missing child, escaped felon, universal health
precautions, etc. was not something that became readily apparent.
High risk and low frequency events, and associated information, could now
been ‘seen’ as rapidly and efficiently disseminated to regional public services
simply by showing that a network existed connecting all levels.
Equipment Deployed and Participating
Agency Capabilities and Status – officers must document in fatal or serious
injury investigations what fire/EMS units/equipment was on scene. Ability to retrieve information regarding what
stations, units, vehicles, equipment, and personnel were on scene would be useful.
Participating Agency Capabilities
and Status – universal access (given operational
security requirements) to identify the location, status, and control protocol
of participating agencies assets (Maryland police requiring and requesting control
of Virginia assets, such as a VDOT CCTV or mobile variable message signs).[2]
Much of these have remained in the forefront of CapWIN’s
technological development; some of which are already accessible by participants
in a limited fashion. Incident detection
and response, emergency/regional highest priority event were the items that have
been first to be deployed in early systems – it immediately addressed the inquiry
as to what was the other public service entity dealing with at this moment; how
might their activities impact my own and vice versa.
Too, this kind of information has proven simple enough to translate across
an electronic medium in textual format. Differing
somewhat, application, or distribution of traffic flow/transportation network
status has proven more difficult and therefore has not yet been deployed within
their system. This has not been due to
a lack of availability of that type of information, rather, the trade-off CapWIN
has confronted between perceived immediate value of relative system state (for
example, incident notification) vs. presentation of that information through limited
resources (technologically – bandwidth, presentation medium, processor power).
As such, presenting traffic flow information remains a priority to participating
CapWIN research entities such as the Smart Travel Laboratory.
The Smart Travel Laboratory and CapWIN
In its role as the transportation research participant
and representative at CapWIN, the University of Virginia’s Smart Travel Laboratory
(UVA-STL) has had a unique opportunity to devise and experiment with network monitoring
tools that may assist CapWIN in realizing improved decision-making and therefore
improved efficiencies across interconnected public service networks.
The objective of the UVA-STL’s
CapWIN research program is to improve the effectiveness of the CapWIN system as
it matures. To meet this objective, the
STL conducts applied research projects and provides technical assistance that
capitalizes on its established reputation as a leader in transportation management
and information technology research. It is the goal of the STL research program to develop tools and
knowledge that assists CapWIN participants in making full use of the capabilities
and data provided by the system. Key activities
for UVA-STL relating to CapWIN:
Incident Management – A key contribution of transportation
management centers to CapWIN is data describing current and past incidents and
traffic conditions. However, during large-scale
regional incidents, forecasted information is presently unavailable.
The UVA STL research team is investigating models and techniques to provide
near term forecasts of traffic conditions and incident probability by location.
Visualization – A key challenge of CapWIN
as it matures will be to present the wealth of data made available by the system
in a usable manner to participants. The
UVA STL research team is investigating new techniques and technologies to address
this challenge – turning the data into information that will improve decision-making.
Information Assurance – As CapWIN becomes a part
of regional operations, the quality and availability of data in the CapWIN system
will be increasingly important. The UVA
STL research team is investigating approaches to test the quality of transportation
data provided to CapWIN, and, when necessary, developing means to estimate missing
values. Furthermore, the team is investigating
novel security monitoring approaches to assess the security of the multi-agency/network
system that CapWIN comprises.
System Development and Deployment
Support – The UVA STL research team provides direct technical support to CapWIN
by reviewing technical documents, providing feedback on interim CapWIN builds,
and participating on CapWIN committees. In particular, the team provides insight on key transportation-related
functions of CapWIN.[3]
Key initial UVA-STL developments for CapWIN
There have been two developments early on in UVA-STL’s
work for CapWIN that have driven follow-on work associated with more advanced
tools and visualizations. These early
works include UVA-STL’s CapWIN system development and deployment support work
with the International Association of Chiefs of Police (IACP) in developing the
CapWIN User Needs Assessment, and the visualization and incident management research
involved with the initial versions of the UVA-STL CapWIN Incident Management Tool
Prototypes. These two efforts lay the groundwork for what would later evolve
into state-based monitoring of select CapWIN information exchanges.
The User Needs Assessment, mentioned earlier in the introduction, identified who had what information and who wanted what relative to the CapWIN participants’ needs in a system designed to share information between public service networks. Information identified within the document was categorized as “critical information sharing elements” that were either common to all domain participants, or unique to one particular domain, such as transportation, fire, EMS, or public safety. Those elements that were commonly requested, related to transportation, and were identified as critical early deployments, were outlined earlier. The document was later utilized by the UVA-STL as a primary resource when developing the CapWIN Incident Management Tool Prototype – it was this prototype that initiated the interest in research concepts involving the monitoring of public service networks.
The earliest versions of the Incident Management Tool prototypes focused on the development of a non, or semi-functional, computer interface that would seek to allow a CapWIN public service network manager to increase their regional situational awareness by seamlessly incorporating and presenting information from their own, and external, associated public service networks; to improve their efficiency and effectiveness in monitoring and managing an incident. The tool was intended to provide complete "state" information of the whole region to allow managers (from any participating agency) to make better strategic decisions. However, given that the UVA-STL’s role with CapWIN – that of a research entity dedicated to supporting CapWIN with a transportation perspective – emphasis was initially given to the Transportation domain in viewing information from their own collection networks, as well as the new information provided from the CapWIN network. For the prototype, the following information was considered to be integrated and presented:
Highway, Arterial, and Local Road Network
– The most basic and fundamental information element to transportation system
visualization is that of the geographical position of roadway network to be managed.
For this reason, in the PC-view (platform specific), for transportation
specialists (domain specific), the roadways – highways, arterials, and local access
roads – will exist as the underlying view, upon which, next to which, all other
information is related and over-laid. The
roads themselves will be color-coded, and labeled, according to the MUTCD and
CapWIN participant transportation agency schema (e.g. interstates are red and
enlarged, etc.). The primary background,
the field around the roads shall be initially displayed in a subdued shade or
color (black) but shall be user definable and alterable as functions and scenarios
require. As the roads are the primary
system, initially nothing else should detract from them. When the highway and arterial roadway network
overlay is active and selected, a functional option for the user shall be to view
the status of those roads (due to data acquisition limitations, the select northern
Virginia highways and arterials) through their current usage as defined as a combination
of volume, occupancy, and speed. These are displayed from green to red and relative
to the roadway’s characteristics. For
example, if a given highway is green, it means that the speed, occupancy, and
volume sensed on that highway are in a favorable condition relative to that roadway’s
limitations (capacity and speed limit); if the roadway is displayed as green,
there is no congestion.
Jurisdictional Boundaries – Several levels governmental
and agency specific jurisdiction/responsibility shall be displayed. Federal, State,
County, City, Agency responsibility areas (VDOT districts, VSP patrol regions,
etc.) will have the opportunity of being overlaid above the roadway network as
either, or both, with text labels and shaded/dashed lines and/or shaded/colored
regions. One possible feature of this static information element that may
be made more dynamic, at the tactical incident level, is the representation of
cross-jurisdictional, incident-scenario specific, legally binding, shifting of
agency responsibility. Such an example
would be an auto incident on a bridge between two legal jurisdictions; although
the incident may physically exist on the Maryland side, practically has necessitated
that Virginia agencies respond to the crisis (eastbound traffic).
Therefore, though the jurisdictional boundaries may be static for the most
part, there may be a specific situation when the system will need to identify
and thus visually represent an incident in one jurisdiction (where it has occurred
situationally/legally) vs. another (where it has occurred geographically).
Incidents – The incident overlay will place CapWIN identified,
roadway-based, incidents in position relative to the existing roadway.
The icons will attempt to represent the following: incident type, location,
status, who is on-scene (by agency and by unit), who is responding and what is
their status (by agency and by unit), whose jurisdiction and responsibility, available
routes to scene, danger areas at scene (HAZMAT, WMD (NBC), bomb threat, sniper,
etc.), number and type of vehicles involved (incident and non-incident), road
closures (macro) and lane blockages (micro), number [and description] of persons
involved, number and type of injuries (use standardized injury notification protocol),
what agencies have been notified, what steps have been taken already, what resources
are still needed, and protocols for incident handling.
CapWIN Agency Specific Assets – CapWIN participating agencies shall have their mobile
and non-mobile assets and their associated characteristics recorded and displayable
as overlays. These include Public Safety,
Fire, EMS, and Transportation entities from the participating States, Counties,
Cities, and other agencies. For example,
Arlington County Police stations will be positioned according to their relationship
to the roadways. CapWIN participating agencies’ mobile units shall also be displayed.
The dynamicism per agency per unit will vary according to that unit’s use
of GIS/AVL update or verbal update; that is, a unit with GIS/AVL will be able
to automatically update the CapWIN system regarding its status, speed, type, etc.,
versus, a unit without such technology will follow its legacy system/method in
updating the responsible agency as to its status, speed, etc.
In either case, CapWIN units associated with a given incident will be displayed;
only their consistent movement across the map will vary.
The display of individual units will incorporate, at the basic level, the
MUTCD symbology.
HAZMAT Routes: Another
static overlaid representation atop the roadway network shall the National, State(s),
and District identified HAZMAT routes. The identified HAZMAT routes shall be highlighted/outlined
along the select roads with the USDOT color scheme for HAZMAT materials, as well
as place sign identifiers along the route per the HAZMAT route symbols.
Weather – ‘Near-real-time’ regional Doppler radar information
from the National Weather Service (NWS) shall be an optional overlay.
Topographical – Regional terrain slopes and features, such as rivers
and lakes, from the USGS shall be an optional overlay.
Critical Infrastructure – Regional infrastructure
designated as critical by the National Critical Infrastructure Protection Center
(major power, communication, and pipe lines) shall be identified and provided
as an overlay.
Sun – A representation of the sun, that follows an arch, and displays the sun’s relative path/position to the roadway network, shall be an overlay.
Organizational groupings – A frame presenting ‘Windows-like’ organizational groupings shall display that day’s events, incidents, units, etc.
Time-bar – A ‘time-bar frame’ shall display incident associated
temporal characteristics, such as incident begin and estimated end times as well
as associated unit on-scene, en-route, and estimated departure times.
Text – A frame to display the low-level details of every
unique feature, such as incidents and units, shall be provided.
Imagery – A pop-up frame containing streaming or individual picture imagery from imagery capable units shall be displayed.
Application of state-based monitoring to potential CapWIN activities
The development of the CapWIN Incident Management Tool
(IMT) Prototype led both to new questions and concepts for visualization and analysis
refinements. One critical question that
developed considered the trust of the user in what was being presented.
The disparate public service networks providing the now conceptually seamless
picture was not telling the whole story to operators who commonly operated their
own stove -piped networks. Now, with the new information seamlessly pooled
into one common view, they would conceivably be unable to discern what information
was from a system they knew (trusted) and what was not. Though, in the long run, this should not necessarily
an issue for the user, rather for the administrator – especially as trust evolves;
in the near term it remains an issue for network administrators and center managers
both for cultural and for technical administration purposes.
Since the center managers, or the CapWIN network administrator, are viewing
a seamless status picture of the physical network, they ought to be able to view
a status picture of the virtual network.
This drove the development of a Security Monitoring
Tool (SMT) to assist the users and managers in the ascertainment of the health
of the information provided them via their network of networks – providing some
level of assurance of the information presented regarding the networks that provide
information on the management of the physical world. At the core of the SMT is a process that calculates
the aggregate security state of the overall network. This state-based approach to understanding
a complex system, along with earlier research in applying state-based assessments
of transportation systems[4],
then led to the refinement of traffic flow analysis and visualization within the
IMT.
A quick note on state-based systems – The SMT, and the refinements
to the IMT, rely on the determination of the state of the aggregate system and
its individual components. Once the state
determination has been made, it is presented for decision support.
The estimation of the state of the system is derived from the state-based
modeling concept.
State-based models attempt to capture how a system
transitions from one state to another, in response to a defined action or actions.
In this approach, an objective function is defined that represents a valuation
of the actual or expected changes to the system's state.
For example, an objective function commonly used in transportation is delay,
measured in vehicle-hours, which is a function of the system's state.[5]
In the case of traffic data and the refinements of
the IMT, the system’s ‘state’ refers to the of volume and speed data collected
from individual inductive loop detectors at a specific point in a roadway. The most recent response from a detector is
compared with relative historical responses from the same detector, and the deviation
from the average response becomes the state of that detector – of traffic flow
at that location. More realistic, complicated,
and intended-to-be-integrated objective functions in such a context will include
comparing that detector’s recent response to previous responses that are situationally
and environmentally similar, utilizing an advanced ‘nearest neighbor’ analysis
technique. In this sense, the detector’s current response
will be compared to its earlier responses that are similar in time of day, day
of week, day of month, season, holiday or not, incident and construction and weather
conditions, etc. The aggregate picture
would be a present a realistic and relative state of how the transportation network
is performing now as compared to similar past conditions/situations – a unique
capability for emergency responders and incident managers.
Thus, the objective for state-based function is focused in on a very small
and singular point, and with enough of these points analyzed in the same fashion,
a powerful decision support tool develops.
In the case of the SMT, the situation is more complex.
The objective for the first version of the SMT was the status, or state,
of the network of networks. This process will be described later in greater
detail, but it requires an analysis of both the individual system’s/network’s
and the aggregate system’s state. Included within this function are security procedures, connectivity,
and subjective valuation of the importance of the system to the operation of regional
activities. The second version of the
SMT views conditions, or the state, of select individual probes, and in that sense,
it is less complex and more akin to the IMT objective function outlined above
– as an aggregate picture of the individual systems will provide a decision support
tool.
Displaying roadway traffic flow information – The participating CapWIN
public service agencies that manage traffic for the metropolitan Washington, DC
are the Intelligent Transportation System Traffic Management Centers (TMC).
While there are a variety of types of these within the metro-DC region,
for the most part, they perform very similar functions and collect very similar
data. This data may be converted into traffic flow information. From a CapWIN vantage point, this has proven
one of the most sought after information items by the CapWIN participants beyond
the transportation domain. While highly
sought, such information has proven difficult to convey across a limited bandwidth
system to a recipient with limited processing power, as it is often best to display
in a map-like format. The visual presentation
of traffic flow characteristics, traffic volume and average traffic speed along
a given segment of road, have often been presented as a color coded linear representation
of a given segment of road that changes color according to the changes in speed
or volume; with the color red often representing high volumes, and green often
representing high average speeds. In early
versions of the aforementioned IMT, this was the case – taken at a regional level
it allowed the user to gain an implied state of the roadway network. Other efforts have taken a more decidedly traffic
engineering note and have presented a color-coded schema as being linked to a
roads’ Level of Service (LoS). State Departments
of Transportation (DoT) have assigned certain traffic volumes along select classes
of roadway as being linked to various levels of service, often listed as A, B,
C, D, and F – ‘A’ being the best case (along this class of roadway, this low volume of traffic would
provide an excellent level of service) and ‘F’ the worse (along this class
of roadway, this high volume of traffic would provide a poor level of service).
From a State DoT point of view, this is highly useful.
However, for the purposes of a system dedicated to regional emergencies,
neither previous example is sufficient.
Based on the premise that the CapWIN user has some
historically-based knowledge about regional traffic conditions along given segments
of road given certain times of day and weather conditions, it was sought to provide
the user with a view of ‘how bad is it really’ along a given segment of road;
how does the current traffic condition compare to the average for this same segment
of road, for the previous same day and time. Therefore, the presented roadway
flow along a selected segment was color coded, blue, green, yellow, and red, each
representing a standard deviation from the norm from either average traffic speed
or traffic volume. Blue suggesting that flow conditions where much better than the
norm (light traffic), green suggesting that flow is considered normal, and the
extreme, red, suggesting conditions were quite far from the norm. While it was an immediate goal to simply demonstrate
this capability, looking at the state of that segment of road with previous calendar
days and time, the long-term intention is to incorporate ‘nearest neighbor’ analysis
to establish a more realistic norm for comparison – for example, looking at previous
Monday’s traffic along said segment of road with similar regional traffic incident
and weather conditions, also, whether it was considered a holiday or not.
Before integrating such a concept directly into the
IMT, stand-alone functional visualizations were developed that utilized real near-real-time
(NRT) and archived traffic flow data as collected by the University of Virginia’s
Smart Travel Lab. The lab, for traffic
flow data archival purposes, maintains a direct connection into the Virginia Department
of Transportation’s Northern Virginia Smart Traffic Center (STC), which manages
freeway traffic in that region, and the Smart Traffic Signal System (STSS), which
manages roughly 1000 different intersections in the same region.
While two separate visualizations were developed, one utilizing java and
one, scalable vector graphics (svg) technologies, both rely on the same data-query
and algorithm program to develop a state-based determination the state-based visualization.
The system works thusly: A program then reads in the file and calculates
the standard deviation, average speed, and average volume for every freeway segment.
This calculation is done for every minute of every day of the past year. The calculation works by taking the current minute, and using the
same day, same time of the past year for data points. Averages and standard deviations for each minute are recorded.
It is only necessary to do this once because all the information is then
stored in a permanent database. A base
SVG (Scalable Vector Graphics) map is then created with the shape files of each
segment. The shape file for each freeway segment is
created externally to this program. This
is done using the recorded detector ids for that segment, and a shape file manipulation
program like Arc Map. This SVG file will
be the base map that is manipulated by the java program.
The java program then retrieves the current data for each segment from
the database, as well as the standard deviations and averages of each segment
from the database that was previously created.
The color of each road is then determined by how far the current average
of each freeway segment deviates from the values recorded for the past year. A new SVG file is then created, which contains the updated color
for each road segment based on the current time and the color for each segment
based on time up to one hour into the past. This
is done the same way the current time data is calculated. The color for each segment based on time up
to on hour into the future – this is done by using a linear regression equation.
The data points for this equation are the same day and same time for the
past seven weeks. Finally, the newly created SVG file is then
sent to the website, where the user can manipulate what data to display.
Additionally, our effort utilized the scalable vector
graphic (svg) format for improved web-based presentation efficiency and security
purposes. This standard afforded our group the opportunity to push a spatially
(metropolitan Washington, DC) and temporally (past, present, and forecasted future
status) rich document beyond our firewalls for web-based presentation and interactivity.
While these images may hold potential use for those
interested in the management of traffic, incidents, and the civic life of a metropolitan
region, they do not address the aspects of information availability and trustworthiness;
that will be accomplished utilizing the following tool.
Displaying a security state – assisting information
assurance
– Whether it is presenting information on traffic flow or on regional events,
the user-participant of CapWIN requires an understanding of the ‘health’ of the
information being presented: how old is it; how truly representational is it;
has it been jeopardized in some fashion; can one trust in it? This is especially the case of the managers
of the primary participating networks and of CapWIN central office. The nature of CapWIN is such that presented
public service network data will be derived from a multitude of sources, determining
the well-being of these sources individually, and as an aggregate, can be quite
challenging, yet may be a necessity in assuring the overall use of the system
by its participants. Therefore, the efforts
of the STL have focused on developing frameworks and prototype systems – applications
– to provide insight into such managers into the health of the overall system.
Thus far, this has been accomplished by developing two state-based monitoring
frameworks and applications – two versions of the Security Monitoring Tool.
Security Monitoring Tool (SMT) v 1 – version one, a
concept outlined in a conference paper to the First Annual Symposium on Intelligence
and Informatics by NSF/NIJ, sought to address the issue of the disparate security
states of the various, to-be-integrated, CapWIN legacy systems – key providers
of information for the public services of the metro-DC region.
[In SMT v.1] the primary concept
is to develop a systemic view of the integrated system, a view that may not be
visible from any one system or sub-group of systems. “Mixed use” network models
involve combining different networks into a single paradigm and describing the
nature of such integrated systems (Ghosh, 2002; Schmuacher,1997). This follows
CapWIN’s structure of disparate public/private, public safety/transportation networks.
Security administrators of networks, especially of a mixed-use network,
must consider the potential threats (or risks) against a network, assess the likelihood
of such events, and alleviate any risks. This system’s goal is to perform a comparative security evaluation
across multiple networks, with the initial focus on detection of events in the
system based on the status of individual networks. Such a system is essential
given that “these changing threats have caused a shift in the network security
paradigm from one of certification to one of risk assessment”[6]
The STL developed the following, four part, conceptual
model for such SMT v.1:
- Obtainment of Security Data – Either/or both connectivity and security
state are obtained though CapWIN action (ping and/or security into request) or
by CapWIN participant action (provision of a security vector regarding their state,
such as, with each represented by an integer “no detected events”, “suspicious
activities”, or “known to be under attack.”
- Standardization of the Data – Provisioned, or ping, security data
will then be normalized for intra-network comparison. This involves integrating the Near-Real-Time
(NRT) security response (current status) with the previously determined severity
(level of potential risk involved), exposure (level of security practiced).
This, now normalized, security vector will serve as the current security
status for a given agency, will afford a fair comparison to other agencies, and
will serve as a component in the determination of the overall security status
of the aggregate system.
- Calculation of Overall System Score – Individual scores for each
agency are multiplied by their system weight – an integer representing their importance
to regional operability, a subjective value that may be determined later given
the nature of the super-systems’ operational mission (CapWIN) – and they are then
added together to provide the overall security score for the aggregate system.
It is this score that may be used by the administration in the determination
of actions to be taken to assure the continuance of their operations.
- Structure of Web-based Interface – The visualization of the individual
and aggregate scores. Available interactive
views include a time series graph with the system scores; the map view shows the
geographical DC region and plot the CapWIN participants; coloring them a color
associated with their status.
While nearly every component of version 1’s concept
was developed into a functional prototype application, the most substantative
portion of the system – that of evaluating and standardizing each and every participating
CapWIN agency’s info-security systems and methods – proved practically beyond
the capability of the STL. However, it
is believed that this is within the capabilities of CapWIN’s organization to perform
such a task. For the prototype application
to function, in lieu of collecting actual security state data responses from each
participating and providing agency, only the simple ‘ping’ mechanism was utilized
to test components.
SMT v 2 – While the first version sought to provide
the CapWIN administrators an idea of the state of their overall network, with
specific regards to the legacy systems – the ‘back end,’ the v.1 design did little
to provide any information regarding the users – the ‘front end.’ Users act as both requesters of information
and providers of information. In this
regard, that of providing information, they are hardly different from their legacy
system information provider counterparts. Thus, conceptually expanding the SMT v.1 concept to look toward
the other end of the CapWIN network might prove efficacious in affording system-wide
awareness to the administrators. However,
the nature of the connections, as well as the systems, are very different – this
‘front end’ environment is dominated by disparate wireless communications internetworking
a wide variety of interfaces (computers, etc.); security states of the individual
systems may become inordinately complex in determination.
Instead of focusing on the security state, or even on the immediate connectivity
of the individual participating wireless user systems, CapWIN administrators expressed
the desire to know the state of CapWIN wireless community connectivity – to facilitate
connection issue resolution between the users and the telecommunication service
providers.
In the SMT v.2 concept, several GPS and java enabled
cellular phones operating on the same wireless telecommunications networks as
CapWIN users, will serve as service probes deposited with CapWIN participating
mobile units. For this concept, in the
basic system outlying mobile units send fundamental information to a SMT central
server database where it is stored and related. This information includes connection strength,
latitude and longitude, estimated spatial error, speed, spatial location method
(triangulation or GPS), and unique vehicle/unit identifier.
This identifier then relates captured data with other spatial and non-spatial
characteristics, including state, county, city/town, and its current ISP provider. Unfortunately, ISP providers do not provide
any information on the location of their towers since they are not required to
register with the FCC. Since this is the
case, it becomes near impossible to use database analysis to find the location
of the malfunctioning tower. However,
GPS may still be used to designate outage areas where connections are lost, or
even a gradient showing the strength of connections in certain areas.
Considering the range of cell towers in certain areas, it is possible to
define a default radius representing tower outage around a probe whose connection
has just been lost. As the closest probe to this center moves closer
within this area, while still maintaining a connection, the outage area’s radius
decreases. The GPS system may also record
information on speed and traffic, and store this information in a database for
other types of analysis.
The follow-on integration of these two concepts and
their early prototypes will be accomplished in the next phase of this development
– the establishment of the SMT v 3 – and will be addressed briefly in the next
section.
Refinements and new directions for CapWIN
Additional refinements and capabilities will be added
to assist in CapWIN participant decision-making, these include:
For the Incident Management Tool
-
.svg
development work will continue
-
State-based
visualizations of roadway traffic average speed and volume will be expanded to
include Maryland State Highway Administration (MDSHA) freeway flow data, VDOT
NOVA STSS arterial roadway flow data
-
Incident
data from NOVA STC, CapWIN, and MDSHA will be made available for overlay
o
Archived/NRT/Forecasted
incident data will be linked with time-space so as to afford the user to select
what space, and what period in time
o
Forecasted
incidents will be based on an existing incident, and its forecasted duration
o
A
new overlay depicting a probability of a given type of incident given certain
features such as traffic flow, other incidents, positioning of public service
units, and weather
-
Improvement
of non-graphical data presentation, for example, a textual-table stating ‘I-66
W between Exit A and Exit B is worse than normal’ will be added
-
Incorporation
of trafficland.com CCTV images
-
Application
visualizations will be made available to CapWIN administration and select users
– their usage activities will be tracked to determine when, where, and under what
circumstances they utilize the visualizations
-
Association
with the SMT – as SMT v.3 is developed, a linkage will be made between the two,
such that, for example, when the IMT user is engaged in normal IMT usage, the
user will be able to move the cursor over any object (such as a freeway) to find
SMT and IMT information, “I-66 W between Exit A and Exit B, volume normal, average
speed normal, VDOT NOVA STC security state normal; data quality good.”
For the Security Monitoring Tool
-
SMT
v.1 and v.2 will be integrated to form SMT v.3
-
SMT
v.2 will acquire additional probes for testing and will develop of simulated probes
for additional experimentation
-
SMT
v.3 will be made available at CapWIN and integrated with select systems for testing
-
Association
with the IMT – when a user is engaging in normal SMT usage, they may select a
particular agency and view the state of the associated physical network they manage,
for example, the user may be examining the security state of the VDOT NOVA STC
and another screen will be made available to show the extent and the state of
that physical network
Possibilities for Public Service Networks
What might all of this imply? Will the new visualizations improve the awareness
and operations of operators within, and/or without, the domains from which data
has been provided? Will combing the tools
– integrating infrastructure and information management – yield improved awareness
and operations? The research the STL is
performing with CapWIN will aspire to provide answers to some of these questions.
The U.S. military has spent billions of dollars on
improving battlespace situational awareness for their soldiers and their commanders;
over the past 50 years, this seems to have dramatically changed their effectiveness
given certain circumstances – though much of this has occurred over the past 10
years, and due to interconnectivity – pooling of information resources.
It seems reasonable to assert that similar benefits, may be found within
the public service domain that manages our civic life – though, there may be significant
monetary differences between military integration and public service integration.
II. CapWIN Element-by-Element Descriptions
A description of the UVA CapWIN test systems follows:
Figure 5 – The existing, to to-be, UVA CapWIN system components.
The above diagram represents the CapWIN system and
its interactions. Please note the legend in the bottom left-hand corner that explains
the various icons in the diagram. Each of the numbered entities are listed and
described below to better explain the system architecture.
It should be noted that the system architecture is
separated into 3 different pieces connected by either direct connections or Virtual
Private Network (VPN) connections over the Internet. These three pieces are the
CapWIN, University (composed of UVA and UMD parts), and NOVA SSP regions.
Represented among these regions are various technology
components such as laptop and workstation computers, communication channels and
protocols, databases, and vehicles. Each of these can be referenced in the legend.
There are also mobile components which will provide
data to the CapWIN system including GPS Probes, Cell Phone Probes, Laptop Probes,
and Existing GPS Probes. For each probe and probe type, disseminated time/location/unique
ID information as well as details about the cellular providers and compression
technologies are stored in a probe information database.
Component Descriptions
CapWIN Components
1.
CapWIN
System and Central Server Program– This is the main product compiled by the CapWIN
project at the University of Virginia. This software allows users to see GPS located
vehicles as they drive around highways and arterials in the Northern Virginia
area. Also, the highways can be shown with traffic flow data obtained from the
STL. Finally, the product allows users to see graphical representations of both
the general traffic flow in the area and the quality of cellular service available
in pre-defined square areas.
Central Server Program
§
Receives
probe data and stores it into the “CapWIN” database
o
‘capwin’
database:
a.
Located
on ‘Fairfax’ database server
b.
IP
address: 128.143.6.173
c.
Username:
administrator
d.
Password:
capwin
e.
Holds
GPS probe data
f.
Holds
agency information
g.
Receives
and stores GPS packets from probes
h.
Tables:
i.
Agency
– Relevant information for agencies associated with registered probes
1.
AgencyID
{PK}
2.
AgencyName
3.
Classification
4.
City
5.
County
6.
State
7.
Zip
ii.
Probe
– Identification information for registered probes
1.
ProbeID
{PK}
2.
AgencyID
{FK}
3.
Name
iii.
Packet
– GPS data sent by probes
1.
ProbeID
{PK}
2.
Date
{PK}
3.
Time
{PK}
4.
Longitude
5.
Latitude
6.
Speed
7.
Error
8.
SpeedError
9.
NumSatsUsed
o
‘statistics’
database:
i.
Located
on ‘Fairfax’ database server
j.
IP
address: 128.143.6.173
k.
Username:
administrator
l.
Password:
capwin
m.
Holds
speed data
n.
Holds
volume data
o.
Holds
aggregated sums and standard deviations
p.
Tables:
i.
nova_freeway_speed_data
1.
controllerid
2.
milepost
3.
time
4.
speed
avg
5.
speed
sttdev
ii.
nova_freeway_volume_data
1.
controllerid
2.
milepost
3.
time
4.
volume
avg
5.
volume
sttdev
iii.
statistics
1.
controllerid
2.
interstate
3.
mile_post
4.
time
5.
day
of year
6.
hourx
7.
date
8.
Volume
SUM 1
9.
Speed
AVG 1
2.
[IN
DEVELOPMENT] CapWIN Incident Log Archive – This database contains data on past
incidents recorded by CapWIN. This data is basically stored information from past
use of the CapWIN tool and can be used to review past incidents. The data is similar
in format to current incidents being recorded by the CapWIN tool.
3.
[IN
DEVELOPMENT] CapWIN AVL Incident Location
4.
[IN
DEVELOPMENT] CapWIN Incident Location – This database contains data on past incidents
recorded by CapWIN. This data is basically stored information from past use of
the CapWIN tool and can be used to review past incidents. The data is similar
in format to current incidents being recorded by the CapWIN tool.
- University Components – UVA and UMD
5.
‘Traveler’
UVA – CapWIN database integrator – This is the database on the ‘Traveler’ server
used for the CapWIN project. This database contains the results of the STL query
supplying data for processing in the CapWIN tool. The data on Freeway and Arterial
Flow from the STL and the UMD-CATT databases is transferred here via a script.
6.
UVA-STL
Database – This database houses data collected by the Smart Travel Lab. This data
is supplied through the Virginia Department of Transportation for many projects
and is housed in Charlottesville, Virginia. It is collected from many traffic
detection devices through out the state.
7.
[IN
DEVELOPMENT] UMD-CATT database - This database houses data collected by the MDSHA
and other Maryland transportation agencies; its data is similar to that found
in the UVA-STL database. It is collected
from many traffic detection devices through out the state.
- NOVA SSP Components
8.
NOVA
STC database – This is the database containing data on freeway flow and incidents
found by representatives associated with CapWIN. It is later moved to the UVA-STL
database.
9.
[IN
DEVELOPMENT] NOVA SSP Database – This is the database containing data on incidents
found by representatives associated with CapWIN. It is later moved to the UVA-STL
database.
10.
NOVA
STSS database – This is the database containing data on arterial flow entered by representatives associated
with CapWIN. It is later moved to the UVA-STL database.
11.
[IN
DEVELOPMENT] CapWIN Laptop modified by UVA-STL SMT (GPS and Communications) –
Standard laptop provided to the CapWIN associated groups. This laptop has been
modified to include GPS locator and can be used to collect data when brought to
the site of an incident. The data is then moved to the VDOT NOVA SPP database.
12.
[IN
DEVELOPMENT] Laptop for SSP Incident Data Collection – Standard laptop provided
to the groups associated with CapWIN. No GPS locator, but this laptop can be used
to collect data when brought to the site of an incident. The data is then moved
to the VDOT NOVA SPP database.
13. [IN DEVELOPMENT] Vehicle –
This is the means of transportation for CapWIN associated individuals who go out
in the field collecting incident data.
- Mobile Components:
14.
[IN
DEVELOPMENT] Probe Information Database – Database including probe data for each
probe and probe type as well as information on the cellular providers and compression
technologies used.
15. [IN DEVELOPMENT] GPS Probes – Send data including location (lat-long),
time, and a unique ID at a predetermined frequency.
The data fields obtained from Laptop and Cell phone
probes are as follows:
| Shared | Phone Only | Laptop Only |
| Time
Stamp Latitude Longitude Altitude Speed Number
of Satellites Travel
Direction/Track Angle | Altitude
Uncertainty Speed
Uncertainty | Fix
Quality Check
Sum |
16. [IN DEVELOPMENT] Cell Phone
Probes – CapWIN participant cell phones integrated GPS chips, and loaded with
‘GPSLocator’ software, become live GPS probes that send GPS location information
to the Central Server program. The phone also allows for customization via code and user settings.
The settings are listed below:
Privacy Settings – Set by user
·
Restricted – GPS info unavailable to JAVA apps.
·
Unrestricted – All GPS info available to JAVA apps.
·
By Permission – Set for each JAVA app by phone user.
“Restricted” or “By Permission”
settings will interfere with the ability of the application to send GPS information
Delay Settings – Set in code
·
Low
– Max timeout: 30 seconds
·
High
– Max timeout: 125 seconds
In order to verify the data
received, basic comparisons can be performed to ensure that the Latitude and Longitude
values returned are feasible and within the desired region. The cellular probes
are somewhat limited in that they will not provide simultaneous voice and data
transmissions. If data is being sent or received, voice calls will not work. If
the phone is on but no data is being transmitted, voice calls can be both sent
and received.
17.
[IN DEVELOPMENT] Laptop Probes – CapWIN participant
laptops, integrated with inexpensive USB connected GPS receivers, become live
GPS probes that send GPS location information to the Central Server program.
The laptop probe returns a “Check Sum” which can be used to verify the integrity
of data packets. Simple verification of
data using the Check Sum will allow for the determination of whether packets have
been corrupted.
18. [IN DEVELOPMENT] Existing GPS-enabled
mobile infrastructure probes – CapWIN participants that already maintain GPS-enabled
Automatic Vehicle Location (AVL) systems can push similar location/time/unique
ID data to the Central Server program and serve as an ordinary probe.
Database Update
Script
Northern Virginia freeway data
is stored in the system in the form of three flat text files located in the ‘www’
folder of the web server Fairfax:
a.
nova_freeway_speed_data.txt
b.
nova_freeway_volume_data.txt
c.
nova_freeway_current_data.txt
These files are re-written
every five minutes with new data from the queries that run in the Smart Travel
Lab, and contain the data as described for the ‘statistics’ database. When the new data has been placed in the files,
this data can be inserted into the ‘statistics’ database under the appropriate
tables. To do so, the .php file, ‘WriteToDb.php’
was created. Also located in the ‘www’
folder on the Fairfax web server, ‘WriteToDb.php’ performs the following tasks:
a.
Connects
to the ‘statistics’ database.
b.
Clears
the ‘statistics’ table within the ‘statistics’ database
c.
Writes
data from ‘nova_freeway_current_data.txt’ into the ‘statistics’ table.
d.
Adds
data from ‘nova_freeway_speed_data.txt’ to ‘nova_freeway_speed_data’ table.
e.
Adds
data from ‘nova_freeway_volume_data.txt’ to ‘nova_freeway_volume_data’ table.
f.
Disconnects
from ‘statistics’ database
g.
Repeats
steps a-f every five minutes.
Below is more detailed information on each of the queries:
Pushing
data out of the STL:
In order to make the map interactive, data must be
made available outside of the STL. Windows Task Scheduler is set to execute a
batch file from Micron_5 in the STL every five minutes. This batch file is located
at C:\scripts\geti495_data.bat and executes the following:
- geti495_data.bat:
REM clean out last run data
files...also to compensate for time drift issue.
REM del nova_freeway_speed_data.txt
REM del
nova_freeway_volume_data.txt
REM del nova_freeway_current_data.txt
REM query for volume, speed,
and current data from NOVA I495.
sqlplus stldbuser/general@simpson
@c:\scripts\nova_freeway_speed_vol_current.sql
REM ftp data files to server
in Olsen Hall.
ftp -s:c:\scripts\ftpputdata.txt
>> timtest.log
This batch file opens SQL*Plus and executes nova_freeway_speed_vol_current.sql,
which runs three queries on the Oracle database in the STL. The batch file then
writes the results to three text files, which are saved in C:\scripts. These text
files are nova_freeway_current_data.txt, nova_freeway_speed_data.txt, and nova_freeway_volume_data.txt.
- nova_freeway_speed_vol_current.sql:
set pagesize 0;
set linesize 300;
set wrap off;
set trimspool on;
set termout off;
set feedback off;
spool c:\scripts\nova_freeway_current_data.txt;
select d.controllerid || ' ' || d.interstate || ' ' || d.mile_post || ' ' || t.time_key || ' '
|| c.dayofyear || ' ' || t.hourx || ' ' || c.datex || ' ' || round(sum(volume),1) || ' ' || round(avg(speed),1)
from nova_detector
d, nova_freeway f,calendar c, timex t
where d.detector_key = f.detector_key
and c.calendar_key = f.calendar_key
and t.time_key = f.time_key
and c.calendar_key=to_char(sysdate,'J')-366
and t.time_key in ((to_char((sysdate
- 1/24),'HH24MI')), to_char((sysdate - (1/24/60)*45),'HH24MI'), to_char((sysdate
- (1/24/60)*30),'HH24MI'), to_char((sysdate - (1/24/60)*15),'HH24MI'), to_char(sysdate,'HH24MI'))
group by d.controllerid,d.interstate,d.mile_post,
c.dayofyear, t.hourx,t.time_key, c.datex;
spool off;
spool c:\scripts\nova_freeway_speed_data.txt;
select d.controllerid|| ' ' || d.mile_post|| ' ' || f.time_key|| ' ' || round(avg(speed),1)|| '
' || round(stddev(speed),1)
from nova_detector d, timex
t, nova_freeway f, calendar c
where d.detector_key = f.detector_key
and t.time_key = f.time_key
and f.calendar_key = c.calendar_key
and f.time_key=(select to_char(sysdate,'HH24MI')
from dual) and c.yearx = 2003
group by controllerid, d.mile_post,
f.time_key
order by controllerid, d.mile_post,
f.time_key;
spool off;
spool c:\scripts\nova_freeway_volume_data.txt;
select controllerid|| ' ' || a.mile_post|| ' ' || a.time|| ' ' || round(avg(vol_sum),1)|| ' ' || round(stddev(vol_sum),1) from (select d.controllerid
controllerid, d.mile_post mile_post, c.dayofyear dayofyear, f.time_key time, sum(volume)
vol_sum
from nova_detector d, timex
t, nova_freeway f, calendar c
where d.detector_key = f.detector_key
and t.time_key = f.time_key
and f.calendar_key = c.calendar_key
and f.time_key=(select to_char(sysdate,'HH24MI')
from dual) and c.yearx = 2003
group by controllerid,d.mile_post,f.time_key,
c.dayofyear
order by controllerid,d.mile_post,f.time_key)
a
group by controllerid,a.mile_post,
a.time
order by controllerid,a.mile_post,
a.time;
spool off;
exit;
The batch file then opens an ftp connection and runs
ftpputdata.txt, which pushes the three text files to the C:\www folder in the
Olsen laboratory.
- ftpputdata.txt:
open 128.143.6.173
capwin
bladell
cd www
put c:\scripts\nova_freeway_current_data.txt
put c:\scripts\nova_freeway_speed_data.txt
put c:\scripts\nova_freeway_volume_data.txt
close
bye
In the Olsen laboratory, a php script inserts the results
of the query into a MySQL database. This data is then used to color code the map
based on current traffic conditions.
Available data:
The database does not have current data available.
Therefore, data from 2003 is used. The
“current” traffic conditions are represented by the conditions of the present
time exactly one year ago. The averages and standard deviations of traffic conditions
to which the “current” data is compared were calculated once and are stored in
the MySQL database as static data. Obviously, if current data was coming in all
the time, it would affect these statistics; standard deviations and averages would
then have to be updated as often as new data was made available. The queries below
are run from the STL. The first runs every five minutes, and the next two
ran every five minutes for a twenty-four hour period.
The current data
query
set pagesize 0;
set linesize 300;
set wrap off;
set trimspool on;
set termout off;
set feedback off;
spool c:\scripts\nova_freeway_current_data.txt;
select d.controllerid || ' ' || d.interstate || ' '
|| d.mile_post || ' ' || t.time_key ||
' ' || c.dayofyear || ' ' || t.hourx || ' ' || c.datex || '
' || round(sum(volume),1) || ' '
|| round(avg(speed),1)
from nova_detector d, nova_freeway
f,calendar c, timex t
where d.detector_key = f.detector_key
and c.calendar_key = f.calendar_key
and t.time_key = f.time_key
and c.calendar_key=to_char(sysdate,'J')-366
and t.time_key in ((to_char((sysdate - 1/24),'HH24MI')),
to_char((sysdate - (1/24/60)*45),'HH24MI'), to_char((sysdate - (1/24/60)*30),'HH24MI'),
to_char((sysdate - (1/24/60)*15),'HH24MI'), to_char(sysdate,'HH24MI'))
group by d.controllerid,d.interstate,d.mile_post, c.dayofyear,
t.hourx,t.time_key, c.datex;
spool off;
exit;
This query selects all controllerids, the interstate, the mile_post, the time, the day of the year, the hour, the date, the volume sum, and the average speed. This data is collected for each controllerid, for the current day of the year (except in 2003), for the current time, and for fifteen minute intervals during the past hour.
Each controllerid represents a station that has many
data-collecting detectors. The volume sum for a controllerid is the sum of all
volume values at each detector. The average speed at a controllerid is the average
of all speed values collected at each detector. Controllerid is currently the
only common attribute between the database and the map. Thus, controllerids change
colors depending on traffic conditions.
Figure 6 Generic despiction of loop detectors
This query gathers current,
real-time data, except for 2003. The same day as the current day is selected;
however, the day is in 2003. This task is accomplished with the following “where”
condition, which is included in the above query: “c.calendar_key=to_char(sysdate,'J')-366”.
This takes the current day and subtracts one year from it (366 days). When the
database is updated with 2004 data, this statement should be changed to: “c.calendar_key=to_char(sysdate,'J')”.
This will gather actual real-time data.
The next “where” condition, which begins “t.time_key in,” selects the times of interest. These times are the current time minus one hour, the current time minus forty-five minutes, the current time minus thirty minutes, the current time minus fifteen minutes, and the current time. Providing this past data allows the web page designer to create maps that show past conditions, which may be useful to the user. Also, the web page designer or user can predict future traffic conditions by analyzing how traffic conditions change in an hour.
The speed statistic query
set pagesize 0;
set linesize 300;
set wrap off;
set trimspool on;
set termout off;
set feedback off;
spool c:\scripts\nova_freeway_speed_data.txt;
select d.controllerid|| ' ' || d.mile_post|| ' '
|| f.time_key|| ' ' || round(avg(speed),1)||
' ' || round(stddev(speed),1)
from nova_detector d, timex t, nova_freeway f, calendar
c
where d.detector_key = f.detector_key
and t.time_key = f.time_key
and f.calendar_key = c.calendar_key
and f.time_key=(select to_char(sysdate,'HH24MI') from
dual) and c.yearx = 2003
group by controllerid, d.mile_post, f.time_key
order by controllerid, d.mile_post, f.time_key;
spool off;
exit;
The volume statistic
query
set pagesize 0;
set linesize 300;
set wrap off;
set trimspool on;
set termout off;
set feedback off;
spool c:\scripts\nova_freeway_volume_data.txt;
select controllerid|| ' ' || a.mile_post|| '
' || a.time|| ' ' ||
round(avg(vol_sum),1)|| ' '
|| round(stddev(vol_sum),1) from (select d.controllerid controllerid, d.mile_post
mile_post, c.dayofyear dayofyear, f.time_key time, sum(volume) vol_sum
from nova_detector d, timex t, nova_freeway f, calendar
c
where d.detector_key = f.detector_key
and t.time_key = f.time_key
and f.calendar_key = c.calendar_key
and f.time_key=(select to_char(sysdate,'HH24MI') from
dual) and c.yearx = 2003
group by controllerid,d.mile_post,f.time_key, c.dayofyear
order by controllerid,d.mile_post,f.time_key) a
group by controllerid,a.mile_post, a.time
order by controllerid,a.mile_post, a.time;
spool off;
exit;
These queries collect speed and standard deviation
statistics- averages and standard deviations at a given time for each controllerid.
The color of a controllerid on the map depends on the number of standard deviations
the current and volume speed data are from the average speed and volume data at
a given time.
The average speed in the above query is the average
of all of the average speeds, calculated at each specific controllerid, for all
of the days available in the database (which are all in 2003), at the current
time. The standard deviation is calculated over these same values. Thus, each
controllerid has a value for average speed and speed standard deviation for each
specific time. These statistics do not change day to day. For example, there is
one average for 11:00am at controllerid 700. Each day at 11:00 am, the current
speed at controllerid 700 is compared to the average speed at controllerid700.
That controllerid changes color accordingly.
The average volume is calculated by first summing all
of the volume data at each particular station to create one volume number for
each controllerid at each time instance. These volume sums are then averaged for
each contollerid at a particular time instance over every day in 2003. This results
in one volume average for each contollerid and for each time. The standard deviation
is calculated from the volume sums for each contollerid at a particular time over
every day in 2003.
Figure
7 Volume calculation
diagram
The speed and volume queries run every five minutes
for twenty-four hours to fill the database with values for every time of the day,
separated by five-minute intervals. The current data query contumies to run every
five minutes.
Currently, the query is as good as it can be without
having access to current data. The standard
deviations and averages can be calculated over different intervals if desired.
When and if current data is made available, the current
queries can be easily modified.
III. CapWIN System Walkthrough
The following document outlines the use of the Capital
Wireless Integrated Network (CapWIN) system. The document is a walkthrough that
gives the step-by-step procedure for using the system. In order to use the CapWIN
system, a user terminal must have Microsoft Internet Explorer (IE) version 5.0
or higher installed with the Java Virtual Machine of version 1.4.2 installed.
Once IE has been loaded, the user should browse to IP address 128.143.6.173 by
entering the following data into the address bar in the browser:
http://128.143.6.173/
This step will bring up a page showing the initial
Smart Travel Lab (STL) homepage. This page is shown in figure 8 below. This page
has four options on it:
- Charlottesville
- Metro DC
- Metro DC (no alert)
- Check Javascript Version
Figure
8 Smart Travel Lab
Homepage
On this page, the first option for Charlottesville
will bring up a page showing a map of the Charlottesville, Virginia area. This
map is shown in figure 9 below.
Figure
9 Charlottesville
Map
The Charlottesville map is broken up into six different
regions each with its own function. Each section allows for different configuration
options or a display of different data. Outside of the partitioned regions, the
page will show the Global Positioning System (GPS) coordinates that are being
displayed.
- Main Display – The center of the interface shows the actual map of
Charlottesville displaying the streets at the current zoom level. This main display
can be zoomed in by holding down Control and Left Clicking or out by holding down
Control, Shift, and left Clicking to give more or less detail. Also, the map can
be panned by pressing the Alternate key and Left Clicking. The colored circles
on this map represent the paths taken by GPS probes being tracked in the Charlottesville
region.
- Data View – The data view section allows a user to pick which data
view is shown. The three options are Geographical, Agency, or Topological which
each show either the layout of the map, a particular highlighted agency, or an
elevation view of the map.
- Agency Selection – This option allows the user to select which Agency’s
probes are shown in the map. Each Agency has a particular Agency Number associated
with it and any number from 0 to all of the Agencies can be shown using these
checkboxes.
- Hide – This section allows the user to customize the interface for
either showing or hiding particular map representations such as the GPS circles,
the first level of detailed streets, the second level of detailed streets (slightly
higher flow than the first level), or the arterial streets.
- Toggle – This section is for future expansion where the ability to
toggle other components of the map would be represented.
- Time Options, Time Interval, and Date Functions – This section is
used for choosing how many or which types of GPS circles will be shown. The Time
Options interface allows a user to see the state of the map at 4 time phases.
45 minutes ago, 30 minutes, 15 minutes, or now. The Time Interval option lets
the user select how much elapsed time will be shown on the map in minutes, up
to ten hours. The Date Function section allows the user to select the data for
which day of the year in the past the map will display. The section is controlled
by the ‘Update’ button.
By clicking on the Metro DC link or the Metro DC (no
alert) links on the STL homepage, a Metro DC map of Washington, DC is shown. The
only difference between the two links is that one displays a Jave alert window
telling the user the page is changing and one does not. The functionality of the
Metro DC page is similar to the Charlottesville page, but has the addition of
a Shaded data view which will shown the Metro DC map with the shading of an overlaying
rectangular grid. The shading of each square of this grid shows the quality of
cellular reception in that square such that a red square has very bad reception,
yellow is decent reception, and green is good reception. Also, as shown on the
Metro DC map below, the CapWIN program has the ability to show the status of the
current traffic flow on the roadways by coloring ‘point stations’ along the major
arteries. The coloring shows how well traffic is moving with red being very slow
traffic, yellow being sluggish, and green being well moving traffic. Grey point
stations mean that no data has been received in the STL databases for that point
station. Please see figure 10 below representing the Metro DC map.
Figure
10 Metro DC Map
An example of the data used by the CapWIN system can
be found figure 11 below. The data is contained in a database with the following
fields:
- Probe ID
- Date
- Time
- Longitude
- Latitude
- Speed
- Error
- Speed Error
- NumSatsUsed
Figure
11 CapWIN Database
Data
The Probe ID field is a unique identifier for each
GPS probe reporting data to the database. The Date and Time fields contain the
day of the year and the time of day for the data sample. The Longitude and Latitude
fields have the coordinates of the GPS location of the data sample. The Speed
field contains the vehicle speed for the data sample with an error as shown in
the Speed Error field. The Error field contains the possible feet of error for
the location coordinates for the probe. The NumSatsUsed field contains the number
of GPS satellites used to triangulate the particular data sample.
Figure 12 below shows the cellular probe used with the CapWIN system. It is a standard cellular phone with GPS capabilities and allows the user to run the probe program by selecting the ‘GPS Info’ program shown in the figure.
Figure
12 Cellular Probe
Acknowledgements
We would like to thank Tom Jacobs and Bruce Barney
of the Capital Wireless Integrated Network (CapWIN) program for their time, support,
and patience, and the National Institute of Justice’s Office of Science and Technology
for their sponsorship. We would also like
to thank the Virginia Department of Transportation and the University of Virginia,
Smart Travel Lab Co-Director, Brian L. Smith, for the use of the lab and its resources
during our research. The UVa SIE Capstone team graduate Student
Yiyi Zhang also provided significant input.
List of References