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