Document Description	Date	Version Number
First draft release of Concept of Operations (Strawman) for review and preparation for workshop.	February 6, 2006	0.1
Second draft of Strawman Concept of Operations, incorporating edits during Feb 22 workshop.	February 28, 2006	0.2
First draft of complete Concept of Operations, incorporating input from the second workshop March 8, input from emergency responders, and adding User Needs.	April 17, 2006	0.3
Modified to incorporate comments from May 9, 2006 ITS Partnership meeting, and to add material related to 511 node.	June 23, 2006	1.0

1 Executive Summary

The Sacramento Transportation Area Network, or STARNET, is an information exchange network and operations coordination framework that will be used by the operators of transportation facilities and emergency responders in the Sacramento region of California. STARNET will enable the real-time sharing of data and live video, and refinement of joint procedures pertaining to the operation of roadways and public transit, and public safety activities.

STARNET will build upon the previous Intelligent Transportation System (ITS) investments by using, with little to no modifications, the existing field infrastructure (cameras, changeable message signs, traffic signals, vehicle location systems, etc) and central systems (freeway management systems, traffic signal systems, transit management systems, computer aided dispatch systems, etc) already operated by each agency. As part of the STARNET implementation, interfaces will be developed to these existing systems to enable them to share data and video with each other, provide data and video to the public via the 511 regional travel information system, and provide operations and emergency response personnel with a map-based regional transportation management display.

This document identifies the concept of operations which represents the STARNET stakeholders’ envisioned day-to-day conditions and activities (operation) during the on-going use of STARNET. The development of a concept of operations involves the following major steps:

1. Describe the environment in which STARNET must be built and must operate. The environment describes the existing systems, communications infrastructure, climate, terrain, and expected regional growth. These are factors over which the STARNET team has little, or no, control. The description of the environment is found in Sections 5 and 6.

2. Identify real-life scenarios illustrating what data should be exchanged between agencies, how they will be used, and joint procedures involved. The scenarios also discuss who will be responsible for the operations and maintenance of the system. The discussion of scenarios is found in Section 7.

3. From the operation scenarios, user needs are identified and found in Section 8. User needs are those items or features the STARNET team needs to provide or make happen.

4. To determine the effectiveness of STARNET, a list of metrics for the STARNET performance evaluation has been identified. These metrics are used after the system is operational to determine if the system is performing as expected. The performance metrics are found in Section 9.

The STARNET team is composed of all parties involved in the design, implementation, operation, and maintenance of STARNET. The team is lead by the Sacramento Region ITS Partnership, which designates a STARNET Technical Advisory Committee. The following agencies are part of the STARNET Team and are being considered as possible participants (to provide and/or receive data) on STARNET: California Highway Patrol, Caltrans District 3, El Dorado County, El Dorado County Transit Authority, Placer County, Sacramento Area Council of Governments, Sacramento County, Sacramento Regional Fire/EMS Communications Center, Sacramento Regional Transit District , Yolo County Transportation District, Yolo County Communications Emergency Service Agency, and the Cities of Citrus Heights, Elk Grove, Folsom, Rancho Cordova, Rocklin, Roseville, Sacramento, and West Sacramento.

Through the operational scenarios, it has been identified that the following types of data will be exchanged on STARNET and available to operators on the Regional Display: incidents (including planned lane closures), changeable message sign message content, traffic signal status, vehicle detector data, transit service disruptions, automated vehicle location data, transit vehicle arrival times, ramp metering status, video, and camera control. A suitably filtered subset of the available data and live video (without camera control) will be provided to the regional travel information system where the data can be incorporated in a publicly accessible web page and a 511 phone system. Each agency will control what data and video they make available to each other agency and to the public travel information system.

To realize the full benefit of STARNET, along with enabling information to be exchanged among the partner agencies, STARNET will help develop procedures to enhance the coordination of activities between agencies. The procedures will focus on how to integrate STARNET, and the data and capabilities provided by it, into agencies’ existing operating procedures. The intent is to not involve any significant additional effort for personnel in participating agencies, and to simplify the task of obtaining information and coordinating inter-agency activities.

Through the combination of data sharing and improved operating procedures, STARNET will enhance the effectiveness of real-time transportation management and emergency response in the following ways:

· Provide procedures for enhanced coordination of activities between agencies.

· Provide additional real-time information, including live video from roadside cameras, needed for operations personnel and emergency responders to make faster and better decisions.

· Provide information exchange, a map-based integrated view of data from all agencies, and joint procedures needed for agencies to better coordinate their activities.

· Provide more comprehensive, accurate, and timely information to the public concerning the current status of transportation facilities and incidents.

· Enable better coordination of transportation management and emergency response activities during major emergencies such as flood evacuations.

· Provide the data exchange needed between computer systems to enable automated coordination of traffic signal timings across jurisdictional boundaries even when using traffic responsive pattern selection.

· Enable agencies to more easily share resources (equipment, software, communications links, and personnel) thus reducing costs and freeing funds for other enhancements.

· Enable automated collection of compatible data from all agencies for use in regional transportation modeling and performance evaluation.

The major types of data exchanged using STARNET are summarized in the following diagram.

Figure 1 - Major Data Flows in STARNET

Major types of data exchanged using STARNET.

2 Introduction

The Sacramento Transportation Area Network, or STARNET, is an information exchange network and operations coordination framework that will be used by the operators of transportation facilities and emergency responders in the Sacramento region of California. It will enable the real-time sharing of data and live video, and refinement of joint procedures pertaining to the operation of roadways and public transit, and public safety activities.

STARNET will enhance the effectiveness of real-time transportation management and emergency response in the following ways.

· Provide procedures for enhanced coordination of activities between agencies.

· Provide additional real-time information, including live video from roadside cameras, needed for operations personnel and emergency responders to make faster and better decisions.

· Provide information exchange, a map-based integrated view of data from all agencies, and joint procedures needed for agencies to better coordinate their activities.

· Provide more comprehensive, more accurate, and more timely information to the public concerning the current status of transportation facilities and incidents.

· Enable better coordination of transportation management and emergency response activities during major emergencies such as flood evacuations.

· Enable agencies to more easily share resources (equipment, software, communications links, and personnel) thus reducing costs and freeing funds for other enhancements.

· Enable automated collection of compatible data from all agencies for use in regional transportation modeling and performance evaluation.

This Concept of Operations document includes the following elements:

· The vision for STARNET, its goals, and its role in the delivery of world class transportation services in the Sacramento region.

· A list of all stakeholders and involved parties, and the existing and planned transportation management systems that may be connected to STARNET.

· A description of other aspects of the environment in which STARNET will be built and will operate.

· A description of representative uses and operation of STARNET, and implementation, configuration and maintenance activities by the stakeholders. These are described within the context of real-world operation scenarios and written in the present tense to help stakeholders relate to the examples.

· A list of stakeholder needs (called user needs) derived from the operation scenarios.

· A list of metrics for STARNET performance evaluation (validation). These are used after the system is operational to answer the question “Is it performing as expected?”

This Concept of Operations document is intended to be read by transportation operations and planning personnel at STARNET stakeholder agencies, and by any contractors hired to assist with design, implementation, operation, or maintenance. As with nearly all documents used in the management of STARNET, this document will be used throughout the life of the system and will be updated as needed. During the planning and design stage of STARNET, it reflects the stakeholders’ vision for how the system will be used and the role of various support measures. After the initial system is operational, this document will be updated to reflect how the system is actually used, to describe the support measures actually in place, and to help plan expansion or enhancements.

3 What is the Concept of Operations?

The concept of operations represents the STARNET stakeholders’ conceptualization of day-to-day conditions and activities (operation) during the implementation and on-going use of STARNET. It describes the purpose of STARNET, the environment in which it will be implemented and operated, how it will be used, roles and responsibilities of involved parties, and what capabilities the stakeholders need in STARNET and in the personnel involved in its implementation and operation – called “user needs”.

Each stakeholder may start with a different concept in their mind of STARNET and who will be responsible for what. The process of developing the formal concept of operations ensures that all stakeholders agree on a common view of STARNET. It also provides a comprehensive description of that consensus view for the benefit of new team members, including new stakeholder agency employees and contractors brought in to help with STARNET implementation, operation, or maintenance.

User needs are a check list of items, written from a user or stakeholder perspective. The stakeholders can read and understand the user needs and check that they are a reasonable and comprehensive summary of needs.

Later, these User Needs will be used to identify system requirements that will guide design and implementation of the system. The user needs will also guide provision of support measures such as the scope of work for an integration contract, policy-level authorizations, agreements between STARNET users, on-going funding sources, etc.

Figure 2 - Overview of the STARNET Concept of Operations

The concept of operations involves three major steps:

5. Describe the environment in which STARNET must be built and must operate. These are the externalities over which the STARNET team has no, or little, control.

6. For things that the STARNET team can control, use operation scenarios to describe how they should perform under different environmental conditions. In these scenarios, consider all stages of STARNET design, implementation, operation, and maintenance.

7. From study of the operation scenarios, identify user needs – those things the STARNET team needs to provide or make happen.

The concept of operations answers questions such as the following.

· What is the purpose of STARNET?

· Who will use it?

· What will they use it for?

· How will they use it?

· When will they use it?

· Where will they use it?

· In what environments will it be used?

· How will it be maintained?

· Who will pay for its maintenance?

· What support measures are needed?

· What are the roles and responsibilities of each party?

· What resources will each party contribute?

· How will we know if it is effective?

The concept of operations does not identify the technology to be used or STARNET’s design – that comes later. However, as part of the description of STARNET’s environment and operation scenarios, the concept of operations will identify existing or planned facilities, policies, funding sources, etc. that represent significant opportunities, constraints, or challenges that need to be considered during the design and implementation of STARNET.

At the core of the concept of operations is a narrative describing the system in use including all the interactions between people involved, the policies that influence operations, the resources that are brought to bear, etc. This narrative is based on realistic scenarios or examples. Each scenario describes STARNET-related activities. These activities may be described in the context of a specific situation or set of circumstances or in a generic sense where the description is applicable to may different situations. Operation scenarios are written in the present tense to help add to the realism. Together, they attempt to illustrate the desired behavior or provisions of STARNET or the STARNET team under all likely conditions.

The operation scenarios are then studied to identify the user needs. Each need is recorded, in the plain language of the stakeholders, not specialty technical jargon, together with a reference to the operation scenarios it derives from. If a stakeholder proposes adding another need to the list, they are challenged to identify its origin in the operation scenarios. This process may result in an update to the operation scenarios and perhaps to the environment description, if a stakeholder can describe another condition that leads to a need that otherwise would go unidentified.

In a later stage of the project, system requirements will be derived from the user needs. They convert the general and qualitative language of user needs into the precise and quantitative language of formal system requirements. The system requirements are oriented to specialty systems engineers. They are written in careful, terse, technical, and somewhat legalistic language so as to be unambiguous and testable. They will form the basis of one or more contracts for system implementation. So the system requirements are a distillation of the user needs, converting from high level, user-oriented language into lower level, precise, technical statements. One user need may generate multiple system requirements.

The operation scenarios will also be used to identify needed support measures, many of which will be provided by the stakeholders themselves. Examples of support measures include the scope of work for the STARNET integration contract, implementation and operation funding that must be secured, provision of training facilities to be provided by stakeholders, assignment of appropriate duties to operations and maintenance personnel, on-going configuration management, etc.

The operation scenarios will also be used to identify metrics for measuring the performance of STARNET once it is operational – a process that is often called “system validation”.

The concept of operations is a critical tool in the systems engineering process. Much has been written on the ideal content and format of a concept of operations. The format of this document has been chosen to suit the nature of STARNET and its institutional environment. It is important that this document capture all information important to the development of requirements for, and design of, STARNET and its needed support measures. Stakeholders are encouraged to find or create a place in this document for all relevant material, even if it does not appear to neatly fit under any existing heading. The format can and should change as needed to accommodate the information.

4 The Purpose of STARNET

Under the leadership of the Sacramento Area Council of Governments (SACOG), the Sacramento region of California is coordinating the implementation of intelligent transportation systems (ITS) as an integral part of transportation and land use management in this rapidly growing metropolitan area. The major agencies involved in transportation in the Sacramento metropolitan region coordinate their ITS activities via the SACOG-led Sacramento Region ITS Partnership. Members include traffic, transit, and incident management personnel from all cities and counties in the metropolitan area and representatives from Sacramento Regional Transit Distirct, Caltrans District 3, and the California Highway Patrol. Various regional agencies are also involved, such as SACOG, Sacramento Regional Fire/EMS Communications Center, and Yolo County Communications Emergency Service Agency.

The recently completed ITS Strategic Deployment Plan for the Sacramento region confirmed the previously-identified need for a regional center-to-center communications network to facilitate the sharing of real-time transportation information (data and video) between agencies and to enable collection of real-time travel information for the public. This transportation information sharing network has been named the Sacramento Transportation Area Network, or STARNET. In addition to providing a data and video exchange network, STARNET provides an institutional framework for developing and implementing enhanced joint operating procedures enabled by those shared data and video.

The overall purpose of STARNET can be summarized as follows:

The purpose of STARNET is to enable real-time data and live video pertaining to the operation of roadways and public transit, to be shared between computers and people involved in transportation operations and emergency response in the Sacramento region, thereby assisting in the coordination of their activities and assisting in providing the public with a regionally focused source of comprehensive information about current travel conditions and options (511). STARNET is also intended to provide improved integration of operation procedures, including procedures that take advantage of the data and video sharing capabilities of STARNET and facilitate improved emergency response.

During a journey, even a local one such as commuting to or from work or a local freight delivery, travelers typically use transportation facilities operated by different public agencies, and perhaps involving a mixture of private automobile and public transit vehicles. These travelers need a single source of information about current conditions on all transportation facilities that they use or may consider using for that journey. And when an incident occurs that causes disruption of service affecting multiple agencies’ facilities, travelers need those agencies to quickly and effectively deal with it in a coordinated manner. Their journey time is reduced and the risk of related accidents is reduced, if the response actions of the involved agencies are coordinated and consistent.

Providing one-stop regional travel information and coordinated real-time operations activities represents current best practices in transportation management. It is achieved by the involved agencies working together to coordinate their operating procedures and by all providing real-time data and video to each other and to a regional travel information outlet. This real-time data and video exchange involves continuous transmission of data and video between computers owned and operated by different agencies.

STARNET is the name given to the physical and institutional infrastructure needed to make the data and video flow between agencies in the Sacramento region, and operation procedures that better coordinate the activities of involved agencies. If it is done well, it will contribute to an improvement in transportation efficiency and safety in the region, and provide all the secondary benefits thus generated for the area’s residents and businesses.

5 Stakeholders and Their Facilities

The real stakeholders in STARNET are the members of the public that use the region’s transportation system. Acting as their proxies, are the public agencies that build and operate the region’s transportation facilities – especially the roads, bus fleets, and light rail transit lines. These agencies act on behalf of the public, providing the planning, construction, operation, and maintenance resources needed to keep the transportation facilities safe and efficient. This document is focused on these public agencies, and their transportation facilities and resources that may play a role in STARNET.

A particular agency may have multiple computer systems, software packages, or closed circuit television (video) systems, each of which can act as a source or sink for information transmitted via STARNET. Each such source or sink is referred to here as a “STARNET node” – that is, a node on the STARNET network.

It is envisioned that agencies will add or delete nodes from the network continually over time. STARNET will be a continually evolving system.

The following table describes some of the agencies that operate major transportation or emergency response facilities in the Sacramento region and the computer and video systems they now or may soon operate that are candidates for being a STARNET node. This is not a comprehensive list but an attempt to focus on some of the more likely early participants in STARNET.

Agency	Role and Facilities *	Potential STARNET Nodes
California Highway Patrol	Law enforcement, public safety, freeway service patrol, __ service patrol beats, up to __ patrol cars on duty in region, 2 fixed wing aircraft (with CCTV cameras), 2 helicopters.	Computer aided dispatch system (incident reports).
Caltrans District 3	Traffic management, 217 miles of freeway, 150 detector stations including 50 ramp meters, 10 changeable message signs, 6 highway advisory radios, 30 CCTV cameras, roadside weather information stations, 20 motorist service patrol beats, 511 travel information service (with SACOG).	Freeway traffic management system, changeable message signs control system, front end field data processor (detector data and ramp meter data), satellite operation center command system, highway advisory radio control system, closed circuit television systems, ramp meter control system, roadside weather information system, traffic signal management system, maintenance management system including computer aided dispatch, lane closure system (including real-time updates during the closure), chain control status system.
Citrus Heights, City	Traffic management, public safety, 40 miles of arterial roads, 95 traffic signals, __ signal system detectors, 5 CCTV cameras.	Traffic signal management system, closed circuit television system.
El Dorado County	Traffic management, 30 miles of arterial roads, 15 traffic signals,.	Traffic signal management system.
El Dorado County Transit Authority	El Dorado Transit bus service, 16 buses.	Transit vehicle location and fleet management system.
Elk Grove, City	Traffic and transit management, public safety, 62 miles of arterial roads, 110 traffic signals, 1 CCTV camera, e-tran bus service, 40 buses.	Traffic signal management system, closed circuit television system.
Folsom, City	Traffic and transit management, public safety, 15 miles of arterial roads, 70 traffic signals, Folsom Stage Line bus service, __ buses.	Traffic signal management system, closed circuit television system, transit vehicle location and fleet management system, maintenance management system including computer aided dispatch.
Placer County (including Transportation Commission)	Traffic and transit management, 35 miles of arterial roads, 15 traffic signals, Placer County Transit bus service, __ buses.	Transit vehicle location and fleet management system, traffic signal management system.
Rancho Cordova, City	Traffic management, public safety, 25 miles or arterial roads, 40 traffic signals.	.
Rocklin, City	Traffic management, public safety, 20 miles of arterial roads, 65 traffic signals.
Roseville, City	Traffic and transit management, public safety, 87 miles of arterial roads, 140 traffic signals, 9 CCTV cameras, Roseville Transit bus service, 34 buses.	Traffic signal management system, transit vehicle location and fleet management system, closed circuit television system, transit stop management system, transit trip planning system, maintenance management system including computer aided dispatch.
Sacramento Area Council of Governments	Regional transportation planning and funding, 511 travel information service.	Regional travel information system (511), transportation planning database.
Sacramento, City	Traffic management, public safety, 400 miles of arterial roads, 9 actively managed parking garages, 650 traffic signals, 50 signal system detectors, 30 CCTV cameras.	Traffic signal management system, closed circuit television system, maintenance management system including computer aided dispatch, parking management system.
Sacramento County	Traffic management, public safety, 200 miles of arterial roads, 300 traffic signals, 30 signal system detectors, 40 CCTV cameras, 5 changeable message signs.	Traffic signal management system, closed circuit television system, changeable message signs control system, maintenance management system including computer aided dispatch, detector data collection system.
Sacramento Regional Fire/EMS Communications Center	Dispatch for fire trucks in most of Sacramento County.	Computer aided dispatch system.
Sacramento Regional Transit District	Regional Transit bus and light rail service, 275 buses, 97 light rail vehicles, __ CCTV cameras.	Transit vehicle location and fleet management system, transit stops management system, transit trip planning system, closed circuit television system, service disruption notification system.
West Sacramento, City	Traffic management, public safety, 25 miles of arterial roads, 40 traffic signals, 2 CCTV cameras.	Traffic signal management system.
Yolo County Transportation District	Yolobus bus service, __ buses.	Transit vehicle location and fleet management system.
Yolo County Communications Emergency Service Agency	Dispatch for fire trucks and some police in Yolo County.	Computer aided dispatch system.

* Facilities are those within or serving the contiguous built-up area surrounding the City of Sacramento.

The types and quantities of facilities shown for each agency above are estimates of those that will be in place when STARNET is being built during 2007-08. These are subject to change.

The following subsections provide an overview of the characteristics of the various types of transportation management systems operated or planned by the stakeholder agencies, including the types of data or information they may send via STARNET. Detailed descriptions of each system are maintained in separate documentation.

5.1 Computer Aided Dispatch Systems

The California Highway Patrol (CHP) operates a computer aided dispatch (CAD) system that records information about highway incidents reported to the CHP. The CHP patrols all highways operated by Caltrans and some roads operated by local jurisdictions. Incident reports are received from CHP officers in the field, from Caltrans personnel, from other public agencies, and from the public. The public most commonly report incidents using the 911 emergency telephone number. The CHP at the Sacramento Communications Center operates the region’s cellular 911 Public Safety Answering Point. If the CHP 911 operator/dispatcher receives a call concerning a roadway not patrolled by the CHP, the call is switched to the appropriate local fire, police, or sheriff.

Both CHP and Caltrans personnel at the joint CHP and Caltrans Communications Center in Rancho Cordova have direct access to the full incident database. A subset of the information is also made available on the CHP’s traffic incident information web site (http://cad.chp.ca.gov/). This information can be extracted from the web page by other organizations and included with other information in more general travel information web sites, such as that provided by the Sacramento Bee (http://www.sacbee.com/cgi-bin/sacbee/traffic/showtraffic.cgi).

Various police, sheriff and fire dispatchers in the region also use computer aided dispatch systems. These include systems by Tiburon, SunGard HTE, and Northrop Grumman/PRC.

The computer aided dispatch systems are sources of incident information.

5.2 Caltrans Highway Traffic Management Systems

Caltrans District 3 operates vehicle detectors at more than 100 sites on freeways in the STARNET area. These detectors are monitored by either a dedicated vehicle detector station, or by a ramp meter that also serves as a vehicle detector station. Count, occupancy and speed data from all vehicle detectors are collected every 30 seconds by a computer called a “front end processor”. The front end processor is STARNET’s only viable source of lane-by-lane raw freeway detector data, including ramp detector data.

Caltrans District 3’s freeway management system (also called the Advanced Traffic Management System or ATMS) receives raw detector data from the front end processor and converts it to an hourly volume, average occupancy, and an average speed for all lanes combined in each direction at each detector site. These aggregated data are displayed on the ATMS map display for Caltrans operators. Every minute, the ATMS software uploads speed data to an FTP web site, together with the text of any message currently displayed on each changeable message sign. These data are then available for downloading by interested parties. This is where the Sacramento Bee travel information web site obtains traffic speed and changeable message sign data.

Some changeable message signs operated by Caltrans in the STARNET area are controlled by Caltrans’ freeway management system software (ATMS) and others are controlled by software from the sign manufacturer, Display Solutions. The goal is to have all signs controlled via the ATMS software eventually. In the meantime, STARNET may need to obtain sign message information from both systems.

Caltrans District 3 operates some highway advisory radio systems in the STARNET area. These are controlled via Highway Information System’s DR2000 software, which is a potential source of advisory radio data for STARNET.

Caltrans District 3 operates some roadside weather information systems. These report visibility and wind speed and direction, precipitation, pavement temperature, and other data. Central software by the manufacturer of some of these systems, Vaisala, is a potential source of such data for STARNET.

Caltrans has a web-based statewide Lane Closure System used to receive, review, and approve applications for lane closures and to provide the public with information about upcoming and current lane closures.

Caltrans has a Chain Control Status system.

Caltrans closed circuit television and traffic signal management systems are discussed below.

5.3 Traffic Signal Management Systems

Most of the involved traffic management agencies operate a traffic signal management system. These systems are used to remotely monitor the status of traffic signals (e.g., current color displayed by each phase, current timing mode and pattern, and any faults or alarm conditions being reported), issue pattern change commands to signals, upload/edit/download signal timings, and collect volume and occupancy data from selected vehicle detectors. Systems operated by the various agencies include VMS330 by Multisonics (now US Traffic/Quixote), Streetwise and ATMS Now by Naztec, TranSuite by TransCore, QuicNet by BI Tran Systems (now McCain Traffic Supply), CTNET by Caltrans, and ACTRA by Eagle Traffic Control (now Siemens ITS). These systems can provide traffic signal status and detector data to STARNET.

5.4 Transit Management Systems

Sacramento Regional Transit District is in the process of providing its light rail fleet with an automated vehicle location system incorporating products from Radio Satellite Integrators, Inc. Central software is located at the Network Operations Center at 1225 R Street near downtown Sacramento. A real-time vehicle location system for the Regional Transit bus fleet in being planned. Regional Transit is in the process of launching a web-based transit trip planning system for the public. This system is designed to accommodate other transit systems so that transit riders have a single trip planning tool regardless of which transit service providers are involved in a trip.

Other transit agencies are planning vehicle location systems.

5.5 Closed Circuit Television Systems

Many of the involved agencies have deployed closed circuit television (CCTV) cameras in the field to enable operators to remotely observe current field conditions. Most of these cameras have remote pan, tilt, and zoom controls, though some may be fixed-view cameras as used for video detection at traffic signals, for example. The video feed is transported from the camera to the agency’s operations center by a variety of communications links, including dial-up ISDN links for many of Caltrans’ cameras. Some camera feeds arrive at the operations center as analog video, while others are digitized and compressed (encoded) at the camera. Most agencies employ an analog video matrix switch and video monitors at their operations center.

The California Highway Patrol has installed a Caltrans-supplied CCTV camera on each of its two fixed wing aircraft, and the feed from these will be available via the Caltrans CCTV system. The City of Sacramento Police Department has a CCTV camera on at least one of its helicopters, and there are plans to make the feed from this camera available via the City’s CCTV system.

Sacramento Regional Transit has installed closed circuit television cameras on transit vehicles and at stations and other critical infrastructure. These are used primarily for passenger security purposes and are probably not suitable as video sources for STARNET.

5.6 Regional Travel Information System

SACOG and Caltrans maintain the Sacramento region 511 travel information interactive telephone service and web site. The telephone service provides transit information, highway incident information, and access to transit service call centers. The web site (http://www.sacregion511.org/) has links to transit service provider web sites, the CHP traffic incident information web site, the Caltrans highway information web site, the Sacramento Bee travel information map, Caltrans live traffic cameras, Caltrans planned road work, and rideshare and cycling information. The recently-completed ITS Strategic Deployment Plan calls for major upgrades to this travel information system. STARNET will play a major role in those improvements.

5.7 Maintenance Management Systems

Caltrans and Sacramento County operate maintenance management systems that include computer aided dispatch. These are a source of real-time information about maintenance activities that are disrupting traffic.

5.8 311 Systems

Sacramento County and the City of Sacramento are installing a 311 telephone service that allows residents to easily report non-emergency requests for repairs or other services. These systems may be another source of real-time incident information.

5.9 Parking Management Systems

The City of Sacramento operates a parking management system for city-owned parking garages.

5.10Communications Infrastructure

Most of the STARNET agencies have installed some fiber optic cable as part of communication links between field equipment and their operations centers. The ITS Partnership has coordinated interconnections between the fiber optic cable owned by different jurisdictions in order to take advantage of local fiber plant for inter-agency communications, such as needed for STARNET. Some of the major fiber cable runs are shown on the map of transportation management facilities in the following section.

The Cities of Sacramento, Roseville, and West Sacramento, Regional Transit, and Sacramento County, are installing WiFi hotspots that could be used for Internet access from the field.

6 Other Environmental Factors

The stakeholders’ transportation facilities and management systems are the obvious and most important components of the environment in which STARNET will be built and must operate. This section describes other environmental factors that need to be considered – those that may directly or indirectly present significant opportunities, constraints, or challenges for STARNET or the STARNET team.

The STARNET environment includes all the things that may affect STARNET but are beyond the control of the STARNET implementation and operation team. These are treated as externalities. They include physical conditions (e.g., location of stakeholder facilities, terrain, etc.), human activities (e.g., operators making mistakes, hacking attempts, etc.), natural phenomena (e.g., weather extremes, vermin chewing through a communications cable, etc.), institutional conditions (e.g., political commitments and policies, agency staff turnover, etc.), technological conditions (e.g., available technologies, technology change and obsolescence, etc.). This is not a comprehensive list, and not all of these items may be worthy of further consideration.

Environmental factors need to be considered in the context of each of the various activities involved in STARNET implementation and operation. These activities include initial design, initial implementation, on-going operation, on-going maintenance, and significant expansions and upgrades. Although we call it a concept of “operations”, this document is really about much more than just the literal operation of STARNET. It addresses all activities associated with STARNET, at any stage in its life cycle.

6.1 Physical Conditions

The following map shows the location of transportation management centers housing server computers for potential STARNET nodes and agency-owned fiber-optic cable that may serve to link some nodes.

Although there are some agency-owned fiber optic cables in place or planned that can support some STARNET links, agency owned communications infrastructure will not be available for other STARNET links, at least not initially.

The terrain in the Sacramento region is generally flat and amenable to use of wireless communications. Areas adjacent to the Sacramento and American rivers are subject to flooding. Levees and the Folsom dam are estimated to provide protection from up to only a once in 77 years flood according to the Sacramento Area Flood Control Agency.

The Sacramento area has a Mediterranean climate with dry summers and mild winters. Annual rainfall averages approximately 17 inches. The highest recorded temperature is 115 degrees Fahrenheit and the lowest recorded temperature is 17 degrees Fahrenheit.

Figure 3 - Map of Transportation Management and Emergency Response Facilities

Map showing transportation or emergency operations centers and agency owned fiber cables.

6.2 Political Conditions

Sacramento is the capital of California. The population of the region has grown rapidly to its present level of approximately two million people, and is expected to nearly double again in the next 50 years. Despite attempts to encourage “smart growth” population density outside the downtown core is generally low and most of the growth is occurring in low density suburbs poorly served by public transit and dominated by automobile travel.

The region of interest to STARNET is comprised of the contiguous built-up areas surrounding the City of Sacramento within parts of Sacramento, El Dorado, Placer, and Yolo Counties. In addition to sizable unincorporated communities, this urbanized area encompasses the incorporated jurisdictions of Sacramento, Roseville, Citrus Heights, Elk Grove, Rancho Cordova, Folsom, West Sacramento, and Rocklin.

Funding for public transportation facilities derives from a mixture of local (city or county), State, and Federal government sources. There are no significant privately owned transportation facilities other than those for freight and parking. Transportation funding at all levels of government is subject to change, in line with economic conditions and political priorities. STARNET stakeholder agencies have typically used Federal and State agency grants to supplement local funds for capital investments, but often rely entirely on limited local funds for on-going operation and maintenance.

Due to high-level policy changes, economic hardship, or other reasons, any of the participating agencies may change, or at least want to change (subject to agreements), its level of involvement in and support of STARNET.

New agencies may wish to begin participation in STARNET.

6.3 Technology Conditions

A participating agency may add or replace transportation system components that are involved in STARNET. These could be nodes on the system or agency-owned communication links used in STARNET. New components may be quite different from any others currently involved in STARNET.

STARNET will make use of various communications and computer technologies. These technologies are evolving rapidly, resulting in rapid changes in product choices, capabilities, price, compatibilities, and level of available support. Many technologies, and especially particular products, tend to have short life spans, often of the order of only a few years.

In many instances, technology-based product manufacturers have agreed on standards for various aspects of various types of products. Use of standardized components can help reduce costs, facilitate interoperability and therefore help in system expansions and upgrades, and avoid early obsolescence.

Despite on-going improvements in technology and product reliability, any of the components of STARNET may fail at any time, and some inevitably will. It is also possible that multiple failures occur simultaneously.

Communication links used by STARNET and shared with non-STARNET communications traffic, may experience overloading due to unusually high amounts of non-STARNET traffic. Such overloading conditions may persist for only a very short time (e.g., a second or less) or for a prolonged period.

6.4 Other Factors

STARNET may continue to operate for many years. During that time, the quantity of data that need to be exchanged and stored may vary significantly depending on factors such as the rate of implementation of planned transportation management system elements by the involved agencies, changes in uses of STARNET or in policies relating to what data are transmitted to where, and the frequency of major disasters or other events that may generate an abnormal quantity of exchanged data.

The personnel responsible for operating and maintaining STARNET will be well qualified and trained, but will inevitably make mistakes from time to time, as all humans always do. Such mistakes may result in unusual and unpredictable conditions, some of which may not be well accommodated by some STARNET components.

Beyond internal failures of hardware and software, the communications links and end equipment involved in STARNET are subject to interruption by events such as trenching operations that break underground cables, earthquakes, floods, storms, line-of-sight obstruction of wireless communication paths, vandalism, cabinet or pole knockdown, theft, power outages, computer hacking, etc. An event that causes disruption of part or all of STARNET may also disrupt transportation and personal communications in ways that prevent maintenance personnel from responding rapidly.

Personnel responsible for some important aspect of STARNET implementation, operation, or maintenance, may suddenly leave the team, due, for example, to a change in their work assignment, employment, or health.

7 Operation Scenarios

Operation scenarios are a conceptualization of future conditions and events, and the resulting activities undertaken by members of the STARNET team or by components of the STARNET system.

A scenario may apply to any stage of STARNET implementation, operation, and upgrade. The STARNET team is composed of all parties involved in the design, implementation, operation, and maintenance of STARNET, whether an agency employee or a contractor employee. The defining events in a scenario may be triggered external to STARNET and the STARNET team (beyond our control), or may be triggered automatically by a STARNET component (e.g., a computer) or by a STARNET team member (e.g., an operator, a designer, an implementer, a maintenance technician, etc.). The time period over which scenario activities occur may be anything from a second or less to many years.

The operation scenarios are grouped into the following types:

· Routine Operation

· Failures and Other Unusual Events

· Design, Implementation, and Upgrades

Scenarios attempt to cover all likely conditions reflected in the STARNET environment description in the prior sections of this document. However, scenarios can also involve realistic conditions that are not directly traceable to the described environment.

The list of operation scenarios must be comprehensive, as any needs not identifiable in one or more scenarios will not be included in the user needs and therefore not allowed for in system implementation and support measures.

Stakeholders can imagine very sophisticated functionality for STARNET and related systems. Funding and time constraints have been considered in limiting the assumed functionality. Even so, the functionality reflected in these scenarios still may not be fully obtainable, and user needs may have to be prioritized to guide compromise decisions and staged implementation.

7.1 Routine Operation

The following scenarios describe examples of situations that occur routinely. The term “operator” here refers to an employee or contractor of a participating agency that has been given a user name and password for use of the shared Regional Transportation Management Display. Such operators may be employees or contractors of cities, counties, the State, and various regional agencies. These agencies are generally involved in transportation management and emergency response.

7.1.1 Freeway 99 Closure at Consumnes

At 7:30 AM on a Tuesday morning, CHP 911 receives multiple emergency cellular phone calls reporting a serious crash on northbound Highway 99 at the Consumnes River Blvd interchange. The accident reportedly involves a truck potentially carrying a hazardous cargo and three cars. The reports are conflicting as to the exact location of the accident, some placing it south of the overcrossing and others placing it north. There may also be one or more separate but related accidents caused by approaching vehicles rear ending those stopped for the accident, adding to the confusion.

CHP and Caltrans operators at the regional Communications Center are quickly alerted to the incident. They notify the local fire department and dispatch CHP patrol cars and Caltrans maintenance vehicles to the scene. While waiting for field personnel to reach the site, they use a Caltrans closed circuit television (CCTV) camera at this interchange to survey the scene. Unfortunately, part of the accident scene is obscured from the camera view by the overcrossing bridge. On a computer, they bring up the Regional Transportation Management Display and log in. Once logged in, the operator launches a regional map showing information for transportation management operators (not the public). This map has dynamic icons showing the location, owner, and current status of all transportation management facilities accessible via STARNET.

After adjusting the regional map (pan and zoom at least as easily as in Google Maps™) to obtain a reasonably scaled view of the area of interest, they see that a County pan/tilt/zoom camera is located on the north side of Calvine Road at the northbound off-ramp traffic signal, and is currently operational and available for remote control. It may be able to see the freeway immediately north of the bridge which is the area obscured from the Caltrans camera. They use the regional map user interface to view and control this camera and are able to see part, though not all, of the obscured area. They see enough to confirm that the truck is a tanker on its side and that no cars are getting past the scene in mainline lanes. They also see that the eastbound Consumnes to northbound 99 on-ramp is blocked, but the westbound Calvine to northbound 99 on ramp is clear. The CHP officer uses this visual confirmation to update the CAD entry with the on-ramp status information. The Caltrans operator puts an advisory message on the northbound 99 changeable message sign located south of Laguna Boulevard in Elk Grove.

Meanwhile, the CHP CAD entry for this incident has been received by the regional travel information (511) system, using STARNET, and made available on the 511 web site and phone service. Once the CHP and Caltrans operators have finished using the cameras for close-up investigations of the accident, the cameras are parked to show an overview of the scene and the feed is made available to the public via the Caltrans and 511 web sites. The feed is delivered to the 511 system via STARNET.

Commercial traffic information services become aware of the incident using the CHP and 511 incident data feeds, and it is announced as a closure of northbound 99 at Consumnes, on the next traffic report on local radio stations. Motorists traveling north on 99 toward the accident hear about it on the radio or see the closure advisory on the changeable message sign. Most exit the freeway at Laguna Boulevard or Sheldon Road, some going east to East Stockton Boulevard, Elk Grove Florin, or Bradshaw, and some going west to I-5, or Bruceville Road and Center Parkway. Since the early public reports are ambiguous as to exactly where the accident is located and which northbound on-ramps at Consumnes are blocked, most motorists using parallel streets stay on the diversion route all the way to Mack Road. The East Stockton Boulevard and Laguna/Bradshaw routes involves travel through Elk Grove and parts of unincorporated Sacramento County. The Bruceville Road route involves travel through Elk Grove and the City of Sacramento.

Looking for more information, a motorist approaching the incident area from the east uses a cell phone to access the 511 travel information system. They are told “Route 99 northbound at Consumnes there is an accident, starting at 7:45 am”, and “Elk Grove Florin Road at Stevenson Avenue there is a traffic signal in flashing mode starting at 7:50 am”. The driver then elects to enter Route 99 at Mack Road.

Other commuters, before leaving home on their morning commute, access the 511 web page and view the map displaying the current speeds along Route 99 and see the flashing active incident icon. The color of the vehicle detector station icons indicates that speeds are very slow in the vicinity of the incident. By zooming in on the map, and selecting the incident icon commuters observe that the incident is a hazardous materials spill. Via the web page, commuters consecutively click on the icons representing the Caltrans and County closed circuit television cameras in the vicinity of the incident and view the incident and congestion. Had an agency operator flagged such a camera as inappropriate for public viewing, the commuter would have received a message indicating that the cameras were temporarily unavailable. By mouse-over or clicking on an icon representing the northbound changeable message sign on Route 99 in Elk Grove they are able to read the text of the message currently displayed on that sign regarding the incident. Armed with this information, at least some of the commuters elect to avoid the incident area or change their time of departure.

Even before public travel information reports provide the details of which ramps are blocked and the extent of the backup on Highway 99, the Elk Grove e-tran operations supervisor uses CCTV camera feeds available via STARNET, the freeway detector data, and the incident report on the Regional Transportation Management Display to confirm that express buses traveling north on Highway 99 should exit at Sheldon Road and use the East Stockton Boulevard detour, and that buses can in deed return to the freeway at the Calvine on-ramp. Freeway detector data show which detectors have a low volume and speed, and high occupancy, thus indicating queued or slow moving traffic. Even without use a mouse-over to see the actual values, the user can see the approximate level of congestion at each detector by virtue of the color of the detector icon on the regional display map.

The Caltrans operator tracking this incident recognizes that the extreme traffic congestion likely to be occurring on the diversion routes could be alleviated somewhat by adjusting the timing of traffic signals on those routes. Attempts to contact the Elk Grove traffic signal management staff fail, but they are able to speak to traffic signal personnel at both Sacramento County and the City of Sacramento. These local agency operators use their respective traffic signal management systems and CCTV cameras to make appropriate changes to the timing of traffic signals along the diversion route. The County also makes changes to Elk Grove signals by remotely accessing the Elk Grove traffic signal system. The procedures for such remote control between agencies are defined and allowed by cooperative agreements. County personnel are also able to check field conditions and the effectiveness of signal timing changes, using an Elk Grove CCTV camera on Sheldon at Highway 99. STARNET makes this camera accessible to the County operator.

The on-call Elk Grove traffic signal operator subsequently picks up a phone message from the County operator advising of the remote control actions taken. The Elk Grove operator speaks to the County operator by phone to obtain a summary of events so far and to say that he will now take over control of the Elk Grove signals. This operator is still at home, and uses his home computer and Internet connection to access the regional transportation management map, which is enabled by STARNET. He logs in and launches the regional map. By clicking on icons representing Caltrans, County and City CCTV cameras, an icon representing the Caltrans changeable message sign at Laguna, and an icon representing the incident report, this operator is able to quickly confirm current conditions.

This incident report was automatically added to the regional display map using data obtained from the CHP incident report. The Caltrans, County, and City of Sacramento operators have since added information explaining their actions and updates on conditions as they become available from personnel in the field or CCTV cameras. He clicks on the Add Information button in the incident report window and makes an entry that indicates that he is actively monitoring and managing the Elk Grove signals. He determines that a further adjustment is needed to one of the Elk Grove signals, and makes a secure remote connection to the City traffic signal system to effect that change.

The Caltrans, County, Sacramento, and Elk Grove operators continue to monitor the situation using the regional map, which gives them access to vehicle detector data, incident data, changeable message sign data, and the status and video feeds from CCTV cameras. From time to time, these local agency operators add relevant information to the regional incident report. As the CHP computer aided dispatch incident report is updated, those updates are automatically reflected in the regional incident report.

Using STARNET, each operator is able to view and control all cameras regardless of the owner. Joint procedures used by the STARNET agencies provide for the owning agency to take control of a camera they own at any time, while non-owner agencies must wait until they know the owning agency is no longer using it, and they can then control it on a first-come-first-served basis. Procedures provide a means for an operator to use a camera movement sequence that identifies them as the owner, both to take control and relinquish control. All operators are trained to occasionally make a refresh movement to indicate continued use of a camera. The Regional Transportation Management Display also shows the name and agency of the two most recent operators to send control commands (e.g., pan, tilt, or zoom) via the regional system to a camera, and the time of the last command from each. This enables operators to identify current users so they can contact them if needed.

When the freeway is re-opened, the public are notified in the same ways that they were notified of the closure, and they stop using the diversion routes. The involved agencies restore normal signal timings. A Caltrans operator makes a final entry in the incident report in the Regional Transportation Management Display, indicating that the incident is over, and updates the End Time field and checks the “actual” flag next to that time. The incident automatically remains as an icon in the regional map and table views for the remainder of the day, but with a color or other means of indicating that the incident is inactive. This enables operators to confirm that the incident was recorded and has ended, as opposed to not being recorded and possibly still active. An incident in this post-closure state (End Time is actual and in the past) can be re-opened if necessary by removing the actual flag for the End Time. Incidents with an End Time flagged as actual and in the past are removed from the 511 web site and phone service. Once the incident is removed from the regional display (e.g., automatically at midnight), the full incident record is archived, including status changes that occurred while it was active and the time of such changes.

Each operator involved in these activities makes an entry in an operations event log, briefly recording the nature of the incident, the actions taken, an assessment of the effectiveness of those actions, lessons learned, and any recommended follow-up actions. Some agencies add such information to the regional incident tracker whiteboard for the incident (often after the incident has ended) while others use other event logging mechanisms that do not involve STARNET.

7.1.2 Planned Roadwork and Bus Detour

Operations staff at Regional Transit, Roseville Transit, e-tran (Elk Grove), Folsom Stage Line, YoloBus, Placer County Transit, and El Dorado Transit routinely review the list of planned lane closures available to STARNET agency operators via the Regional Transportation Management Display. They check for work that may interfere with transit operations, such as a lane closure that may block access to a bus stop. They use this information to coordinate with the public agency approving the street work, making arrangements for temporary detours or bus stop relocations when needed.

The agency creates the planned lane closure record in the regional system even before the encroachment permit is issued. The permitting process offers another opportunity to coordinate the bus stop relocation, and the regional record of this closure is updated when the formal arrangement is finalized. Lane closures shown in the Caltrans Lane Closure System are automatically imported to the regional display.

As with other dynamic information available via the Regional Transportation Management Display, lane closure information can be viewed in a table format or via icons on a regional map. The table view enables rapid scanning of a particular data type, regardless of location. Each row in the table provides at least the type, identifier, owner, and location of a transportation management object, such as a camera, an incident, a lane closure, etc. and is a clickable link to further information about that object. The operator can choose between different sorting options for the table, based on any column.

The map view enables rapid scanning of all objects in a geographic area. Clicking on an object on the map provides the same pop-up details window as clicking on the object row in the table view.

7.1.3 Light Rail Transit Bus Bridge

Regional Transit's light rail system occasionally suffers from power substation failures during hot summer months. During these failures, buses ferry passengers from one Light Rail station to another, thereby bridging the "dark" section of track. The situation is entered in RT’s service disruption notification system from where it is automatically picked up by STARNET’s regional incident tracker, shown as an incident (type = “transit service incident”) on the operators’ Regional Transportation Management Display (map), and passed to the regional travel information (511) system for dissemination to the public. Other transit agencies are manually alerted of the service disruption and alter inter-system passenger transfer plans. Some transit agencies use the web services offerings of other transit agencies to automatically receive such notifications, separate from STARNET.

To facilitate coordination between agencies, the Regional Transportation Management Display shows all transit routes (in an optional layer) and the current location and direction of travel of in-service light rail vehicles (the location of buses may also be added in the future when available). Adjacent freeway drivers are alerted via Caltrans and County changeable message signs prior to exiting the freeway system or major arterials to an affected light rail station. These messages are activated using each agency’s existing sign control software.

7.1.4 Transit Information

A member of the public is about to leave her home and catch the bus for a trip. She goes to her computer and the Sacramento Region 511 web site, and accesses the “Next Train or Bus” page. She enters her location (street address) and is presented with the location of the nearest bus and LRT stops and the time of arrival of the next few buses and trains at each, sorted by route, and within each route by direction of travel, and within each direction by arrival time.

Provision of this information by the 511 web site is made possible by automated vehicle location data collected from the buses and trains, and a regional transit stops database, the arrival times calculated, and the information made available to the traveler on the 511 web site. Each transit agency generates arrival time data for its vehicles and sends these to the regional travel information (511) system via STARNET. The 511 system uses the regional transit stops database to determine the stops closest to the user and obtains transit vehicle arrival time data from the transit agencies serving those stops. Results presented to the user show, for each vehicle, the service provider, route number, destination, and an indication as to whether the arrival time estimate is based on actual vehicle location data or only the scheduled arrival time.

Travelers not already familiar with the region’s transit services click on a link on the 511 web page that takes them to a regional transit services map maintained by SACOG using its Geographical Information System, with the collaboration of the region’s transit agencies. It shows all current scheduled transit routes and transfer points, indicates the transit agency providing each service, and the route number. Links are provided to summary information about each agency, and to more detailed web sites maintained by each agency.

7.1.5 Local Freeway Detector Data

The traffic operations personnel at a city or county obtain from Caltrans a description of all vehicle detectors on the freeways in that local jurisdiction for which real-time traffic flow data are available via STARNET. They create links or other appropriate entities in their traffic management system to represent the traffic flow data from these detectors, and they establish a STARNET subscription for both the static and dynamic data for those detectors.

As the Caltrans traffic data collection system obtains new data from these detectors, those data are automatically transmitted to all subscribers. The traffic management system at a subscribing agency receives these data and automatically updates the display of link status and values, or other entities configured to display, use, or store such data.

A city or county incorporating freeway detector data in their local traffic management system configures alarms or other triggers (in their node system) to alert operators to abnormal congestion or low traffic volume on the freeway; as such conditions may reflect an incident or traffic-generating event that could result in significant diversion of freeway traffic to local streets.

7.1.6 Changeable Message Sign Status

The current status of changeable message signs, used to advise travelers of current conditions, automatically appears on the operators’ Regional Transportation Management Display (map) via a changeable message sign icon, and is automatically reported to the regional travel information system which reports it to the public on the travel information (511) web site. On the regional display map, the color and perhaps other attributes of the sign icon reflect its status (e.g., out of service, in service but no message, routine message, incident message). A mouse-over reveals the text of the current message, and static information about the sign, such as type, identifier, owner, and location. As with other dynamic data, the same information is also available in a list view, where all changeable message signs in the region are listed together, and the user can sort the list based on any column.

To enable reporting of sign status, all agencies with a central sign management system link their system to STARNET and allow the regional display map and regional travel information (511) system to obtain appropriate sign status data. Sign status information is shown on the 511 web site map and tables (list view), similar to the regional display.

In the initial implementation of STARNET, the regional display cannot be used to change the message on a sign. That must be done by remote access to the owning-agency’s sign management software. Mutual aid operating procedures developed under the STARNET program facilitate sharing of signs between agencies when and where appropriate.

7.1.7 Freeway Ramp Meter Status

The current status of freeway ramp meters automatically appears on the operators’ Regional Transportation Management Display (map) via ramp meter icons. At least some subset of such information is automatically reported to the regional travel information system which reports it to the public on the travel information web site and 511 web site maps, the color and perhaps other attributes of the ramp meter icon reflect its status (e.g., out of service, in service but currently not metering, now metering). A mouse-over confirms the operating status in text, reveals the current metering rate if any, and static information about the meter, such as type, identifier, owner, and location. As with other dynamic data, the same information is also available in a list view, where all ramp meters in the region are listed together, and the user can sort the list based on any column.

To enable reporting of ramp meter status, Caltrans District 3 links their ramp meter management system to STARNET and allows the regional display and regional travel information (511) system to obtain and display appropriate ramp meter status data.

7.1.8 Video Used by Operators

When an operator wants to view a camera to which they do not have direct access via a local video management system, that operator goes to a computer and logs in to the Regional Transportation Management Display. They click on a camera icon on the regional map or a camera name in the table of cameras, to activate the display of the video feed from that camera. If the camera provides pan-tilt-zoom control, they use on-screen remote controls to achieve the desired field of view.

An operator thus views the video and controls the camera from any ordinary computer with an Ethernet connection to the Internet or directly connected to the STARNET side area network. Video is viewed and controlled via a web page using popular web browser software so as to avoid limiting system access to computers with pre-installed software. The video feed is initiated quickly after the camera is selected.

An operator at any involved agency may have a need to use a camera that is outside its jurisdiction. For example, the camera may be at an intersection on or near the boundary between adjacent jurisdictions, or they may need to check traffic conditions within a neighboring jurisdiction to predict the impact on their own intersections. In some cases, the County or another agency may provide traffic signal operation and maintenance services on behalf of the owning agency, and may need to observe conditions as part of that function.

It is estimated that up to six operators may be viewing the same camera simultaneously. Each agency may have multiple operators, and the estimated total number of operators from all involved agencies is estimated to be not greater than forty. It is possible that all cameras available via STARNET could be being viewed simultaneously.

Where available, an operator takes advantage of high quality (television quality) video from a camera to observe details that are not readily evident in poorer quality video. Where only poorer quality video is available, due to communications bandwidth constraints for example, the operator still uses the camera, even though the same details may not be discernable. Where bandwidth permits, an operator displays multiple camera feeds simultaneously, by choosing to not close prior feeds prior to launching the next one.

The cameras are often programmed with presets. For example nine presets might be programmed at a four legged intersection – one showing an overview of just the intersection itself, one for each leg showing an overview of the entire leg, and one for each leg zoomed in and showing more detail of part of the leg. Operators may use such presets when operating their own cameras and when operating a camera owned by another agency. After choosing a preset from a list, the operator may refine the field of view using individual pan, tilt and zoom controls. The camera controls are intuitive and avoid confusion by not showing controls for cameras that cannot be controlled by that user due to user privileges. Similarly, the user interface does not show camera controls for cameras that do not have remote control capabilities.

Operators control a camera by an on-screen action controlled by the computer’s mouse or other pointing device. While doing this, the operator monitors the video display to confirm that the desired action has taken place and so as to know when to cease a sustained or repeating action (the camera has reached the desired position). This process is easy, accurate, and fast if there is minimal latency (time delay) between when the operator commences the control action and when the video display shows the resulting change in the camera’s field of view. If this latency exceeds one second, precise control becomes difficult and time consuming, and precise camera control becomes particularly challenging if the latency exceeds two seconds.

Operators in different agencies with shared use of cameras use mutually agreed procedures to avoid contention and interference when two or more operators want to use a camera simultaneously. For example, cameras are programmed to automatically “park” at a particular preset after a period of no movement, or users are trained to manually park it. Agreed procedures may require a non-owning operator to not move a camera that is not so parked. In any case, if while using another agency’s camera, an operator sees the camera moved by someone else, they assume the other user is unaware that it is already in use, and they move the camera back again, thus informing the other user that it is already in use. However, if an owning agency operator moves the camera, they can make a distinctive series of camera movements that informs others that this is an owning agency operator. In this case, others abandon their use of the camera in favor of the owning agency. The owning agency can make a different distinctive set of camera movement to signal that they are finished with the camera. They may also park it at the default view.

If the regional camera control system provides control locks and overrides, these may be used instead of, or in addition to, such procedures. However, owning agency operators may use a camera control system that is separate from that provided in the regional system, and therefore it may not be convenient for them to use locks and overrides in the regional system. Their local camera control system may or may not have lock out capabilities. If it is critical that other users do not attempt to control the camera during a use session, such as a television station using the camera during a live traffic conditions broadcast, either a lock is set or the feed is temporarily disconnected from the regional video distribution system.

When an operator considers the current camera view to be unsuitable for public viewing, they click on the Cut Public Feed button for that camera in the Regional Transportation Management Display. This causes the public to see a message such as “This camera is temporarily unavailable” instead of the video feed. To restore the public feed, they click on the Restore Public Feed button.

The communications link used for transporting the video feed from its source to the operator may vary in effective bandwidth (i.e., the lowest throughput at this time at any point in the link) for different camera/operator pairs, and will vary depending on the location of the operator. If the feed does not automatically scale to suit the available bandwidth, a system administrator may configure the system to provide two or more different video feeds from the same camera, one optimized for low bandwidth links and the other for high bandwidth links. An operator can choose between such alternative feeds.

A Regional Transportation Management Display operator with suitable permissions may assign different privileges to different users or user groups to limit their access to a camera or camera group. Some agencies, or users in that agency, may be restricted to view-only access, while others are given view and control privileges for that camera or camera group.

A failure in a communications link, or in video distribution hardware or software, may result in the loss of access to another agency’s camera. This condition is recognized by an operator when attempting to use that remote camera. The operator reports the problem to the appropriate maintenance personnel, who work cooperatively with involved parties to diagnose and correct the problem, using typical communications, hardware, and software troubleshooting techniques.

Transmission of video via STARNET is enabled by encoding the analog video to a compressed, digital stream. Agencies installing video encoders can select from multiple manufacturers, as the system uses popular standards for video compression and supports multiple encoders.

The video distribution system tolerates some jitter in the delivery network. Even though varying levels of network traffic rapidly change the amount of bandwidth available for the video packets and packet delivery times vary, the final video image is nearly always of reasonable quality and usable.

Each agency is responsible for making any video recording they may need. There is no central or automatic recording of any video. As with all data and information collected via STARNET, an agency that captures video from another agency’s camera does not release such recordings to third parties without written permission from the source agency.

7.1.9 Video Used by the Public

The public use the Internet to view the live video feed from any CCTV camera in the region by clicking on a link to that camera on a 511 web page, or other web pages that arrange to provide links to the region’s transportation cameras. Some cameras that are available to agency operators may not be suitable for public viewing (e.g., security cameras on transit station platforms), and these are configured to be permanently not available to the public. Others can be normally available for public viewing but can have their public feed temporarily cut by an agency operator when the view is considered unsuitable for public viewing. This causes the public to see a message such as “This camera is temporarily unavailable” instead of the video feed.

To limit bandwidth use, the public can view only one camera at a time and a camera stream automatically terminates, unless manually refreshed, after a time limit set by the video distribution system administrator.

The public cannot control cameras. The public do not have to log in or otherwise identify themselves to view a camera.

If the video does not automatically scale to fit the available bandwidth, at least two different video feeds are offered to the public for each camera. One is suited to low bandwidth connections and the other to high bandwidth connections. If the time to start of viewing is high, or the minimum bandwidth is unsuitable for some low-speed Internet users, a snapshot option is available either automatically while the stream is loading or as the only video display.

7.1.10 Traffic Responsive Signal Pattern Selection

The City of Sacramento’s traffic signal management system continuously receives traffic volume and occupancy data from the Sacramento County traffic signal management system on Arden Way and Alta Arden Expressway, and uses these data, together with data from its own detectors, to select the most appropriate traffic signal timing pattern for signals on Arden Way and Exposition Boulevard. The City signal system automatically implements the selected timing pattern in its own involved signals and, if feasible, uses STARNET to issue a “request for action” to the County signal system to implement the same pattern in its involved signals. At other times or locations, the roles of the two signal systems are reversed so that the County system obtains the detector data, makes the selection, and implements the pattern.

7.1.11 Traffic Signal Status

While a traffic signal is flashing red due to a failure (not programmed flash) it automatically appears on the operators’ Regional Transportation Management Display (map) as an incident, and is automatically reported to the regional travel information system which reports it to the public on the travel information (511) web site and phone service.

To enable reporting of signals in flash, all agencies with a central traffic signal management system link their system to STARNET and allow the regional display system to obtain signal flash status data. The regional display system automatically creates an incident (type = roadway incident) and hence it is automatically reported on the 511 web map and 511 phone service.

Each traffic signal appears on the operators’ regional display map as a traffic signal icon. The color, and perhaps other attributes, of the icon indicate its current operating mode (e.g., off-line, flash due to failure, police manual control, programmed flash, preempt, free, coordinated). A mouse-over reveals the current basic timing parameters (e.g., plan or pattern number, cycle length if coordinated, offset if coordinated), and static information about the signal, such as type, identifier, owner, and location. As with other dynamic data, the same information is also available in a list view, where all traffic signals in the region are listed together, and the user can sort the list based on any column.

To enable reporting of traffic signal status, agencies link their traffic signal management system to STARNET and allow the regional display map to obtain appropriate traffic signal operating mode and timing data. An operator uses such information to confirm that a group of coordinated traffic signals spanning a jurisdictional boundary is operating as jointly planned by the two involved agencies. Fire truck dispatchers use the display to confirm that traffic signal preemption is working as expected. Transit operations supervisors use the display as part of investigations into possible causes of a late-running bus. Emergency or event managers use the display to confirm that police are controlling a traffic signal as expected.

7.1.12 Transportation Planning Database

As a STARNET node system collects traffic flow data (any combination of volume (by vehicle class where feasible), occupancy, and speed) from vehicle detectors on the freeways and arterial roads, those data are automatically transmitted to other STARNET nodes that have subscribed for such data. One of the nodes that subscribes for such data from all nodes providing them, is the SACOG transportation planning database. Each transmission of data collected from a detector includes the operational status of the detector, data values (e.g., any of volume, occupancy, and speed), a unique identifier for the detector, duration of the time period over which the values apply, the date and time at the end of that measurement period, and if possible, an indication of the data quality.

The SACOG transportation planning database node also subscribes for static data describing each vehicle detector. The static data include at least the detector identifier, type, owner, and location. A STARNET node automatically transmits static data to subscribers following any change in those data.

The transportation planning database also subscribes for incident data from the Regional Transportation Management Display system, and transit data (e.g., ridership statistics, vehicle location, vehicle arrival times, perhaps on-time performance statistics, facilities locations (including bus stops), service disruptions/cancellations, routes database including temporary diversions/detours, schedules, etc., as appropriate and agreed to by the source agency),

SACOG uses the data for validation and other aspects of its regional transportation model maintenance. Incident data are used to exclude or explain unusual traffic volumes, caused by an incident.

As with all data collected via STARNET, SACOG does not release such data to third parties without written permission from the source agency.

7.1.13 Emergency Responders Use STARNET

An emergency response dispatcher views live video from transportation agency cameras, transmitted via STARNET, to confirm the location, direction, type, extent, etc. of a reported incident, hence enabling a more appropriate choice of resources for dispatch.

An emergency response dispatcher views traffic congestion and lane closure information on STARNET’s Regional Transportation Management Display (map) before choosing which unit to assign to the incident or which route to recommend that unit use to reach the incident site.

Emergency response personnel on site at an incident or in a temporary command post, use an in-vehicle terminal or laptop computer with wireless Internet access to view live video and traffic flow data via STARNET in order to determine conditions just out of sight, such as the extent of a traffic queue backup, confirmation of a reported secondary incident, the message being displayed on a changeable message sign on approach to the area, etc.

Emergency response personnel view entries by transportation agencies and other emergency response agencies on the STARNET incident whiteboard to increase their awareness of the situation (information not already reported to them via voice radio) and actions of other agencies, and to coordinate activities with those other agencies. The whiteboard is a free-form text area in the regional incident tracker used to record any information considered useful.

Emergency response personnel overseeing an active incident make entries on the STARNET regional incident whiteboard to inform other agencies and the public of the status of the incident and response activities. The information they enter for other agency personnel may be different from that which they enter for the public if any.

During a major emergency, incident command staff at an emergency operations center view live video from transportation agency cameras, transmitted via STARNET, to assess the extent of the damage or secondary impacts.

During a major emergency or event, incident or event management staff use STARNET’s Regional Transportation Management Display (map) to illustrate the area currently affected by the incident (e.g., area flooded, area being evacuated due to a flood or toxic spill, area closed for a parade or other event, etc.), and choose to make this graphical information available just to other agency personnel (choose event type “operations”) or to the public too.

During a major emergency or event, transportation department representatives at an emergency or event operations center use STARNET’s Regional Transportation Management Display to keep the incident command staff informed of transportation conditions, and to enable an operator to answer questions such as "what routes are currently best to evacuate people from area A to facility B?"

To help relate incident impacts to street geometry and surrounding land uses, operators make use of the aerial photograph background option in the Regional Transportation Management Display (similar to the “satellite” view in Google Maps™).

Operators use links on the Regional Transportation Management Display to access web sites maintained by third parties such as the National Weather Service, the United States Geological Survey (stream gage readings), and the Office of Emergency Services.

7.1.14 Regional Transportation Operations Review

At a meeting of the Sacramento ITS Partnership, the agencies perform a review of regional transportation operations activities – those activities involving the cooperation and coordination of multiple agencies. In preparation for this meeting, each agency reviews its operations event logs (recorded either in the regional incident tracker whiteboard or in any other form the agency chooses) for the period since the previous review, and extracts information pertinent to the discussion. They also obtain the number of messages sent and received by each node. SACOG extracts and summarizes records of incidents from STARNET’s regional incident tracker and gathers statistics from the 511 system for both phone and web services, in accordance with the 511 Deployment Coalition’s Implementation and Operations Guidelines for 511 Services (http://ops.fhwa.dot.gov/511/resources/publications/511guide_ver3/511guide3.htm#topdoc).

Items discussed include what worked well, what didn’t, and how can regional operations be improved. Out of this discussion come recommendations for changes to STARNET and regional transportation operation procedures. Subsequently, SACOG takes the lead in evaluating the feasibility of making the recommended changes to STARNET.

In addition to these periodic reviews, after a major incident involving multiple agencies, an incident-specific performance review is conducted to analyze and learn from that experience.

7.1.15 Static Data Update

An operator at an agency operating a STARNET node that is a source of data, edits a database to add, change, or delete static information about a field device or the node system. Such static data are sent to other nodes that subscribe for them. Static data include information such as identifier, type, owner, and location. The data fields vary depending on the type of element being described.

If feasible, the automatic exchange of static data extends to providing a uniform view of traffic signal timing and street geometry such as that used in signal timing analysis software such as Synchro.

7.1.16 Incident Report Creation and Display

An accident occurs in Citrus Heights at the intersection of Greenback Lane and San Juan Avenue. The accident is first reported by a cell phone 911 call. The CHP call taker routes the call to the Sacramento Regional Fire/EMS Communications Center where it is entered in their computer aided dispatch system and paramedics are dispatched. Citrus Heights police are also notified and dispatch a police car. The fire truck is the first to arrive on scene and finds that a traffic signal pole has been damaged and traffic can get past the accident scene in only one lane and very slowly. The fire truck crew has their dispatch center notify Citrus Heights traffic engineering personnel who dispatch a signal maintenance crew.

Alerted to the situation, a Citrus Heights traffic management center operator uses a CCTV camera to survey the scene. To inform travelers and other transportation and emergency response agencies, he goes to the Regional Transportation Management Display and ensures the incident is entered in STARNET’s regional incident tracker. He finds that it has not already been created by other personnel or by the automatic feed from the Sacramento Regional Fire/EMS Communications Center, so he clicks on the Create Incident Report option. In the dialog window, he selects an incident type code (e.g., roadway incident, transit service incident, disaster (e.g., flood, fire, toxic plume), planned event, planned lane closure, truck restriction, operations), enters the approximate date and time it started (and checks “actual” flag next to that time), enters an estimate of when it will end (but does not check its “actual” flag), enters a description of the location including travel direction (the public hears this on the 511 phone service), enters a brief description of the incident (the public hears this on the 511 phone service) , makes an entry in the 511 phone message if appropriate (usually left blank), checks the Major Incident flag (since this is considered a major incident), and clicks the Save button. By clicking on the regional map, he selects the placement of the incident icon for this incident. The system automatically assigns a unique identifier for the incident, records the latitude and longitude of the icon placement, and records the user’s name and agency as the creator of the incident report. An operator wishing to fine tune the location of the incident icon can enter a mode that allows the icon to be dragged to another location. The centroid latitude and longitude fields can also be edited.

This new incident immediately appears on the Regional Transportation Management Display and 511 web site as both an icon on the map and an entry in the table of incidents. The map and table views automatically refresh periodically or upon change. The text shown in the table of incidents shows the unique identifier, the incident type, the owner (originator), the location, start time and end time and whether each is estimated or actual, and the description. This same information is displayed as a mouse-over bubble on the map. Both the icon on the map and text or other indicator in the row in the table view, are colored red and are flashing to indicate that this is an active major incident. If it were a minor incident it would not flash. If it were not currently active it would not be red. An incident is considered active if its Start Time is actual and in the past, and its End Time is estimated or actual-and-in-the-future.

As soon as the incident is flagged as “major”, the Regional Transportation Management Display system automatically sends a text message to the cell phones of those operators who have subscribed for such notifications. These subscriptions allow the operator to select the types of incidents that will trigger a message when it is flagged as “major”. Where feasible, the severity or other attribute of the data source used to automatically create an incident is used to automatically flag a new incident as “major”, but an operator can always manually change this flag.

Shortly thereafter, a second incident record for the same incident is automatically created in STARNET’s regional incident tracker by virtue of filtered data transmitted from the Sacramento Regional Fire/EMS Communications Center computer aided dispatch system, and a second incident icon appears next to the first on the regional display map. If the accident had not impacted the traffic signal or otherwise prompted emergency responders to alert the city traffic management personnel, this automatic entry from the computer aided dispatch system would be the only way the incident would appear on the regional display. The process of extracting data from the emergency response computer aided dispatch system includes removal of unnecessary and inappropriate information by filtering by fields, codes, and key words.

In this case, the creator of the manually-entered incident record sees that a duplicate record has been created and performs a merge action to combine the information into one. All entries in the whiteboards of each incident record are time stamped and automatically listed in chronological order when combined in the merged record. All entries also show the source. Further free text information about this incident flowing from the computer aided dispatch system is automatically inserted in the whiteboard of the merged incident record, as are any further manual entries by the Citrus Heights traffic operator or any other agency operator having useful information to contribute.

A subset of the incident entries (free text in the “whiteboard”) in the regional incident tracker for each incident, are transmitted (as soon as the entry is made) to the regional travel information (511) system for dissemination to the public via the 511 web site (not via the 511 phone service). At the time of data entry, within the Regional Transportation Management Display system, each entry is manually or automatically flagged as suitable for public distribution depending on its content or source. For example, information automatically obtained from the CHP’s public incident information web site is automatically flagged as suitable for public dissemination.

The same process is used to create “incidents” that represent planned future events, such as lane closures and special events that may generate unusual traffic or disrupt traffic flow. These are simply different incident types. The icon and text for a distant future incident are colored light gray, for a near future incident (e.g., commencing within say two days) are colored darker gray, and for an impending future incident (e.g., commencing within say two hours) is colored black. The icon and text for a current incident are colored red, and for a closed incident (End Time is actual and in the past) are colored green. Any user can click on the icon or text and use the pop-up dialog to edit any of the data fields, including adding further information about the incident or actions being taken. In this way, the incident record is a shared whiteboard on which all parties can share their information.

When an operator adds an information entry, they have the option to flag it as public information. If they don’t do this, it is not passed to the regional travel information (511) system and not displayed on the 511 web site, converted to speech for the 511 phone server, nor passed to third party travel information disseminators. Operators sometimes make two entries pertaining to some new information – one with details needed by cooperating transportation agencies but not appropriate for the public, and another that is an appropriate message for the public. Entries that are flagged as public are differentiated by color. All operators can see what the public sees.

When an operator adds an entry to the incident report (whiteboard entry), the date and time that the entry is made is captured (timestamp) and appended to the beginning of the entered text. The system also automatically records the name and agency of the operator making the entry. This name and agency information is displayed on the report when viewed by other operators, but is not given to the public by the 511 system nor passed to third party travel information disseminators.

The user clicks on the incident icon to see information not available in the mouse-over, and to add, change, or delete information. Entries in an incident report, both public and non-public, can be edited or deleted by any operator, subject to mutually agreed procedures. The name and agency of the operator making a change or deleting an entry is automatically recorded. Deleted whiteboard entries remain visible to all agency users (not to the public) while that incident remains in the database, but are clearly distinguished as deleted. Deleted entries are used in post mortems and training to better understand the dynamics of real-time incident management and reporting.

If the incident location is blank or outside the map area, the incident icon appears in a corner of the map (both operators display and 511 web page). Multiple such icons can be stacked but distinguishable there if necessary.

7.1.17 Local Truck Restrictions

An operator at a local jurisdiction uses STARNET’s regional incident tracker to record a temporary or permanent truck restriction, such as a height, weight, or size limit. It is just another incident type. This information shows on the Regional Transportation Management Display for operators, but more importantly, it is also automatically sent to the regional travel information (511) system where “incidents” of this type are automatically added to the truck restrictions layer of the 511 web site map.

7.1.18 Parking Availability

Prior to starting a trip, or en route, travelers use 511 to determine if a parking garage they intend to use in downtown Sacramento is already full. This is enabled by STARNET linking the City’s parking management system to the regional travel information (511) system. The 511 web site includes a page showing the current occupancy of parking garages – those garages for which data are currently provided to the 511 system via STARNET. The Regional Transportation Management Display web page includes a link to this parking information page. The 511 phone system reads the parking information to users when they select the Parking option. Initially, the only parking garages monitored are those that are part of the City of Sacramento’s parking management system.

For a planned event (e.g., parade, fair, air show, concert, sporting event, etc.), event management personnel use the Regional Transportation Management Display to create an incident (type = “planned event”) to provide travel information to the public related to that event. Such information includes transit services, parking availability as well as any street closures or access restrictions. The “511 phone message” field is used to either summarize such information or direct callers to the 511 web site for more information. As with other incident types, planned event “incidents” are available for viewing by operators on the regional display and by the public via the 511 system. When a planned event results in a significant disruption to traffic or transit services, operators might also create another incident type (e.g., roadway incident, or transit service incident) to report it, so that it is separately brought to the attention of travelers on the main 511 web map and directly under the Traffic and Transit options in the 511 interactive telephone service.

7.1.19 Travel Information

To check current travel conditions and opportunities, travelers use a computer or telephone to access travel information made available by the 511 system. Telephone users dial the number 511. Upon accessing the recorded greeting, they are prompted with the options to select whether they want information regarding Traffic, Transit, Parking, Help, or Other. After selecting Other, the user can choose between Rural Highways, Bay Area 511, Other Areas, Amtrak, Ridesharing/Bicycling/Telecommuting, Events, Weather, and Help. The user selects an option by either speaking the menu item or pressing a key on the phone keypad. The touchtone menu is accessed by pressing the zero key.

If there are any active incidents of type “disaster”, these are read to the phone user immediately, before any menu options are presented.

After selecting Traffic, the user is asked to specify the highway route number or area (such as Central, Northeast, East, South, West, or North) for which they would like to receive traffic information. Once a selection is made, the system responds with a spoken list of current incidents and slow downs on that route or in that area. Incidents are filtered to eliminate transit incidents, truck restrictions, “disaster” incidents, “operations” incidents, and incidents that are not currently active (except for planned event incidents). Of the remaining incidents, those flagged as Major are presented first. Incidents are secondarily sorted by start time, where the most recent are presented first (except that planned events are listed last). The information provided for each active incident are the location, description, start time, estimated end time, and 511 phone message fields, read directly from the incident record received from the Regional Transportation Management Display system. The “511 phone message” field is used by agency operators to provide additional information or advice that is important to have included in the 511 phone message for an incident. It is also provided in the 511 web site report for the incident. No whiteboard entries are read to 511 phone users.

Significant slowdowns are presented after all incidents. Slow down information is derived from freeway detector data from Caltrans, transmitted to the 511 system via STARNET. Slowdown reports provide the highway route number, the approximate start and end points of the slow section, and an indication of the slowest average speed at any detector station in this segment (e.g., “20 to 40 mph” or “less than 25 mph”).

After selecting Transit, the user is asked for the name of a county. They then hear a spoken list of any current transit service incidents (incident type = “transit service incident”) and all planned event incidents (even if not yet started) relevant to that county. The user is then asked to specify a transit agency in that county for which they want information. After selecting an agency, the user is transferred to the customer service phone line for that agency.

After selecting Parking, the voice message reads the list of currently monitored garages, providing the percent occupancy of each. The garages are heard in order of occupancy, starting with the highest occupancy.

At any time while listening to a list of traffic or parking conditions, the user can say Skip to immediately move to the next item, Repeat to start over at the beginning of the current item, Back to back up to the previous item, or Stop to return to the prior menu. If there is no information to report, the user hears “There are no significant events reported at this time – returning to the main menu” or similar.

After selecting Rural Highways, the user is transferred to the Caltrans Highway Information Network interactive telephone service (800-427-7623). After selecting Bay Area 511, the user is transferred to the San Francisco Bay area 511 interactive telephone service (510-817-1717). Other options similarly cause the user to be transferred to the relevant third party customer support phone line.

A user unfamiliar with the 511 phone system can say “help” at any time to hear a recording that explains how the interactive phone system works, how to hear the touchtone options, and tips for better results.

Hearing impaired users can access the 511 phone system either through a parallel Telecommunications Device for the Deaf (TDD) teletypewriter (TTY) service or, by using the 711 relay services that have been established to enable the hearing-impaired to call any phone number, regardless of whether it is TDD-TTY-equipped.

The 511 phone system is built with sufficient capacity to avoid callers getting a busy tone 95% of the time. The number of lines is adjusted over time according to changes in demand.

Rather than using the telephone service, some users go to the 511 web site (www.sacregion511.org) to obtain travel information. The web site provides, in text and/or graphical form, all the information available directly by telephone (not information provided indirectly via third party interactive phone service or customer support phone lines) and more. The 511 web site also provides links to third party web sites providing travel related information useful to the public (e.g., San Francisco Bay area 511 web site – www.511.org, National Weather Service, Office of Emergency Services, Caltrans District 3 chain control information website – www.dot.ca.gov/dist3/projects/chainmap/chain_control_map.pdf). The 511 web site also provides telephone numbers for travel information services.

The 511 web site provides a map of the Sacramento region similar to that displayed to operators by the Regional Transportation Management Display system. The 511 map and tabular views of data contain a subset of the information available to operators. The public cannot see video from closed circuit television cameras that are currently flagged as unsuitable for public viewing. The public have no ability to control cameras, create or edit incident records, or otherwise affect devices or data. The public cannot see those entries in an incident whiteboard that have been flagged as unsuitable for public viewing. The public cannot see incidents of type “operations”. These are intended for information sharing between agency operators only, such as reporting STARNET system or critical field equipment faults and follow up. The public cannot see the name of the operator who created the incident or who made a particular entry in the whiteboard.

By default, incidents with a start time in the future, and incidents that record truck restrictions, are not shown on the 511 map. However, the user can reveal such incident types and hide other incident types by clicking check marks in a list of display options. The public cannot see traffic signals, either on the map or in a table. The public cannot see the current location of buses, but can see the location of Regional Transit’s light rail vehicles.

To facilitate further dissemination of the information, and use by researchers and other interested parties, the 511 system makes continuous computer-to-computer data feeds available to third parties including commercial information service providers. These feeds are based on the NTCIP Center-to-Center XML standard. All data received by the 511 system are offered to third parties via this data feed. Third parties can subscribe for all or a subset of the data.

7.1.20 Subscriptions

To allow for data to be pushed “on change” rather than pulled via continuous polling and to avoid having all available data flowing at all times from and to all nodes, operators can establish subscriptions for the data they want a node to receive from each other node. To create, edit, or delete a subscription, an operator launches the subscription editor dialog provided by the node system. This functionality may be provided by an auxiliary software and hardware package adjacent to the node server rather than modifying the node system itself to add this functionality.

The subscription editor allows the user to enter or edit fields such as the identifier of the source node, the type of data requested, and whether it should be sent once, repeatedly at a fixed interval, or whenever any part of it changes. Most operators choose the change driven option for most purposes, as it ensures the least delay in receiving data changes while minimizing unnecessary network traffic. The subscription management system at each node automatically sends a “keep alive” message periodically if no message has been sent by virtue of current subscriptions.

Each node that is capable of exporting data in accordance with a subscription also has the ability for a user to accept or reject subscription requests from other nodes. Such acceptance or rejection can be effected one subscription at a time, or by a blanket acceptance or rejection for all subscriptions of a certain type or from a certain node. This functionality may be provided by an auxiliary software and hardware package adjacent to the node server rather than modifying the node system itself to add this functionality. Prior to attempting to establish a subscription, or during the subscription process, a user at a subscribing node will manually coordinate with their counterpart at the publishing node to ensure the subscription is accepted.

An operator of node A can request any other node (e.g., node B) to send a list of active subscriptions it currently holds for node A. This is used to confirm that subscriptions were successfully established and is also used in troubleshooting when expected data are not received.

7.1.21 STARNET Facilitator

The Regional Transportation Management Display system and the 511 travel information system normally operate unattended. However, during peak travel times and during normal work hours, at least one experienced operator with a STARNET agency facilitates the use and maintenance of these systems and other components of STARNET. This includes activities such as the following:

· Monitor a local radio station, emergency response voice radio traffic, and other information sources, for reports of relevant incidents. If not already done automatically or by an agency operator, create an incident in the Regional Transportation Management Display for significant incidents. Such incident reports are automatically made available to the public via the 511 system.

· Monitor the progress of incidents currently reported on the Regional Transportation Management Display and update information if not done automatically or by an agency operator.

· Identify duplicate incident records and communicate with involved operators to facilitate having such records appropriately merged.

· Communicate with agency operators if needed to ensure relevant personnel are aware of major incidents or problems, and to help coordinate activities of all involved agencies.

· Monitor the status of the Regional Transportation Management Display system and the 511 system to ensure all automated functions are operating correctly. This includes routinely looking at all material on all web pages produced by these systems and exercising all parts of the 511 interactive telephone service.

· Receive and follow up on problems reported by system users. Provide real-time interactive help to agency operators upon request by telephone or e-mail. The 511 web site provides a non-real-time feedback facility whereby users can report problems, describe their experience with the system, and suggest improvements.

· Investigate and diagnose problems found in the Regional Transportation Management Display and 511 systems.

· Monitor the status of STARNET nodes, field devices critical for multi-agency cooperation, and STARNET communications, and report any problems to the agency responsible for the problem component.

· Follow up on previously reported problems to help ensure corrective action is taken in a timely manner.

· Provide advice and assistance to agency personnel involved in problem follow up.

· Identify potential improvements in regional coordination procedures.

· Identify corrections and updates needed to web pages including the regional map used in the Regional Transportation Management Display and in the 511 web site.

· Maintain a database of all significant events, activities, feedback from the public and agency users, and other information relevant to any aspect of STARNET, the Regional Transportation Management Display system and the 511 system.

The personnel providing this facilitator service are not responsible for any aspect of direct transportation operations (at least not by virtue of this role – they may be so responsible in other roles within their employing agency, for facilities owned and operated by that agency). They are not responsible for any STARNET node systems other than the Regional Transportation Management Display and the 511 travel information system. They do not make operational decisions or take operational actions. They have no authority over the operational personnel in the various transportation agencies. They are merely an information collector and disseminator, where that information includes real-time travel information, and real-time and historical information about the STARNET system and regional coordination. They help ensure STARNET is effectively used and maintained, and assist in coordinating activities between STARNET agencies.

7.2 Failures and Other Unusual Events

7.2.1 Node System Status

The Regional Transportation Management Display system monitors the status of communications with each STARNET node (e.g., by sending “are you alive” requests when no message has been received from that node for a certain amount of time) and performs appropriate health monitoring. If a node is not communicating, it is flagged as such and the node icon on the map and text in the table view change to a gray color to reflect this state. Also, a message is sent to any other nodes that have subscribed for node health messages. When communications resume, the node icon changes back to the normal color, and a “communications restored” message is sent to subscribers. This facility is used by operators to check the status of nodes they are expecting to see data from on the regional display or in direct subscriptions, and is also used by maintenance personnel.

At least some other nodes also have the ability to detect loss of communications with other nodes and to report it in messages sent to subscribers. The Regional Transportation Management Display system collects such node communication status reports from other nodes, and reports these in a pop-up window launched by clicking on the icon for a node on the map or the row in the table view. This pop-up window might show, for example, that nodes A and B have lost communication with node C, but node D is communicating with node C just fine (presumably via a different communication link). Such information is used by maintenance personnel to isolate the problem, in this case obviously a communications link problem rather than a node failure.

The Regional Transportation Management Display system also logs all such loss of communication incidents, recording the date and time that a problem is first recognized and the date and time it is corrected. This information is used in periodic system performance evaluation and to identify equipment that needs to be replaced or upgraded because the same failure occurs repeatedly.

When the Regional Transportation Management Display system detects a node communication failure, it automatically sends an alert e-mail or text message to a designated maintenance person. If this person does not acknowledge the message within a certain time, a message is sent to a second person. The system allows different people to receive alerts at different times, according to work schedules. An operator of the regional display system creates, edits, and deletes alert configuration data as needed.

When the Regional Transportation Management Display system detects a node communication failure, it also denotes such condition for any device icon on the map or other view of data normally coming from that node.

7.2.2 Maintenance

Each agency maintains its own STARNET nodes, the STARNET interface, and communications equipment used by STARNET that it owns. Shared nodes such as the Regional Transportation Management Display and associated regional incident tracker, are treated as being owned by SACOG for the purpose of maintenance. The agencies agree to give appropriate priority to STARNET-related maintenance activities in recognition of its importance to other agencies and the region.

When any aspect of the STARNET system is found to be malfunctioning, the operator discovering the problem contacts designated maintenance personnel in other agencies that may be able to assist in correcting the problem. All involved parties work cooperatively to restore normal operation.

Maintenance personnel refer to system configuration records to determine what equipment and software may be involved in a problem and how it is currently configured. After any changes are made as part of the maintenance activity, these configuration records are updated. Configuration management procedures (see STARNET Configuration Management Plan) require joint approval of any change, even one made for maintenance purposes, which may impact other users.

7.2.3 Adding or Deleting a Node Reference

Nodes join and leave the network without other nodes having to make any change in configuration data. However, when existing node A needs to obtain data from new node B, a node A administrator enters the name of the new node B in a configuration database and can then select that node in subscription configurations. The name of the new node and which data messages it supports are obtained manually.

Similarly, if new node B wants to obtain data from node A, a node B operator must add node A to its list of known nodes and establish appropriate subscriptions. If either node is manually filtering subscription requests, that is, authorizing acceptance of subscriptions only if approved by an operator, then an operator at the node receiving a subscription request will receive an e-mail advising that a subscription is awaiting approval. That operator will check that the subscriber is a valid recipient of the requested data, and accept the subscription. A node may configure their STARNET interface to automatically accept all or certain types of subscriptions from certain nodes. Agencies agree to not withhold approval of subscriptions without reasonable cause.

Design and implementation activities associated with the addition of a new node are discussed in the next section.

7.2.4 Third Party Access

Organizations that are not a part of the STARNET team request access to at least some data. Such organizations might include, for example, commercial or non-profit travel information providers, Caltrans Headquarters, the San Francisco Bay Area 511 system, the Federal Highway Administration, Department of Homeland Security, researchers at universities, other regional systems wishing to test interoperability, etc.

The STARNET agencies agree on a general policy on this issue in advance, and consider the merits of each request in light of that policy. The policy might, for example, preclude certain types of organizations or purposes from having access to STARNET data on the assumption that their needs are more appropriately met by tapping the Sacramento 511 data feed rather than the more extensive data available directly from STARNET. The requirements of other organizations or purposes may be satisfied by access to SACOG’s regional transportation database which includes historical data collected via STARNET. Others warrant a guest user account on the Regional Transportation Management Display system as they want only human access to the information. Appropriate privileges can limit what data they see, if needed, and can preclude camera control for example. Other organizations may be justified in having a system added as a node on the network so that their system can automatically obtain data at all times.

In all cases, the request is discussed by all STARNET participating agencies before a joint decision is made as to how to respond to the request. If the request is to be satisfied by allowing access to data from a non-source data store, such as SACOG’s regional transportation planning database, the data store owner (SACOG in this example) may require written approval from the source agencies before providing access to the data.

7.2.5 Adding or Deleting a Regional Display User

An operator with administrator privileges for the Regional Transportation Management Display system adds and deletes users (operators) of that system when needed. The information stored for each user include their name, agency, role, telephone numbers, e-mail address, login name, password, and system access privileges (directly or via their assignment to a user group). An administrator occasionally edits the data stored for a user to reflect changes.

7.2.6 Security Challenges

Security mechanisms and procedures provide reasonable protection against predictable threats, including the following examples:

· An authorized operator logs into the Regional Transportation Management Display and then walks away from the computer without logging out. An unauthorized person in the room can now use this logged-in interface to access the system.

· After terminating his employment with a STARNET agency, a prior operator attempts to access the Regional Transportation Management Display system using the user name and password used while he was an agency employee.

· An on-line hacker attempts to determine a valid administrator or guest password for the Regional Transportation Management Display system.

· A hacker attempts to find a written record of a user name and password by sifting through trash from a transportation management facility or by physically entering and searching within the building.

· A hacker attempts to connect to, disable, or damage a node computer via the STARNET network, using techniques such as spoofing, denial of service, packet fragmentation, password cracking, FTP bouncing, and various configuration or operating system vulnerabilities.

Firewalls and other appropriate measures are used to avoid STARNET creating increased vulnerabilities for nodes systems, or computers and databases on the local area networks to which they are connected. Firewalls are configured in accordance with local agency network security policies.

Each time an operator uses the Regional Transportation Management Display they do not have to log-in again, unless they have not used the interface for a long time, or they are performing an unusual action that warrants particularly stringent security requirements.

7.3 Design, Implementation, and Upgrades

7.3.1 Initial System Design

The user needs identified in this document are used to derive system requirements and a scope of work for a system integration contract. Stakeholders review and approve these items. The requirements are used by the STARNET team (consultant and stakeholders) to develop a high level design and system architecture. These are used to estimate the system cost and to guide the system integrator.

The requirements, high level design, and scope of work are included in a Request for Proposals for initial system integration services. The proposals include a proposed conceptual design, which are compared by stakeholders as part of the evaluation of proposals. Proposers are encouraged to adopt design approaches that make maximum use of existing systems operated by the agencies, off-the-shelf software, and popular standards.

The first task of the selected system integrator is to prepare a detailed system design based on the conceptual design included in their proposal and any changes agreed to during contract negotiations. Stakeholders and the STARNET technical assistance consultant review the detailed design.

7.3.2 System Implementation

Once the detailed design is approved, the system integrator proceeds to build the system. Stakeholders and the technical assistance consultant review progress by reading progress reports, reviewing prototype demonstrations, reviewing each release of functional modules, checking hardware installations, and performing software code reviews where appropriate.

During system implementation, involved agency personnel cooperate with the integration contractor as needed to facilitate implementation of the interface to each node system. Where necessary, they facilitate involvement of the manufacturer of node systems, at least to provide information about the system needed to build an interface to it, and possibly to make software modifications.

Agencies also cooperate with the integration contractor to establish the necessary communications links, whether this involves use of agency-owned communications plant, leased dedicated links, or shared commercial data services including the Internet. Each agency ensures that its network configuration and security policies are known well in advance and adhered to. The STARNET network will connect with local area networks at each agency and to the Internet, and appropriately secure interfaces are provided.

7.3.3 Procedures, Training, and Documentation

Prior to system startup, the STARNET agencies develop joint regional transportation operations procedures. The technical assistance consultant helps in this effort. These procedures include those for shared use of CCTV cameras, STARNET subscriptions, creation and editing of incident reports using the Regional Transportation Management Display, remote access to other agencies’ transportation management systems, etc.

During implementation of the initial STARNET system, operations and maintenance personnel in the STARNET agencies take every opportunity to be involved with the system implementation as part of the learning process. In addition to this informal learning, formal training sessions are help where the system integrator, the technical assistance consultant, and agencies contributing communications or other facilities, provide hands-on training in the use of the software, configuration of hardware and software, operation and maintenance procedures, maintenance techniques for all components (hardware and software), and configuration management procedures. Formal training is also used an opportunity to practice the regional transportation operations procedures.

Materials, presentations, and hands-on demonstrations during formal training are all specific to the implemented system and its particular configuration and concept of operation, not generic. All training is conducted by effective trainers familiar with the details of the STARNET implementation and concept of operations. Where possible, training involves use of the actual system. Off-line, test, or dummy devices and nodes are used as needed during training to ensure all aspects of system operation and maintenance are demonstrated where training can’t be done using the actual system.

All aspects of the system and related procedures are thoroughly documented. A new employee joining the team is able to read the documents and fully understand the system and needed procedures. The documents are also effective as reference materials during system use and maintenance, enabling the user to quickly find needed information. On line help is provided in software where appropriate.

7.3.4 Connecting a System to STARNET

The STARNET interface specifications are well documented and made available to any agency wishing to add a node to the network. These specifications provide all the information needed to provide and configure an interface between any node system and the rest of STARNET.

The initial system integrator provides software that serves as a test node against which new nodes can be tested in an off-line environment. This is used by the integrator during development of the initial system, becomes SACOG property at the end of the contract, and continues to be available for use in subsequent node additions. Use of this test software helps avoid disruptions that can result when, for example, a new node floods the network with repeated connection attempts or data transmissions due to software bugs.

The initial system integrator can be hired to facilitate implementation of a STARNET interface on new nodes. However, system documentation, the test node, and use of industry standards are sufficient to allow new nodes to be provided with a compatible interface without requiring the involvement of the initial system integrator.

7.3.5 Upgrading a Node

A STARNET agency upgrades a node system. In this process, they ensure the STARNET interface is fully supported on the upgraded system. They use off-line testing and other procedures similar to those used when adding a new node. They also keep the existing system on-line until the new system is ready to take over, and arrange an efficient cutover process that minimizes interruption to STARNET participation.

7.3.6 Expanding and Upgrading the Whole System

STARNET is built in stages due to funding constraints. The initial system provides the fundamentals and connects some nodes. Subsequent expansions add both functionality and more nodes. The whole STARNET system eventually becomes obsolete and needs replacement or a major upgrade.

For each expansion, upgrade or replacement, the STARNET agencies go through a process similar to that used for the initial system implementation, hiring consultants and integration contractors if necessary, and using the systems engineering process. A major difference in this case is that the process must allow for continued operation of the existing STARNET and efficient cutover to the new system with minimal disruption. Costs, and the need for hiring consultants and contractors, in subsequent expansions and upgrades are minimized by designing for expansion, comprehensive documentation and training, and use of open standards, in the initial implementation. Agencies plan for predictable upgrades and identify needed funding.

7.3.7 STARNET Management

STARNET components are managed by the owning partner agencies after taking into account regional considerations as advised by the Sacramento Region ITS Partnership. This committee is composed of Intelligent Transportation Systems (ITS) and emergency response personnel from local agencies. They meet regularly and discuss issues related to STARNET among other things. They appoint a STARNET Technical Advisory Committee that engages in more in-depth discussion and research of issues.

During the initial implementation of STARNET they use the needs identified in this Concept of Operations to arrange support measures as needed. These include funding for implementation and on-going operation, development of joint operation and maintenance procedures, development of guiding policies, and signing of cooperative agreements where necessary. Each agency’s representative on the Partnership briefs the appropriate policy makers in their agency, gets their input, and actively seeks to gain agency support and approval for the measures needed for STARNET, including on-going funding of the operation and maintenance of the portion of STARNET owned by that agency.

7.3.8 Regional ITS Architecture Updates

When appropriate, a STARNET configuration change is reflected in an update to the Sacramento Regional ITS Architecture.

7.3.9 ITS Standards Feedback

Experience during the initial implementation and subsequent upgrades of STARNET is used to provide feedback to relevant standards development agencies as to the efficacy of ITS standards used or attempted to be used, and recommendations for changes to standards where appropriate.

8 User Needs

The following user needs are derived from the operation scenarios. Needs are in random order and the order does not imply priority. At the end of each need statement are hyperlinks to the operation scenarios from which it is derived. These appear between braces and use italics.

Lower priority needs are identified as such by wording, such as “if feasible” or “lower priority”.

1. Provide a STARNET interface to transportation management systems, databases, and computer aided dispatch systems (or web page derived there from) operated by the following agencies:

a. California Highway Patrol.

b. Caltrans District 3.

c. Sacramento Area Council of Governments (511 system, and transportation planning database).

d. Sacramento Regional Fire/EMS Communications Center

e. Yolo County Communications Emergency Service Agency

f. Sacramento County

g. Ed Dorado County

h. Sacramento Regional Transit District

i. Yolo County Transportation District

j. City of Sacramento

k. City of Citrus Heights

l. City of Elk Grove (traffic and transit)

m. City of Folsom

n. City of Rancho Cordova

o. City of Roseville (traffic and transit)

p. City of Sacramento

q. City of West Sacramento

{Freeway 99 Closure at Consumnes, Light Rail Transit Bus Bridge, Transit Information, Local Freeway Detector Data, Changeable Message Sign Status, Freeway Ramp Meter Status, Traffic Responsive Signal Pattern Selection, Traffic Signal Status, Transportation Planning Database, Parking Availability}

2. Provide a Regional Transportation Management Display system. This is also another STARNET node. It provides a regional map with clickable icons representing transportation management facilities operated by STARNET agencies and current and planned incidents, a table view of the same facilities and incidents, a means for manual entry of incident information, and configuration dialogs for use by system administrators. {Freeway 99 Closure at Consumnes, Planned Roadwork and Bus Detour, Video Used by Operators, Incident Report Creation and Display, etc.}

3. Subject to availability, and the capabilities of a node system to export such data, make the following real-time raw data available for exchange between appropriate nodes (including the 511 system) and viewable in the Regional Transportation Management Display where appropriate. Where appropriate, data displayed on the regional display and made available via the 511 system may be an aggregated and translated version of the raw data sent between nodes.

a. Vehicle count, per detector (per lane) per count period per vehicle class.

b. Vehicle detector average occupancy, per detector (per lane).

c. Vehicle average speed, per detector (per lane).

d. Traffic signal operating mode (e.g., off-line, flash due to failure, police manual control, programmed flash, preempt, free, coordinated).

e. Traffic signal current basic timing parameters (e.g., plan or pattern number, cycle length if coordinated, offset if coordinated).

f. Traffic signal pattern command (request to implement a certain pattern at selected signals).

g. Ramp meter status (e.g., out of service, in service but currently not metering, now metering, flow rate if metering).

h. Changeable message sign status (e.g., out of service, in service but no message, routine message, incident message) and the text of the current message if any.

i. Incident data (e.g., location description, icon location (latitude/longitude) incident description, incident type (e.g., roadway incident, transit service incident, disaster, planned event, planned lane closure, truck restriction, operations), start time (can be in future, and whether projected or actual), end time (and whether projected or actual), whether major or not, 511 phone message, remarks or whiteboard entries, and source agency and operator name).

j. Transit vehicle arrival time at upcoming stops.

k. Transit vehicle location (latitude and longitude), direction of travel, and speed (initially only light rail vehicles).

l. Transit service disruptions (e.g., route, direction, location/extent, projected duration,

m. Transit ridership statistics.

n. Parking garage occupancy data.

o. Video source status (e.g., available for viewing, available for control, ID of two most recent users and time of last control command by each).

{Freeway 99 Closure at Consumnes, Light Rail Transit Bus Bridge, Transit Information, Local Freeway Detector Data, Changeable Message Sign Status, Freeway Ramp Meter Status, Traffic Responsive Signal Pattern Selection, Traffic Signal Status, Video Used by Operators, Video Used by the Public, Transportation Planning Database, Parking Availability}

4. Provide a web-based video distribution mechanism that enables all agencies’ closed circuit television cameras to be viewed and controlled (as and when appropriate) by any agency operator via the Regional Transportation Management Display and enables all cameras to be viewed but not controlled by the public. {Freeway 99 Closure at Consumnes, Video Used by Operators, Video Used by the Public, Incident Report Creation and Display}

5. Provide suitable communication links between nodes. {Freeway 99 Closure at Consumnes, Light Rail Transit Bus Bridge, Transit Information, Local Freeway Detector Data, Changeable Message Sign Status, Freeway Ramp Meter Status, Traffic Responsive Signal Pattern Selection, Traffic Signal Status, Video Used by Operators, Video Used by the Public, Transportation Planning Database, Parking Availability}

6. Provide access to the Regional Transportation Management Display and live video, from the Internet. {Video Used by Operators, Video Used by the Public}

7. Provide authorized user access to the Regional Transportation Management Display (which includes the regional incident tracker and live video) for operators from all involved agencies. Allow users to be added and deleted and assigned to user groups with appropriate privileges. {Adding or Deleting a Regional Display User}

8. Don’t allow the public to have access to the Regional Transportation Management Display (they use 511). {Freeway 99 Closure at Consumnes, Video Used by the Public, Incident Report Creation and Display}

9. Allow authorized user access to the Regional Transportation Management Display from a computer in any location with Internet access, without the computer needing any special software installed, other than a popular web browser. {Freeway 99 Closure at Consumnes, Video Used by Operators}

10. Require authorized users (operators) to log-in to the Regional Transportation Management Display including entry of a password. {Adding or Deleting a Regional Display User, Security Challenges}

11. Allow users to pan and zoom the regional display map, preferably using techniques similar or superior to Google Maps™. {Freeway 99 Closure at Consumnes}

12. Allow users to turn on or off an aerial photo background on the regional display map (similar to Google Maps™). {Emergency Responders Use STARNET}

13. Objects displayed in both the map and table views of the regional display include incidents (including planned lane closures and truck restrictions), vehicle detectors, traffic signals, CCTV cameras, changeable message signs, ramp meters, and STARNET node systems. {Freeway 99 Closure at Consumnes, Light Rail Transit Bus Bridge, Changeable Message Sign Status, Freeway Ramp Meter Status, Traffic Signal Status, Video Used by Operators}

14. In the table view of the regional display, show at least the object type, identifier, owner, and location, in addition to dynamic data. {Freeway 99 Closure at Consumnes, Changeable Message Sign Status, Freeway Ramp Meter Status, Traffic Signal Status, Video Used by Operators, Incident Report Creation and Display}

15. Allow regional display users to sort the objects table view by any column.

16. A mouse-over of an object icon on the regional display map reveals all data available in the table view, to the extent feasible.

17. In both the map and table views, the regional display uses the color and perhaps other attributes of the icon or text to indicate if the object is active or inactive (including loss of communication or otherwise unavailable), and where feasible, its status (e.g., signal operation mode, sign has a message displayed, level of congestion at a vehicle detector, transit vehicle behind schedule, etc.). In the case of incidents, colors are also used to distinguish future, current, and past incidents, and flashing icon or text to highlight major active incidents.

18. When a user clicks on an object on the regional display map or table, a pop-up window reveals additional details relevant to the object type if appropriate, and allows editing of displayed information (e.g., in the case of incidents).

19. The Regional Transportation Management Display system continually monitors computer aided dispatch systems (or a web site derived there from), traffic signal management systems, and transit service disruptions systems, parses and filters the data, and automatically creates a new incident in the regional display system on appearance of a new event meeting selection criteria. Any subsequent additions or changes to the source incident report are automatically reflected in an update to the regional display version of the incident as the new information is received.

20. The regional display system allows operators to manually create new incidents, including future incidents such as planned lane closures, in addition to those automatically created based on data received from nodes systems. A unique incident identifier is automatically assigned by the system. An incident can be manually flagged as “major”. The creator’s name and agency are automatically recorded, with “Automatic” shown as the operator name in the case of an automatically created incident. The user is able to position a standard icon on the map to represent the incident’s location, or create a custom polygon on the map to represent the area affected by the incident. The operator can adjust the icon location. The icons for incidents with a location beyond the map extents are placed in a corner of the map in a way that they are individually accessible.

21. The regional display system allows an operator to select any two incidents and merge them into one incident.

22. For an incident recorded in the regional display system, operators from any STARNET agency are able to add textual information to a “whiteboard” history of such operator-provided information. The operator is able to designate the entered information as suitable or unsuitable for distribution to the public via the 511 system. The system records and displays time of entry and the name and agency of the operator adding the information. This operator name information is never distributed by the 511 system. If the incident originated from, or is merged with, an incident automatically originating from a computer aided dispatch system, any suitable remarks added by the dispatcher are automatically added to the whiteboard.

23. When an incident is flagged as “major”, the Regional Transportation Management Display system automatically sends a text message to the cell phones of those operators who have subscribed for such notifications. These subscriptions allow the operator to select the types of incidents that will trigger a message when it is flagged as “major”

24. An agency can configure a STARNET node system to subscribe to any other node system for any data offered by that other node.

25. STARNET subscriptions can be for one instance of the data or for continued automatic delivery of the data by time period or when a change occurs.

26. Enable an operator to configure a node’s STARNET interface to automatically accept none or all subscriptions from selected other nodes and for selected messages.

27. An agency can obtain from other nodes, a list of all subscriptions they currently recognize for that agency’s system.

28. When an operator of a node system changes the node’s database to add, change, or delete a field device, the changed static data relevant to other nodes (e.g., device type, identifier, location) are sent to other nodes that have subscribed for such data. If feasible, this functionality extends to providing a uniform view of traffic signal timing and street geometry such as that used in signal timing analysis software such as Synchro.

29. When a user clicks on a camera object in the regional display, pop-up a window with the live video feed from that camera.

30. When a user clicks on a camera object in the regional display, the pop-up video feed window (or elsewhere) provides on-screen pan/tilt, zoom, and preset controls for that camera, but only if the camera has remote control capabilities and the user is authorized to control that camera.

31. Pan/tilt and zoom camera controls in the regional display are actuated by the computer mouse or other pointing device, and are easy to use, preferably allowing click and drag/slide operations rather than repeated clicks.

32. A camera user can choose a camera preset view such as by clicking on the description of that preset in a presets list.

33. The video distribution functions of the regional display support up to six operators viewing the same camera simultaneously, and allows all cameras to be viewed simultaneously by at least one operator.

34. The regional display uses streaming compressed digital video to deliver video over the STARNET network and to remote operators (including camera control) over the Internet.

35. The regional display video distribution system supports multiple brands of video encoders, based on one or more popular video compression standards.

36. The video feed latency in the regional display is less than a second, thus facilitating remote camera control.

37. The video feed in the regional display has some tolerance to network jitter.

38. Streaming video is also made available to the public via the 511 web site, without any need to log-in, and without any camera controls. Latency is less critical in this application.

39. If the streaming video doesn’t automatically scale to any available bandwidth, a regional display or public user can choose between at least two different bandwidth versions – one suited to a high bandwidth link and the other suited to a low bandwidth link.

40. A regional display administrator can add or delete cameras, configure different bandwidth feeds, and assign different privileges to different users or user groups, including view-only restrictions when appropriate for selected cameras. Selected cameras can be precluded from ever being available to the public.

41. A regional display user (operator) observing a camera feed may click on a Cut Feed to Public button when the image is not suitable for public distribution. A Restore Feed to Public button is used to restore the public feed. When the public feed is cut, the public see a message such as “This camera is temporarily unavailable” in place of the video image.

42. The owner of a camera has priority for control of that camera and can override other users by agreed procedures and, if available, via locks and overrides provided by the video system.

43. Provide an upgraded 511 system that offers the public an interactive telephone service and a web site.

44. The upgraded 511 telephone service provides the caller with voice messages containing current incident information and significant slowdowns on the region’s freeways.

45. In the 511 telephone service, provide options of Traffic, Transit, Parking, Rural Highways, Bay Area 511, Other Areas, Amtrak, Ridesharing/Bicycling/Telecommuting, Events, Weather, and Help.

46. If the 511 caller chooses Traffic, then ask them to specify the highway route number or area (such as Central, Northeast, East, South, West, or North) for which they would like to receive traffic information. Then provide incident and slowdown information for that route or area. Incidents are filtered to eliminate transit incidents, truck restrictions, “disaster” incidents, “operations” incidents, and incidents that are not currently active (except for planned event incidents). Of the remaining incidents, those flagged as Major are presented first. Incidents are secondarily sorted by start time, where the most recent are presented first. The information provided for each incident are the location, description, start time, estimated end time, and 511 phone message fields, read directly from the incident record received from the Regional Transportation Management Display system. The “511 phone message” field is used by agency operators to provide additional information or advice that is important to have included in the 511 phone message for an incident.

47. Slow down information reported on the 511 telephone service is derived from freeway detector data from Caltrans. Slowdown reports provide the highway route number, the approximate start and end points of the slow section, and an indication of the slowest average speed at any detector station in this segment (e.g., “20 to 40 mph” or “less than 25 mph”).

48. If the 511 caller chooses Transit, they are asked for the name of a county. Then announce any active transit service incidents and planned event incidents (active or future) for that county, before asking the caller for the name of a transit agency in that county. Once a transit agency is selected, the call is transferred to that agency’s customer support line.

49. If the 511 caller chooses Parking, then announce the name, location, and current occupancy (percent full) of each monitored parking garage, starting with the highest occupancy garage.

50. If the 511 caller chooses Events, then announce any future or active planned event incidents.

51. If the 511 caller chooses Help, a recording provides an overview of the interactive telephone service, options, how to work it, and tips for better results.

52. If the 511 caller chooses any option other than Traffic, Transit, Parking, Events, or Help, then they are transferred to the appropriate third party information line.

53. If there is no information available for the 511 caller’s choice, then announce “There are no significant events reported at this time – returning to the main menu”, or similar.

54. In the 511 telephone service, allow the public to make selections by either voice commands or touchtone key presses.

55. Allow 511 callers using voice commands to say Skip, Back, Repeat, and Stop while listening to a list of incidents, slowdowns, or parking garage information. These commands cause the voice message to jump to the start of the next item, start of the previous item, start of the current item, or to return to the previous menu, respectively.

56. When the 511 telephone system first answers, it announces any incidents of type “disaster” before explaining the first level menu options.

57. The 511 phone system is built with sufficient capacity to avoid callers getting a busy tone 95% of the time.

58. The upgraded 511 web pages show a map and table views similar to those in the Regional Transportation Management Display, except the following information is not shown:

a. Traffic signals.

b. Incident whiteboard entries currently flagged as unsuitable for public viewing.

c. The name of agency personnel entering incident data.

d. Incidents of type “operations”.

e. The current location of buses (the public can see the location of light rail vehicles)

f. Video from cameras currently flagged as unsuitable for public viewing.

g. The public can view only one camera at a time and a camera stream automatically terminates, unless manually refreshed, after a time limit set by the video distribution system administrator

h. Cameras cannot be controlled by the public.

59. The 511 system uses the regional transit stops database and transit vehicle arrival time data from the transit agencies to allow a 511 web site user to obtain, for each nearby transit stop, for each vehicle, the service provider, route number, destination, and an indication as to whether the arrival time estimate is based on actual vehicle location data or only the scheduled arrival time.

60. The 511 web site and the Regional Transportation Management Display provide links to third party web sites providing travel related information useful to the operators and to the public (e.g., San Francisco Bay area 511 web site, National Weather Service, Office of Emergency Services, Caltrans District 3 chain control information website, US Geological Service stream gage information, etc.). The 511 web site also provides telephone numbers for travel information services, and explains the 511 interactive telephone service.

61. The 511 system makes continuous computer-to-computer data feeds available to third parties including commercial information service providers. These feeds are based on the NTCIP Center-to-Center XML standard. All data received by the 511 system are offered to third parties via this data feed.

62. The 511 system collects usage statistics.

63. The STARNET node interface includes a mechanism for counting the total number of messages transmitted and received to or from each other node. These data are used in STARNET evaluation and troubleshooting, and are readily accessed without resetting the cumulative counters.

64. The Regional Transportation Management Display system monitors the status of communications with each node (e.g., by sending “are you alive” requests when no message has been received from that node for a certain amount of time) and other appropriate health monitoring (e.g., reports from nodes of loss of communication with other nodes – if feasible). If a node is found to be unavailable or otherwise malfunctioning, the icon for that node on the regional display map changes color (e.g., to gray) to reflect this state, a message is sent to other nodes that have subscribed for such messages, the change in status is logged, and an e-mail or text message is sent to a maintenance person designated to currently receive such alerts. If no acknowledgement of the message is received within a certain time, a message is sent to a second person. The system allows different people to receive alerts at different times, according to work schedules.

65. STARNET is built with appropriate security measures and implemented in accordance with each agency’s network security policies.

66. System requirements are derived from these User Needs and are used in turn to produce system requirements and a high level design that are used in turn to procure the services of a system integrator.

67. The STARNET system integrator’s scope of work requires that training of agency personnel be conducted by effective trainers knowledgeable of the details of the STARNET system and its concept of operations, and that all materials, presentations, and demonstrations be specific to the STARNET environment and configuration.

68. The STARNET system integrator’s scope of work requires provision of comprehensive and effective documentation of all aspects of the system and related procedures.

69. Enable parts of STARNET to be added, upgraded, or replaced while the remainder of the system remains fully functional.

70. Provide system documentation, and especially interface documentation, which facilitate later addition of nodes to STARNET without requiring the involvement of the original system integrator.

71. Enable an operator to add new nodes to the list of known nodes.

72. Each STARNET agency provides on-going funding for the portion of STARNET for which that agency is responsible. SACOG is responsible for the Regional Transportation Management Display system (including regional incident tracker and shared video distribution server) and regional travel information system (511), and facilitates the cooperation of member and partner agencies as needed in maintaining these systems.

73. STARNET agencies jointly develop and adhere to operating procedures intended to make maximum use of STARNET’s capabilities with minimal disruption to other facilities and operations.

74. STARNET agencies agree to not release data from other agencies to third parties without the permission of the source agency.

75. Form a STARNET Technical Advisory Committee to advise the Sacramento Region ITS Partnership which in turn coordinates and advises the participating agencies in their management of the resources owned by each agency.

76. During peak travel times and during normal work hours, at least one experienced operator with a STARNET agency facilitates the use and maintenance of the Regional Transportation Management Display system, the 511 travel information system, and other components of STARNET. This includes activities such as the following:

a. Monitor a local radio station, emergency response voice radio traffic, and other information sources, for reports of relevant incidents. If not already done automatically or by an agency operator, create an incident in the Regional Transportation Management Display for significant incidents. Such incident reports are automatically made available to the public via the 511 system.

b. Monitor the progress of incidents currently reported on the Regional Transportation Management Display and update information if not done automatically or by an agency operator.

c. Identify duplicate incident records and communicate with involved operators to facilitate having such records appropriately merged.

d. Communicate with agency operators if needed to ensure relevant personnel are aware of major incidents or problems, and to help coordinate activities of all involved agencies.

e. Monitor the status of the Regional Transportation Management Display system and the 511 system to ensure all automated functions are operating correctly. This includes routinely looking at all material on all web pages produced by these systems and exercising all parts of the 511 interactive telephone service.

f. Receive and follow up on problems reported by system users. Provide real-time interactive help to agency operators upon request by telephone or e-mail. The 511 web site provides a non-real-time feedback facility whereby users can report problems, describe their experience with the system, and suggest improvements.

g. Investigate and diagnose problems found in the Regional Transportation Management Display and 511 systems.

h. Monitor the status of STARNET nodes, field devices critical for multi-agency cooperation, and STARNET communications, and report any problems to the agency responsible for the problem component.

i. Follow up on previously reported problems to help ensure corrective action is taken in a timely manner.

j. Provide advice and assistance to agency personnel involved in problem follow up.

k. Identify potential improvements in regional coordination procedures.

l. Identify corrections and updates needed to web pages including the regional map used in the Regional Transportation Management Display and in the 511 web site.

m. Maintain a database of all significant events, activities, feedback from the public and agency users, and other information relevant to any aspect of STARNET, the Regional Transportation Management Display system and the 511 system.

9 Evaluation Metrics

The following are potential measures of STARNET performance.

· Quantity of data exchanged per month.

· Number of operator access events per month – or data requests.

· Number of camera control actions.

· Number of subscriptions of each type.

· Completeness of the regional transportation database.

· Percentage of up time for the regional systems.

· Percentage of time that each node pair are able to communicate.

· Number of operation incidents per month in which STARNET played a role - divide into day types and time-of-day (e.g., peak periods), and duration/type of incident.

· Description of actual operation scenarios involving STARNET.

· Results of a survey of operators as to their experience with, and opinion of, STARNET.

· How many agencies are participating.

· How many multi-agency events.

· Number of 511 users.

The evaluation metrics and procedures for gathering and evaluating the information will be included in a separate STARNET Evaluation Plan developed during system implementation.

10 References and Terminology

10.1References

1. Intelligent Transportation Systems Strategic Deployment Plan for the Sacramento Region, September 2005, Sacramento Area Council of Governments.

2. STARNET Needs Assessment, November 2001, Sacramento Area Council of Governments.

3. Systems Engineering Guidebook for ITS, version 1.1, February 2005, Caltrans and Federal Highway Administration.

4. Guide for the Preparation of Operational Concept Documents, 1992, American National Standards Institute / American Institute of Aeronautics and Astronautics.

5. Implementation and Operation Guidelines for 511 Services, 2005, 511 Deployment Coalition.

10.2Terminology

The following table defines acronyms and uncommon terms used in this document.

Term	Meaning
ATMS	Advanced Traffic (or Transportation) Management System
Caltrans	California Department of Transportation
CAD	Computer Aided Dispatch system that records incident information
CCTV	Closed Circuit Television
CHP	California Highway Patrol
FHWA	Federal Highway Administration
FTP	File Transfer Protocol
ISDN	Integrated Services Digital Network – a data communications service offered by telephone companies
ITS	Intelligent Transportation Systems
Jitter	Variation in the travel time of data packets on a network due to changes in conditions such as the available bandwidth, congestion at network switches, or routing of packets.
RT	Sacramento Regional Transit District
SACOG	Sacramento Area Council of Governments
Spoofing	The falsification or misdirection of information on a network so that the information appears to have originated from someone or somewhere other than the actual source.
STARNET	Sacramento Transportation Area Network
Validation	Evaluation of degree to which a planned outcome was achieved. Validation of STARNET involves evaluating how well it achieved its purpose.

-oOo-