Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
TABLE OF CONTENTS
Page
LIST OF ACRONYMS .................................................................................................III-ii
1.0
III-INTRODUCTION ...........................................................................................III-1
2.0
III-ADAPTATION METHODOLOGY ..................................................................III-3
2.1
III-Review of NIA Top-Level Logical Architecture ............................................III-3
2.2
III-Review and Selection of Lower-Level Processes .......................................III-5
2.2.1
III-“Manage Traffic” Process Tree.............................................................III-7
2.2.1.1 III-Traffic Surveillance ...........................................................................III-7
2.2.1.2 III-Device Control ..................................................................................III-9
2.2.1.3 III-Incident Management ..................................................................... III-11
2.2.2
III-“Manage Emergency Services” Process Tree .................................... III-14
2.2.3
III-“Provide Driver and Traveler Services” Process Tree ........................ III-16
2.2.4
III-“Plan System Deployment and Implementation” Process Tree........... III-18
3.0
III-ROC LOGICAL ARCHITECTURE DESCRIPTION ..................................... III-21
3.1
III-ROC Context Diagram ............................................................................. III-21
3.2
III-Top-Level ROC Processes ....................................................................... III-23
3.3
III-“Monitor Regional Traffic” Child Processes............................................... III-24
3.3.1
III-“Gather and Display Traffic Data” Child Processes ............................ III-25
3.3.2
III-“Monitor Incident Data” Child Processes ............................................ III-26
3.4
III-“Coordinate Multi-Agency Incident Response” Child Processes ............... III-29
3.5
III-“Coordinate Traveler Information Dissemination” Child Processes ........... III-31
3.6
III-“Provide Incident-Response Training” Child Processes ............................ III-33
4.0
III-SUMMARY .................................................................................................. III-35
November 1998
III - i
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
LIST OF ACRONYMS
DFD - Data Flow Diagram
DPW&T
- Department of Public Works and Transportation (Prince George’s County)
DPWT
- Department of Public Works and Transportation (Montgomery County)
ECC
- Emergency Communications Center
ERU
- Emergency Response Unit
ETP
- Emergency Traffic Patrol
FEMA
- Federal Emergency Management Administration
HAZMAT
- Hazardous Materials
ISP
- Information Service Provider
MDE
- Maryland Department of the Environment
MEMA
- Maryland Emergency Management Administration
MSP
- Maryland State Police
NIA
- National ITS Architecture
OEP
- Office of Emergency Preparedness
P+R
- Park-and-Ride (as used in the NIA)
ROC
- Regional Operations Coordination
SHA
- State Highway Administration
SOC
- Statewide Operations Center
TAR
- Traveler Advisory Radio
TM
- Traffic Management
TMC
- Traffic Management Center (in a general context)
TMC
- Transportation Management Center (the center in Montgomery County)
TMS
- Traffic Management System
TOC3
- Traffic Operations Center in the SHA District 3
TRIP
- Traffic Response and Information Partnership
VDOT
- Virginia Department of Transportation
VMS
- Variable Message Sign
WMATA
- Washington Metropolitan Area Transit Authority
November 1998
III - ii
Regional Operations Coordination (ROC)
1.0
Task 3, Vol. 1 - ROC Logical Architecture
INTRODUCTION
The National ITS Architecture (NIA) provides a common structure for the design of
Intelligent Transportation Systems. It is not a system design nor is it a design concept. It
is, however, a framework around which multiple design approaches can be developed
and each one specifically tailored to meet the individual needs of the user. The NIA
defines the functions needed to implement a given User Service (e.g., gather traffic
information or respond to an emergency assistance request). It also defines the physical
entities or subsystems where these functions reside (e.g., the roadside or the center). It
specifies the interfaces and information flows between the physical subsystems, and the
communication medium for the information flows (e.g., wire-line or wireless). In addition,
the NIA identifies and specifies the requirements for the standards to support national
and regional interoperability, as well as product standards needed to support economy
of scale in deployment.
Since the NIA is the guideline for ITS implementation at regional and local levels, it is
important that the Regional Operations Coordination (ROC) systems architecture for the
Maryland National Capital Region is consistent with the NIA to ensure interoperability.
To achieve this purpose, an approach was employed to adapt the NIA for the ROC
architecture. In this approach, the requirements and vision1 identified by representatives
of the ROC agencies were used as a basis for tailoring the NIA elements (refer to Figure
1-1). The result of the tailoring is a ROC Logical Architecture and a ROC Physical
Architecture. This document describes only the ROC Logical Architecture while the
ROC Physical Architecture is described in a separate document.
ROC Requirements
and Vision
National ITS Architecture
ROC Logical
Architecture
ROC Physical
Architecture
Figure 1-1. ROC Systems Architecture is an Adaptation of the National ITS Architecture
To provide a background for understanding the ROC Logical Architecture, below are the
high-level functional requirements that the ROC system will address:
1
Refer to another Working Paper that describes the ROC Goals, Objectives, and Functional Requirements.
November 1998
III - 1
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
a. The ability to monitor the traffic and travel conditions in the region.
b. The ability to coordinate incident responses with other agencies and jurisdictions.
c. The ability for the appropriate ROC agencies to coordinate the dissemination of
travel information.
d. The ability to support interagency incident-response training.
With these requirements as a guideline, the methodology to adapt the NIA for the ROC
is described in Section 2.0 while the ROC Logical Architecture is presented in Section
3.0 of this document. Section 4.0 concludes the document with a brief summary.
November 1998
III - 2
Regional Operations Coordination (ROC)
2.0
Task 3, Vol. 1 - ROC Logical Architecture
ADAPTATION METHODOLOGY
The process to adapt the NIA Logical Architecture for the ROC Logical Architecture
includes a review of various elements of the NIA and an assessment of the relevance of
those elements to the ROC requirements. Since the NIA was developed using
structured methods to describe the functions of the intelligent transportation systems, the
adaptation process employed here followed the same structure to ensure completeness
and consistency. This process began with the review of the NIA top-level Logical
Architecture from which the relevant functional processes were identified. The lowerlevel elements of these identified functional processes were then reviewed and the
relevant ones selected for the ROC Logical Architecture. The following sections
describe the results of the review and assessment of the NIA functional processes.
2.1
Review of NIA Top-Level Logical Architecture
The NIA Logical Architecture contains eight processes at the top-level, as illustrated in
the simplified data flow diagram (DFD) in Figure 2-1. A DFD is a tool that depicts
functional requirements of a system. It partitions the requirements into smaller
component functions, or processes. (These processes are shown as rectangles in
Figure 2-1.) All the relevant processes of a system are shown in a DFD as a network
interconnected by data flows into or out of each process (i.e., input data flows and output
data flows, respectively). A process, thus, shows the function to be performed by a
system to transform input data flows into output data flows.
A process may be broken down into lower-level functions to more accurately describe
what it does in the system – this action is called decomposition. The lowest level of
decomposition is a Process Specification. (The NIA documents have a complete set of
Process Specification.) Because all the top-level functional processes of the NIA contain
many lower-level functions, they may be referred to as functional process trees.
Another element of a DFD is the terminator (shown as oblong shapes in Figure 2-1),
which represents an external entity that interfaces with the system by providing data to
or receiving data from the system. Many classes of terminators have been defined in
the NIA but are not shown here in this simplified DFD.
Based on the review of the NIA Logical Architecture and its lower-level processes, the
following four top-level processes have been determined to be relevant to the ROC
requirements (see Figure 2-2):
a. Manage Traffic
b. Manage Emergency Services
c. Provide Driver and Traveler Services
d. Plan System Deployment and Implementation
November 1998
III - 3
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
Vehicle Status
Basic Vehicle
Traf fic
traff ic control
inf ormation
NA 3
Provide Vehicle
Monitoring &
Control
NA 1
priority request
Manage Traf fic
incident
inf ormation
NA 4
incident
notif ication
Manage
Transit
Financial Institution
traff ic
inf ormation
traff ic inf or
request
transit schedules
emergency
acknow ledge
NA 5
Manage
Emergency
Services
NA 7
transit requests
Provide Electronic
Payment Services
NA 6
payment
request
Incident
data
Provide Driver &
Traveler Services
payment
emergency
notif ication
E911
NA 2
route request
Manage
Commercial
Vehicles
route information
NA 8
congestion
inf ormation
Plan System
Deployment &
Implementation
route information
Commercial
Vehicle
ITS Planners
Figure 2-1. Top-Level National ITS Logical Architecture
Intelligent Transportation Systems
NA 1
NA 2
NA 3
NA 4
NA 5
NA 6
NA 7
NA 8
Manage
Traffic
Manage
Commercial
Vehicles
Provide
Vehicle
Monitoring
& Control
Manage
Transit
Manage
Emergency
Services
Provide
Driver &
Traveler
Services
Provide
Electronic
Payment
Services
Plan System
Deployment &
Implementation
Top-Level Processes that are relevant to ROC
Figure 2-2. Three NIA Processes Relevant to ROC Requirements
November 1998
III - 4
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
The other processes were deemed not relevant to the current ROC requirements
because of the following reasons:
a. The process to Manage Transit deals mainly with managing the operations of a
transit system, which is intra-agency and does not fit the context of ROC. There
are, however, three interfaces that the ROC system must have to support transit
operations. The first interface is the signal priority request/response operation,
which is accounted for in the Manage Traffic process (whose specific “child
process” is Provide Device Control). The second interface is to support transit
emergency management, which is accounted for in the Manage Incidents
process of Manage Traffic and in the Manage Emergency Services process. The
third interface is with the Provide Driver and Traveler Services to support traveler
information dissemination.
b. The process to Manage Commercial Vehicles is not needed given that similar
initiatives are being conducted at the State and Interstate levels in this region.
c. The process to Provide Vehicle Monitoring and Control is more appropriate for
the private sector in that automated functions are developed for the vehicle.
d. The Provide Electronic Payment Service process addresses the various fee
collection functions of an intelligent transportation system and is not currently
within the scope of ROC.
In the following paragraphs, the review and selection of the lower-level processes of the
relevant top-level processes is presented.
2.2
Review and Selection of Lower-Level Processes
The approach to tailoring the selected process trees of the NIA (i.e., Manage Traffic,
Manage Emergency Services, Provide Driver and Traveler Services, and Plan System
Deployment and Implementation) for the ROC architecture is shown in Figure 2-3. In
this approach, all elements of each process tree were assessed, and only those relevant
to the ROC functional requirements were selected for the ROC Logical Architecture.
Because the ROC architecture is an adaptation of the NIA, which addresses many
hierarchical levels of a transportation system (from the field equipment to a control
center), it is important to identify the NIA elements that belong to the appropriate
hierarchical levels for incorporation into the ROC architecture. To achieve this purpose,
a ROC organizational hierarchy along with the appropriate functions in each level were
defined and used as a guide to select the elements of the NIA’s process trees (see
Figure 2-4).
As shown in Figure 2-4, the system functions that are appropriate at the ROC level are:
a. Maintain Regional Awareness
b. Select Coordination Plans
c. Identify Mutual Support Needs
November 1998
III - 5
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
Construction
A gencies
S tate/County
Traf Mgt S ystems
local traffic data
local incident data
local parking data
local road network data
construction information
Manage Traffic
Manage Traffic
1.1.2
local transportation data
1.1.1
E xchange data
with Other
Traffic Centers
P rocess Traffic
Data for S torage
Provide Traffic
Surveillance
Provide Traffic
Surveillance
local transit data
traffic & sensor static
data
current data
Transit Mgt S ys
Process Traffic
Sensor Data
Process Traffic
Sensor Data
Process and Store
Traffic Data
long-term data
Process and Store
Traffic Data
Generate Predictive
Traffic Model
local transit static data
1.1.3
Maintain Traff &
S ensor S tatic
Data
link data update,
new sensor static data
Generate Predictive
Traffic Model
regional info request
Display and Output
Traffic Data
Exchange Data With
Other Traffic
Functions
Display and Output
Traffic Data
Collect Vehicle
Smart Probe Data
Data for
Link Calculations
Process Traffic
Data for Storage
Provide Traffic
Ops Personnel
Traffic Data I/F
requested traffic data
Retrieve Traffic
Data
Collect Vehicle Tag
Traffic Operation
P ersonnel
parameter updates,
information request
Provide Traffic
Ops Personnel
Traffic Data I/F
Collect Vehicle
Smart Probe Data
Process
Traffic Data
Process
Traffic Data
Provide Media
Operator
Traffic Data I/F
Update Data Source
Static Data
traffic data retrieval
parameters
traffic
information
display
1.1.6
P rovide Traffic
Ops P ersonnel
Traf Data I/F
request traffic map
display update
Update Data Source
Static Data
Update Traffic
Display Map Data
regional traffic data
retrieved traffic operations
data
Process Traffic
Data for Storage
Provide Media
Operator
Traffic Data I/F
1.1.5
P rovide Traffic
Data Retrieval
Interface
Retrieve Traffic
Data
Process and Store
Traffic Data
Retrieve Traffic
Data
traffic data request
1.1.4
Display and Output
Traffic Data
Exchange Data With
Other Traffic
Functions
Process and Store
Traffic Data
Collect Vehicle Tag
Data for
Link Calculations
request traffic
operations data
Display and Output
Traffic Data
1.1.7
Update Traffic
Display Map Data
Monitor HOV
Lane Use
Update Traffic
Display Map
Data
Monitor HOV
Lane Use
Provide
Media System
Traffic Data I/F
Provide
Media System
Traffic Data I/F
Process AVI Data for
Link Time Data
map data update
Process AVI Data for
Link Time Data
Provide Traffic
Data Retrieval I/F
map data for
traffic display
Provide Traffic
Data Retrieval I/F
Process Collected
Veh Smart Probe
Data
Process Collected
Veh
Smart Probe
Data
National
Architecture
Adaptation for
ROC
Map Update
P rovider
ROC Logical
Architecture
Figure 2-3. ROC Logical Architecture Development Process
ORGANIZATIONAL HIERARCHY
PRIMARY FUNCTIONS
Maintain Regional Awareness
Select Coordination Plans
Identify Mutual Support Needs
ROC
SHA
MSP
MC
SOC
College Pk
TMC
TOC3
Forestville
ECC
ECC
Rockville
• Police
• Fire
• Police
• Fire
Police Veh.
Signals
Signals
CCTV
CCTV
CCTV
Port. VMS
Port. VMS
Port. VMS
VMS
Police Veh.
Police Veh.
ERU/ETP
Fire Veh.
Fire Veh.
Signals
PGC
TIC
Gather Jurisdictional Information
Implement Coordination Plans
Control Field Assets
Execute Plan Elements
Figure 2-4. Guidelines for Identifying Relevant NIA Elements for ROC
These functions were the primary focus for identifying the appropriate processes in the
NIA. Furthermore, functions at the agency level that support the ROC-level functions
were also considered as levied requirements. These include:
a. Gather Jurisdictional Information.
b. Implement Coordination Plans.
November 1998
III - 6
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
c. Control Field Assets.
Many elements of the levied requirements already exist; therefore, only their interfaces
to the ROC system were considered for the ROC Logical Architecture. Finally, the
system functions at the field level are performed by the individual agencies. They were
not considered as parts of the ROC Logical Architecture; only the necessary interfaces
to those functions were identified.
2.2.1
“Manage Traffic” Process Tree
The Manage Traffic process includes traffic surveillance, traffic control, incident
management, travel-demand management, emissions management, and highway-rail
intersection management functions. It also includes an interface to the Manage
Emergency Services process to facilitate emergency responses to detected incidents.
Only the traffic surveillance, device control, and incident management functions are
relevant to the ROC as described below.
2.2.1.1 Traffic Surveillance
The Traffic Surveillance process provides the functionality for traffic monitoring, data
storage, predictive modeling and communication with other Traffic Management Centers
(TMC’s). In the context of ROC, the Traffic Surveillance process gathers and integrates
traffic and roadway monitoring data from the appropriate agencies. It also stores and
classifies the data as current or long-term for use by the ROC agencies and other
system functions. “Current data” pertains to events that occur within a few minutes from
the current time. “Long-term data” pertains to historical records that may be used for
planning and/or projecting future traffic conditions. The relevant elements of the Traffic
Surveillance process are shown in Figure 2-5 and described below.
The Process Traffic Data for Storage (an element of Process and Store Traffic Data)
function receives traffic monitoring data from individual agencies, combines this data into
regional data, and stores the regional data in the current and long-term data stores. The
data includes processed traffic monitoring data, parking lot occupancy data, traffic
control device status data, and current and planned incident data (including road
construction).
The Display and Output Traffic Data process provides interfaces that allow regional
traffic data to be “exported” for display by an operator or for use by other ROC functions.
It includes the following relevant elements.
a. Retrieve Traffic Data, which retrieves data from the data stores on request.
b. Provide Traffic Operations Personnel Traffic Data Interface, which provides the
interface for traffic operations personnel to obtain traffic, weather, and
equipment-status data stored in the system. It also allows traffic operations
personnel to set up the parameters governing data availability to other users
(e.g., the media). Where appropriate, the process overlays the requested data
onto the road network map.
November 1998
III - 7
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
Manage Traffic
Provide Traffic
Surveillance
Process Traffic
Sensor Data
Process and Store
Traffic Data
Generate Predictive
Traffic Model
Display and Output
Traffic Data
Exchange Data With
Other Traffic
Functions
Display and Output
Traffic Data
Process and Store
Traffic Data
Collect Vehicle Tag
Data for
Link Calculations
Collect Vehicle
Smart Probe Data
Retrieve Traffic
Data
Provide Traffic
Ops Personnel
Traffic Data I/F
Process Traffic
Data for Storage
Process
Traffic Data
Provide Media
Operator
Traffic Data I/F
Update Data Source
Static Data
Update Traffic
Display Map Data
LEGEND:
Monitor HOV
Lane Use
ROC Process
Provide
Media System
Traffic Data I/F
End process
(no further decomposition)
Non-ROC Process (potential
functions of Individual agencies)
Process AVI Data for
Link Time Data
Provide Traffic
Data Retrieval I/F
Process Collected
Veh Smart Probe
Data
Figure 2-5. Relevant Traffic Surveillance Processes for ROC
November 1998
III - 8
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
c. The Update Traffic Display Map Data function updates the store of digitized map
data upon the request of traffic operations personnel. This process will obtain
the new map data from either a specialized data supplier or a designated data
source.
d. Provide Traffic Data Retrieval Interface provides customized sets of traffic data
for broadcast, advisories, or media dissemination. This process will use predefined parameters to determine the data to be retrieved for each request type.
The Exchange Data with Other Traffic Functions process transmits data to and receives
data from other Traffic Management Systems (TMS's) that can be adjacent
geographically or under control of a different jurisdiction. The exchange of data can be
triggered either by a request from a remote TMS or by a pre-determined command to
supply the data to other TMS’s. The exchanged data may pertain to traffic conditions,
incidents, traffic management strategies, or emergency vehicle preemption/priority
operations.
2.2.1.2 Device Control
In the NIA, the Device Control process enables the remote operations and remote
monitoring of traffic control devices in the field (e.g., VMS, TAR, and traffic signals).
Such functions are performed by agencies that own the devices and, therefore, should
not be considered as a part of the ROC Logical Architecture. However, the Device
Control process contains a few elements that have regional implications and are
deemed relevant to ROC. Figure 2-6 shows these elements. Their consideration for
ROC is described below.
The Select Strategy process helps the operators to select the appropriate traffic control
strategy (e.g., adaptive control, fixed-time control, or local operations) to be implemented
for a given traffic situation. Although the NIA defines this process for selecting local
traffic control strategies, it is used in the context of ROC for selecting regional
transportation management strategies. These strategies will deal with traffic incidents
and special events, and will involve multiple agencies as well as multiple type of
transportation services (e.g., traffic, transit, and parking). The selected strategy will be
communicated to the appropriate agencies for implementation.
For the ROC system, the Manage Parking Lot State process will determine the current
conditions of parking lots within the ROC area based on data supplied by agencies that
operate those lots. Where Park-and-Ride (P+R) services are provided, the P+R lot
monitoring data may be used to adjust the transit service frequencies to accommodate
the demand. The following functions in this process tree are deemed relevant to ROC:

The Determine Parking Lot State process will determine the vacancy level (or the
state) of the parking lots in the ROC area so that this information can be
disseminated to the travelers and other agencies. The state of each individual
parking lot (as well as the parking occupancy data) is determined by its operating
agency and supplied to the ROC system.
November 1998
III - 9
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
Manage Traffic
Provide Device
Control
Select Strategy
* “Implement Roadway and Freeway
Control Strategies” is more accurate
Determine Roadway
and Freeway State*
Determine Ramp
State
Output
Control Data
Manage Parking
Lot State
Maintain Static
Data for TMC
Provide Roadside
Control Facilities
Provide Roadside
Control Facilities
Collect and Process
Indicator Fault Data
Collect and Process
Indicator Fault Data
Process Indicator
Output Data
for Roads
Monitor Indicator
Operations for
Faults
Collect Indicator
Fault Data
Maintain Indicator
Fault Data Store
LEGEND:
Provide Traffic
Ops Personnel
Indicator Fault I/F
Provide Intersection
Collision Avoidance
Data
Non-ROC Process (potential
functions of Individual agencies)
Provide Static Data
Store Output I/F
Process In-Vehicle
Signage Data
Process Indicator
Output Data for
Freeways
End process
(no further decomposition)
Maintain Traffic and
Sensor Static Data
Manage Indicator
Preemption**
Provide Indicator
Fault Interface for
C and M
ROC Process
Maintain Static
Data For TMC
Process In-Vehicle
Smart Probe Data
for Output
** Manage Signal Preemption
Figure 2-6. Relevant Device Control Processes for ROC
November 1998
III - 10
Manage Parking
Lot State
Determine Parking
Lot State
Provide Parking
Service Provider I/F
Provide Parking
Lot Operator I/F
Determine P&R
Needs for Transit
Management
Calculate Parking
Lot Occupancy
Regional Operations Coordination (ROC)

Task 3, Vol. 1 - ROC Logical Architecture
Determine P+R Needs for Transit Management, which estimates the demand for
transit services at P+R lots. For ROC, this demand will be determined based on
the historical parking-lot occupancy data.
The Maintain Traffic and Sensor Static Data process (an element of the Maintain Static
Data for TMC process) stores, updates, and retrieves sensor static data (e.g., type and
location) and road network link data for the region. The data will be used by other
processes within the ROC system and provided by the pertinent ROC agencies (e.g.,
transportation agencies).
In the context of the ROC system, the Manage Indicator Preemption process (an
element of Provide Roadside Control Facilities) will gather information on signal
preemption and priority requests submitted to traffic operations agencies. It will use this
information to provide signal preemption coordination across multiple jurisdictions.
The Maintain Indicator Fault Data Store process (an element of Collect and Process
Indicator Fault Data) collects and updates data about faults of traffic signal systems.
The data (including fault clearance) is supplied by traffic operations agencies in the ROC
area. This process also maintains a store of the current operational status of all signals,
and allows traffic operations personnel to review the signal status at the ROC level.
(Any update to the traffic signal status will be performed by the agency that operates the
signals.) The current status of signals will be made available to the traffic control
strategy selection process described earlier.
Finally, the Provide Traffic Operations Personnel Indicator Fault Interface process allows
traffic operations personnel at the ROC level to review and/or monitor all signal
equipment faults so that appropriate traffic control strategies may be selected for
implementation.
2.2.1.3 Incident Management
The Incident Management process of the NIA supports the detection, recording, and
management of both planned and current incidents. It also initiates responses to current
incidents. Incident responses may be generated automatically from a library of preplanned responses, which are based on experiences and lessons learned from previous
incidents. For user interfaces, the process provides capabilities for traffic operations
personnel to monitor and, if necessary, override the automated operations, particularly
for incidents that do not have a pre-planned response.
Incident management at the ROC level will have similar functions except that of incident
detection. Instead of detecting incidents, the ROC system will receive incident
notifications from member agencies and use this information to coordinate incident
responses with other agencies. ROC incident responses may be pre-planned or ad hoc.
A part of the ROC incident management responsibilities will also be to maintain
interagency pre-planned responses and to provide data for creating new, pre-planned
responses. Figure 2-7 shows the relevant elements of the Incident Management
process tree. These elements are described below.
November 1998
III - 11
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
Manage Traffic
Manage Incidents
Traffic Data Analysis
for Incidents
Review and Manage
Incident Data
Respond to Current
Incidents
Provide Operator
Interfaces for
Incidents
Manage Possible
Pre-planned
Response Store
Manage Pre-planned
Incident Response
Data
Provide Operator
Interfaces for
Incidents
Review and Manage
Incident Data
Retrieve Incident
Data
Store Possible
Incident Data
Analyze Incident
Response Log‡
Provide Traffic Ops
Personnel Incident
Data Interface
Provide Media
Incident
Data Interface
LEGEND:
Update Incident
Display Map Data
ROC Process
End process
(no further decomposition)
Mange
Resources for
Incidents
Non-ROC Process (potential
functions of Individual agencies)
Review & Classify
Possible Incidents
Review & Classify
Planned Incidents*
Provide Planned
Incident Store
Interface*
Provide Current
Incidents Store
Interface
* Planned Incidents are referred to as Predicted Incidents in the NIA
‡
For ROC Training
Figure 2-7. Relevant Incident Management Processes for ROC
The Review and Manage Incident Data process receives data on incidents from other
sources and classifies each incident as planned or current (via the Review and Classify
Planned Incidents process). It also provides interfaces to the incident data stores
November 1998
III - 12
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
through the Provide Planned Incident Store Interface process and the Provide Current
Incident Store Interface process.
When a current incident is confirmed, the Respond to Current Incidents process
attempts to find a pre-planned response that is appropriate for that type of incidents. If a
pre-planned response is not available, this process will send the incident details to the
traffic operations personnel so that a new response can be formulated. Otherwise, it will
send pre-planned responses to other appropriate functions. When a current incident is
clear, this process will provide information to update the current incident data store.
The Provide Operator Interfaces for Incidents process allows traffic operations personnel
to review and update data about incidents, data defining the responses to each type of
incident, and data about a system-suggested response (when a pre-planned response
does not already exist). It also provides a means to filter out incident data that is not
appropriate for dissemination to the media or to the public. The following child
processes of the Provide Operator Interfaces for Incidents process are relevant to ROC.
a. Retrieve Incident Data from the stores of predicted and current incidents. This
process will retrieve data upon a request from traffic operations personnel or a
media operator and then send it to the requesting source.
b. Provide Traffic Operations Personnel Incident Data Interface, which allows an
operator to request and obtain incident and incident-response information
(including video images) and to re-classify incidents as needed. It will also
display to the operator the details of an incident that has no pre-planned
responses; and will accept input for a new response from the operator.
Whenever appropriate, this process will display information on a map.
c. Provide Media Incident Data Interface to allow the media to request incident
information as well as to provide information to the media. The media can also
contribute traffic and incident data to the ROC system through this process.
d. Update Incident Display Map Data using the digitized map data supplied by predetermined ROC agencies.
e. Manage Resources for Incidents, which generates and receives requests for
resources from participating agencies to respond to incidents (e.g., equipment
and personnel).
There are two other processes in Incident Management process tree that are relevant to
ROC. First is the Manage Pre-planned Incident Response Data process, which provides
and updates pre-planned incident response data. Second is the Analyze Incident
Response Log process, which identifies from the incident log any pre-planned incident
response that can be standardized. In the NIA, the analysis results are kept in the
system as “possible responses” to be considered when a pre-planned response does
not exist. For ROC, such real-time applications may be difficult because of the large
number of agencies involved. This process is therefore used for planning and training,
instead.
November 1998
III - 13
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
“Manage Emergency Services” Process Tree
2.2.2
In the NIA, the Manage Emergency Services process includes the dispatch and control
functions of emergency services in response to incidents, and the activation of law
enforcement resources against violators (e.g., pollution emissions). The emergency
service dispatch and control functions are relevant to ROC. And in this context, this
process needs to interact with the Manage Traffic function to coordinate incident
management (including resource coordination between traffic management and
emergency management) and to provide priority for emergency vehicles at signalized
intersections and freeway ramps. This process also provides coordination supports to
incident commanders in the field, emergency services, and allied emergency
management agencies. The relevant elements of the Manage Emergency Services
process tree are shown in Figure 2-8 and described in the following paragraphs.
Manage
Emergency
Services
Provide Emergency
Service Allocation
Provide Operator
I/F for Emergency
Data*
Manage Emergency
Vehicles
Identify Emergencies
from Inputs
Select Response
Mode
Determine Coord’d
Response Plan
Dispatch
Vehicle*
Communicate
Emergency Status
Track
Vehicle*
Manage Emergency
Response
Assess
Response Status
Manage Emergency
Service Alloc. Store
Provide Emergency
Personnel I/F
Update Emergency
Display Map Data*
Provide Law
Enforcemt Allocation
Maintain Vehicle
Status
LEGEND:
ROC Process
* Partially applicable to ROC
End process
(no further decomposition)
Non-ROC Process (potential
functions of Individual agencies)
Figure 2-8. Relevant Emergency Service Management Processes for ROC
November 1998
III - 14
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
The Provide Emergency Service Allocation process helps the operator to determine the
type and level of emergency services to be assigned to an incident-response request.
This process will use a set of pre-defined criteria for service assignment. It will also
allow the operator to set up and override these criteria. If there are no allocation criteria
that would meet the needs of an incident, the operator will determine the required
allocation and provide the necessary input to the system. The following functions under
this process are relevant to ROC.
a. Determine Coordinated Response Plan, which will classify and prioritize the
incident notified by a ROC agency. It will use the information contained in the
incident notification to determine an appropriate response plan (many of which
may be pre-planned). A detailed description of the incident and the suggested
response plan will be sent to other pertinent agencies for coordination of
response operations and implementation.
b. Communicate Emergency Status, which will receive the emergency-service
response plans and the status of their implementation. It will screen this
information according to pre-defined rules and then disseminate the information
to other ITS functions.
c. Manage Emergency Response, which will enable emergency centers to receive
emergency management data (e.g., response plan, vehicle dispatch status, etc.)
and route response status information to agencies or vehicles. It will also store
the current status of all emergency service responses in a log.
d. Manage Emergency Service Allocation Store, which will retrieve and update the
store of data (e.g., type of emergency, time of day, location of the emergency,
etc) that is used in the resource allocation process.
The second relevant element in the Manage Emergency Services process tree is to
Provide Operator Interface for Emergency Data. This process is only partially relevant to
ROC because it is intended to help the operators in an Emergency Communications
Center (ECC) to manage all type of emergency responses, not only traffic-related
responses. It will allow an operator to review and update the emergency service
allocation data, to override the pre-defined emergency service allocations to suit the
specific needs of a current incident, and to monitor the status of emergency dispatches.
The third relevant function in the Manage Emergency Services process tree is to
Manage Emergency Vehicles when they are dispatched to an incident. In most
situations, this function will be performed by the agency responsible for the vehicles.
Only when vehicles are dispatched to other jurisdictions, as in the case of ROC, this
functionality is needed at the regional level to provide continuous communications and
support to the response personnel (e.g., route guidance information). Following are the
lower-level functions of the Manage Emergency Vehicles process.
a. Select Response Mode, which will determine the type and number of vehicles to
be dispatched based on the emergency vehicle status. Once the vehicle types
and units are determined, this process will update the emergency vehicle status
data and send the dispatching information to the agency responsible for the
actual dispatch function.
November 1998
III - 15
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
b. Dispatch Vehicle, which will notify the personnel of the dispatched emergency
vehicles of their assignments, receive assignment acknowledgements, and
provide the location and details of the incident to the vehicles. Where applicable,
this process will also request emergency vehicle routing information and
coordinate signal preemption requests for those vehicles.
c. Track Vehicle, which will track the location of all emergency vehicles for
dispatching, arrival-time estimating, and signal preemption/priority support. It will
store the vehicle tracking data as part of the emergency vehicle status.
d. Provide Emergency Personnel Interface, which will allow emergency-response
personnel in the field (or en route) and at central to communicate with each
other. It will support both audible and manual forms of input, and audio and
visual forms of output. The interface mechanisms shall in no way affect the
driver's ability to operate the emergency vehicle in a safe manner.
e. Maintain Vehicle Status, which will retrieve and update a data store of current
vehicle locations, operational conditions, availability to respond to emergencies,
and emergency-response status. Below is a list of possible emergency vehicle
status:

At the emergency location.

Disabled (possibly involved in an incident itself).

En route to an emergency.

Not available.

Requires additional support (more resources needed).

Returning from an emergency, which may be divided into “mission capable”
or “mission incapable.”

Requires maintenance/repair.

At station house.
The fourth, also the last, relevant function in the Manage Emergency Services process
tree is to Update Emergency Display Map Data. This process updates the store of
digitized map data used in displaying incident locations and other emergency-response
information to the operators.
2.2.3
“Provide Driver and Traveler Services” Process Tree
This functional process tree provides multi-modal trip planning, route guidance, and
advisory services to travelers and drivers. Among the elements of this process tree, only
the Provide Information Services process is relevant to the ROC requirements.
Furthermore, only the Provide Advisory and Broadcast Data element of the Provide
November 1998
III - 16
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
Information Services process is relevant to ROC as shown in Figure 2-9 and described
below.
The Provide Advisory and Broadcast Data process gather the regional traffic and transit
information from other ROC system functions to create data for broadcasting. The data
may be disseminated to the media or to designated points for access (e.g., via the
Internet). The functions included in this process are:
Provide Driver &
Traveler Services
Provide
Information
Services
Provide Advisory &
Broadcast Data
Prepare & Output
In-Veh Displays
Provide Advisory &
Broadcast Data
Provide Transit
User Advisory I/F
Collect Traffic
Data & Advisory
Messages
Collect Yellow
Pages Data
Provide Traffic &
Transit Advisory
Messages
Provide Driver
Interface
Provide Yellow Pages
Data & Reservations
Collect Transit
Data & Advisory
Messages
Provide Traffic &
Transit Broadcast
Messages
Provide ISP
Operator Broadcast
Param I/F
LEGEND:
ROC Process
End process
(no further decomposition)
Non-ROC Process (potential
functions of Individual agencies)
Figure 2-9. Relevant Driver and Traveler Service Processes for ROC
November 1998
III - 17
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
a. Collect Traffic Data for Advisory Messages, which will collect and fuse traffic
data. The fused traffic data will be used to create broadcast or advisory
messages to travelers. The input data will consist of historical and current traffic
data; and historical, current, and planned incident data.
b. Collect Transit Data for Advisory Messages, which will collect and fuse transit
data. The fused transit data will be used to create broadcast or advisory
messages to travelers. The data will be provided by the transit agencies in the
ROC area.
c. Provide Traffic and Transit Broadcast Messages, which will extract traveler
information messages from the traffic and transit data stores at pre-determined
intervals and send it to the processes that broadcast these messages.
2.2.4
“Plan System Deployment and Implementation” Process Tree
This functional process tree provides a capability to analyze the system performance,
and to identify changes that will improve the operation and benefits of ITS. It obtains
data from other functions and allows engineers and planners to construct and evaluate
scenarios for system improvements. The ability to construct and evaluate scenarios is
relevant to the requirement to support training and evaluation of ROC operational
procedures. The processes selected for the ROC Logical Architecture are illustrated in
Figure 2-10 and described in the following paragraphs.
The Import Static and Historical Data process will collect static and historical data
(including video images) from other functions of the ROC systems. The collected data
may be used as a source of input for simulation and evaluation of the ROC network.
The Provide Storage and Processing Functions process will store the static and
historical data and will perform the evaluation and simulation tasks as commanded by
the users. This process will also allow the user to generate documents from the contents
of the data stores. Below are the lower-level elements of the Provide Storage &
Processing Functions process.
a. Update Data Stores, including both historical and static data stores.
b. Communicate with Transportation Planner, which provides a means to receive
the user’s commands allow the users to obtain the required information from the
system. It should be noted that, in the context of the ROC system, the users of
this process are not limited to only Transportation Planner. The frequent users
will probably be the incident-response personnel (such as police, fire, and traffic
operations personnel).
c. Evaluate System, which will perform the evaluation of the performance of the
network of roads and freeways served by the ROC agencies. This evaluation will
take into account factors that may affect the ability of the transportation systems
to move people and goods and the efficiency that these systems can achieve.
The process will be driven by the evaluation parameters provided by the users.
November 1998
III - 18
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
Plan System
Deployment &
Implementation
Import Static &
Historical Data
Provide Storage &
Processing Functions
Export Static
Data
Provide Transp.
Planner I/F
Provide Map Update
Provider Deployment
Interface
Update Data
Stores
Communicate with
Transp. Planner
Generate Static
Data
Evaluate
System
LEGEND:
ROC Process
Simulate
System
End process
(no further decomposition)
Non-ROC Process (potential
functions of Individual agencies)
Document
System
Figure 2-10. Relevant System Deployment and Implementation Processes for ROC
d. Simulate System, which provides a means to simulate the way the road and
freeway network would operate under various incident scenarios and/or traffic
management actions. The simulation process will be used to train personnel on
incident-response procedures, and to serve as a tool to develop more effective,
coordinated incident responses. The simulation process will be linked with the
evaluation process for assessing the feasibility of candidate procedures.
e. Document System, which provides capabilities for generating documentation in
electronic and printed forms. The users will have the ability to specify the
parameters of documents to be generated (e.g., type, format, form).
The last process of the Plan System Deployment and Implementation process tree that
is relevant to the ROC requirements is the Provide Transportation Planner Interface
process. In the context of the ROC system, the users of this process are not limited to
only transportation planners; the frequent users will probably be the incident-response
personnel. This process will receive a user’s commands and allow the user to obtain the
required information from the system. It will also allow the user to control the processing
parameters of and the input data to the simulation, evaluation, and generation of
scenarios. The user can obtain documentation on the simulation and evaluation results,
and import and export data through this process.
November 1998
III - 19
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
The above elements of the NIA are the last ones that are relevant to the ROC Logical
Architecture. In the next section, the way in which all the identified elements are used to
construct the ROC Logical Architecture is described.
November 1998
III - 20
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
3.0
ROC LOGICAL ARCHITECTURE DESCRIPTION
3.1
ROC Context Diagram
Although the ROC Logical Architecture is a subset of the National ITS Architecture as
described earlier in Section 2.0 of this document, the ROC system will operate in an
environment that is specific to the Maryland National Capital Region. To describe this
environment, a Context Diagram is used as shown in Figure 3-1. The Context Diagram
provides a precise definition of the ROC ITS architecture boundary. It consists of a
functional process that represents the ROC system and, more importantly, a number of
external entities known as “terminators.” Each terminator represents an external entity
that communicates data to, or receives data from the system being designed (as
described earlier in Section 2.1 of this document). The terminators for the ROC system
have been grouped as follows.
User Terminators. These are personnel at the operations centers in the ROC region and
travelers who use the ROC system (e.g., to gain access to traffic information). The User
Terminators of the ROC system are:

Traffic Operations Personnel, including operators at the TOC3, SOC,
Montgomery County TMC, and the future Prince George’s County TRIP (Traffic
Response and Information Partnership) center.

Emergency System Operators, including County Police and Fire & Rescue
Dispatchers, and State Police Dispatchers.

Travelers who access the system for traffic and travel information (for example,
through the Internet).
System Terminators. These are the systems that are not parts of the ROC system but
interact with it. They include:

Other Traffic Management (TM) systems such as the traffic signal control system
operated by the Montgomery County TMC or that by the SHA.

Emergency 911 and #77 systems operated by the County Emergency
Communications Centers and the State Police, respectively.

Transit Management Systems (such as dispatching systems), including the
Montgomery County’s Ride-On, Prince George’s County’s The BUS, WMATA,
and the MTA’s MARC.

Emergency Response Vehicle Onboard systems such as data communication.

Media systems that can request and receive traffic information (data and
images).

Planning systems that can receive historical traffic and incident data.
November 1998
III - 21
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
Pr. George’s Co. Veh
MSP Dispatcher
Montgomery ECC
Montgomery Co. Veh.
Co. F&R Dispatcher
Pr. George’s ECC
MSP
Co. Police Dispatcher
Emergency
System Operator
Montgomery
State
911& #77
Centers
Emergency
Response Veh
incident response,
coordination data
incident response,
coordination data
incident response,
coordination data
Pr. George’s
MSP Barracks
ETP/ERU
Planning
incident
notification
planning
data request
historical data
travel information request
Travelers
local traffic data
Media
travel
information
request
regional information
Montgomery TMC
Pr George’s TRIP
Radio
TV
Other TMs
travel information
regional
traffic data
traffic info display
ROC
SYSTEM
Traffic
Operations
Personnel
commands
SOC
TOC 3
transit information
incident response,
coordination data
VDOT
SHA Operators
MC Operators
DC DPW
regional
information
planning &
coordination data
Other EM
OEP
construction information
MDE
Transit
Management
parking
occupancy
travel information request
MEMA
FEMA
Ride-On
regional information
Construction
& Maintenance
Parking Service
Provider
ISP
Partners In Motion
Pr George’s DPW&T
AAA
PGC Operators
Pr George’s DPW&T
Montgomery DPWT
Montgomery DPWT
MTA
SHA
The BUS
Event
Promoters
WMATA
MTA-MARC
Kemper Open
JKC Stadium
US Air Arena
FUTURE INTERFACE OR TERMINATOR
Figure 3-1. ROC System Context Diagram showing current and future interfaces

Construction and Maintenance systems at Prince George’s County DPW&T,
Montgomery County DPWT, and the SHA to exchange current and planned
construction schedules and road closure information.

Information Service Provider (ISP) systems that can exchange information with
the ROC.

Other Emergency Management systems operated by the County Office of
Emergency Preparedness (OEP), Maryland Emergency Management
Administration (MEMA), Federal Emergency Management Administration
(FEMA), and the Maryland Department of the Environment (MDE).

Parking Service Providers of public parking facilities (e.g., Park-and-Ride lots).

Event Promoters systems that can exchange data with the ROC system for event
planning and traffic management activities. The interface to these systems is
envisioned to be available in the future.
The above definitions encompass most of the terminators defined for the ROC logical
and physical architectures. However, additional terminators may be required in the
development of the physical architecture because of the potential need to represent very
specific entities.
November 1998
III - 22
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
Recall that the Context Diagram illustrates the external environment within which a
system operates. The logical architecture, however, shows the internal functional
processes that the system must have in order to satisfy the intended requirements. In
the following subsections, the ROC Logical Architecture is described according to the
“parent” and “child” relationship of each process.
3.2
Top-Level ROC Processes
At the highest level, the ROC system consists of the processes that directly address the
needs identified by the participating ROC agencies. These needs include:
a. The ability to monitor the traffic and travel conditions in the region.
b. The ability to coordinate incident responses with other agencies and jurisdictions.
c. The ability for the appropriate ROC agencies to coordinate the dissemination of
travel information.
d. The ability to support interagency incident-response training.
The functions that will satisfy the above needs are contained in the four processes
shown in Figure 3-2 and described below.
1. The Monitor Regional Traffic process will first gather traffic condition data,
transit operations data, parking data, and construction data from all
appropriate agencies. It will then integrate the data into regional travel
information. This process will also group the received data into current data
and long-term data, and will supply the data to other processes as needed.
2. The Coordinate Multi-Agency Incident Response process will receive incident
data and facilitate the coordination of incident management activities and
information exchange among all appropriate agencies – public safety, traffic
operations, and emergency management, etc.
3. The Coordinate Traveler Information Dissemination process will maintain the
regional transportation data and facilitate the dissemination of travel
information to the media and the travelers.
4. The Provide Incident-Response Training process will help the users to
access the historical traffic and incident data to create scenarios for training
and developing pre-planned incident response procedures. This process is
not explicitly identified in the NIA, but it is composed of various elements of
the NIA as described later in its child processes.
November 1998
III - 23
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
traffic info display
State/County
T raf M gt Syst
Operati ons
Personnel
local
data
device fault data update,
response veh status
Police
archived
incident data
selected
strategy
M ap Provider
com m ands
regional
traffic data
Construction
Agenci es
4
map data update
Provi de Inci dentResponse T rai ni ng
Inform ati on
police dispatch info
construction
information
1
2
commands
Coordi nate M ultiAgency Incident
Response
M oni tor Regional
T raffic
historical
incident data
incident data
& status
incident data
& status
fire dispatch info
long-term data
current data
regional
information
request
regional
traffic data
Fire
M edi a/ISP
travel information for
media
3
Coordi nate
T raveler
Inform ati on
Dissem ination
request from media
advisory data,
broadcast data
T ravelers
request from user
inci dent response
log
Figure 3-2. Top-level Processes of the ROC Logical Architecture
3.3
“Monitor Regional Traffic” Child Processes
This process is composed of two child processes (see Figure 3-3):
1. Gather and Display Traffic Data is the process that will receive “local” data
and map data from individual agencies, integrate the data into “regional” data
and display the data upon request. It will also store the current traffic
condition data (including incidents) in a database for use by other processes.
2. Monitor Incident Data is the process that will examine the current data to
determine whether or not there is any current incident that would require
incident management responses. On the other hand, this process will also
determine if the status of a current incident should be changed because it is
already cleared by an incident-response team.
November 1998
III - 24
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
The above two processes were further decomposed, as described in the next few
paragraphs, to more clearly show the functions to be performed by the ROC system.
incident response data
regional traf f ic data
regional info request,
local data
1.1
1.2
Gather &
Display Traf fic
Data
Monitor
Incident Data
map data update
incident data
current data
Figure 3-3. Child Processes of the “Monitor Regional Traffic” Process
3.3.1
“Gather and Display Traffic Data” Child Processes
Figure 3-4 shows the child processes of the Gather and Display Traffic Data process.
These include:
1. Exchange Data with Other Traffic Centers.
2. Process Traffic Data for Storage.
3. Maintain Traffic Sensor Static Data (e.g., type and location in the ROC network).
4. Retrieve Traffic Data.
5. Provide Traffic Data Retrieval Interface.
6. Provide Traffic Operations Personnel (with) Traffic-Data Interface.
7. Update Traffic Display Map Data.
Because the ROC system does not own or operate any traffic monitoring devices, it will
create the regional traffic and travel condition information by receiving input from all
appropriate agencies through the Exchange Data with Other Traffic Centers process.
The “local” data is processed and stored by the Process Traffic Data for Storage
process.2 To establish the spatial references and other attributes of the agency-provided
data, the ROC system needs a process to Maintain Traffic Sensor Static Data.
When another process of the ROC system requests the regional data, the Retrieve
Traffic Data process will be activated through the Provide Data Retrieval Interface
process. The latter will provide pre-determined parameters for data retrieval (e.g., data
type and data format) based on the type of request it receives.
2
Although the NIA uses the word “Traffic” in these processes, the correct word, in the ROC context, should be
“Transportation.” This change was not made to the diagrams to allow the opportunity to trace the ROC architecture to its
origin  the National ITS Architecture.
November 1998
III - 25
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
Regional data requests from an operator will be submitted to the Retrieve Traffic Data
process by the Provide Traffic Operations Personnel Traffic-Data Interface. The
operator (or system administrator) can also update the pre-defined data retrieval
parameters and submit display map data requests through this interface. The Update
Traffic Display Map Data process (the last child process of the Gather and Display
Traffic Data process) will receive the operator’s request and perform the necessary
functions to update the map data.
3.3.2
“Monitor Incident Data” Child Processes
The Monitor Incident Data process has five child processes as shown in Figure 3-5 and
described below.
1. Review and Classify Current Incident Data.
2. Review and Classify Stored Incidents.
November 1998
III - 26
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
Construction
Agencies
State/County
Traf Mgt Sy stems
local
local
local
local
construction inf ormation
local transportation
data
1.1.2
traf f ic data*
incident data*
parking data*
road network data*
1.1.1
Exchange data
with Other
Traf f ic Centers
Process Traf f ic
Data f or Storage
local transit
data*
traf f ic & sensor static
data
current data
Transit Mgt Sy s
long-term data
local transit static data*
1.1.3
Maintain Traf f &
Sensor Static
Data
link data update*,
new sensor static data*
regional inf o request
request traf f ic
operations data
traf f ic data request
1.1.4
1.1.5
Prov ide Traf f ic
Data Retriev al
Interf ace
Retriev e Traf f ic
Data
requested traf f ic data
regional traf f ic data
retriev ed traf f ic
operations data
Traf f ic Operation
Personnel
parameter updates,
inf ormation request
1.1.6
traf f ic data retriev al
parameters
traf f ic
inf ormation
display
Prov ide Traf f ic
Ops Personnel
Traf Data I/F
request traf f ic map
display update
1.1.7
Update Traf f ic
Display Map
Data
map data update
map data f or
traf f ic display
Map
Prov ider
* Elements of the "local data" data f low
Figure 3-4. Child Processes of the “Gather and Display Traffic Data” Process
November 1998
III - 27
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
current data
current & planned incidents
(f rom local TMCs)
1.2.1
Rev iew & classif y
current incident
data
new, planned
incidents
planned incident data
update
new, current
incidents
planned
incident data
1.2.2
incident data
Rev iew and
classif y stored
incidents
1.2.3
current incident data update
Retriev e
Incident Data
current incident
data*
stored current incident data
retriev ed incident
operations data
incident operations data
1.2.4
request incident
operations data
Prov ide Traf f ic
Ops Personnel
Inc. Data I/F
map display
update
incident data request
request
incident
map display
update
map data f or
incident display
1.2.5
Update Inc.
Display Map
Data
* Consists of responded incidents and
unresponded incidents
Figure 3-5. Child Processes of the “Monitor Incident Data” Process
3. Retrieve Incident Data.
4. Provide Traffic Operations Personnel (with) Incident-Data Interface.
5. Update Incident Display Map Data.
November 1998
III - 28
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
As the current traffic condition data becomes available, the Review and Classify Current
Incident Data process examines each data record to determine if a new incident is
recorded for the ROC region. A recorded, new incident will then be classified as
“current” or “planned” and then stored in the appropriate data stores. The Review and
Classify Stored Incidents process will then review these incident records periodically and
update their status accordingly. If a “current” incident is cleared, this process will
remove it and then update the “current” incident data store. If a “planned” incident (e.g.,
a construction road closure or a sport event) is due to occur at the current time, this
process will transfer it to the “current” incident data store and will then update both data
stores.
Other processes of the ROC system (e.g., those related to incident response or traveler
information) may obtain details of the “current” incident data through the Retrieve
Incident Data process. An operator may also retrieve incident data through the Provide
Traffic Operations Personnel Incident-Data Interface process. This operator interface
process will also provide a means to Update Incident Display Map Data.
3.4
“Coordinate Multi-Agency Incident Response” Child Processes
The primary functions of multi-agency incident response coordination are to select an
appropriate response plan, allocate resources to manage the incident, and communicate
the status of the response operations to all responsible agencies. The following eleven
child processes (see Figure 3-6) describe these functions.
1. Respond to Current Incidents.
2. Determine Coordinated Response Plan.
3. Select Response Mode, which will determine the type and number of vehicles
to be dispatched based on the emergency vehicle status.
4. Maintain Vehicle Status (data).
5. Manage Emergency Service Allocation Store, which helps the operator to
determine the type and level of emergency services to be assigned to an
incident-response request.
6. Communicate Emergency Status, which receives response-plan information
and implementation status, and screens information for dissemination.
7. Manage Emergency Response.
8. Select Traffic Management Strategy.
9. Maintain Device Fault Data Store.
10. Manage Pre-planned Incident Response Data.
11. Provide Traffic Operations Personnel Incident-Response Interface.
November 1998
III - 29
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
2.4
f ire v eh status
Maintain Vehicle
Status
Police Barracks/
Stations
Fire Stations
f ire
dispatch
inf o
police dispatch inf o
police v eh status
emerg v eh status data
current incident
data
Select
Response Mode
Other Emerg Mgt
Agencies
f ire v eh
status
incident
details
incident data
emerg
resp v eh
status
emergency serv ice
allocation criteria
emerg serv
alloc criteria
incident
details
emerg serv alloc
criteria update
updated
response status
2.1
emergency serv ice
allocation request
2.2
identif ied
emergency
Respond to
Current
Incidents
emerg v eh
dispatch status
2.3
2.5
Manage Emerg
Serv ice Allocatn
Store
Determine
Coordinated
Respone Plan
emergency serv ice
allocation data
incident
response log
emerg response
data f or
communications
emerg response data f or mgt
2.6
incident details,
emerg response plan
Communicate
Emerg Status
emerg response status,
emerg response plan
selected
strategy
detailed
emerg status
2.8
Select Traf f ic
Mgt Strategy **
State/County
TMs
dev ice
f ault data
update
2.7
Manage
Emergency
Response
Operators
pre-planned inc.
response updates
dev ice f ault
data
pre-planned inc.
response data*
pre-planned inc.
response
commands
2.9
2.10
Maintain Dev ice
Fault Data Store
Manage Preplanned Inc.
Resp. Data*
pre-planned inc.
response data*
NOTE:
* Known in the NIA as "def ined responses"
** May include signal priority /preemption
pre-planned inc.
response data
pre-planned inc.
response updates
2.11
Prov ide Traf f ic
Ops Personnel
Inc. Resp. I/F
requested
pre-planned inc.
response data
Figure 3-6. Child Processes of the “Coordinate Multi-Agency Incident Response” Process
When there is an incident that would require regional coordination (e.g., one that has the
potential to impact traffic in another jurisdiction, or one to which the local jurisdiction has
not been able to respond because of a lack of resources), the ROC system will activate
the Respond to Current Incidents process. This process will receive details of the
incident from the “current” incident database and then provide this information to other
processes for response coordination. The response information is also logged in the
Incident Response Log for future reference and evaluation.
Once the Determine Coordinated Response Plan process receives the incident
information from the Respond to Current Incidents process, it will request emergency
response resources from the Manage Emergency Service Allocation Store process; and
November 1998
III - 30
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
it will then provide the incident details to the Select Response Mode. The response
mode will consist of the type and number of vehicles to be dispatched to the incident
based on the incident type and resource availability. An input to the resource dispatch
decision is the status of emergency-response vehicles. This information is provided to
the Select Response Mode process by the Maintain Vehicle Status process, which in
turn receives the information from the police and fire/rescue stations, and traffic
operations agencies.
A part of the response plan coordination is to inform other agencies and other ROC
processes of the plan’s contents and implementation status. The Communicate
Emergency Status process is responsible for this function. It receives details of the
selected response plan from the Determine Coordinated Response Plan process, and
the response status from the Manage Emergency Response process.
In addition to the processes that allocate and dispatch resources to the incident, the
ROC system will also Select Traffic Management Strategy from a set of pre-planned
strategies. To aid in this selection, equipment fault data will be provided by the Maintain
Device Fault Data Store process. The slelected strategy will be transmitted to the
appropriate traffic operations agencies for implementation (i.e., the Montgomery County
TMC, or the Prince George’s future TRIP center, or the SHA’s SOC or TOC3).
The pre-planned incident response strategies will be continually evaluated and updated
to account for changes in incident response procedures and/or technologies. These
functions are performed by the Manage Pre-planned Incident Response Data process
(which may employ expert-system technologies) and the Provide Traffic Operations
Personnel Incident-Response Interface process. The latter allows incident management
personnel to review, override, and update incident response plans.
3.5
“Coordinate Traveler Information Dissemination” Child Processes
This Coordinate Traveler Information Dissemination process will gather and maintain the
regional transportation data, and facilitate travel information dissemination to the media
and travelers. The travel information will include the current and planned incidents,
transit services (e.g., schedules, routes, etc.), and parking availability. The seven child
processes of the Coordinate Traveler Information Dissemination process are as follows
(see Figure 3-7):
1. Collect Travel Information
2. Provide Current Incident Store Interface
3. Provide Planned Incident Store Interface
4. Determine Parking Lot State
5. Provide Traffic and Transit Broadcast Messages
6. Provide Media Traffic and Incident Data Interface
7. Determine Park-and-Ride Needs for Transit Management
November 1998
III - 31
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
parking lot transit request
State/County
TMs
parking guidance
f or VMS
3.4
static data f or parking lots,
parking serv ice-prov ider input data
3.7
parking lot ocupancy
Determine
Parking
Lot State
adv isory data,
broadcast
data
parking lot
occupancy
conf irmed inc.,
congestion, & parking
data output
inci., congestion, &
parking data output
3.5
3.6
parking av ail.
data request
Prov ide
Traf f ic & Transit
Broadcast Msgs
adv isory & broadcast
data request
Prov ide
Media Traf f ic &
Inc Data I/F
3.1
Collect Trav el
Inf ormation**
current transit data*
inci., congestion, &
parking data output
trav el inf o to media
current inc. data
request
planned inc. data
planned
inc. data
request
current inc. data
3.2
3.3
planned-incident
new data*
Determine P&R
Needs f or transit
Mgt
Prov ide Planned
Incident Store
Interf ace
planned
incident store
Prov ide Current
Incident Store
Interf ace
current data
current inc. new data*
current inc. data update*
current
incident store
* Elements of "Regional Traffic Data"
** including travel conditions & advisory info.
Figure 3-7. Child Processes of the “Coordinate Traveler Information Dissemination”
Process
The process to Collect Travel Information will periodically send requests to the Provide
Current Incident Store Interface process, the Provide Planned Incident Store Interface
process, and the Determine Parking Lot State process for updated information. The
received information is then fused and disseminated to the media through the Provide
Media Traffic and Incident Data Interface process according to pre-determined criteria.
The same information will also be used to formulate broadcast messages (by the
Provide Traffic and Transit Broadcast Messages process) to be displayed by other
systems such as TAR, VMS, or the Internet.
To facilitate multi-modal coordination, parking lot occupancy information for the region
will be used to determine transit service needs at park-and-ride facilities. This function
November 1998
III - 32
Regional Operations Coordination (ROC)
Task 3, Vol. 1 - ROC Logical Architecture
will be performed by the Determine Park-and-Ride Needs for Transit Management
process. Parking occupancy information may also be displayed along major roadways
to help inter-modal users to make informed choices for their travel.
“Provide Incident-Response Training” Child Processes
3.6
To effectively support incident-response training, the ROC system must have the
capability to record and replay past incident scenarios and the responses to those
incidents. It must provide a means for the trainers and the trainees to review past
events, critique response actions, identify shortcomings, document lessons learned, and
create new response procedures. For new and/or modified response procedures, the
ROC system must be able to help the users to evaluate their effectiveness and, if
possible, their benefits. This evaluation capability inherently requires a capability to
simulate incident events, their impacts on traffic, as well as the effects of the intended
response actions. The simulation capability may also be used to develop responses to
anticipated incident scenarios (e.g., those related to domestic terrorism) and to analyze
“what if” situations. The above functional needs for ROC incident-response training may
be described by the following six processes (see Figure 3-8).
1. Provide Incident Management Training Interface
2. Retrieve Historical Incident Scenario Data
3. Analyze Incident-Response Log
4. Update Data Stores
5. Simulate Scenario
6. Evaluate Scenario
An incident training session may begin with a user (either a trainer or a trainee) entering
a scenario search command to the ROC system through the Provide Incident
Management Training Interface process. This search command will be transmitted to
the Retrieve Historical Incident Scenario Data process, which will search the long-term
data store for the requested incident scenario and its identification. The Analyze
Incident-Response Log process will then search the log for data on the responses to this
incident and/or other responses to similar incidents. At this point, the Update Data
Stores process refreshes all training databases. The users now can perform a number
of training functions as follows:

Replay the incident for review and critique.

Simulate the incident scenario with new or modified responses (through the
Simulate Scenario process).

Evaluate traffic impacts of response procedures (through the Evaluate Scenario
process).
November 1998
III - 33
Regional Operations Coordination (ROC)
long-term
data
Task 3, Vol. 1 - ROC Logical Architecture
historical inc.
impact data
scenario search command
inc. response
training data
pre-def ined
inc. resp. update
inc. scenario data
4.2
Retriev e
Historical Inc.
Scenario Data
historical inc.
scenarion data
4.1
scen. ev al results
scen sim results
4.4
historical inc.
identif ication
4.3
inc. scenario
training data
scenario sim
parameters
Update Data
Stores
Prov ide Inc Mgt
Training I/F
scenario ev al.
parameters
historical inc.
resp. data
4.5
Analy ze Incident
Response Log
4.6
Simulate
Scenario
potential, pre-planned
inc. response data
simulation data
Ev aluate
Scenario
incident
response log
Figure 3-8. Child Processes of the “Provide Incident-Response Training” Process

View the simulation and evaluation results, or create documentation from these
results (through the Provide Incident Management Training Interface process).
The above training functionality may also be used to create potential incident scenarios
(e.g., HAZMAT and terrorist incidents) and develop pre-planned responses accordingly.
The users may also use this functionality to evaluate and refine existing response
procedures or to access the historical database for planning purposes.
November 1998
III - 34
Regional Operations Coordination (ROC)
4.0
Task 3, Vol. 1 - ROC Logical Architecture
SUMMARY
Based on the ROC functional requirements identified by the participating agencies, the
ROC Logical Architecture has been developed. To ensure that the ROC architecture is
consistent with the National ITS Architecture while preserving the regional needs and
requirements, an adaptation process was developed and applied to the ROC Logical
Architecture. The details of the adaptation methodology are described in Section 2.0 of
this document, and those of the ROC Logical Architecture in Section 3.0. In this
architecture, all the process names and almost all data flow names are kept the same as
those of the NIA for cross-referencing purposes.
This ROC Logical Architecture provides a framework for tailoring the NIA Physical
Architecture to create the ROC Physical Architecture, which is described in another
document (Volume II of Task 3 of this Project). Both of these architectures were used to
identify and define the needed initiatives to fulfill the ROC requirements.
November 1998
III - 35