System Requirement Specification for the IH-10 Integrated Corridor Management System (ICMS) in San Antonio, Texas
You will need the Adobe Reader to view the PDFs on this page.
PDF (3.4 MB)
March 31, 2008
FHWA-JPO-08-048
EDL Number 14428
Submitted to:
U.S. Department of Transportation
Federal Highway Administration
Federal Transit Administration
Research and Innovative Technology Administration
TABLE OF CONTENTS
1.0 PROJECT INFORMATION
1.1 Project Identification
Return to Contents
This Requirements Specification Document (RSD) was developed under the project titled “TransGuide Integrated Corridor Management – Stage 1” as part of the United States Department of Transportation (USDOT) Integrated Corridor Management (ICM) program.
1.2 Integrated Corridor Management (ICM) Background
Return to Contents
Congestion in U.S. metropolitan areas is a serious and growing problem. Transportation agencies have typically implemented traffic management policies and strategies to improve mobility and reliability on a specific network, e.g., expressway, instead of looking at the entire transportation system across multiple transportation networks. Integrating traffic management strategies with adjacent networks, e.g., arterials and public transit, within a corridor will provide opportunities for transportation authorities to maximize mobility across the combined transportation networks. ICM is the “next generation” of transportations strategies to reduce congestion. ICM will be implemented by using improved individual network traveler information data and integrated operational procedures. For the individual traveler’s experience, ICM will result in reduced congestion and mobility and will make travel times more reliable and predictable. In addition, ICM will result in improved incident management and a reduction of incidents, lower emissions, and reduced fuel consumption.
1.3 Document Purpose
Return to Contents
The purpose of the document is to capture the requirements of the San Antonio ICM System (ICMS). Requirements are primarily concerned with capturing "what" the system will accomplish as opposed to "how." The document is a valuable and essential component of the system engineering process as part of the ICM project to improve quality and efficiency in implementing the ICM corridor in the San Antonio region. The document captures the system functionality to communicate the information to stakeholders and vendors that would implement the ICMS. Through revisions, the Requirements Specification Document has provided a mechanism for obtaining feedback and refining the system functions.
1.4 Requirements Working Group Meetings
Return to Contents
This document was developed in coordination with multiple transportation agencies within the San Antonio region. Four stakeholder working group meetings were held to discuss the requirements for ICMS in the proposed corridor. The dates of the meetings along with a summary of what was discussed are listed below.
Meeting 1 – May 30, 2007:
The main purpose of this working group meeting was to introduce the requirements development process to the regional ICM stakeholders. The system engineering process, USDOT guidance on the requirements gathering process, and sample ICM requirements were reviewed. The USDOT feedback on the draft ICM Concept of Operations was also reviewed at the meeting.
Meeting 2 – July 27, 2007:
This meeting was utilized to discuss ideas for future transit involvement, which included park and ride, bus rapid transit, and express services. The requirements format was reviewed in detail, confirming the elements that would be collected for each requirement and the system allocations for organizing the requirements. High level requirements extracted from the Concept of Operations were reviewed, and the criticality and high level implementation of the associated systems were discussed. Preparations for the USDOT site visit to San Antonio, Texas on August 9, 2007 were also made at the meeting.
Meeting 3 – November 27, 2007:
The ICM System Architecture was reviewed at the meeting. The architecture was utilized to determine the ICM system boundaries of what will be implanted under the project and documented in the Requirements Specification Document. The ICM user interface approach was discussed, and the functional needs for implementing the ICM tactics were reviewed. In addition, the draft Decision Support System Requirements were reviewed, and feedback was collected. Preparations for the USDOT requirements team site visit to San Antonio, Texas on November 29, 2007 were also made at the meeting.
Meeting 4 – January 11, 2008:
The primary purpose of this meeting was to review draft requirements and to discuss requirements for evaluating corridor performance measures. The draft requirements for the ICM operations user interface, web site, personal emergency trip planner, and data exchange were reviewed with the stakeholders. Requirements for evaluating system and corridor performance were discussed and captured.
1.5 Document Overview
Return to Contents
This RSD was developed under the project titled “TransGuide Integrated Corridor Management – Stage 1” as part of the Federal Highway Administration’s Integrated Corridor Management program. The TransGuide ICM RSD provides high level and detailed level system requirements for the San Antonio IH-10 corridor implementation of ICM. Section 1.0 provides the scope of the document. Section 2.0 contains the functional architecture. Section 3.0 describes the requirements attributes. Section 4.0 contains the requirements captured in multiple tables. Notes are included in Section 5.0.
1.6 Related Documents
Return to Contents
This section lists the documents referenced in this document.
Document ID: FHWA-JPO-06-042
Originator: FHWA JPO
Issue: April 12, 2006
Title: ICM Implementation Guidance
Document ID: FHWA-JPO-06-032
Originator: FHWA JPO
Issue: April 18, 2006
Title: ICMS Concept of Operations for a Generic Corridor
Document ID: TG-ICM-COO-1.0.2
Originator: Southwest Research Institute® (SwRI)
Issue: March 31, 2008
Title: TransGuide Integrated Corridor Management Concept of Operations
Document ID: C2CI-SRS-4.0.0
Originator: Texas Department of Transportation
Issue: November 8, 2007
Title: Center-to-Center Communications Infrastructure Software Requirements Specification
Document ID: C2C-SDD-3.1.1
Originator: Texas Department of Transportation
Issue: May 28, 2004
Title: Center-to-Center Communications Software Design Document
Document ID: C2C-SICD-4.0.0
Originator: Texas Department of Transportation
Issue: August 8, 2007
Title: Center-to-Center Communications Status Interface Control Document
2.0 FUNCTIONAL ARCHITECURE
Return to Contents
This section first provides an overview and introduction of the ICM concept of operation in San Antonio including a description of the corridor, networks, stakeholders, and operating conditions. An overview of the ICM approaches and proposed tactics is also provided. Next, this section provides an overview of the ICMS system architecture. Finally, a description of the system components that make up the ICMS is provided.
2.1 ICM Overview / Introduction
Return to Contents
San Antonio, Texas was selected as one of eight ICM pioneer sites for the development of the Concept of Operations (COO), corridor data modeling, and the development of functional requirements. This RSD was developed in coordination with the San Antonio ICM team, which includes the Texas Department of Transportation (TxDOT) San Antonio District as the lead agency. Additional stakeholders include the City of San Antonio (CoSA), VIA Metropolitan Transit (VIA), SwRI, and the Texas Transportation Institute (TTI).
2.1.1 ICM Corridor Boundaries, Networks and Stakeholders
Return to Contents
The San Antonio ICM stakeholder team has selected a corridor in the northwest area of the San Antonio region for modeling and demonstration of ICM. The corridor was selected because it connects major workplace concentrations and the downtown region of San Antonio. IH-10, the major expressway route around which the corridor was developed, handles approximately 190,000 vehicles a day. In addition to the traditional expressway services available, the corridor has major signalized arterials that can be used to traverse the same geographic area. Bus transit, which uses both expressways and arterials, is available to reach a multitude of destinations within and beyond the corridor.
The IH-10 ICM corridor is composed of three main transportation networks: an expressway network, an arterial network, and a transit network. A summary description of the networks in the corridor is given below.
-
Expressway Network - San Antonio’s ICM corridor extends from Loop 1604 in the northwest part of the city to the downtown area. Longitudinally, the corridor includes one major expressway (IH-10) as well as several arterials including Fredericksburg, Vance Jackson, Northwest Military Highway, Babcock, and Bandera. Expressways providing cross connectivity include Loop 1604 and Loop 410. Arterials providing cross connectivity include DeZavala, Huebner, Wurzbach, and Callaghan. High-capacity controlled-access roadway facilities in northwestern San Antonio are the primary mobility providers for the region. IH-10 is the only radial expressway of this type serving the northwest part of the city, establishing itself as the primary route between northwest and downtown San Antonio. IH-10 also forms the western leg of a ring of intersecting, controlled access interstate and US highways surrounding downtown. Providing circumferential service around the body of the inner city and outer areas, Loop 410 is among the highest volume roadways in the city, especially in the northern part of the city. Outside of Loop 410, Loop 1604 primarily serves suburban commuting, shopping, and educational trip needs.
-
Arterial Network - The arterial roadway network in the proposed corridor within San Antonio serves a myriad of functions for its users. Arterials providing cross connectivity include DeZavala, Huebner, Wurzbach, and Callaghan. They collect longer-distance trips destined for the interstate (IH-10) and deliver trips from the interstate to local destinations. In addition, the local network serves and distributes shorter trips for a myriad of trip types including school, shopping, and local commuting trips. All of the arterial intersections within the study corridor are managed by CoSA with the exception of the signals within incorporated towns, which are operated by TxDOT. Intersections along Loop 410 and IH-10 are operated by either TxDOT or CoSA, depending on location. Since CoSA uses Type 170-specification traffic signal controller equipment and TxDOT operates signals and interchanges using equipment based on National Electrical Manufacturers Association (NEMA) standards, signal coordination and timing continuity issues are present along major routes.
-
Transit Network - Transit service is extensive within the IH-10 ICM corridor. Over the years, transit service has expanded to meet commuting and educational trips needs and now includes park-and-ride service at IH-10 and Loop 1604, IH-10 and Loop 410 (Crossroads Mall), and downtown San Antonio. Express bus routes include service between the University of Texas at San Antonio (UTSA) main campus near IH-10 and Loop 1604 and the UTSA downtown campus along IH-10 just west of downtown. Transit services are also provided along cross-connect and parallel arterials throughout the corridor.
The stakeholders considered in the development of San Antonio ICM strategies are listed in Table 1.
|
|
|
|
|
|
|
|
2.1.2 Corridor Operating and Institutional Conditions
Return to Contents
The proposed corridor provides transportation for the movement of commuters, freight, recreational, and other traffic within and through the populous northern section of San Antonio. Traffic congestion along the roadway-based networks is a growing problem in the IH-10 corridor, particularly during the peak periods. Some specific issues are listed below.
-
Over time the regular expressway lanes continue to have increased use and congestion. There has been significant loss of reliability during peak travel periods.
-
The main arterial roadways in the corridor normally operate near or at capacity during peak periods. Due to multi-agency control of signalized intersections along several primary arterials, a continuously operated signal pattern cannot be utilized to maximize arterial throughput.
-
With respect to transit operations within the corridor, the roadway congestion problems noted above have also degraded the reliability of operation of the buses during peak periods – particularly on the arterials and surface streets.
To help reduce the amount of congestion and improve traffic flow, each of the transportation agencies located in the corridor have implemented several different approaches to improve the performance of their networks. A summary of the approaches used by each agency is shown in Table 2.
| TxDOT (Expressway Network) |
|
|---|---|
| City of San Antonio and smaller incorporated municipalities (Arterial Network) |
|
| VIA (Bus Transit Network) |
|
These strategies have allowed each agency to improve operations within their respective networks. However, in the past there has been little information and decision sharing across different agencies with the exception of major events and incidents.
Although there is a history of routine cooperation in the corridor, the capability is in place to allow for information sharing and a more comprehensive ICM approach.
2.1.3 Need and Potential for ICM
Return to Contents
The IH-10 corridor is affected by several unique issues that have made it a prime candidate for ICM. The corridor links the downtown San Antonio central business district with residential areas, regional commercial development, educational institutions, and the medical center complex in the northwest quadrant of San Antonio. In addition to the normal business activity in the central business district, downtown San Antonio is the location of the Riverwalk (the most visited tourist destination in Texas). Within the ICM corridor there are additional major attractions including Six Flags Fiesta Texas, The Rim (retail and commercial development), the UTSA, and the Shops at La Cantera, which also attract numerous visitors. Along the western portion of the corridor, there are other major traffic generators that include the South Texas Medical Center, the United States Automobile Association (USAA) headquarters, and Valero Energy Headquarters. These various locations are linked by the IH-10 corridor.
To improve on existing network operations and to manage the proposed corridor from an integrated multi-modal approach, several needs that could be addressed with the ICMS concept were identified. The needs were gathered in workshops and in one-on-one meetings with the participating stakeholder agencies. These needs are summarized in Table 3.
|
2.1.4 ICM Operational Approaches and Strategies
Return to Contents
During stakeholder meetings and workshops, the stakeholders identified several strategies that could be used to achieve the goals and objectives identified for the proposed corridor. These strategies were categorized into the following ICM approaches.
-
Information Sharing/Distribution : Real-time data from TransGuide is available to the public via website to provide pre-trip information to travelers. This information is also used for en-route devices such as DMSs and LCSs to provide travelers with the current conditions of the roadways. By sharing this information between stakeholders, information relating to the corridor as a whole can be provided to travelers. Information could then be used to describe current conditions on all available networks in the corridor (via website, DMS, etc.). Information sharing tactics such as these will create an integrated network that can be used as the base for many other ICM approaches. An example of this could be using a DMS on IH-10 to display a message informing travelers of congestion on a cross-connect arterial, and suggesting an alternate route.
-
Improve the Operational Efficiency of Network Junctions and Interfaces : A common theme through all ICM approaches is to promote modal shifts by informing travelers of current conditions across all networks in the corridor. To allow these shifts to be effective, the stakeholders must have methods in place to accommodate large traffic shifts across networks. For example, stakeholders could modify arterial signal timing to compensate for traffic being shifted off the expressway or modify bus priority signal timing to allow more buses to stay on schedule. Accommodating these shifts across networks will allow the corridor to make the best use of all of its transportation networks and allow travelers to choose from multiple transportation alternatives.
-
Accommodate/Promote Cross-Network Route and Modal Shifts : A common theme through all ICM approaches is to promote modal shifts by informing travelers of current conditions across all networks in the corridor. To allow these shifts to be effective, the stakeholders must have methods in place to accommodate large traffic shifts across networks. For example, stakeholders could modify arterial signal timing to compensate for traffic being shifted off the expressway or modify bus priority signal timing to allow more buses to stay on schedule. Accommodating these shifts across networks will allow the corridor to make the best use of all of its transportation networks and allow travelers to choose from multiple transportation alternatives.
-
Manage Capacity and Demand within the Corridor : In order to successfully implement shifts across networks, there must be spare capacity on the adjacent networks. If traffic demand becomes too high relative to capacity for this to be possible, it will be necessary to increase the capacity of the networks or reduce the traffic demand in the corridor. This can be accomplished in several ways. For example, the stakeholders could adjust the number of buses to increase capacity, open shoulders on expressways, implement alternative signal timing plans, modify transit fares, or funnel traffic to another portion of the network. The success of these approaches will help to maintain and enhance the reliability and mobility of traffic throughout the corridor.
2.1.5 ICM Concept Operational Description
Return to Contents
During stakeholder meetings and workshops, the stakeholders identified several strategies that could be used to achieve the goals and objectives identified for the proposed corridor. These strategies were categorized into the following ICM approaches.
Each agency possesses an equal vote in the management process. Transportation issues are effectively coordinated by this agency committee. Each agency representative is responsible for providing the regional support and interface to their respective agency according to committee authority.
The TransGuide facility will host the regional ITS operations, and all decisions in relation to ITS operations are coordinated through the TransGuide facility. Assigned agency staff is responsible for the daily operations, response scenarios, and administration. Most agencies maintain 24/7 operations on a normal basis.
Performance measurement plays a key role in the improvement of ITS operations for the region. Integrated data mining and archiving is performed at the TransGuide facility. This provides useful transportation management, transportation engineering, and corridor trend models and reports.
2.1.6 ICM Corridor
Return to Contents
The San Antonio area has a unique expressway configuration in that there are three loops (one around downtown, Loop IH-410 about 7 miles from downtown and Loop 1604 about 15 miles from downtown) with four major interstate or US highways acting as radial expressways interconnecting the loop expressways (IH-10, IH-35, IH-37, and US-90).
As Figure 1 shows, the San Antonio ICM team has selected a 15-mile expressway and arterial corridor along IH-10 from the IH-35/IH-10 Interchange in downtown San Antonio to the Loop 1604/IH-10 Interchange in northwest San Antonio. The IH-10 ICM corridor is bound on the west by State Highway (SH) 16 (Bandera Road) and on the east by Farm-to-Market (FM) Road 1535 (Northwest Military Highway). IH-10 runs roughly a southeast to northwest direction in the corridor area.
Figure 1. Proposed San Antonio ICM Corridor
The corridor includes one major longitudinal expressway (IH-10) as well as several arterials including Fredericksburg, Vance Jackson, Northwest Military Highway, Babcock, and Bandera. Expressways providing cross connectivity include Loop 1604 and Loop 410. Arterials providing cross connectivity include DeZavala, Huebner, Wurzbach, and Callaghan. The corridor boundaries in Figure 2 cover some of the most important, prevalent travel patterns (both recurrent and non-recurrent) as well as major highway, arterial, and transit facilities in northwest San Antonio. The boundaries, however, are preliminary. The final boundary selection will be made in conjunction with the U.S. Department of Transportation, taking into account a variety of factors such as Stage 2 modeling/simulation capabilities/requirements, and nature and characteristics of potential events to manage (the larger the event, the larger the area potentially impacted, which obviously has an effect on management area boundaries).
The IH-10 ICM Corridor encompasses a variety of land uses such as residential, commercial, industrial, and institutional. The corridor includes several major traffic generators, including the Loop 1604 and downtown campuses of UTSA, the corporate headquarters of USAA and Valero Energy, the South Texas Medical Center, and downtown San Antonio. Other important transportation destinations include Crossroads Mall (IH-10 @ Loop 410) and The Rim and Shops at La Cantera (IH-10 at Loop 1604), as well as tourist attractions (e.g., Six Flags Fiesta Texas just outside Loop 1604 and the Riverwalk and the Alamo in the downtown area). Over the last several decades, major changes in land use have also occurred, where urban commercial and residential development, which was primarily confined to the area inside Loop 1604 through the early 1990s, has extended well beyond Loop 1604. Concomitant increases in commuting and retail activity have resulted in additional traffic demand along both expressway and arterial networks.
The IH-10 ICM corridor is one of San Antonio’s most heavily traveled corridors and is steadily increasing due to the growth along the corridor and continuing west. As an illustration, Table 4 summarizes Average Annual Daily Traffic (AADT) numbers observed on the corridor in 2004. Over the years, transit service has also expanded to meet commuting and educational trips needs and now includes park-and-ride service at IH-10 and Loop 1604, IH-10 and Loop 410 (Crossroads Mall), Loop 410 and Bandera Road, and downtown San Antonio. Express bus routes include service between the UTSA IH-10 at Loop 1604 campus and the UTSA downtown campus at IH-10 just west of downtown.
| Facility | Sector | AADT |
|---|---|---|
IH-10 |
Loop 1604 – Loop 410 |
140,000 – 188,000 |
IH-10 |
Loop 410 – Downtown |
163,000 – 166,000 |
Loop 1604 |
Bandera Rd – IH-10 |
78,000 – 88,000 |
Loop 1604 |
IH-10 – Northwest Military Highway |
102,000 |
Loop 410 |
Bandera – Northwest Military Highway |
165,000 – 174,000 |
Bandera Rd |
Loop 1604 – Loop 410 |
35,000 – 56,000 |
Bandera Rd |
Loop 410 – Downtown |
24,000 – 36,000 |
Northwest Military Highway |
Loop 1604 – Loop 410 |
9,700 – 21,000 |
Fredericksburg |
IH-10 (north) – IH-10 (downtown) |
27,000 – 40,000 |
2.1.7 ICM Tactics and Strategies
Return to Contents
The San Antonio region needs to focus on three primary networks as part of its ICM effort. Those networks are TxDOT’s expressway system, the city’s arterial signal system, and VIA’s transit system. During meetings and workshops the stakeholders identified several tactics, as defined by the ICM Request for Information (RFA), which could be used to support the proposed strategies. The goal of these tactics was to help meet the high level needs identified in the proposed corridor. The needs identified are shown in Table 5.
| ICM Needs |
|---|
After hours operational procedures for the arterial traffic operations as CoSA staff is unavailable for 24/7 operations. |
Method for sharing computer-aided dispatch system data between the City of San Antonio, Balcones Heights, Castle Hills, Leon Valley, and Shavano Park Police Departments. |
Need for seamless traffic signal system control along corridor arterials. |
Automated notification during incident scenarios for VIA from external agencies. Current information exchange is accomplished manually. |
Central control for all devices. Communications network infrastructure requires update. |
Improved coordination with Balcones Heights, Castle Hills, Leon Valley, and Shavano Park Police Departments for incident management. |
Procedure for notifying travelers of modal shifts without violating TxDOT policy preventing route guidance on DMSs. |
Extended usability of entrance ramp DMS. |
Addition of red-light enforcement cameras. |
Improvement of communication network to traffic signals. |
Pre-planned timing patterns for specific events and scenarios. |
Signal priority system for buses. |
Real-time arrival update signs at certain bus stop locations. |
Formal procedure for information and data sharing system. |
Formal procedure for communication between agencies. |
Decision support system available to all agencies. |
Coordinated operations for several construction projects throughout the corridor. |
These tactics were separated into two groups of approaches: the Network Management Approach and the Corridor Management Approach. A high-level functional diagram of these tactics is provided in Figure 2, and a summary of each is contained in the following section.
Figure 2. High Level Functional Diagram of ICMS Tactics
Network Tactic 1 - Expansion of CoSA’s Traffic Signal System
TxDOT is working with CoSA to develop an area-wide fiber and communications sharing plan that will include allowing CoSA’s traffic signal controllers to use TransGuide’s fiber network to transmit data from the signal controllers to its operations system at the TransGuide Operations Center. Signal controller vehicle count and occupancy data, as well as video snapshots from the video image vehicle detectors (VIVDs), will be available for use by the ICMS. An interface from the CoSA signal operations system to the TransGuide Data Archive will be developed. This integration is scheduled as part of the CoSA communication upgrade and will begin in the downtown central business district in early 2008. Once the expansion is complete, it will provide more dependable and seamless control of traffic signals throughout the corridor.
Network Tactic 2 - Entrance Ramp DMS
All entrance ramps in the corridor area instrumented with the frontage road DMS are also equipped with a detection device, either a loop detector or a microwave sensor. The data from the entrance ramp detection devices is transmitted to the TransGuide Advanced Traffic Management System (ATMS) system and is used to provide data for the incident detection algorithm. The detection device provides vehicle counts and occupancy data. The signalized intersections in the corridor are instrumented with a VIVD system. The traffic signal VIVD system units provide vehicle count and occupancy data to the signal controllers at the intersection. This data will be transmitted to the CoSA signal 0perations system located at TransGuide.
This will allow the ICM team to develop an application that will incorporate expressway travel times, adjacent signalized intersection delay calculations, entrance ramp traffic volumes, and intersection traffic volumes. This data can then be used to place messages on the existing entrance ramp DMSs to provide the traveling public with advisories that will direct drivers to remain on the frontage road during congested periods when overall vehicle throughput can be improved by balancing the flow of traffic on the expressways with the frontage roads.
Network Tactic 3 – Network-Based Advanced Traveler Information Systems
TransGuide provides travelers with information about delays due to railroad operations that cross expressway access or frontage roads. This information is provided by the Advanced Warning to Avoid Railroad Delays (AWARD) program. There are several arterials that cross IH-10 in the corridor area that can be impacted by a train traveling in a north-south direction on tracks that parallel IH-10. A slow moving train can block crossing traffic for up to 30 minutes, causing a potential backup onto IH-10 in some areas.
VIA’s web site provides Route Service, which includes features such as a personal route planner, bus schedules, fares and passes, and express services; Accessibility Service, which includes features such as transit services for passengers with disabilities, reduced fares, bus schedules to special events and venues; and Rider News, which includes features such as service interruption alerts due to construction, weather, traffic accidents, and other road conditions. VIA is in the process of installing “On Street” passenger signs that provide up-to-date bus arrival information based on the present location of the bus in relation to the destination location and the speed of the bus.
CoSA’s web site provides real time traffic incident reporting from the Police Department, street closures from the Public Works Department, and emergency preparedness information from the Office of Emergency Management on events such as fire, flood and thunderstorms, hazardous materials accidents, hurricanes and tornados, winter storms, and acts of terrorism.
These sites, as well as the new integrated corridor website, will provide travelers with up-to-date information for all methods of transportation available in the corridor. This will allow for a better balance of traffic and improve the overall efficiency of the corridor.
Corridor Tactic 1 - Co-location at TransGuide
The benefits of co-location of transportation (TransGuide and CoSA), transit (VIA) and incident response (San Antonio Police Department [SAPD]) agencies at TransGuide are well established. Currently, the TxDOT operations staff conducts expressway operations for the San Antonio region from the TransGuide Operations Center. The CoSA Public Works Department also conducts traffic signal operations from TransGuide. VIA Metropolitan Transit conducts bus dispatch operations from TransGuide. This includes the fixed route buses as well as the VIA Trans operations. Finally, the San Antonio Police Department performs 911 traffic incidents dispatching from the TransGuide Operations Center.
At present, VIA's controllers get the information real-time at TransGuide, and then they notify the dispatchers at VIA's central dispatch in the first-floor operations area, who then send text messages to the vehicle operators. Central dispatch can also send messages to riders using one-line crawl message signs that are on board the buses.
Corridor Tactic 2 - Enhanced Traffic Signal Control:
Traffic responsive operation allows a system of traffic signals to change predetermined timing plans in response to vehicle speeds, volumes, densities, and occupancies along the corridor. The characteristics of the traffic stream are measured by system detectors placed at the entry points into the system as well as between major intersections within the system. Once the characteristics of the traffic crossing the system detectors reach a user-defined threshold, a user specific timing plan can be called. In the case of the Fredericksburg Road corridor, system detectors could be placed on key exit ramps from IH-10 to measure the volume of exiting traffic. If this volume exceeds a threshold value, which would be set at a level that would be experienced under normal traffic conditions, traffic signal operations can be alerted, allowing them to switch to a timing plan to account for the increased diverting traffic. This would also allow for pre-planned incident management timing patterns that could be used to manage the flow of traffic in the event of an incident on an arterial, or an incident on an expressway that causes large amounts of traffic to exit onto the same frontage roads and arterials.
Corridor Tactic 3 - Sharing of Real Time Data and Joint Use of Data Archive
Since 1996, TransGuide has shared video with the local media and the general public by broadcasting live video using a 1,000 watt low power television transmission. TransGuide has provided video switching equipment that allows external agencies to have camera selection ability. Twenty channels of video are broadcast simultaneously. TxDOT has agreements in place with the three local network affiliates and one dedicated local cable news channel for this evideo access.
The components making up the real time data, including traffic measurements and incident management data, are written to local storage moments after the data is read from roadway devices or dynamically produced by the traffic management system. This data is then made available in a number of locations in the network for internal and external uses. Since 1997, TransGuide has also made available archived lane data (20-second speed, volume, and occupancy data from each loop detector) to consultants, university researchers, and the general public. The data is stored in compressed file format. A set of web services designed to utilize the Center-to-Center (C2C) system has been running in production at TransGuide since January 20, 2007. These services will be used as a means of delivering information products produced from this data. Similarly, the presence of an Extranet in TransGuide will facilitate direct access to data stores for corridor management partners as well as emergency management organizations and university researchers engaged in TxDOT projects.
The final result of this network of real-time data and data archive would be a decision support system that would be available to each stakeholder organization. This support system would provide specific data types to different organizations, allowing them to view data from other organizations that would be the most useful to them. This would be used to aid in decision making and improving the overall flow of traffic throughout the corridor.
Corridor Tactic 4 - Personal Emergency Transportation Plan
The personal emergency transportation plan will consist of a website that provides travelers with the ability to plan alternate routes for their most common daily commutes. This website will use data provided by all of the stakeholders and will be linked to each of their respective websites. By entering beginning and ending addresses, travelers will be provided with directions using the expressway network, arterials, and VIA bus routes. These routes can be updated as necessary due to construction, or VIA route or schedule changes, by logging back into the personal emergency planner website. The results can be saved and printed out by travelers so that they will be on hand and easy to find. The traveler will continue to use their preferred method of obtaining traffic information, local news, traffic websites, radio, etc. to find out if there are any incidents or construction closures along their normal routes. In the event of expressway closures, arterial closures, or even automobile issues, the traveler will easily and immediately know the next best route to take. By visiting the personal emergency plan website ahead of time, travelers will always have the necessary information available to them. This will allow them to continue with their normal day with as little delay and inconvenience as possible. By knowing alternate routes ahead of time, the travelers can also avoid areas already becoming backed up or congested, thereby minimizing the delay for other travelers as well.
Corridor Tactic 5 - Expanded Congestion Management Program
TransGuide implemented the automated display of travel times on DMS in 1999. This process uses the point travel speeds from loop detectors, video detection systems, and radar detection systems, and the distance covered by each, to determine the estimated travel times from a DMS to major intersections and/or interchanges. These messages are displayed on the majority of the overhead DMSs on the expressway main lanes from 6 a.m. through 10 p.m., seven days a week. Through the implementation of the ICMS, this automated congestion management can be extended to include arterials and frontage roads. Using the data collected from CoSA and VIA’s AVL system, alternate travel times for each network can be displayed as well as recommendations for which route will involve the least delay.
2.2 Integrated Corridor Management System Architecture
Return to Contents
The ICMS must accomplish the following high level system functions in order to support the ICM tactics and strategies outlined above:
-
“Data Exchange” – Sharing of information between stakeholder agencies and between systems that comprise the ICMS.
-
“Detection and Data Collection” – Collection of traffic conditions data or other relevant data (i.e. weather).
-
“Traveler Information” – Display of traveler information through the use of DMS, websites, text-messages, LCSs, etc.
-
“Decision Analysis” – Analysis of traffic conditions data and historical data to provide recommended real-time ICM operational strategies.
The high-level architecture diagram below shows the existing regional architecture with the planned additions that will comprise the TransGuide ICMS. Existing systems are shown in light blue. Systems highlighted in dark blue are new modules proposed to be implemented as part of the San Antonio ICM deployment. The requirements in this document describe the functionality of the new modules only. Discussion of the existing modules is included in this section to describe the aspects of the existing systems as they relate to the ICMS.
Figure 3: ICMS Architecture
2.3 Assumptions, Dependencies, and Constraints
Return to Contents
The ICMS system and operations have the following assumptions, dependencies, and constraints:
-
The ICMS shall utilize the existing TxDOT C2C System for collection and dissemination of transportation conditions data. The interface to the C2C System is defined by an existing interface control document, the C2C Status Interface Control Document (C2C-SICD).
-
Processing associated with collection, fusion, and dissemination of real-time data feeds shall introduce a latency of no more than two (2) minutes.
-
Systems hosting the ICMS shall have their system clocks synchronized to a Network Time Protocol (NTP) server.
-
The ICMS shall utilize existing hardware servers for hosting ICMS subsystem modules when possible. Existing hardware and operating system platforms include Sun-based Solaris 9 and Intel-based Windows Server 2000 and Server 2003.
-
Existing VIA, CoSA, and TxDOT operations staffing levels and schedules will not require modification for ICMS operations. Existing TxDOT operations are 24 hours a day, seven days a week. VIA operations are from approximately 4:00 AM to 2:00 PM seven days a week. CoSA operations are from 7:00 AM to 6:00 PM Monday through Friday.
-
The TransGuide facility will host the regional ITS operations, and all decisions in relation to ITS operations are coordinated through the TransGuide facility.
-
The ICMS will not allow one agency to control another agency’s ITS assets. All recommended actions from the ICMS shall be sent to the appropriate agency’s operations staff for modification of the ITS asset (change in selected traffic signal timing pattern, DMS message, bus frequency, etc.)
-
A Simple Mail Transfer Protocol (SMTP) based e-mail server is available to the ICMS for sending alert e-mails with travelers’ information.
-
Network access between the host systems from which the ICMS must collect and disseminate data and video are available or will be established by the host system agency and the ICMS stakeholder agencies. Network connectivity will be secured by firewall and will require agency IT support for the configuration of the network firewalls to allow communication with the ICMS.
- The following Memorandums of Understanding (MOU) will be developed by public agency ICMS stakeholders to support ICMS operations:
- Video Sharing Agreement with the Emergency Operations Center (EOC).
- Remote Workstation Operation with the EOC.
- Bus Rapid Transit Operations Co-location.
2.4 ICMS Subsystems
Return to Contents
The following sections describe the individual ICMS subsystem components (or modules) that make up the entire system.
2.4.1 ICMS Interfaces
Return to Contents
The ICMS needs to interface with existing external systems to collect and store ITS data from the regional stakeholder agencies. The ICMS will need access to real-time and historical information to support decision analysis for operations. In addition, video distribution will be required to support event management and operations for the various agencies. The systems required to implement these interfaces are described below.
2.4.1.1 Center-to-Center
Return to Contents
In order for the ICMS to perform a meaningful analysis of the status of the transportation networks in the corridor, the system needs to collect real-time transportation conditions data from various agency systems in the region. The following systems have been identified as sources of essential traffic conditions data for the corridor:
-
TxDOT will move all remaining traffic signal operations performed by the San Antonio District of TxDOT to the TransGuide Operations Center
-
Begin the process of transferring Operations and Maintenance of approximately 140 additional traffic signals at expressway intersections with major arterials from TxDOT to CoSA to facilitate area wide traffic signal coordination
-
TxDOT TransGuide ATMS
-
CoSA Traffic Signal (TS) System
-
VIA Metropolitan Transit AVL System
-
Municipality Computer Aided Dispatch (CAD) Systems
-
Begin the process of retrofitting legacy shuttered fiber optic technology DMS with LED panels, and upgrading the controllers to National Transportation Communications for ITS Protocol (NTCIP)
A system component is needed that can aggregate and collect data from these and future systems. The existing systems and the data generated by them are dissimilar in nature; therefore, the information must be collected and aggregated into a single system and common data format so the information can be used and shared by the ICMS. In addition, the data exchange system should be extensible to allow for future identified data sources with meaningful traffic conditions data to be integrated into the system. The data exchange system should utilize national ITS standards to provide an open interface. In order to accomplish the collection and aggregation of the dissimilar data, the existing TxDOT C2C system will be utilized. Because the C2C system exists, specific requirements for it will not be included in this requirements document. A separate documentation set for the C2C system exists, including a requirements document and an Interface Control Document (ICD). References to these documents are provided in Section 1.6.
2.4.1.1.1 Center-to-Center Background
Return to Contents
The C2C project began as a TxDOT FHWA earmark project in which TxDOT was to be an early adopter of the Traffic Management Data Dictionary (TMDD) standard. The first version of the C2C project used DATEX as the carrier protocol and used the TMDD 1.0 messages. The results of the TxDOT implementation were provided back to the TMDD and were used in several revisions of the version 1 message sets. TxDOT then decided to move forward with a XML-based approach before the TMDD steering committee had committed to this approach. The results of the TxDOT XML solution were provided to the TMDD version 2.x development efforts, and the TxDOT messages were the baseline messages for the standard along with the Condition Acquisition and Reporting System (CARS) states and TRANSCOM messages. TxDOT utilized XML/SOAP (Extensible Markup Language/Simple Object Access Protocol) as the carrier for the TMDD 2.x messages. The TxDOT XML/SOAP was a used as a reference implementation by the National Transportation Communications for ITS Protocol (NTCIP) Center-to-Center Working Group to produce NTCIP 2306, which is the XML/SOAP-based protocol to carrier C2C messages.
C2C is a system made up of a set of existing software modules used to collect and disseminate ITS data. The C2C project provides an “infrastructure” for information exchange that will be utilized by the ICMS. This infrastructure has a well-defined interface that allows systems to deposit and retrieve data in a highly predictable fashion. The infrastructure does not permanently store information; all data is kept in memory and is lost when a software process is restarted.
The C2C infrastructure must have the capability to interconnect similar or dissimilar traffic management systems. In order to create the C2C infrastructure, interfaces to the existing systems must be created. The data being deposited into the C2C infrastructure will be converted to a standard format (ITS standards based). The C2C infrastructure is built using a series of building blocks. These building blocks allow the C2C software modules to be utilized in a number of configurations (by simply altering the configuration parameters of the software). The building blocks include:
| Block Name | Block Description | Block Diagram |
|---|---|---|
Data Provider |
A building block that receives data from an ITS system in a format established in the infrastructure’s ICD. |
|
Data Collector |
A building block that combines data from multiple sources (both Data Providers and Data Collectors) in the format established in the infrastructures ICD and stores the data in local memory. Data Extractor blocks subscribe to this block to receive the stored data in the ICD format. |
|
Data Extractor |
A building block that receives data from the Data Collector in the format specified in the infrastructure’s ICD. |
|
Command Receiver |
A building block that interfaces to an ITS system (gateway) to receive command/control requests for its ITS equipment. The interface and data format is specified in the infrastructure’s ICD. |
|
The capabilities are implemented using four building blocks described above, these blocks are installed and configured to provide the services that a center expects to receive or provide. A deployment will typically have multiple instances of each block. Figure 4 contains a depiction of a simple deployment between two centers. Note that all data that passes through the C2C infrastructure is formatted using XML, which is described in a set of XML schema files (provided in a separate zipped file).
The C2C status XML schemas describe how status information is formatted. The schemas describe both OUTBOUND status data (data being sent to outside organizations) as well as INBOUND status data (data being received to be processed locally).
TThe C2C command XML schemas describe how commands to devices are formatted. The schemas describe both the sending of OUTBOUND commands (commands being sent to other centers) as well as INBOUND commands (commands being received for local processing).
Figure 4. Example of Center-to-Center Infrastructure
In order to deploy the C2C infrastructure, it is necessary to have Transmission Control Protocol/Internet Protocol (TCP/IP) connectivity between the agencies wishing to utilize the C2C functionality. The C2C infrastructure is implemented using Web Services, so any network appliances must be configured to allow hypertext transfer protocol (HTTP) communication.
Once a client data connection has been established, client data requests or client data subscriptions can be made. Client data requests allow clients to get the complete current status of a particular type of data. Client data requests can be made at any time (with or without a subscription) after the connection has been established. Client data subscriptions allow clients to get the current complete status (one time) of a particular type of data followed by updates for that type of data. Once a subscription is in place and until it is removed, the data provider will provide asynchronous updates for each type of data subscribed to.
A region establishes a C2C infrastructure by deploying multiple instances of the building blocks to exchange information. The primary advantage of the C2C infrastructure is that only a single interface to a system needs to be developed. Once the system is connected to the C2C infrastructure, any system with appropriate privileges operating within the C2C infrastructure, can gain access to data from the system using the single interface point established. Organizations can develop custom applications to process the data available from the C2C infrastructure. An example of a custom application would be a web server that provides a visual view of the regional traffic conditions.
Strengths include:
- HTTP-based data exchange “easy” to move through firewalls: most IT departments can agree to move port 80 HTTP traffic through firewalls without major modifications to networks.
- Highly scalable: the “building block” approach makes it simple to expand the infrastructure across many agencies.
- Very extensible: the C2C infrastructure is designed to communicate well-formed XML messages; updating or adding messages is a simple activity.
Weakness includes:
- XML-based data does not efficiently utilize network bandwidth. This can be overcome by using compression techniques widely available.
2.4.1.1.2 Use of Center-to-Center in the ICMS
Return to Contents
The C2C infrastructure has been implemented for TxDOT and has been deployed and operational at TransGuide since 2006. It is currently integrated with the TxDOT ATMS system and is used to provide expressway conditions data to seven different third-party commercial data consumers that use the information for traffic reporting services. The ICMS will need to include C2C interfaces with the following additional systems (these interfaces do not exist and need to be implemented):
- CoSA TS System
- VIA Metropolitan Transit AVL System
- Municipality CAD Systems
These external systems to the ICMS have existing interfaces with C2C. Data from them will be utilized in the ICMS:
- City of SAPD CAD System
- TransGuide ATMS
Interfaces into the C2C infrastructure from an external system are implemented as a “plug-in.” In the case of status information, a plug-in is responsible for interacting with the external system (i.e., the CoSA traffic signal system) to obtain data by integrating into the system. This integration can be performed by integrating with an Application Programming Interface (API) that exists for the external system, or reading a database or updated file that contains the required up-to-date transportation conditions data. The plug-in will collect and format the data obtained from the external system into the C2C format described in the C2C ICD. The formatted data is sent to the C2C infrastructure to be aggregated and shared with the regional subscribers.
C2C plug-ins will be implemented for each of the interfaces listed above. The C2C architecture for the collection of data for the ICMS is shown in the following diagram. The components shown inside the C2C system (Network boundary, the Data Extractor, Data Collector, and Data Provider) are already existing and deployed. The external interfaces (shown in light blue) also exist. The plug-ins (shown in dark green) need to be developed to extract data from the existing systems and provide it to the C2C system.
Figure 5: ICMS Center-to-Center Architecture
2.4.1.1.3 CoSA Traffic Signal System C2C Plug-in – To Be Implemented
Return to Contents
The CoSA traffic signal system plug-in will be responsible for obtaining data from the CoSA traffic management systems, primarily the traffic signal system. The data obtained will include the following:
-
Traffic Signal Network Data – Describes the layout of the arterial network as a list of links and nodes. This data will typically be static (although updates will be allowed to occur dynamically) and will be based on existing geographic information system (GIS) data.
-
Traffic Signal Status Data – Includes the identifier, location, and real-time status data for each of the signalized intersections. The traffic signal plan selected, a description of the plan, and the plan expiration will be included.
-
Arterial Traffic Conditions Data – Data will be limited to traffic volume and occupancy counts available at signalized intersections. Traffic speeds will not be available directly from the CoSA traffic signal system.
-
CCTV Status Data – Data will include the status of cameras deployed at traffic signal intersections. Currently all cameras deployed at signal intersections are video presence detectors and are fix-mounted with no Pan-Tilt-Zoom (PTZ) control.
-
CCTV Snapshot Data – Includes a snapshot from each available video presence detector camera. Some intersections include two cameras (one fixed in each direction): one for the detection at the stop bar and one for detection on the approach. Both the stop bar and approach views will be provided when available.
2.4.1.1.4 VIAAVL System Plug-in – To Be Implemented
The VIA AVL plug-in will be responsible for obtaining data from the VIA AVL system. The data obtained will include the following:
-
Bus Route Information – Describes the routes and their associated frequency of service. This data will typically be static (although updates will be allowed to occur dynamically.)
-
Bus Stop Status Data – Lists the bus stops, describing their location and associated bus routes that service the stops. This data will typically be static (although updates will be allowed to occur dynamically.)
-
Bus Location Data – Includes real-time updates on the locations of VIA buses tracked through the AVL system. In addition to the location data, information will include the dwell time in order to help calculate accurate arterial travel time data from the bus location data. This data is available from the AVL system on one-minute intervals.
2.4.1.1.5 Municipality CAD System Plug-ins – To Be Implemented
Return to Contents
CAD incident data from Shavano Park, Castle Hills, Leon Springs, and Balcones Heights will support ICMS operations. A plug-in will be developed for each type of CAD system deployed. The CAD plug-ins will be responsible for obtaining CAD system incident data, which includes a real-time list of current incidents in the system. A detailed set of incident description data, as available from the CAD system, will be part of the incident data that is collected.
2.4.1.1.6 City of San Antonio Police Department CAD System – Existing Interface
Return to Contents
CAD incident data is currently collected in real-time from the CAD system directly by the TransGuide ATMS. This data has been collected and used to support expressway management operations since the late 1990’s. The data includes a list of current incidents and the associated detailed incident description data. Once the incident data is received by the TransGuide ATMS, it is sent to the TransGuide C2C plug-in, which provides the data to the C2C infrastructure. The SAPD CAD data is currently available to C2C clients and will be used by the ICMS.
2.4.1.1.7 TransGuide ATMS Plug-in – Existing Interface
Return to Contents
The C2C plug-in to the TransGuide ATMS already exists and has been operational since 2006. The plug-in is responsible for collecting real-time status information for the following data elements:
-
Incident Data (includes SAPD CAD incidents)
-
Lane Closure Data
-
Traffic Conditions Data
-
Special Events Data
-
Emergency Management Data
-
Dynamic Message Sign Data
-
Lane Control Signal Data
-
CCTV Snapshot Data
-
Railroad Crossing Status Data
This data is currently available in C2C and will be available for use by the ICMS.
2.4.1.1.8 Data Archive Interface Plug-in – To Be Implemented
Return to Contents
The TransGuide Data Archive will be responsible for archiving multiple years of ITS data for the San Antonio region. The Data Archive is external to the ICMS; however, data contained in the archive will be utilized to support the ICMS decision support system. Additionally, the ICMS will be responsible for interfacing with the data archive to store the real-time C2C data that is collected. The Data Archive interface plug-in will be responsible for the following:
-
Archiving the real-time C2C data
-
Obtaining historical data from the archive to support the ICMS decision support system
The following data will be sent to the plug-in by C2C to be archived:
-
VIA AVL System Bus Route Information Data
-
VIA AVL System Bus Stop Status Data
-
VIA AVL System Bus Location Data
-
CoSA TS System Traffic Signal Status Data
-
CoSA TS System Traffic Conditions Data
-
CoSA TS CCTV Status Data
-
TransGuide ATMS Incident Data
-
TransGuide ATMS Lane Closure Data
-
TransGuide ATMS Traffic Conditions Data
-
TransGuide ATMS Special Event Data
-
TransGuide ATMS Emergency Management Data
-
TransGuide ATMS DMS Data
-
TransGuide ATMS LCS Data
-
TransGuide ATMS Railroad Crossing Status Data
-
Regional Police Department CAD Systems Incident Data
The Data Archive interface plug-in will also support requests from the historical data analysis engine, described below, to extract historical traffic conditions for analysis. The Plug-in will be able to perform data queries to the database as requested by the historical data analysis engine and will return the results to the engine for processing.
The Data Archive will also be used to support the calculation and reporting of performance measures utilized to determine the effectiveness of ICM in the corridor. Agencies will be able to utilize custom reports based on historical archived data to evaluate the performance of ICM. The performance measures will be calculated and evaluated as described in the ICM Concept of Operations.
2.4.1.2 Video Distribution
Return to Contents
Video is used by each agency to support operations and incident management. TxDOT currently has 144 CCTV cameras located in San Antonio. Of those cameras, 32 are currently operating in the corridor to support expressway incident management and operations. The cameras are used to scan for incidents, determine congestion limits, and to view incident scenes to determine incident response levels. The video feed and basic control, allowing pan, tilt, and zoom functionality for these TxDOT cameras, are currently shared with the following agencies located at TransGuide:
-
TxDOT traffic management operations
-
CoSA traffic signal management operations
-
City of San Antonio Police Department expressway dispatch
-
VIA transit operations
To further improve ICMS operations, the CoSA traffic signal video feeds need to be made available to the TxDOT traffic management operations, City of San Antonio Police Department expressway dispatch, and the VIA transit operations. Currently, CoSA deploys video presence detection cameras at signalized intersections. Some intersections include two cameras fixed in each direction, one for the detection at the stop bar and one for detection on the approach. Both the stop bar and approach video feeds need to be provided when available. IP-based video distribution will be utilized to share the video on operations workstations for each identified agency. Video will be selected from the ICMS operations user interface map. The ICMS needs to be able to limit the number of video feeds a single user can display in order to not overload network resources. The system needs to allow multiple users to view the same video stream concurrently. Since the CoSA cameras are fixed in position at the intersections, control of the cameras is not possible.
2.4.2 Decision Support System
Return to Contents
The final result of this network of real-time data and data archive would be a Decision Support System (DSS) that needs to be available to each stakeholder organization. The DSS will be the “brain” of the ICMS, analyzing the available traffic conditions data to draw meaningful conclusions about traffic conditions that should result in an operational response.
This support system needs to be able to provide specific data types and alarms to different agencies, allowing them to view data from other sources that would be the most useful to them. This would be used to aid in decision making and improving the overall flow of traffic throughout the corridor. Figure 4 shows the concept for the ICMS decision support system. Utilizing the C2C infrastructure described above, outside organizations can feed data into the TransGuide C2C server where it can be combined with the real-time and archived data already located at the TransGuide ATMS. This data is supplied to the decision support system where it is then made available through the C2C web services to stakeholder agencies that have a need for the data. Once each stakeholder organization has obtained necessary data, it may then be made available through the traveler information websites described in following sections.
Figure 6: Decision Support System for the ICMS
The Decision Support System is made up of the following components:
-
Historical Data Analysis Subsystem – responsible for analyzing historical data to support historical divergence alarms.
-
ICMS Event Management Subsystem – responsible for identifying potential events in the corridor and dispatching alarms to agency operators.
-
ICMS Arterial Travel Times Subsystem – responsible for generating arterial travel times from VIA bus location data.
The following subsections describe these Decision Support System components in more detail.
2.4.2.1 Historical Data Analysis
Return to Contents
The historical data analysis engine needs to be responsible for analyzing historical data utilized to generate historical divergence alarms. Historical divergence alarms are incident management notifications that will be sent to various ICMS operations staff. The alarms are generated by comparing current traffic conditions data with historical trend data. The historical data analysis engine needs to be responsible for calculating the historical trend data. The engine needs to interface with the Data Archive interface plug-in to obtain historical traffic conditions data from expressways, arterials, and frontage roads. In addition, it will also need to obtain bus location and stop data. The historical data analysis engine needs to support the following features:
-
Calculate historical trend data for each segment in the transportation network. Segments can be defined on expressways, arterials, and frontage roads.
-
Historical trend data will be calculated for timeslices throughout the day. The number of timeslices in a day needs to be configurable. It is envisioned that time slices will be no larger than 30 minutes each.
-
The historical trend data needs to be an average of the traffic conditions or bus schedule adherence occurring during that timeslice over the past configurable period of time. It will need to account for the day of week, holidays, and “outliers” for creating the historical trend.
A set of trends needs to be created for each timeslice in advance. The trends for the timeslice will need to be provided to the ICMS event management subsystem for making comparisons of the current conditions data with the trend data in order to produce the historical convergence alarms.
2.4.2.2 ICMS Event Management
Return to Contents
The ICMS event management engine will be responsible for identifying potential events in the corridor and dispatching alarms to agency operators. Two types of alarms need to be generated by the event management engine:
-
Current Condition Threshold Alarms – Alarms based on comparing current conditions data with statically configurable thresholds. For example, if the bus schedule adherence for a route is higher than the 5-minute configured threshold allowed, an alarm needs to be generated.
-
Historical Divergence Alarms – Alarms based on comparing current conditions data with historical trend data. For example, if the current speed is 10% lower on a particular segment than it has been on average at the same time period of the day over the past two months, an alarm needs to be generated
The ICMS event management engine needs to receive current conditions information from the C2C infrastructure. The current conditions information will then need to be compared to the configured thresholds and historical averages. Historical averages need to be received from the historical data analysis engine. Generated alarms need to be sent to the ICMS operations user interface described below. The user interface needs to be responsible for dispatching the alarms to the appropriate agency operator/user that has subscribed to the events. This allows alarms to only be sent to the agencies that will be responsible for managing them.
The following alarm events need to be generated by the ICMS event management engine:
-
Incident alarms
-
Bus schedule adherence alarms
-
Speed threshold alarms
-
Volume threshold alarms
-
Occupancy threshold alarms
-
Railroad crossing alarms
-
Bus schedule divergence alarms
-
Speed Divergence Alarms
-
Volume divergence alarms
-
Occupancy divergence alarms
These alarms are described in more detail in the requirements.
2.4.2.3 ICMS Arterial Travel Times
Return to Contents
Implementation issues that could affect the successful ICM deployment have been identified below. In addition to the issues, a mitigation strategy has been developed to address the concerns. The San Antonio ITS Technical Committee will be responsible for reviewing the implementation risk and executing the mitigation strategy. When necessary, the mitigation strategy will be revised and adapted. As new implementation issues are determined, corresponding mitigation strategies will be developed and the issues will be tracked by the San Antonio ITS Technical Committee. Identified implementation issues fall into three areas: Operational, Technical, and Institutional.
-
Bus dwell time - the time a bus is stopped with its doors open to load and unload passengers.
-
Bus speed – bus speeds are typically slower than the surrounding traffic conditions due to slower acceleration, advanced deceleration, and safer (i.e. slower) driving tactics used by drivers of large commercial grade vehicles.
Dwell time is provided by VIA in the AVL data for bus locations. The factor for bus speed needs to be configurable and based on more detailed future analysis. The resultant travel times, calculated by individual arterial segment, need to be fed back into the C2C infrastructure so the travel times can be utilized for ICM event management and traveler information services.
2.4.3 ICMS Operations User Interface
Return to Contents
The ICM operations user interface will be the primary method for viewing and configuring data and alarms from the DSS. The user interface needs to receive and display status data and alarms from the DSS, as well as providing the method for configuring the necessary values for the DSS. The status information displayed through the user interface is as follows:
-
Link data
-
Network data
-
Traffic conditions data
-
Incident data
-
Lane closure data
-
Special event data
-
Emergency management data
-
Railroad crossing data
-
Bus stop data
-
Bus location data
-
Expressway travel time data
-
Arterial travel time data
Operators need to be able to view this data through the user interface as well as configuring which data they would like to view. The user interface needs to be able to also display the following alarms to the operators:
-
Incident alarms
-
Bus schedule adherence alarms
-
Speed threshold alarms
-
Volume threshold alarms
-
Occupancy threshold alarms
-
Railroad crossing alarms
-
Bus schedule divergence alarms
-
Speed divergence alarms
-
Volume divergence alarms
-
Occupancy divergence alarms
Operators need to be notified visually of these alarms through the user interface as well as be able to configure which types of alarms they would like to receive. Each operator logged into the system needs to be able to select the alarms they want to receive as well as those they want to suppress.
The user interface also needs to allow the operator to configure the values used to trigger alarms. Each threshold alarm has a configurable threshold value, and each divergence alarm has a configurable divergence value. All of these values, as well as a distance value for incident alarms and a time value for scheduled alarms, need to be viewable and configurable from the user interface.
Alarms received from the DSS need to also provide the operator with recommended actions to respond to the event that caused the alarm. Recommendations for each alarm type need to contain a specific set of data elements and actions that are specific to the location, values, and type of each alarm. These recommended actions and their data elements are described in detail in the requirements. The user interface needs to also provide the operator with a method of acknowledging an alarm as accepted or ignored. This will provide a method for each operator to know whether an alarm has been handled by someone else or still requires attention.
2.4.4 Corridor Web Suite
Return to Contents
The ICMS website will consist of two main applications: the Personal Trip Planner and the ICMS Corridor website. These applications need to provide traffic and route information to the public through the web, allowing them to view this information anytime. The website needs to include an interface to the ICMS DSS as well as C2C to obtain the necessary data. Using these two data feeds, the website needs to be able to provide updated corridor status information to both the Personal Trip Planner and the website.
2.4.4.1 Personal Trip Planner
Return to Contents
The personal emergency transportation plan will consist of a website that provides travelers with the ability to plan alternate routes for their most common daily commutes and to be notified via email when incidents occur on the predefined routes. The website needs to provide the following high-level functionality:
-
User management – Allows a user to create an account.
-
Creation of personal emergency transportation plan – Provides alternate transportation routes for multiple modes of transportation.
-
Personal incident alerts – Alerts need to be sent via email to subscribers when incidents occur on predefined routes.
This website needs to use data provided by each of the transportation networks. Data to display on the website needs to be obtained from the C2C system. The Personal Trip Planner needs to provide a link to the website of each respective regional transportation agency.
User Management
The Personal Trip Planner needs to require users to login to access the site. First time users need to have the option to create a new account. Account information should include the following:
-
E-mail address (used as username for login)
-
Password
-
Stored route informationo Route starting addresso Route ending addresso Route option to select either shortest time or shortest distance for the route calculationo Departure day(s) of week and timeo Return day(s) of week and time
-
Selection to receive incident notifications via e-mail
Account information, including the routes, need to be stored so that when the user logs back into the website again the routes will be loaded. The users need to be able to update their account information, modify the routes, print out selected routes, or change their preference to receive incident notifications via e-mail. Each time the user logs into the website, the travel route needs to be updated to reflect current construction, lane closures, and changes in bus routes and schedules.
Personal Emergency Transportation Plan
By entering beginning and ending addresses, travelers will be provided with directions using the expressway network, arterials, and VIA bus routes. These routes need to be updated as necessary due to construction, or VIA route or schedule changes, by logging back into the personal emergency planner website. The results may be saved and printed out by travelers so that they will be on hand and easy to find. The travelers may continue to use their preferred method of obtaining traffic information, local news, traffic websites, radio, etc. to find out if there are any incidents or construction closures along their normal routes. In the event of expressway closures, arterial closures, or even automotive mechanical issues, the traveler will easily and immediately know the next best route to take. By visiting the personal emergency plan website ahead of time, travelers will always have the necessary information available to them. This will allow them to continue with their normal day with as little delay and inconvenience as possible. By knowing alternate routes ahead of time, the travelers can also avoid areas already becoming backed up or congested, thereby minimizing the delay for other travelers as well.
Personal Incident Alerts
Users that have elected to receive incident notifications need to receive an email when a traffic incident or lane closure occurs during the time of day and day(s) of week for the route that has been identified by the traveler. This will allow users to receive the notification in their personal email account prior to leaving work. Additionally, if the traveler’s mobile phone or personal digital assistant (PDA) has access to text messaging or email through an email address, the message could be received while away from the user’s computer. This will allow travelers to make intelligent decisions about selected alternate routes while they are away from home or the office.
2.4.4.2 ICMS Corridor Web Site
Return to Contents
The ICMS Web Site will be used to provide up-to-date status data for the corridor. The primary display method for this data needs to be a map of the corridor; however, certain data will also be available without using the map. A complete list of the status data that will be shown is listed here:
-
Link data
-
Network data
-
Traffic conditions data
-
Incident data
-
Lane closure data
-
Special event data
-
Emergency management data
-
Traffic signal status data
-
DMS data
-
LCS data
-
CCTV status data
-
CCTV snapshot data
-
Railroad crossing data
-
Bus route data
-
Bus stop data
-
Bus location data
This data needs to be displayed graphically on the corridor map to allow the user to view the data from one place. The website should also allow the user to filter the map on each data type, so that only the desired information is viewable.
The website needs to also provide a mobile version of the corridor website for mobile devices, with a limited set of data. The functionality of the mobile website should be very similar to the original site, with the exception of being limited in the number of data elements that will be viewable simultaneously.
3.1 Verification Methods
Return to Contents
The verification methods describes the methodology to be used to verify (or test) the requirement following implementation. The following verification methods can be used:
-
“Demonstration” - observing function of the software without requiring instrumentation, special test equipment, or subsequent analysis.
-
“Test” - observing function of the software using instrumentation or special test equipment to collect data for later analysis.
-
“Analysis” - processing accumulated data obtained from other verification methods.
-
“Inspection”- visual inspection of the software source code, documentation, etc.
-
“Special methods” - special tools, techniques, procedures, or facilities.
3.2 Precedence and Criticality of Requirements
Return to Contents
Prioritization of requirements to document the level of importance and impact of the requirement in the ICMS will be captured as the “criticality” for each requirement. Criticality will be categorized as follows:
-
“High” – Requirement is critical for the successful operation of the ICMS.
-
“Medium” – Requirement adds significant benefit to the operation of the ICMS.
-
“Low” – Requirement adds benefit to the operation of the ICMS, but the ICMS will function without it.
3.3 Requirement Attributes
Return to Contents
For each requirement the following will be captured and documented when applicable
| Field | Description |
|---|---|
ID |
Unique Identifier (ID) that shows “hierarchy.” The ID will include the abbreviated allocation and be in a numbered outline format that will document the parent/child relationship of the requirements. |
Title |
A brief name summarizing the intent of the requirement. |
Requirement |
The requirement text. The requirements will be formatted as “shall” statements. |
Traceability |
Documents the relationship between each requirement and the project-items that it addresses. High level requirements will be derived from the ICM ConOps. “Derived” indicates that the requirement was based on its own parent in the requirements hierarchy and would therefore trace to the same needs as the parent requirement. If a requirement is not derived directly from its parent, the requirement number or section from the Concept of Operations will be shown. |
Allocation |
Classification of the Requirement into one of the following subsystems:
|
Comment |
Additional relevant information specific to the requirement. If the requirement has already been implemented in an existing system it will be noted. Includes rationale when it is not self-evident.
|
Criticality |
Level of importance and impact of the requirement in the ICMS in relationship to the other requirements. |
Verification Method |
Documents the method used to verify the requirement during acceptance testing of the system. |
A sample table for documenting the ICMS requirements is show below. The table will be used in each subsection of section 4.0 to record the requirements.
| ID | Title | Requirement | Traceability | Allocation | Criticality | Comment | Verification Method |
|---|---|---|---|---|---|---|---|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
4.0 SYSTEM REQUIREMENTS
Return to Contents
The ICMS requirements will be contained in the following sections. If there are no requirements in a given section, the section will state this. If a requirement fits into more than one section, it may be stated once and referenced from the other sections.
4.1 ICM Interfaces
Return to Contents
The following Data Exchange Requirements have been identified for the ICMS.
| ID | Title | Requirement | Traceability | Allocation | Criticality | Comment | Verification Method |
|---|---|---|---|---|---|---|---|
| DX-1 | ICMS Center-to-Center Data Sharing | The ICMS shall collect and disseminate data from external systems utilizing the existing C2C System. | TG-ICM-COO p43 | C2C Plugins | High | |
Demonstration |
| DX-2 | ICMS Interface with the VIA AVL System | The ICMS shall interface with the VIA AVL System using the interface defined in the C2C-Status interface Control Document (SICD) | TG-ICM-COO p44 | C2C Plugins | High | The interface is defined and documented in the C2C-SICD. | Demonstration |
| DX-2.1 | VIA AVL System Bus Route Information Data | The ICMS shall obtain the following bus route information data as available from the VIA AVL System:
|
Derived | C2C Plugins | High | |
Demonstration |
| DX-2.2 | VIA AVL System Bus Stop Status Data | The ICMS shall obtain the following Bus Stop Status Data as available from the VIA AVL System:
|
Derived | C2C Plugins | High | |
Demonstration |
| DX-2.3 | VIA AVL System Bus Location Data | The ICMS shall obtain the following Bus Location Data as available from the VIA AVL System:
|
Derived | C2C Plugins | High | |
Demonstration |
| DX-2.4 | VIA AVL System Data Updates | The ICMS shall obtain data from the VIA AVL system when changes in the data become available to the C2C system. | Derived | C2C Plugins | High | |
Demonstration |
| DX-3 | ICMS Interface with the CoSA TS System | The ICMS shall interface with the CoSA Traffic Signal System using the interface defined in the C2C-SICD. | TG-ICM-COO p44 | C2C Plugins | High | The interface is defined and documented in the C2C-SICD. | Demonstration |
| DX-3.1 | CoSA TS System Network Data | The ICMS shall obtain the following Network Data as available from the CoSA Traffic Signal System:
|
Derived | C2C Plugins | High | Link and Node data are defined in the C2C-SICD. | Demonstration |
| DX-3.2 | CoSA TS System Traffic Signal Status Data | The ICMS shall obtain the following Traffic Signal Status Data as available from the CoSA TS System:
|
Derived | C2C Plugins | High | |
Demonstration |
| DX-3.3 | CoSA TS System Traffic Conditions Data | The ICMS shall obtain the following Traffic Conditions Data as available from the CoSA Traffic Signal System from intersections capable of collecting the data:
|
Derived | C2C Plugins | High | Only VIVD sensor enabled signal intersections will be capable of providing traffic conditions data. Available conditions data is likely limited to volume and occupancy. | Demonstration |
| DX-3.4 | CoSA TS System CCTV Status Data | The ICMS shall obtain the following CCTV Status Data as available from the CoSA Traffic Signal System from intersections with cameras:
|
Derived | C2C Plugins | Medium | Only VIVD sensor enabled signal intersections will be capable of providing CCTV data. | Demonstration |
| DX-3.5 | CoSA TS System CCTV Snapshot Data | The ICMS shall obtain the following CCTV Snapshot Data as available from the CoSA Traffic Signal System from intersections with cameras:
|
Derived | C2C Plugins | High | Only VIVD sensor enabled signal intersections will be capable of providing CCTV snapshots. | Demonstration |
| DX-3.6 | CoSA TS System Data Updates | The ICMS shall obtain data from the CoSA Traffic Signal System when changes in the data become available to the C2C system. | Derived | C2C Plugins | High | |
Demonstration |
| DX-4 | ICMS Interface with the TransGuide ATMS | The ICMS shall interface with the TxDOT TransGuide ATMS using the interface defined in the C2C-SICD. | TG-ICM-COO p44 | C2C Plugins | Existing | This interface is already implemented. Detailed data is not provided in sub-requirements because the data source is already integrated with the C2C System using the interface defined and documented in the C2C-SICD. | Demonstration |
| DX-4.1 | TransGuide ATMS Data | The ICMS shall obtain the following data as available from the TransGuide ATMS:
|
Derived | C2C Plugins | High | |
Demonstration |
| DX-5 | ICMS interface with the SAPD CAD System | The ICMS shall interface with the City of San Antonio Police Department (SAPD). | Derived | C2C Plugins | Existing | This interface is already implemented. Detailed data is not provided in sub-requirements because the data source is already integrated with the C2C System through the TransGuide ATMS. | Demonstration |
| DX-6 | ICMS Interface with Regional Police Department CAD Systems | The ICMS shall provide an interface for regional police departments to provide CAD system data to the ICMS using the interface defined in the C2C-SICD. | TG-ICM-COO p44 | C2C Plugins | High | The interface is defined and documented in the C2C-SICD. | Demonstration |
| DX-6.1 | Regional Police Department CAD Systems Incident Data | The ICMS shall obtain the following incident data as available from Regional CAD Systems:
|
Derived | C2C Plugins | High | Data will be limited to what is available in the host CAD system for each regional police department. | Demonstration |
| DX-6.2 | Regional Police Department CAD Systems Data Updates | The ICMS shall obtain data from the Regional Police Department CAD Systems when changes in the data become available to the C2C System. | Derived | C2C Plugins | High | |
Demonstration |
| DX-7 | ICMS Interface with the Data Archive | The ICMS shall archive the following historical data elements provided by the external systems:
|
TG-ICM-COO p44 | Data Archive | High | CCTV Snapshot Data for both the TransGuide and CoSA will not be archived. | Demonstration |
| DX-7.1 | Data Archive Configurable Interval | The ICMS shall send the historical data elements to the data archive on a configurable interval. | Derived | Data Archive | High | |
Demonstration |
| DX-7.1.1 | Data Archive Configurable Interval by Data Element | The ICMS shall use a configurable parameter for each historical data element, with a default value of two minutes, to determine the interval each data element is sent to the data archive. | Derived | Data Archive | High | Allows for data to be archived at different frequencies depending on the resolution of data needed. | Demonstration |
| DX-8 | C2C System Interface with the Decision Support System | The ICMS Decision Support System shall obtain current conditions data from the C2C System. | TG-ICM-COO p44 | C2C Plugins | High | |
Demonstration |
| DX-9 | Data Exchange Through Center-to-Center | The ICMS shall utilize the existing C2C System to implement data exchange between the VIA AVL System, CoSA Traffic Signal System, Data Archive, TransGuide ATMS, Regional CAD Systems, and the Decision Support System. | TG-ICM-COO p43 | C2C Plugins | High | |
Demonstration |
| DX-9.1 | C2C System Data Format | The ICMS data exchange using the C2C System shall be network-based using TCP/IP connectivity, the HTTP, and XML data format based and shall be consistent with TMDD 2.1 (and NTCIP 2306) and the emerging TMDD 3.0 (and NTCIP 2306). | Derived | C2C Plugins | High | |
Demonstration |
| DX-9.2 | Management of External Data Feeds | The ICMS shall manage the connections with external data feeds through the C2C System. | TG-ICM-COO p44 | C2C Plugins | High | |
Demonstration |
| DX-9.2.1 | Detection of External Data Source Disconnections | The ICMS shall detect when an external data source has disconnected. | Derived | C2C Plugins | High | |
Demonstration |
| DX-9.2.2 | Detection of Lack of Data Updates from External Data Sources | The ICMS shall detect stale data when an external data feed is no longer providing data updates. | Derived | C2C Plugins | High | |
Demonstration |
| DX-9.2.3 | Display of External Data Source Status | The ICMS shall display the status of each external data feed as connected, disconnected, or stale data. | Derived | C2C Plugins | High | Stale Data is defined in requirement DX-9.2.2. | Demonstration |
| DX-9.2.4 | Logging of External Data Source Status | The ICMS shall log the status of each external data feed when the status changes between connected, disconnected, or stale data. | Derived | C2C Plugins | High | |
Inspection |
| DX-9.3 | C2C System Data Source Extensibility | The ICMS shall be extensible to add up to 25 total data sources to the system. | Derived | C2C Plugins | High | This will be a requirement of the C2C system. Due to difficulties in creating this number of interfaces for testing, inspection of the C2C system documentation and software will be used for verification. | Inspection |
| DX-9.4 | C2C System Performance | The ICMS shall disseminate data provided to it from external interfaces (such as the TransGuide ATMS, CADD systems, CoSA TS, etc.) to the ICMS subsystems in less than two minutes. | Derived | C2C Plugins | High | |
Demonstration |
| DX-9.5 | C2C Data Element Time Stamps | The ICMS shall time-stamp data elements in the C2C data feed. | Derived | C2C Plugins | High | Allows subscribers of the C2C data to determine the "freshness" of the data. | Demonstration |
| DX-10 | CoSA CCTV Video Distribution | The ICMS shall display CoSA CCTV video streams to TxDOT, VIA, and SAPD operators. | TG-ICM-COO p43 | C2C Plugins | Medium | Only VIVD equipped signal intersections will be capable of providing CCTV video streams. | Demonstration |
| DX-10.1 | Video Stream Availability | The ICMS shall distribute video streams that are not blacked out. | Derived | C2C Plugins | Medium | |
Demonstration |
| DX-10.2 | Video Stream Sharing | The ICMS shall be capable of sharing the same video stream to multiple operators. | Derived | C2C Plugins | Medium | |
Demonstration |
| DX-11 | TransGuide CCTV Video Distribution | The ICMS shall display TxDOT TransGuide CCTV video streams to CoSA, VIA, and SAPD operators. | TG-ICM-COO p43 | C2C Plugins | High | This requirement is already implemented. Detailed requirements will not be provided. | Demonstration |
4.2 Decision Support System
Return to Contents
The following subsections include the requirements for the ICMS DSS.
4.2.1 Historical Data Analysis
Return to Contents
The ICMS DSS Historical Data Analysis requirements are included in the table below.
| ID | Title | Requirement | Traceability | Allocation | Criticality | Comment | Verification Method |
|---|---|---|---|---|---|---|---|
| DA-1 | ICMS Decision Support System | The ICMS shall include a DSS. | TG-ICM-COO p43 | Decision Support System (DSS) | High | |
Demonstration |
| DA-2 | DSS C2C System Interface | The DSS shall include a C2C System interface. | TG-ICM-COO p43 | Decision Support System (DSS) | High | |
Demonstration |
| DA-2.1 | DSS Subscription to C2C Data | The DSS shall receive the following C2C data elements:
|
Derived | Decision Support System (DSS) | High | The detailed data elements are defined in the C2C-SICD | Demonstration |
| DA-3 | DSS Historical Data | The DSS shall include an interface to the Data Archive. | TG-ICM-COO p44 | Decision Support System (DSS) | High | |
Inspection |
| DA-3.1 | DSS Historical Data Retrieval | The DSS shall retrieve the following historical data from the Data Archive for processing historical divergence alarms:
|
Derived | Decision Support System (DSS) | High | |
Inspection |
| DA-4 | Historical Data Calculation | The DSS shall calculate historical data averages for volume, occupancy, speed, and bus schedule adherence as data is available for each segment. | TG-ICM-COO p44 | Decision Support System (DSS) | High | Segments are sections of expressway, arterial, or bus routes typically half to one mile in length that generally have historical and real-time conditions data available. | Demonstration |
| DA-4.1 | Historical Timeslice | The DSS shall calculate historical averages for each historical timeslice. | Derived | Decision Support System (DSS) | High | |
Demonstration |
| DA-4.2 | Historical Timeslice Configuration | The DSS historical timeslice shall be configurable with a default value of 30 minutes. | Derived | Decision Support System (DSS) | High | |
Demonstration |
| DA-4.3 | Historical Window | The DSS shall calculate historical averages by averaging the past historical window worth of data occurring in the same historical timeslice period of the day. | Derived | Decision Support System (DSS) | High | |
Demonstration |
| DA-4.4 | Historical Window Configuration | The DSS historical window shall be configurable with a default value of 30 days. | Derived | Decision Support System (DSS) | High | |
Demonstration |
| DA-4.5 | Historical Sample Set Outliers | The DSS shall filter outliers from the sample set used to calculate the historical average. | Derived | Decision Support System (DSS) | High | |
Demonstration |
| DA-4.6 | Historical Timeslice Archiving | The DSS shall archive the historical timeslice calculations. | Derived | Decision Support System (DSS) | High | |
Demonstration |
| DA-4.7 | Historical Timeslice Sent to DSS-Event Management Subsystem (EMS) | The DSS shall provide the historical timeslice calculations to the DSS-EMS. | Derived | Decision Support System (DSS) | High | |
Demonstration |
| DA-4.8 | Historical Data Calculation Performance | The DSS shall calculate historical averages in advance before they are needed to generate alarms. | Derived | Decision Support System (DSS) | High | Calculation of the historical averages in advance eliminates need for real-time performance of calculations. | Demonstration |
4.2.2 ICMS Event Management
Return to Contents
The ICMS DSS Event Management requirements are included in the table below.
| ID | Title | Requirement | Traceability | Allocation | Criticality | Comment | Verification Method |
|---|---|---|---|---|---|---|---|
DA-5 |
C2C Data Monitoring for Events |
The DSS-EMS shall monitor current the C2C system data to identify conditions and events that potentially impact traveling conditions in the corridor. |
TG-ICM-COO p45 |
Decision Support System (DSS) |
High |
|
Demonstration |
DA-5.1 |
Incident Alarm |
The DSS-EMS shall generate an incident alarm when an incident event is within the incident distance threshold from a monitored segment. |
Derived |
Decision Support System (DSS) |
High |
|
Demonstration |
DA-5.1.1 |
Incident Alarm Monitored Segments |
The DSS-EMS shall monitor pre-configured expressways, arterial, frontage roads and bus routes. |
Derived |
Decision Support System (DSS) |
High |
|
Demonstration |
DA-5.1.2 |
Incident Distance Threshold Configuration |
The DSS-EMS shall use an incident distance threshold, which is configurable, with a default value of two miles. |
Derived |
Decision Support System (DSS) |
Medium |
|
Demonstration |
DA-5.1.3 |
Incident Alarm Data |
The DSS-EMS shall include the following data elements in each incident alarm:
|
Derived |
Decision Support System (DSS) |
High |
Detailed data element descriptions are available in the C2C-SICD. |
Demonstration |
DA-5.2 |
Bus Schedule Adherence Alarm |
The DSS-EMS shall generate a bus schedule adherence alarm event when a bus’s schedule adherence is greater than the bus schedule adherence threshold. |
Derived |
Decision Support System (DSS) |
High |
|
Demonstration |
DA-5.2.1 |
Bus Schedule Adherence Threshold Configuration |
The DSS-EMS shall use a bus schedule adherence threshold which is configurable, with a default value of 12 minutes, for calculation of bus schedule adherence alarms. |
Derived |
Decision Support System (DSS) |
Medium |
|
Demonstration |
DA-5.2.2 |
Bus Schedule Adherence Alarm Data |
The DSS-EMS shall include the following data elements in each bus schedule adherence alarm:
|
Derived |
Decision Support System (DSS) |
High |
Detailed data element descriptions are available in the C2C-SICD |
Demonstration |
DA-5.3 |
Speed Threshold Alarm |
The DSS-EMS shall generate a speed threshold alarm when the speed of a monitored expressway, frontage road, or arterial is less than the speed threshold. |
Derived |
Decision Support System (DSS) |
High |
|
Demonstration |
DA-5.3.1 |
Speed Threshold Configuration for Expressways |
The DSS-EMS shall use a speed threshold, which is configurable by individual expressway segments, with a default value of 30 miles per hour for calculation of speed threshold alarms. |
Derived |
Decision Support System (DSS) |
Medium |
|
Demonstration |
DA-5.3.2 |
Speed Threshold Configuration for Arterials |
The DSS-EMS shall use a speed threshold, which is configurable by individual arterial segments, with a default value of 15 miles per hour for calculation of speed threshold alarms. |
Derived |
Decision Support System (DSS) |
Medium |
|
Demonstration |
DA-5.3.3 |
Speed Threshold Configuration for Frontage Roads |
The DSS-EMS shall use a speed threshold, which is configurable by individual frontage road segments, with a default value of 15 miles per hour for calculation of speed threshold alarms. |
Derived |
Decision Support System (DSS) |
Medium |
|
Demonstration |
DA-5.3.4 |
Speed Threshold Alarm Data |
The DSS-EMS shall include the following data elements in each speed threshold alarm:
|
Derived |
Decision Support System (DSS) |
High |
Detailed data element descriptions are available in the C2C-SICD |
Demonstration |
DA-5.4 |
Volume Threshold Alarm |
The DSS-EMS shall generate a volume threshold alarm when the volume of a monitored expressway, frontage road, or arterial drops by more than a configurable amount in a configurable time period. |
Derived |
Decision Support System (DSS) |
High |
|
Demonstration |
DA-5.4.1 |
Volume Threshold Configuration for Expressways |
The DSS-EMS shall use a volume threshold, which is configurable for expressways by individual segment, with a default value of 200 vehicles in a 20 minute period for calculation of volume threshold alarms. |
Derived |
Decision Support System (DSS) |
Medium |
|
Demonstration |
DA-5.4.2 |
Volume Threshold Configuration for Arterials |
The DSS-EMS shall use a volume threshold, which is configurable for arterials by individual segment, with a default value of 100 vehicles in a 20 minute period for calculation of volume threshold alarms. |
Derived |
Decision Support System (DSS) |
Medium |
|
Demonstration |
DA-5.4.3 |
Volume Threshold Configuration for Frontage Roads |
The DSS-EMS shall use a volume threshold, which is configurable for frontage roads by individual segment, with a default value of 100 vehicles in a 20 minute period for calculation of volume threshold alarms. |
Derived |
Decision Support System (DSS) |
Medium |
|
Demonstration |
DA-5.4.4 |
Volume Threshold Alarm Data |
The DSS-EMS shall include the following data elements in each volume threshold alarm:
|
Derived |
Decision Support System (DSS) |
High |
Detailed data element descriptions are available in the C2C-SICD |
Demonstration |
DA-5.5 |
Occupancy Threshold Alarm |
The DSS-EMS shall generate an occupancy threshold alarm when the occupancy of a monitored expressway, expressway entrance ramp, or expressway exit ramp is greater than the occupancy threshold. |
Derived |
Decision Support System (DSS) |
High |
|
Demonstration |
DA-5.5.1 |
Occupancy Threshold Configuration |
The DSS-EMS shall use an occupancy threshold, which is configurable for expressways, expressway exit ramps, and expressway entrance ramps by individual segment, with a default value of 80 percent for calculation of occupancy threshold alarms. |
Derived |
Decision Support System (DSS) |
Medium |
|
Demonstration |
DA-5.5.2 |
Occupancy Threshold Alarm Data |
The DSS-EMS shall include the following data elements in each occupancy threshold alarm:
|
Derived |
Decision Support System (DSS) |
High |
Detailed data element descriptions are available in the C2C-SICD |
Demonstration |
DA-5.6 |
Railroad Crossing Alarm |
The DSS-EMS shall generate a railroad crossing alarm when a train crossing an AWARD monitored intersection is detected. |
Derived |
Decision Support System (DSS) |
High |
AWARD is an existing system to detect train blockages of frontage road intersections. The AWARD data is available from the TransGuide ATMS. |
Demonstration |
DA-5.6.1 |
Railroad Crossing Alarm Data |
The DSS-EMS shall include the following data elements in each railroad crossing alarm:
|
Derived |
Decision Support System (DSS) |
High |
Detailed data element descriptions are available in the C2C-SICD |
Demonstration |
DA-5.7 |
Current Conditions / Threshold Alarm Performance |
The DSS-EMS shall be capable of processing the current conditions data in comparison with thresholds in two-minutes or less for generating alarms. |
Derived |
Decision Support System (DSS) |
High |
|
Demonstration |
DA-6 |
DSS-EMS Engine for Historical Divergence Alarms |
The DSS shall include an Event Management Engine that processes and compares current conditions with historical data to detect “anomaly” conditions. |
TG-ICM-COO p44 |
Decision Support System (DSS) |
High |
Need to evaluate the effectiveness of real-time alarms compared to “historical divergence“ alarms. |
Demonstration |
DA-6.1 |
Bus Schedule Adherence Divergence Alarm |
The DSS-EMS shall generate a bus schedule adherence divergence alarm event when a bus’s schedule adherence is greater than the historical bus schedule adherence plus the bus schedule adherence divergence threshold. |
Derived |
Decision Support System (DSS) |
Low |
Unlikely this alarm type will add benefit over the bus schedule adherence alarm |
Demonstration |
DA-6.1.1 |
Bus Schedule Adherence Divergence Threshold Configuration |
The DSS-EMS shall use a bus schedule adherence divergence threshold, which is configurable and has a default value of 10 minutes, for calculating a bus schedule adherence divergence alarm. |
Derived |
Decision Support System (DSS) |
Low |
See previous comment. |
Demonstration |
DA-6.1.2 |
Bus Schedule Adherence Divergence Alarm Data |
The DSS-EMS shall include the following data elements in each bus schedule adherence divergence alarm:
|
Derived |
Decision Support System (DSS) |
Low |
Detailed data element descriptions are available in the C2C-SICD |
Demonstration |
DA-6.2 |
Speed Divergence Alarm |
The DSS-EMS shall generate a speed divergence alarm when the speed of a monitored expressway, frontage road, or arterial is greater than the historical speed of segment plus the speed divergence threshold. |
Derived |
Decision Support System (DSS) |
High |
|
Demonstration |
DA-6.2.1 |
Speed Divergence Threshold Configuration for Expressways |
The DSS-EMS shall use a speed divergence threshold, which is configurable for expressways by individual segment and with a default value of 25 miles per hour, for calculation of a speed divergence alarm on expressway segments. |
Derived |
Decision Support System (DSS) |
Medium |
|
Demonstration |
DA-6.2.2 |
Speed Divergence Threshold Configuration for Arterials |
The DSS-EMS shall use a speed divergence threshold, which is configurable for arterials by individual segment and with a default value of 15 miles per hour, for calculation of a speed divergence alarm on arterial segments. |
Derived |
Decision Support System (DSS) |
Medium |
|
Demonstration |
DA-6.2.3 |
Speed Divergence Threshold Configuration for Frontage Roads |
The DSS-EMS shall use a speed divergence threshold, which is configurable for frontage roads by individual segment and with a default value of 15 miles per hour, for calculation of a speed divergence alarm on frontage road segments. |
Derived |
Decision Support System (DSS) |
Medium |
|
Demonstration |
DA-6.2.4 |
Speed Divergence Alarm Data |
The DSS-EMS shall include the following data elements in each speed divergence alarm:
|
Derived |
Decision Support System (DSS) |
High |
Detailed data element descriptions are available in the C2C-SICD |
Demonstration |
DA-6.3 |
Volume Divergence Alarm |
The DSS-EMS shall generate a volume divergence alarm when the volume drop of a monitored expressway, frontage road, or arterial is lower than the historical volume drop of the segment plus the volume divergence threshold. |
Derived |
Decision Support System (DSS) |
High |
|
Demonstration |
DA-6.3.1 |
Volume Divergence Threshold Configuration for Expressways |
The DSS-EMS shall use a volume divergence threshold, which is configurable for expressways by individual segment and with a default value of 150 vehicles, for calculation of a volume divergence alarm on expressway segments. |
Derived |
Decision Support System (DSS) |
Medium |
|
Demonstration |
DA-6.3.2 |
Volume Divergence Threshold Configuration for Arterials |
The DSS-EMS shall use a volume divergence threshold, which is configurable for arterials by individual segment and with a default value of 100 vehicles, for calculation of a volume divergence alarm on arterial segments. |
Derived |
Decision Support System (DSS) |
Medium |
|
Demonstration |
DA-6.3.3 |
Volume Divergence Threshold Configuration for Frontage Roads |
The DSS-EMS shall use a volume divergence threshold, which is configurable for frontage roads by individual segment and with a default value of 100 vehicles, for calculation of a volume divergence alarm on frontage road segments. |
Derived |
Decision Support System (DSS) |
Medium |
|
Demonstration |
DA-6.3.4 |
Volume Divergence Alarm Data |
The DSS-EMS shall include the following data elements in each volume divergence alarm:
|
Derived |
Decision Support System (DSS) |
High |
Detailed data element descriptions are available in the C2C-SICD |
Demonstration |
DA-6.4 |
Occupancy Divergence Alarm |
The DSS-EMS shall generate an occupancy divergence alarm when the occupancy of a monitored expressway, expressway entrance ramp, or expressway exit ramp is greater than the historical occupancy of the segment plus the occupancy divergence threshold. |
Derived |
Decision Support System (DSS) |
High |
|
Demonstration |
DA-6.4.1 |
Occupancy Divergence Threshold Configuration |
The DSS-EMS shall use an occupancy divergence threshold, which is configurable for expressways, expressway exit ramps, and expressway entrance ramps by individual segment, and with a default value of 25 percent, for calculation of occupancy divergence alarms on expressway, expressway exit ramps, and expressway entrance ramp segments. |
Derived |
Decision Support System (DSS) |
Medium |
|
Demonstration |
DA-6.4.2 |
Occupancy Divergence Alarm Data |
The DSS-EMS shall include the following data elements in each occupancy divergence alarm:
|
Derived |
Decision Support System (DSS) |
High |
Detailed data element descriptions are available in the C2C-SICD |
Demonstration |
DA-6.5 |
Divergence Alarm Performance |
The DSS-EMS shall be capable of comparing the historical average data with the current conditions data in two-minutes or less for generating divergence alarms. |
Derived |
Decision Support System (DSS) |
High |
|
Demonstration |
DA-7 |
Recommended Actions |
The DSS-EMS shall generate recommended actions for each current conditions and historical convergence alarm that is generated. |
Derived from DA-6 |
Decision Support System (DSS) |
High |
|
Demonstration |
DA-7.1 |
Generated Recommended Actions |
The DSS-EMS generated recommended actions shall include the following:
|
Derived |
Decision Support System (DSS) |
High |
Recommended actions will not be automatically executed by the agencies. The suggestions will be reviewed and executed as appropriate by the agency’s operations staff. |
Demonstration |
DA-7.1.1 |
Traffic Signal Timing Pattern Recommended Action |
The DSS-EMS recommended action for changes in traffic signal timing patterns shall include the following for each effected traffic signal:
|
Derived |
Decision Support System (DSS) |
High |
The CoSA traffic signal operations staff will be responsible for selecting an appropriate traffic signal timing pattern. |
Demonstration |
DA-7.1.2 |
Reroute of Buses Recommended Action |
The DSS-EMS recommended action for reroute of buses shall include the following for each effected bus route:
|
Derived |
Decision Support System (DSS) |
High |
The recommended action will not suggest to the operator where to route the bus, only that the route should be rerouted. |
Demonstration |
DA-7.1.3 |
DMS Message Recommended Action |
The DSS-EMS recommended action for DMS messages shall include the following for each effected DMS:
|
Derived |
Decision Support System (DSS) |
High |
|
Demonstration |
DA-7.1.4 |
LCS Signalization Recommended Action |
The DSS-EMS recommended action for LCS signalization shall include the following for each effected LCS:
|
Derived |
Decision Support System (DSS) |
High |
|
Demonstration |
DA-7.2 |
Recommended Action Equipment |
The DSS-EMS shall determine the traffic signals, bus routes, DMS signs, and LCS signals that are to be included in recommended actions. |
Derived |
Decision Support System (DSS) |
High |
|
Demonstration |
DA-8 |
Alarm Logging |
The DSS-EMS shall archive alarm events and recommended actions that are generated. |
Derived from DA-6 |
Decision Support System (DSS) |
Medium |
|
Demonstration |
DA-9 |
Alarm Filtering |
The DSS-EMS shall filter alarm events. |
Derived from DA-6 |
Decision Support System (DSS) |
High |
|
Demonstration |
DA-9.1 |
Alarm Filtering for Segments |
The DSS-EMS shall send the ICMS Graphical User Interface (GUI) only the alarm events that occur on the expressway, arterial, frontage road, or bus route segments that the user has “subscribed” to. |
Derived |
Decision Support System (DSS) |
High |
More detailed requirements for how the ICMS GUI handles alarm events are included in section 4.3. |
Demonstration |
DA-9.2 |
Alarm Filtering for Alarm Types |
The DSS-EMS shall send the ICMS GUI only the alarm events for the alarm types that the user has “subscribed” to. |
Derived |
Decision Support System (DSS) |
High |
|
Demonstration |
DA-9.3 |
Alarm Filtering Configuration |
The DSS-EMS shall include a user interface that provides the capabilities for each individual user to configure the filtering for alarms that the user wishes to receive. |
Derived |
Decision Support System (DSS) |
High |
|
Demonstration |
4.2.3 ICMS Arterial Travel Times
Return to Contents
The ICMS Arterial Travel Times Engine requirements are included in the table below.
| ID | Title | Requirement | Traceability | Allocation | Criticality | Comment | Verification Method |
|---|---|---|---|---|---|---|---|
DA-10 |
AVL Arterial Travel Time Engine |
The ICMS shall include an AVL Arterial Travel Time (ATT) Engine for determining traffic conditions on arterial road segments. |
TG-ICM-COO p43 |
Decision Support System (DSS) |
High |
|
Demonstration |
DA-10.1 |
AVL Travel Time Engine Bus Monitoring |
The DSS-ATT Engine shall monitor each bus that completely traverses an expressway, arterial, or frontage road segment tracking the bus ID, bus route, number of stops made, time entering the segment and time leaving the segment. |
Derived |
Decision Support System (DSS) |
High |
|
Demonstration |
DA-10.2 |
Individual Bus Travel Time Calculation |
The DSS-ATT Engine shall generate a travel time in seconds for each bus that traverses a road segment. |
Derived |
Decision Support System (DSS) |
High |
|
Demonstration |
DA-10.2.1 |
Account of Bus Dwell Time |
The DSS-ATT Engine shall calculate travel times for individual buses by removing the dwell time for the bus. |
Derived |
Decision Support System (DSS) |
High |
Removing the dwell time will provide the travel time of the bus across the road segment. |
Demonstration |
DA-10.3 |
AVL Bus Average Travel Time |
The DSS-ATT Engine shall generate a fused travel time in seconds for each segment by averaging the individual bus travel times that have been calculated in the last bus travel time window period. |
Derived |
Decision Support System (DSS) |
High |
|
Demonstration |
DA-10.3.1 |
Bus Travel Time Window Period Configuration |
The DSS-ATT shall use a bus travel time window period, which is configurable with a default value of 30 minutes, for the calculation of segment travel times. |
Derived |
Decision Support System (DSS) |
High |
|
Demonstration |
DA-10.3.2 |
Bus Travel Time Outliers |
The DSS-ATT engine shall filter outliers from the sample set used to calculate the average travel times. |
Derived |
Decision Support System (DSS) |
High |
Specific mechanism for filtering outliers will be determined in the design of the algorithm. |
Demonstration |
DA-10.4 |
Account of Reduced Bus Speed |
The DSS-ATT Engine shall account for a reduced bus speed factor in determining the average segment travel time. |
Derived |
Decision Support System (DSS) |
High |
|
Demonstration |
DA-10.4.1 |
Reduced Bus Speed Factor Configuration |
The DSS-ATT shall use the reduced bus speed factor, which is configurable with a default value of 15%, for the calculation of segment travel times. |
Derived |
Decision Support System (DSS) |
High |
|
Demonstration |
DA-10.5 |
DSS-ATT Engine Performance |
The DSS-ATT Engine shall generate travel times for each segment (provided an accurate sample size exists) at a minimum of once every 2 minutes. |
Derived |
Decision Support System (DSS) |
High |
|
Demonstration |
DA-10.6 |
DSS-ATT Engine Archiving |
The DSS-ATT Engine shall archive the time, date, latitude, longitude, route, block and type of event for each of the following events:
|
Derived |
Decision Support System (DSS) |
High |
|
Inspection |
4.3 ICMS Operations User Interface
Return to ContentsThe ICMS Operations User Interface requirements are included in the table below.
| ID | Title | Requirement | Traceability | Allocation | Criticality | Comment | Verification Method |
|---|---|---|---|---|---|---|---|
UI-1 |
ICMS Graphical User Interface |
The ICMS shall include a GUI |
TG-ICM-COO p44 |
ICM Operations UI |
High |
|
Demonstration |
UI-2 |
GUI DSS Interface |
The ICMS GUI shall include an interface to the DSS |
TG-ICM-COO p44 |
ICM Operations UI |
High |
|
Inspection |
UI-2.1 |
GUI DSS Data Types |
The ICMS GUI shall receive the following status data from the DSS:
|
Derived |
ICM Operations UI |
High |
|
Demonstration |
| UI-2.2 | GUI DSS Alarm Data | The ICMS GUI shall receive Alarm Incident Data from the DSS | Derived | ICM Operations UI | High | |
Demonstration |
UI-2.2.1 |
GUI DSS Alarm Types |
The ICMS GUI shall receive Alarm Incident Data for the following alarms
|
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-2.2.2 |
GUI DSS Recommended Actions |
The ICMS GUI shall receive recommended actions for alarms from the DSS. |
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-2.2.3 |
GUI DSS Lag Threshold |
The ICMS GUI shall display alarms and recommended actions from the DSS in a maximum of 15 seconds from the time the alarm is detected in the DSS. |
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-3 |
GUI Data Display |
The ICMS GUI shall display all DSS status data to the user unless the user has specified a filter for the data. |
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-3.1 |
GUI Data Filtering |
The ICMS GUI shall provide a list of data types for each user to select which DSS data will be displayed. |
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI3.2 |
GUI Data Lag Threshold |
The ICMS GUI shall update displayed data in a maximum of 5 seconds from when the updated data is received from the DSS. |
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-4 |
GUI Alarm Display |
The ICMS GUI shall display all DSS alarms to the user unless the user has specified a filter for the alarms. |
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-4.1 |
GUI Alarm Filtering |
The ICMS GUI shall provide a list of alarm types for each user to select which DSS alarms will be displayed. |
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-4.1.1 |
GUI Alarm Location Filtering |
The ICMS GUI shall provide users the option to filter alarms based on location by selecting segments from the following location types
|
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-4.1.2 |
GUI Alarm Type Filtering |
The ICMS GUI shall provide users the option to filter alarms based on type. |
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-5 |
GUI Recommended Action Display |
The ICMS GUI shall display recommended actions to the user. |
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-5.1 |
GUI Recommended Action Filtering |
The ICMS GUI shall only display recommended actions for alarms that have been selected by the user. |
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-5.1.1 |
GUI Recommended Action Types |
The ICMS GUI shall display one or more of the following action types in each recommended action:
|
Derived |
ICM Operations UI |
High |
|
Demonstrated |
UI-5.2 |
GUI Recommended Action Tracking |
The ICMS GUI shall track the status of each recommended action as either “acknowledged” or “ignored”. |
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-5.3 |
GUI Tracking Mechanism |
The ICMS GUI shall provide an option for the user to select whether the recommended action has been acknowledged or ignored. |
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-6 |
GUI DSS Configuration |
The ICMS shall provide users an interface for configuring DSS functionality. |
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-6.1 |
GUI DSS Current Conditions Alarm Configuration |
The ICMS GUI shall include a user interfacefor configuring the following DSS current conditions alarm threshold values
|
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-6.2 |
GUI DSS Historical Divergence Alarm Configuration |
The ICMS GUI shall include a user interfacefor configuring the following DSS historical divergence alarm threshold values
|
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-6.3 |
GUI DSS Historical Data Configuration |
The ICMS GUI shall include a user interface for configuring the following DSS historical data configuration values:
|
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-6.4 |
GUI DSS AVL Travel Time Configuration |
The ICMS GUI shall include a user interfacefor configuring the DSS AVL travel time configuration values. |
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-6.5 |
GUI Update Cycle |
The ICMS GUI shall include a user interfacefor configuring the DSS update period - how often the DSS shall provide updated data to the ICMS GUI (default every 300 seconds). |
Derived |
ICM Operations UI |
Medium |
|
Demonstration |
UI-7 |
GUI User Management |
The ICMS GUI shall display all user accounts currently in the ICMS. |
Derived |
ICM Operations UI |
Medium |
|
Demonstration |
UI-7.1 |
GUI User Addition |
The ICMS GUI shall provide users the ability to add user accounts to the ICMS. |
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-7.1.1 |
GUI User types |
The ICMS GUI shall provide three types of users:
|
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-7.1.1.1 |
GUI Observer Permissions |
ICMS observers shall be able to view status data currently available on the GUI. |
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-7.1.1.2 |
GUI Operator Permissions |
ICMS operators shall possess the abilities of ICMS observers, as well as the ability to acknowledge alarms and configure the ICMS. |
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-7.1.1.3 |
GUI Administrator Permissions |
ICMS administrators shall possess the ability of ICMS operators, as well as the ability to add/delete users and reset passwords. |
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-7.1.2 |
GUI User Accounts |
The ICMS GUI shall include the following fields for each user added
|
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-7.2 |
GUI User Modification |
The ICMS GUI shall provide administrators the ability to modify users currently in the system. |
Derived |
ICM Operations UI |
Medium |
|
Demonstration |
UI-7.3 |
GUI User Deletion |
The ICMS GUI shall provide administrators the ability to delete users currently in the system. |
Derived |
ICM Operations UI |
Medium |
|
Demonstration |
UI-7.4 |
GUI Login |
The ICMS GUI shall require each user to log in using their username and password. |
Derived |
ICM Operations UI |
Medium |
|
Demonstration |
UI-7.5 |
GUI User Logging |
The ICMS GUI shall log user modifications including adding, deleting and modifying users. |
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-7.6 |
GUI Configuration Logging |
The ICMS GUI shall log system configuration modifications made by a user. |
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-7.6.1 |
Log Fields |
The logs generated by the ICMS GUI shall contain the user who initiated the action, the change that was made and the data and time that the action occurred. |
Derived |
ICM Operations UI |
High |
|
Demonstration |
UI-8 |
Video Distribution User Interface |
The ICMS shall provide a list for users to select CCTV video streams to view. |
Derived |
ICM Operations UI |
Medium |
|
Demonstration |
UI-8.2 |
Video Distribution Video Stream Selection |
The ICMS shall include a user interface that provides users a way to select the CCTV icon of the desired video. |
Derived |
ICM Operations UI |
Medium |
|
Demonstration |
UI-8.3 |
Video Distribution CCTV Status Data |
The ICMS shall display a CCTV status popup from the map that will include the following CCTV status data: name, identifier, status, blackout, and current camera direction. |
Derived |
ICM Operations UI |
Medium |
|
Demonstration |
UI-8.4 |
Video Distribution Stream Limit |
The ICMS shall limit the number of video streams displayed at one IP address to a configurable limit. |
Derived |
ICM Operations UI |
Medium |
Assume a web browser or Commercial-off-the-Shelf (COTS) video decoder will be utilized to view the video streams. Assume video stream is IP based. |
Demonstration |
UI-9 |
ICMS GUI User Management |
The ICMS shall support a minimum of 50 users. |
Derived UI-7 |
ICM Operations UI |
High |
|
Demonstration |
UI-9.1 |
ICMS GUI Concurrent Users |
The ICMS shall support a minimum of 15 users concurrently. |
Derived |
ICM Operations UI |
High |
|
Demonstration |
4.4 Corridor Web Suite
Return to ContentsThe ICMS Corridor Web Suite requirements are included in the following table.
| ID | Title | Requirement | Traceability | Allocation | Criticality | Comment | Verification Method |
|---|---|---|---|---|---|---|---|
WS-1 |
ICMS Web Site General Web Site Requirements |
The ICMS Web Site shall meet the following general requirements for TxDOT web sites: |
Requirement TI-2 |
Web Server |
High |
This is a parent requirement for the child requirements below. |
Demonstration |
WS-1.1 |
ICMS Web Site Wait Times |
The ICMS web site software shall use server side processing. |
Requirement TI-2 |
Web Server |
High |
|
Demonstration |
WS-.12 |
ICMS Web Site Compliance with ADA |
The web site shall include a text-only version of the web site information that complies with Section 508 of the American Disabilities Act (ADA). |
Requirement TI-2 |
Web Server |
High |
|
Demonstration |
WS-1.3 |
ICMS Web Site Help Page Link |
The ICMS web site shall provide a link to a Help Page offering information in text and/or graphic format on the basic use of the Web site, and listing types of content available on the site. |
Requirement TI-2 |
Web Server |
Medium |
|
Demonstration |
WS-1.4 |
ICMS Web Site Webmaster E-mail Link |
The ICMS web site shall provide an e-mail link that will enable users to send a message to the Webmaster. |
Requirement TI-2 |
Web Server |
Medium |
|
Demonstration |
4.4.1 Personal Emergency Transportation Planner
Return to ContentsThe ICMS Personal Emergency Transportation Planner (PETP) requirements are included in the following table.
| ID | Title | Requirement | Traceability | Allocation | Criticality | Comment | Verification Method |
|---|---|---|---|---|---|---|---|
PETP-1 |
ICMS PETP |
The ICMS shall include a PETP. |
TG-ICM-COO p45 |
Corridor Websites |
High |
|
Demonstration |
PETP-1.1 |
ICMS PETP Web Interface |
The ICMS PETP shall be web based. |
TG-ICM-COO p45 |
Corridor Websites |
High |
|
Demonstration |
PETP-1.2 |
ICMS PETP Route Input Fields |
The ICMS PETP shall include the following route input fields:
|
TG-ICM-COO p45 |
Corridor Websites |
High |
|
Demonstration |
PETP-1.3 |
ICMS PEPT Route Determination |
The ICMS PEPT shall determine the following route types based on the input fields:
|
TG-ICM-COO p45 |
Corridor Websites |
High |
|
Demonstration |
PETP-1.3.1 |
ICMS PEPT Bus Route Schedule Information |
The ICMS PEPT shall display the bus route schedule for each individual bus route that is part of the entire bus route. |
Requirement TI-1.3 |
Corridor Websites |
High |
|
Demonstration |
PETP-1.3.2 |
ICMS PEPT Driving Route Information |
The ICMS PEPT shall display the following suggested route related information on a map for expressway and arterial routes:
|
Requirement TI-1.3 |
Corridor Websites |
High |
|
Demonstration |
PETP-1.3.3 |
ICMS PEPT Bus Route Information |
The ICMS PEPT shall display the following suggested route related information on a map for bus routes:
|
Requirement TI-1.3 |
Corridor Websites |
High |
|
Demonstration |
PETP-1.3.4 |
ICMS PEPT Map Background Information |
The ICMS PEPT shall display the following background information on the map:
|
Requirement TI-1.3 |
Corridor Websites |
High |
|
Demonstration |
PETP-1.3.5 |
ICMS PEPT Step-by-step Directions |
The ICMS PEPT shall display step-by-step directions for the traveler to traverse the driving routes and bus route. |
Requirement TI-1.3 |
Corridor Websites |
High |
|
Demonstration |
PETP-1.3.6 |
ICMS PEPT Legend |
The ICMS PEPT shall display a legend of all color-coding and route related icon descriptions on the same page as the map. |
Requirement TI-1.3 |
Corridor Websites |
High |
|
Demonstration |
PETP-1.3.7 |
ICMS PEPT Display of Routes |
The ICMS PEPT shall only display one route (Expressway Route, or Arterial Route, Bus Route) on the map at a time. |
Requirement TI-1.3 |
Corridor Websites |
High |
Concerned displaying all routes at one time will be “cluttered”. |
Demonstration |
PETP-1.3.8 |
ICMS PEPT Selection of Routes |
The ICMS PEPT shall provide the mechanism for the user to select which route (expressway, arterial, or bus) to view on the map. |
Requirement TI-1.3 |
Corridor Websites |
High |
|
Demonstration |
1.3.9 |
ICMS PEPT Default Route to Display |
The ICMS PEPT default route to display shall be configurable with the default value set to the expressway route. |
Requirement TI-1.3 |
Corridor Websites |
High |
|
Demonstration |
PEPT-1.3.10 |
ICMS PEPT Time to Display Routes |
The ICMS PEPT shall display a response for the user requested route within 30 seconds. |
Requirement TI-1.3 |
Corridor Websites |
High |
Slow Internet connection may affect ability to communicate the response back to the user within 30 seconds. |
Demonstration |
PETP-1.4 |
ICMS PEPT Route Printout Page |
The ICMS PEPT shall provide a link to a Route Printout Page. |
TG-ICM-COO p45 |
Corridor Websites |
High |
Allows user to store route/direction information in their vehicle. |
Demonstration |
PETP-1.4.1 |
ICMS PEPT Route Printout Page Size |
The ICMS PEPT Route Printout Page shall be formatted to print on 8 ½ by 11 inch pages. |
Requirement TI-1.4 |
Corridor Websites |
High |
|
Demonstration |
PETP-1.4.2 |
ICMS PEPT Route Printout Page Information |
The ICMS PEPT Route Printout Page shall include the following information:
|
Requirement TI-1.4 |
Corridor Websites |
High |
|
Demonstration |
PETP-1.5 |
ICMS PEPT Agency Website Links |
The ICMS PEPT shall provide links to the following agency websites:
|
TG-ICM-COO p45 |
Corridor Websites |
High |
|
Demonstration |
PETP-1.6 |
ICMS PEPT User Account |
The ICMS PEPT shall provide the mechanism for new users to create a user account. |
TG-ICM-COO p45 |
Corridor Websites |
High |
Creating a user account will allow for incident alert emails to be sent and for a user to return to the system to review their route. |
Demonstration |
PETP-1.6.1 |
ICMS PEPT User Account Information |
The ICMS PEPT shall provide the mechanism to input the following user account information:
|
Requirement TI-1.6 |
Corridor Websites |
High |
|
Demonstration |
PETP-1.6.2 |
ICMS PEPT User Account Storage |
The ICMS PEPT shall provide the mechanism to store the user account information. |
Requirement TI-1.6 |
Corridor Websites |
High |
|
Demonstration |
PETP-1.6.3 |
ICMS PEPT Route Loading |
The ICMS PEPT shall store the saved routes for the next time the user logins into the system. |
Requirement TI-1.6 |
Corridor Websites |
High |
|
Demonstration |
PETP-1.6.4 |
ICMS PEPT Route |
The ICMS PEPT shall display a list of the saved routes for the user to select to view. |
Requirement Ti-1.6 |
Corridor Websites |
High |
|
Demonstration |
PETP-1.6.5 |
ICMS PEPT Route Recalculation |
The ICMS PEPT shall “recalculate” the saved route the next time it is viewed to account for construction, lane closures, bus route changes, and bus schedule changes. |
Requirement TI-1.6 |
Corridor Websites |
High |
|
Demonstration |
PETP-1.6.6 |
ICMS PEPT User Account Updates |
The ICMS PEPT shall provide the mechanism for the user to update the account information. |
Requirement TI-1.6 |
Corridor Websites |
High |
|
Demonstration |
PETP-1.6.7 |
ICMS PEPT Incident Alerts |
The ICMS PEPT shall send an email notification to the user account’s email address when an incident or lane closure occurs on the route within 30 minutes of the day of week and time the traveler selected to travel the route. |
Requirement TI-1.6 |
Corridor Websites |
High |
|
Demonstration |
PETP-1.6.8 |
ICMS PEPT Route Management |
The ICMS PEPT shall allow users to add, update, and delete existing saved routes up to five routes. |
Requirement TI-1.6 |
Corridor Websites |
High |
|
Demonstration |
PETP-1.6.9 |
ICMS PEPT Administrative User Management |
The ICMS PEPT shall allow the system administrator to add, remove, or update existing user accounts. |
Requirement TI-1.6 |
Corridor Websites |
High |
|
Demonstration |
PETP-1.6.10 |
ICMS PEPT User Account Expiration |
The ICMS PEPT shall expire user accounts that are not accessed for more than one year. |
Requirement TI-1.6 |
Corridor Websites |
High |
|
Demonstration |
PETP-1.6.11 |
ICMS PEPT Login |
The ICMS PEPT will require users to login with a valid username and password. |
Requirement TI-1.6 |
Corridor Websites |
High |
|
Demonstration |
PETP-1..6.12 |
ICMS PEPT User Management |
The ICMS PEPT shall support a minimum of 5,000 user accounts. |
Requirement TI-1.6 |
Corridor Websites |
High |
Verification will be performed by ensuring sufficient database space exists to store the user account information. |
Inspection |
PETP-1.6.13 |
ICMS PEPT Concurrent Users |
The ICMS shall support a minimum of 50 users concurrently. |
Requirement TI-1.6 |
Corridor Websites |
High |
|
Demonstration |
4.4.2 Corridor Data
Return to ContentsThe ICMS Corridor Data web server requirements are included in the following table.
| ID | Title | Requirement | Traceability | Allocation | Criticality | Comment | Verification Method |
|---|---|---|---|---|---|---|---|
CD-1 |
ICMS Web Server |
The ICMS shall include a Web Server to provide ICMS status data to the public. |
TG-ICM-COO p42 |
Corridor Websites |
High |
|
Demonstration |
CD-2 |
ICM External Connections |
The ICMS Web Server shall receive status data from external sources. |
Derived |
Corridor Websites |
High |
|
Inspection |
CD-2.1 |
Web Server DSS Interface |
The ICMS Web Server shall include an interface to the DSS. |
Derived |
Web Server |
High |
|
Inspection |
CD-2.2 |
Web Server C2C System Interface |
The ICMS Web Server shall include an interface to the C2C System. |
Derived |
C2C Plugins |
High |
|
Inspection |
CD-2.3 |
Web Server DSS Data Types |
The ICMS Web Server shall receive the following status data:
|
Derived |
Web Server |
High |
|
Demonstration |
CD-3 |
Web Server Web Site |
The ICMS Web Server shall provide a web site for displaying the latest version of the status data sent from the DSS to the Web Server. |
Derived |
Web Server |
High |
|
Demonstration |
CD-3.1 |
Web Site Update Cycle |
The ICMS Web Server shall provide users an interface for configuring the update period of the web site - how often the Web Server shall provide updated data to the web site (default every 300 seconds). |
Derived |
Web Server |
High |
|
Demonstration |
4.4.3 Corridor Map
Return to ContentsThe ICMS Corridor Map requirements are included in the following table:
| ID | Title | Requirement | Traceability | Allocation | Criticality | Comment | Verification Method |
|---|---|---|---|---|---|---|---|
CM-1 |
Web Site |
The ICMS Web Site shall provide a map for displaying the following data types:
|
Derived from CD-3 |
Corridor Websites |
High |
|
Demonstration |
CM-1.1 |
Web Map Filtering |
The ICMS Web Site shall provide an interface for users to filter which data types will be displayed on the map. |
Derived |
Corridor Websites |
Medium |
|
Demonstration |
CM-1.2 |
Web Site Data Display |
In addition to the map, the ICMS Web Site shall provide textual information for the following data types:
|
Derived |
Corridor Websites |
Medium |
|
Demonstration |
4.4.4 Mobile Device Accessible Web Site
Return to ContentsThe Mobile Device Accessible Web Site requirements are contained in the following table.
| ID | Title | Requirement | Traceability | Allocation | Criticality | Comment | Verification Method |
|---|---|---|---|---|---|---|---|
MD-1 |
Mobile Device Web Site |
The ICMS Web Server shall include a mobile device accessible web site. |
TG-ICM-COO p42 |
Corridor Websites |
Medium |
|
Inspection |
MD-1.1 |
Mobile Device Web Site Data |
The ICMS mobile device web site shall provide the following data:
|
Derived |
Corridor Websites |
High |
|
Demonstration |
MD-1.1.1 |
Web Map Filtering |
The ICMS mobile device web site shall provide a mechanism for users to filter which data types will be displayed on the map. |
Derived |
Corridor Websites |
Medium |
|
Demonstration |
MD-1.1.2 |
Mobile Device Filtering |
The ICMS mobile device web site shall restrict the number of concurrently displayed data types to a configurable value (default 2). |
Derived |
Corridor Websites |
High |
|
Demonstration |
MD-1.2 |
Web Site |
The mobile device web site shall provide a map for displaying the data types. |
Derived |
Corridor Websites |
High |
|
Demonstration |
MD-1.3 |
Mobile Site Size |
The ICMS mobile device web site render at a minimum size of 2” x 2”. |
Derived |
Corridor Websites |
Medium |
|
Demonstration |
MD-1.4 |
Mobile Site Load Times |
The ICMS mobile device web site shall have maximum page load times of 15 seconds when minimum connection speed of 50 kbps exists. |
Derived |
Corridor Websites |
Medium |
|
Demonstration |
MD-1.5 |
Mobile Site Update Cycle |
The ICMS Web Server shall provide a mechanism for configuring the update period of the mobile device web site - how often the Web Server shall provide updated data to the mobile device web site (default every 300 seconds). |
Derived |
Corridor Websites |
High |
|
Demonstration |
4.5 General Requirements
General requirements for the ICMS are included in the following table. These requirements are applicable to the ICMS as a whole. Requirements with a Traceability of Not Applicable (NA) were derived after completion of the Concept of Operations. Since these requirements are associated with technical, as opposed to operational, aspects of the ICMS they are not documented in the Concept of Operations.
| ID | Title | Requirement | Traceability | Allocation | Criticality | Comment | Verification Method |
|---|---|---|---|---|---|---|---|
GEN-1.0 |
ICMS Source Code Ownership |
The ICMS Software Source Code shall be owned by one or more of the public San Antonio ICM stakeholder agencies (TxDOT, VIA, CoSA). |
NA |
High |
Allows for long-term maintenance of the system to occur without dependence on a single system vendor. |
Inspection |
|
GEN-2.0 |
ICMS Source Coding Standards |
The ICMS software source code shall confirm to known coding standards. |
NA |
General - Maintenance |
High |
Improves readability and maintainability. |
Inspection |
GEN-2.1 |
ICMS Source Coding Standards for the C Language |
The ICMS C language software source code shall conform to the Indian Hill C Standard. |
NA |
General - Maintenance |
High |
Existing C code used in the TransGuide ATMS is based on this coding standard. |
Inspection |
GEN-3.0 |
ICMS Design Documentation |
The ICMS shall include documentation that describes, where applicable, the system architecture, detailed design, data flow, interfaces, system components, system resources, design decisions, data dictionary, and software requirements. |
NA |
General - Maintenance |
High |
Allows for improved maintainability of the system. |
Inspection |
GEN-4.0 |
ICMS Interfaces Implemented Using XML |
ICMS System Interfaces that are not constrained to a format shall be implemented using XML when possible. |
NA |
General - Maintenance |
Medium |
XML interfaces ease integration between system modules and improve maintainability for ease of future use of the data. |
Inspection |
GEN-5.0 |
ICMS System Uptime |
The ICMS shall be designed with hardware components and software architecture that will be capable of providing 99% uptime. |
NA |
General – Reliability and Performance |
High |
System hardware and software design should be capable of providing 99% uptime. |
Inspection |
GEN-6.0 |
Obtaining Performance Measure Data |
The ICMS shall provide a mechanism for obtaining data used to calculate performance measures. |
TG-ICM-COO Section 2.3.9 |
General - Reliability and Performance Verification |
High |
Data to support the derivation of performance measures will be accessible in reports. Reports will be added to the existing TransGuide Data Archive. |
Demonstration |
GEN-6.1 |
Effective and Reliable Transportation Performance Measure Data |
The ICMS shall provide the following data to support the performance measures associated with Effective and Reliable Transportation:
|
TG-ICM-COO Section 2.3.9 |
General - Reliability and Performance Verification |
High |
|
Demonstration |
GEN-6.2 |
Safety Performance Measure Data |
The ICMS shall provide the following data to support the performance measures associated with Safety:
|
TG-ICM-COO Section 2.3.9 |
General - Reliability and Performance Verification |
High |
|
Demonstration |
GEN-6.3 |
Incident Management Performance Measure Data |
The ICMS shall provide the following data to support the performance measures associated with Incident Management:
|
TG-ICM-COO Section 2.3.9 |
General - Reliability and Performance Verification |
High |
|
Demonstration |
GEN-6.4 |
Traveler Information Performance Measure Data |
The ICMS shall provide the following data to support the performance measures associated with Traveler Information:
|
TG-ICM-COO Section 2.3.9 |
General - Reliability and Performance Verification |
High |
Web usage statistics are commonly available from web server reporting tools and will likely be obtained from this source instead of the TransGuide Data Archive. |
Demonstration |
APPENDIX A
Return to Contents
ACRONYMS
Acronym |
Definition |
AADT |
Average Annual Daily Traffic |
AIH |
Alarm Incident Handler |
ATIS |
Advanced Traveler Information Service |
ATMS |
Advanced Traffic Management System |
AVL |
Automated Vehicle Location |
AWARD |
Advanced Warning to Avoid Railroad Delays |
BRT |
Bus Rapid Transit |
C2C |
Center-to-Center |
CCTV |
Closed Circuit Television |
COO |
Concept of Operations |
CoSA |
City of San Antonio |
DMS |
Dynamic Message Sign |
EOC |
Emergency Operations Center |
FHWA |
Federal Highway Administration |
FM |
Farm-to-Market |
ICM |
Integrated Corridor Management |
ICMS |
Integrated Corridor Management Services |
IT |
Information Technology |
ITS |
Intelligent Transportation Systems |
LCS |
Lane Control Signal |
LCU |
Local Control Unit |
NEMA |
National Electrical Manufacturers Association |
NIOSA |
Night in Old San Antonio |
NTCIP |
National Transportation Communications for ITS Protocol |
SAPD |
San Antonio Police Department |
SH |
State Highway |
SwRI |
Southwest Research Institute |
TBD |
To Be Determined |
TBR |
To Be Reviewed |
TTI |
Texas Transportation Institute |
TWLTL |
Two-Way Left Turn Lane |
TxDOT |
Texas Department of Transportation |
USAA |
United States Automobile Association |
UTSA |
University of Texas at San Antonio |
VIA |
VIA Metropolitan Transit |
VIVD |
Video Image Vehicle Detection |