*STARNET
Version 1.0
Prepared for the Sacramento Area Council of Governments
and associated agencies in the Sacramento region
by Siemens ITS
*STARNET
Version 1.0
Prepared for the Sacramento Area Council of Governments
and associated agencies in the Sacramento region
by Siemens ITS
|
Document Description |
Date |
Version Number |
|
First draft for review |
August 9, 2006 |
0.1 |
|
Incorporated comments |
October 29, 2007 |
2.0 |
|
|
|
|
|
|
|
|
|
|
|
|
2 Purpose of System Requirements
3 Assumptions Behind the System Requirements
3.1 Use of the System Requirements
3.4 Computer Systems to be Integrated
3.5 CCTV Cameras to be Integrated
Figure 1 - Major Data Flows in STARNET
Figure 2 - Map of the Sacramento Region
The Sacramento Transportation Area Network, or STARNET, is an information exchange network 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. It will thereby assist operations personnel in the coordination of their activities and in providing the public with comprehensive information about current travel conditions and options.
This System Requirements document presents high-level requirements to be used in procuring system integration services for the initial STARNET deployment. System requirements were derived from User Needs described in the document titled STARNET Concept of Operations. The User Needs were in turn derived from the operation scenarios also described in the STARNET Concept of Operations. The reader is advised to review the operation scenarios to gain an understanding of the goals and context of STARNET.
This document has the following objectives:
· Explain the purpose, and plans for evolution, of the system requirements.
· Present the system requirements.
· Explain the assumptions behind the system requirements.
· Explain terminology used in the system requirements.
Initially, the system requirements provide guidance to firms responding to the Request for Proposals for integration services for the initial STARNET deployment. During negotiations with the selected firm, it is expected that requirements will change some what to reflect the specifics of the chosen solution. The modified system requirements document will form part of the initial system integration contract agreement.
During STARNET deployment, the requirements will be changed if needed to reflect any changes found necessary during implementation. Later versions or extensions of the system requirements will be used to define subsequent enhancements to STARNET.
Terms used in this section, and in the system requirements table, are defined and explained in the Terminology section of this document.
These initial system requirements will be used in the Request for Proposals for integration services for the initial STARNET deployment. As such, they represent desired functionality that may not be fully achievable within the constraint of funding available for the initial deployment. Firms responding to the Request for Proposals will state the extent to which they can or cannot meet each requirement given the project’s funding, additional functionality that may be useful but not requested, and an alternative architecture or approach that achieves similar functionality more economically or practically. Such information will enable selection of the most valuable proposal, and will form the basis of contact negotiations, including negotiation of a refined set of system requirements to which the contractor will be held during implementation.
The concept of operations is fully described in the STARNET Concept of Operations. The description here provides only a brief overview.
Public agencies in the Sacramento urban area will exchange real-time information among themselves to facilitate improved coordination, and therefore effectiveness, of their transportation and emergency response activities. These agencies will also provide relevant real-time information to travelers via the region’s 511 travel information distribution system.
As illustrated in Figure 1, real-time information will be extracted from the various computer systems operated by the involved agencies and appropriate portions thereof will be sent to a Regional Transportation Management Display system, the 511 travel information system, and the SACOG Transportation Planning Database. Some information will also be sent to peer systems operated by other agencies. The information transmitted will include data and streaming live video.
The following are the categories of different users or consumers of the transmitted information. A STARNET organization is one that directly provides or consumes exchanged information. Non-STARNET organizations may obtain a one-way feed of selected information from the 511 travel information system.
· Operators in STARNET organizations
· Computers operated by STARNET organizations
· Computers operated by non-STARNET organizations
· Planners at SACOG
· The public
Operators in STARNET organizations will use the Regional Transportation Management Display to view data and video describing current conditions, and to enter information about current incidents and planned events. Computers operated by STARNET organizations will use real-time information to make decisions, alert operators, and take automatic actions in support of more efficient transportation system operation and emergency response. Computers operated by non-STARNET organizations may use real-time data for various purposes such as enhanced travel information distribution services, transportation research, and transportation system performance monitoring. Planners at SACOG (the Sacramento Area Council of Governments) will use historical data gathered in the Transportation Planning Database to measure the transportation system’s past performance and to predict its future performance. The public will use real-time travel information (data and video) to gain knowledge of current travel conditions, to make decisions about the time, mode, and route of travel, and to estimate and inform others of their likely time of arrival.
Figure 1 - Major Data Flows in STARNET
The following map illustrates the area of interest for the initial deployment of STARNET. The area will likely expand in the future.
Figure 2 - Map of the Sacramento Region
The initial implementation of STARNET will involve the computer systems described in Table 1.
Table 1 - Computer Systems to Serve as a Data Source or Sink
|
Host System |
Status |
Data |
Host System Interface |
|
California Highway Patrol, Computer Aided Dispatch system (http://cad.chp.ca.gov) |
Existing |
Source for roadway incident data. |
XML via FTP with RSS notification of changes. |
|
Sacramento Regional Fire/EMS Communications Center, Computer Aided Dispatch system (Northrop Grumman COBOL CAD). |
Existing |
Source for incident data |
Database read. |
|
Yolo County Communications Emergency Service Agency, Computer Aided Dispatch system (Northrop Grumman Altaris CAD) |
Existing, but may change |
Source for incident data |
Database read. |
|
City of Sacramento Police Computer Aided Dispatch System |
Existing |
Source for incident data. |
XML. |
|
County of Sacramento Lane Closure System |
Existing |
Source for planned and unplanned lane closure data (treated as incidents). |
HTML files available on Internet via HTTP. |
|
Caltrans Lane Closure System |
Existing |
Source for planned lane closure data (treated as incidents). |
ASCII file freely available on the Internet via HTTP (http://www.dot.ca. gov/travel/dist_03/lcs/ lane_closures_d3_xy .txt) |
|
|
|
|
|
|
Caltrans District 3, Advanced Traffic Management System (ATMS) |
Existing |
Source for static data defining ramp meters, and CMS on freeways, & changeable message sign data. |
ASCII files freely available on the Internet via HTTP (e.g., http://www.dot.ca. gov/travel/dist_03/ webinit.txt) |
|
Caltrans, Performance Measurement System (PeMS - http://pems.eecs.berkeley.edu) |
Existing |
Source for static data defining detector stations on freeways. |
XML file freely available on the Internet via HTTP. |
|
Caltrans, Performance Measurement System (PeMS - http://pems.eecs.berkeley.edu) |
Existing |
Source for five minute processed loop detector data (volume, occupancy, speed) for freeways. |
Comma delimited ASCII file freely available on the Internet via FTP. |
|
Caltrans District 3, Front End Protocol Translator (FEPT). |
Existing |
Source for freeway ramp meter data. |
RPC-based. |
|
|
|
|
|
|
Sacramento Regional Transit District, Central Train Tracking system |
Existing |
Source for LRV location data. |
SQL Server database query (e.g., indexed view). |
|
Sacramento Regional Transit District, Incident Tracking System |
In development by Regional Transit (RT) |
Source for RT service disruption incidents |
SQL Server database query (e.g., indexed view). |
|
Sacramento Regional Transit District (RT), Ridership Statistics System |
Existing |
Source for RT ridership statistics |
SQL Server database query (e.g., indexed view). |
|
Yolo County Transit Management System |
Existing |
Source of incident and ridership statistics data. |
SQL database query. |
|
El Dorado County Transit Management System |
Existing |
Source of incident and ridership statistics data. |
Incidents via e-mail. Ridership statistics via database read. |
|
|
|
|
|
|
Sacramento County, VMS 330 traffic signal systems |
Existing |
Source for traffic signal and detector data. |
Via the VMS 330 Proxy Server - format to be determined. |
|
Sacramento County, ACTRA traffic signal system |
Existing |
Source for traffic signal and detector data, and signal commands. Sink for detector data and signal commands. |
XML – based on NTCIP 2306 + TMDD.. |
|
City of Sacramento, TransSuite traffic signal system |
Existing |
Source for traffic signal and detector data, and signal commands. Sink for detector data and signal commands. |
XML – based on NTCIP 2306 + TMDD. |
|
City of Roseville, ATMS Now traffic signal system |
Existing |
Source for traffic signal and detector data. Sink for detector data. |
XML or SQL database |
|
City of Elk Grove, ATMS Now traffic signal system |
Existing |
Source for traffic signal and detector data. Sink for detector data. |
XML or SQL database |
|
City of Citrus Heights, traffic signal system |
Existing |
Source for traffic signal and detector data. Sink for detector data. |
XML or SQL database |
|
|
|
|
|
|
City of Sacramento, Parking Management System |
Existing |
Source for parking garage occupancy data. |
To be determined – assume database read. |
|
|
|
|
|
|
SACOG Transportation Planning Database |
Existing |
Sink for many data. |
To be determined – assume XML push. |
|
SACOG, Regional Transportation Management Display system (aka Regional Display) |
To be provided by STARNET integrator |
Source for incident data. Sink for most data. |
To be determined by the STARNET integrator |
|
SACOG, 511 Telephone System |
To be provided by others. |
Sink for incidents, slowdowns and parking data. |
To be determined. Assume XML push. |
|
Third Party Data Feed server. |
To be provided by STARNET integrator |
Sink for most data. |
To be determined by the STARNET integrator. |
The initial implementation of STARNET will involve providing operators (via the Regional Display web-browser-based interface) and the public (via the 511 web site) live streaming video from closed circuit television cameras as follows.
Table 2 CCTV Cameras to be Integrated
|
Agency |
Type of Camera |
Approx. No. of Cameras Mid 2007 |
Interface Information |
|
Caltrans District 3 |
Cohu analog Pan Tilt Zoom |
20 |
Windows Media Services |
|
Sacramento County |
Cohu analog Pan Tilt Zoom |
44 |
Motion JPEG and Windows Media Services |
|
City of Sacramento |
Analog Pan Tilt Zoom |
30 |
Analog and TBD |
|
Roseville |
IVC 3130-LL-NCS digital Pan Tilt Zoom with integral Axis encoder |
70 |
Motion JPEG and MPEG-4 |
|
Citrus Heights |
Cohu analog Pan Tilt Zoom |
5 |
Analog |
|
Elk Grove |
IVC 3130-LL-NCS digital Pan Tilt Zoom with integral Axis encoder |
1 |
Motion JPEG and MPEG-4 |
|
Regional Transit |
Fixed |
20 (of use to other agencies) |
MPEG-4 |
The initial system requirements are a compromise between high-level functional descriptions that make no assumptions about the physical or even logical architecture of the implemented system, and more detailed functional descriptions that assume a certain logical architecture, if not a physical one. The system integrator will derive more detailed requirements once the final architecture and design are chosen.
In order to adequately describe the intended functionality, some requirements imply a particular logical architecture. To address issues of component ownership, operation, and maintenance, some aspects of the physical architecture have also been assumed. Such architectural assumptions are not intended to constrain the creativity and offerings of prospective system integrators, who will be free to suggest alternative approaches that still satisfy the basic concepts and needs described in the STARNET Concept of Operations.
The System Requirements assume that the computer systems involved in STARNET are interconnected in a logical many-to-many network. Any computer system can obtain data directly from any other computer system. There is no hierarchy or centralization. However, not all computer systems have the same data available nor the same use for data from other systems. Therefore, at least initially, data will not flow between all computer systems, as illustrated in Table 1 above.
The System Requirements assume that a computer system can establish a persistent request (subscription) with any other computer system to have real-time data automatically sent (published) either periodically or upon change. Hence data can flow continuously and without human involvement, other than configuration of subscriptions. A computer system may choose to reject a subscription so that agencies maintain control of what data are allowed to flow to what other computer systems.
Figure 3 - STARNET Gateways
Each STARNET node is logically comprised of a “host system” and a “gateway”. The gateway provides STARNET interface functionality, including management of subscriptions and publications, and translation between STARNET and host system data formats and communication protocols. The host system provides the remainder of the functionality of that node. For existing host systems, the gateway will be provided by the STARNET system integrator and will likely function on a new computer separate from any computer used by the existing host system. For new host systems being provided by the STARNET integrator (e.g., Regional Transportation Management Display system, and 511 system), the gateway may be integral with the host system. Figure 3 illustrates this architectural concept, of all nodes having at least a logical gateway. The gateways communicate with each other using a single standard protocol and message set. On the other hand, each node may use a different protocol and message set for “internal” communications between its gateway and its host system.
The term “object” is used to refer to any entity for which data are exchanged via STARNET. Examples of objects include traffic signals, vehicle detector stations, light rail vehicles, incidents, nodes, etc. Among other things, all objects have a location (e.g., latitude and longitude), and an owner. The owner of an incident is the name of the agency of the operator that created the incident record in the Regional Transportation Management Display system (if created manually) or the name of the source node, in the case of incident records created automatically by the Regional Transportation Management Display system.
A “message” in the context of data communications, is a predefined, structured set of data passed between computer systems. The intent is for node-to-node communications to use standard messages, such as those defined by the Traffic Management Data Dictionary (TMDD) and IEEE Standard for Common Incident Management Message Sets for Use by Emergency Management Centers (IEEE 1512), where feasible. The data actually included within a particular transmittal may be a subset of the data allowed for in the standard structure for a particular message type, as many fields are optional. Due to dependence on legacy interfaces, communications between a host system and its STARNET gateway will likely have to use different messages, or other data transfer techniques, than those used between nodes. The gateway will translate.
The system requirements table has the following columns:
· Grouping – A heading indicating the type of requirements in a group.
· Requirement Number – A unique number assigned to each requirement and preceded by the letters SR – for example, SR-123.
· Requirement Text – A formal and concise description of the requirement.
· User Need – The User Need(s) from which the requirement is derived.
· Priority – The implementation priority assigned to the requirement (High, Medium, Low).
The requirement number provides a unique identifier which serves as a shorthand means of referring to a particular requirement.
The requirement priority reflects the importance of this requirement to the stakeholders. Lower priority implies that the stakeholders put less value on the requirement and are more amenable to the requirement not being met or only partially met.
Table 3 STARNET System Requirements
|
Grouping |
No. |
Requirement |
User Need |
Priority |
|
DEFINITIONS |
SR-1 |
In addition to object-specific definitions in other requirements, objects of all types, data available from the source node shall include the following universal data: object type, identifier, owner (agency), location (lat/long), location description (including direction where relevant), and date/time of last update; except that light rail vehicles and buses shall not have a location description. |
UN-3 |
High |
|
|
SR-2 |
When timestamps are unavailable from the host system, the gateway nearest the source system shall provide the timestamp. |
UN-3 |
High |
|
|
SR-3 |
Objects types shall include: incidents, vehicle detectors stations, traffic signals, CCTV cameras, changeable message signs, ramp meters, parking garages, light rail vehicles, buses and STARNET nodes. |
UN-3 |
High |
|
Vehicle Detector Data Definition |
SR-4 |
Vehicle detector data shall include count (by class), average occupancy, average speed, detector health (e.g., OK, suspect, soft failed, hard failed, disabled, and no response), and the time period for which the data applies, as available from the host system. |
UN-3 |
High |
|
SR-5 |
Vehicle detector data shall be available per detector per lane and per station, as available from the host system. A station is defined as an aggregation of available data from all lanes in a particular direction at a particular location. |
UN-3 |
High |
|
|
Slowdown Data Definition |
SR-6 |
Slowdown data shall include the route, beginning and ending (if more than one station is involved) extents, the average speed across the stations, and the time of last update. The components of universal data are not applicable to Slowdown data. |
UN-58 |
High |
|
Traffic Signal Data Definition |
SR-7 |
Traffic signal data shall include operating mode, basic timing parameters, and pattern commands, as available from the host system. |
UN-3 |
High |
|
|
SR-8 |
Traffic signal operating modes shall include the following: off-line, flash due to failure, police manual control, police flash, programmed flash, preempt, priority, standby, free, and coordinated. |
UN-3 |
High |
|
|
SR-9 |
Traffic signal current basic timing parameters shall include the following: plan or pattern number, cycle length if coordinated, offset if coordinated, and phase sequence if coordinated. |
UN-3 |
High |
|
|
SR-10 |
Traffic signal pattern commands shall consist of a request to implement a certain pattern at selected signals at another traffic signal node. |
UN-3 |
High |
|
SR-11 |
Ramp meter data shall include ramp meter status and metering rate, as available from the host system. |
UN-3 |
Medium |
|
|
|
SR-12 |
Ramp meter states shall include the following: out of service, in service but not currently metering, and currently metering; as available from the host system. |
UN-3 |
Medium |
|
CMS Data Definition |
SR-13 |
Changeable message sign data shall include sign status and message content, as available from the host system. |
UN-3 |
High |
|
|
SR-14 |
Sign states shall include out of service, in-service but blank, displaying a routine message (e.g., travel time or Buckle Up), and displaying a non-routine (e.g., incident) message; as available from the host system. |
UN-3 |
High |
|
Incident Data Definition |
SR-15 |
Incident data shall include: incident type, incident description, impact (none, low, moderate, high, highest), incident record creation data/time, route, direction, area, start date/time (and whether estimated or actual), end date/time (and whether estimated or actual), 511 phone message, 511 phone announce time, whiteboard entries, and creator's name, as available from the host system. For an incident, the object location (lat/long) determines the location of the icon on the map. |
UN-3 |
High |
|
|
SR-16 |
Incident types shall include the following: roadway incident, transit incident, disaster, planned event, planned road changes, truck restriction, operations and test. |
UN-3 |
High |
|
Ridership Statistics |
SR-17 |
Ridership Statistics data shall include: unlinked passenger trips, passenger miles and average trip length as available from the host system. |
UN-3 |
|
|
Parking Garage Data Definition |
SR-18 |
Parking garage data shall include the percentage filled and the number of spaces available, hours of operation, currently open/closed, as available from the host system. |
UN-3 |
High |
|
Light Rail Vehicle Data Definition |
SR-19 |
Light rail vehicle data shall include the route, line, destination, number of cars in the train, in service indicator, passenger counts, and speed, as available from the host system. |
UN-3, UN-60 |
High |
|
Bus Vehicle Data Definition |
SR-20 |
Bus vehicle data shall include the route, destination, in service indicator, passenger counts, and speed, as available from the host system. |
UN-3 |
High |
|
Camera Data |
SR-21 |
Camera data shall include: whether the camera is available for viewing, cut from public feed, the control status, ID of the current (most recent) operator and two previous most recent operators within the last “x” number of seconds, where “x” is a system configurable parameter. |
UN-3 |
High |
|
|
SR-22 |
The control states shall consist of: no control, out of service, no permission, in use, locked-override available, and locked. |
UN-3 |
High |
|
|
SR-23 |
A camera shall be considered "in use" if a camera control request has been sent to the camera in the last "y" seconds, where as "y" is a system configurable parameter. |
UN-3 |
High |
|
|
SR-24 |
Video feed configuration data shall consist of setting the frame rates, video quality levels, image size and bandwidth for the video streams. |
UN-54 |
High |
|
Operator Permissions |
SR-25 |
Operator permissions shall indicate whether a particular operator can control and/or view video from a specific camera, and whether the user can create, edit and delete incidents, whether the user can view the Regional Display User Interface, and the date/time of last update. The components of universal data are not applicable to operator permissions. |
UN-54 |
High |
|
Node Status |
SR-26 |
Node status shall include whether the node is communicating with all nodes, non-communicating with at least one node with no maintenance response, and non-communicating with at least one node with a maintenance response. |
UN-68 |
High |
|
PUBLISHERS |
SR-27 |
Gateways shall obtain and publish changed data (not video feeds) within two (2) seconds of such changed data being available in the host system. |
UN-3 |
Medium |
|
Vehicle Detector Data Publishers |
SR-28 |
Vehicle detector data shall be available from nodes operated by the following agencies: Caltrans District 3 (Performance Management System PeMS); the County of Sacramento signal system; the County of Sacramento weigh-in-motion system; the Cities of Citrus Heights, Elk Grove, Folsom, Roseville, and Sacramento. |
UN-1 |
High |
|
Traffic Signal Data Publishers |
SR-29 |
Traffic signal data shall be available from nodes operated by the following agencies: the County of Sacramento; the Cities of Citrus Heights, Elk Grove, Roseville, and Sacramento. |
UN-1 |
High |
|
Ramp Metering Data Publisher |
SR-30 |
Ramp meter data shall be available from a node operated by Caltrans District 3. |
UN-1 |
Medium |
|
CMS Data Publishers |
SR-31 |
Changeable message sign data shall be available from nodes operated by Caltrans District 3 and the County of Sacramento. |
UN-1 |
High |
|
Incident Data Publishers |
SR-32 |
Incident data shall be available from the Regional Display node and nodes operated by the following agencies: California Highway Patrol (incident xml feed), Sacramento Regional Transit District (service disruptions), Yolo County Transportation District (service disruptions), Sacramento Regional Fire/EMS Communications Center (computer aided dispatch system), Sacramento County Lane Closure Database, the City of Sacramento Police (computer aided dispatch system) Caltrans (lane closure system), and Yolo County Communications Emergency Service Agency (computer aided dispatch system). |
UN-1 |
High |
|
Slowdown Publisher |
SR-33 |
Slowdown data shall be available from the Regional Display node. |
UN-58 |
High |
|
Light Rail Vehicle Data Publisher |
SR-34 |
Light Rail Vehicle data shall be available from a node operated by Sacramento Regional Transit District. |
UN-1 |
High |
|
Bus Data Publisher |
SR-35 |
Bus data shall be available from nodes operated by El Dorado County Transit Authority and Yolo County Transportation District. |
UN-1 |
High |
|
Camera Data Publisher |
SR-36 |
Camera data shall be available from the following agencies: Caltrans District 3; the County of Sacramento; the Cities of Citrus Heights, Elk Grove, Sacramento Regional Transit, Roseville, and Sacramento. |
UN-1 |
High |
|
Video Feed Sources |
SR-37 |
Video shall be available from the following agencies: Caltrans District 3; the County of Sacramento; the Cities of Citrus Heights, Elk Grove, Sacramento Regional Transit, Roseville, and Sacramento. |
UN-1 |
High |
|
Video Feed Configuration Publisher |
SR-38 |
Video Feed Configuration data shall be available from the Regional Display node. |
UN-54 |
High |
|
Operator Permissions Publisher |
SR-39 |
Operator Permissions shall be available from the Regional Display node. |
UN-54 |
High |
|
Parking Garage Data Publishers |
SR-40 |
Parking garage data shall be available from a node operated by the City of Sacramento. |
UN-1 |
High |
|
Ridership Statistic Data Publishers |
SR-41 |
Ridership statistic data shall be available from nodes operated by Sacramento Regional Transit District, El Dorado Transit District, and Yolo County Transportation District. |
UN-1 |
High |
|
511 Data Feed Publications |
SR-42 |
The 511 data feed shall publish the following data, as received and permitted: incident, vehicle detector, bus, light rail vehicle, traffic signal, ramp meter, changeable message sign, parking garage, and ridership statistics. This is for the purpose of third party (non STARNET) organizations. |
UN-63 |
High |
|
Non communicative Node Publications |
SR-43 |
All nodes that detect a non-communicative node shall publish a list of non-communicative nodes. |
UN-68 |
High |
|
SUB-SCRIPTIONS |
SR-44 |
An agency shall be able to subscribe to any available data from any other node. |
UN-38 |
High |
|
Regional Display Subscriptions |
SR-45 |
The Regional Display shall subscribe to the following data from all nodes publishing such data: incident, vehicle detector, light rail vehicle, bus, traffic signal, ramp meter, changeable message sign, parking garage, camera, and nodes. |
UN-59 |
High |
|
SACOG Transportation Planning Database Subscriptions |
SR-46 |
The SACOG Transportation Planning Database Gateway shall subscribe to the following data from appropriate nodes publishing such data: incident (from Regional Display), vehicle detector, traffic signal, ramp meter, and transit ridership statistics. |
UN-2, UN-3 |
High |
|
511 Telephone System Subscriptions |
SR-47 |
The 511 telephone system gateway shall subscribe to the following data from appropriate nodes publishing such data: incidents (from Regional Display), parking garage, and slowdowns. |
UN-1, UN-3, UN-33, UN-58 |
High |
|
Traffic Signal System Gateway Subscriptions |
SR-48 |
The gateways located at the following agencies: the County of Sacramento; the Cities of Citrus Heights, Elk Grove, Roseville, and Sacramento, shall be able to subscribe for vehicle detector data and translate such data so that it can be received and used by the host traffic signal system. |
UN-3 |
High |
|
|
SR-49 |
The gateways located at the following agencies: the County of Sacramento and the City of Sacramento, shall be able to subscribe for pattern command requests and translate the pattern command request so that it can be received and acted upon by the host traffic signal system. |
UN-3 |
High |
|
Video System Subscriptions |
SR-50 |
The gateways located at the follow agencies: Caltrans District 3; the County of Sacramento; the Cities of Citrus Heights, Elk Grove, Roseville, and Sacramento, shall subscribe to Video Feed Configuration data and Operator Permissions data from the Regional Display. |
UN-54 |
High |
|
|
SR-51 |
Camera control commands shall be sent to the following agencies: Caltrans District 3; the County of Sacramento; the Cities of Citrus Heights, Elk Grove, Roseville, and Sacramento. |
UN-45 |
High |
|
COMMUNI-CATIONS |
SR-52 |
Agency-supplied communication links shall be configured to enable all required: node-to-node data communications; video stream acquisition and distribution; and Internet access for operators, 511 web page users, and users of the 511 data feed for third parties. |
UN-5 |
High |
|
REGIONAL DISPLAY & 511 WEB PAGE - GENERAL |
SR-53 |
Upon an operator entering the Regional Display URL in a web browser, a login page shall be displayed. The public does not have access to the Regional Display. |
UN-8, UN-9, UN-10 |
High |
|
|
SR-54 |
Upon an operator's successful login, a top-level view of a map of the STARNET area shall be displayed on the Regional Display. The 511 web page does not require a user to log in. |
UN-2, UN-7 |
High |
|
|
SR-55 |
STARNET shall provide the dynamic elements, which contain a map and transportation data similar to the Regional Display user interface, to be included in the 511 web page developed by SACOG. |
UN-57, UN-59 |
High |
|
|
SR-56 |
The Regional Display and 511 web page dynamic elements shall be accessible using popular web browsers including Internet Explorer and Firefox. |
UN-9, UN-59 |
High |
|
|
SR-57 |
Plug-ins, if necessary for the Regional Display and 511 web page dynamic elements, shall be free and downloadable. |
UN-9 |
High |
|
|
SR-58 |
The Regional Display shall provide links to third party web sites. |
UN-62 |
High |
|
|
SR-59 |
A Regional Display Administrator shall be able to add, edit, and delete links to third party web pages on the Regional Display. |
UN-62 |
High |
|
|
SR-60 |
Operators of the Regional Display shall be able to view a list of all currently logged in operators. |
UN-32 |
High |
|
|
SR-61 |
If feasible, the Regional Display system shall provide traffic signal timing and street geometry in a uniform format such as that used in signal timing analysis software such as SynchroTM. |
UN-42 |
Low |
|
Map |
SR-62 |
The map displayed on the Regional Display and 511 web page dynamic elements, shall include all freeways, streets, city boundaries, and light rail tracks within the STARNET region. |
UN-3 |
High |
|
|
SR-63 |
The map on the Regional Display and 511 web page dynamic elements shall have pan and zoom capabilities, preferably using techniques similar or superior to Google MapsTM. |
UN-11, UN-59 |
High |
|
|
SR-64 |
The map shall include an aerial photo background, comparable in quality and currency as Google Maps, that users can turn on or off. |
UN-12, UN-59 |
Medium |
|
|
SR-65 |
Map users shall be able to access a legend such as by clicking a legend button. |
UN-19 |
High |
|
|
SR-66 |
The legend shall explain the icon color and shape codes for the various information types. |
UN-19 |
High |
|
|
SR-67 |
The legend shall be contained in a separate window and the user can leave the floating legend window visible or close it. |
UN-19 |
Medium |
|
Objects on map |
SR-68 |
Objects of the following types shall be shown as selectable icons and in table format on the Regional Display map: incidents, vehicle detectors stations, traffic signals, CCTV cameras, changeable message signs, ramp meters, parking garages, light rail vehicles, buses and STARNET nodes. |
UN-2, UN-13 |
High |
|
|
SR-69 |
The following objects shall be shown as selectable icons and in table format in the 511 web page dynamic elements: incidents, vehicle detector stations, CCTV cameras (without camera control), changeable message signs, ramp meters, parking garages, buses and light rail vehicles. |
UN-13, UN-59 |
High |
|
|
SR-70 |
Each table shall display all available object data for all instances of a particular object type. |
UN-14 |
High |
|
|
SR-71 |
In the table view, all columns (fields) shall be sortable. |
UN-15 |
High |
|
|
SR-72 |
Table views shall be scrollable to allow the users to see all rows and columns. |
UN-14 |
High |
|
|
SR-73 |
Table windows shall be resizable. |
UN-14 |
Medium |
|
|
SR-74 |
Upon clicking on a table row, a pop-up window shall reveal all available details relevant to that specific object, the same as shown when selecting an icon on the map. See SR-1 through SR-16 for the definition of the "details" relevant to each specific object. |
UN-18 |
Medium |
|
|
SR-75 |
Through automatic generation of one time subscriptions, or other means, the Regional Display shall become aware of an unusual cessation of object reporting and shall report the object as unavailable when appropriate. The intent is to avoid presenting misleading information due to, for example, failure of a field device or its communications link. |
UN-21 |
High |
|
ICONS |
SR-76 |
Dynamic data shown on an operator's instance of the Regional Display and the user’s instance of the 511 web page dynamic elements shall be automatically updated, without changing the operators scrolled or zoomed position within the page, within 10 seconds of changed data becoming available at the web server. |
UN-17, UN-59 |
High |
|
|
SR-77 |
Different icons shall be used for different types of objects and types of incidents. |
UN-17, UN-59 |
High |
|
|
SR-78 |
A Regional Display operator or 511 web page user shall be able to turn on and off icons on their map display by object type. |
UN-17, UN-59 |
High |
|
|
SR-79 |
A Regional Display operator or 511 web page user shall be able to turn on and off incident icons on their map display by status (future, active, and past). |
UN-17, UN-59 |
High |
|
|
SR-80 |
A Regional Display operator or 511 web page user shall be able to turn on and off incident icons on their map display by type. |
UN-20 |
High |
|
|
SR-81 |
A mouse-over or selecting an object icon on the map display shall reveal all data available regarding that object, except for incident icons. |
UN-16, UN-18 |
Medium |
|
|
SR-82 |
A mouse-over an incident icon on the map display shall review the 511 message, selecting an object icon on the map display shall reveal all data available regarding that object. |
UN-16 |
High |
|
Light Rail Vehicle - Icon |
SR-83 |
Light rail vehicle icons in the map view and corresponding text in the light rail vehicle table view shall be color coded to indicate the vehicle's (train) destination (route). There are four different destinations/routes. |
UN-17, UN-60 |
High |
|
|
SR-84 |
Light rail vehicles shall not appear as icons in the map view or in the light rail vehicle table view when they are out of service. |
UN-13 |
High |
|
|
SR-85 |
A Regional Display administrator shall be able to configure the icon/text color codes for the light rail destinations (routes). |
UN-17, UN-60 |
Medium |
|
Bus- Icon |
SR-86 |
Bus vehicle icons in the map view and corresponding text in the bus table view shall be color coded to indicate the vehicle's owner. |
UN-17, UN-61 |
High |
|
|
SR-87 |
Bus vehicles shall not appear as icons in the map view or in the bus table view when they are out of service. |
UN-13 |
High |
|
|
SR-88 |
A Regional Display administrator shall be able to configure the icon/text color codes for the bus owners. |
UN-17 |
Medium |
|
Node - Icon |
SR-89 |
Each STARNET node icon in the map view and corresponding text in the node table view shall be color coded to indicate that the node is communicating with all nodes, non-communicating with at least one node with no maintenance response, and non-communicating with at least one node with a maintenance response. |
UN-17, UN-68 |
High |
|
|
SR-90 |
A Regional Display administrator shall be able to configure the icon/text color codes for the STARNET node communication status. |
UN-68 |
Medium |
|
Vehicle Detector Station - Icon |
SR-91 |
Vehicle detector station icons in the map view and corresponding text in the detector table view shall be color coded with four color codes representing four average speed ranges and a fifth color representing that data are unavailable. |
UN-17, UN-59 |
High |
|
|
SR-92 |
A Regional Display administrator shall be able to configure the icon/text color codes for detector speed/status. |
UN-17, UN-59 |
Medium |
|
|
SR-93 |
A Regional Display administrator shall be able to configure the vehicle detector speed ranges. |
UN-17, UN-59 |
Medium |
|
Incident - Icon |
SR-94 |
Both incidents automatically created and those manually created or modified via the Regional Display's incident editor, shall be displayed on the Regional Display and 511 web page dynamic elements. |
UN-13 |
High |
|
|
SR-95 |
Incidents of the types "operations" and "test" shall be excluded from the 511 web page dynamic elements, 511 phone system and Third Party Data Feed. |
UN-59 |
High |
|
|
SR-96 |
Incident icons in the map view and corresponding text in the incident table view, shall be color coded to distinguish future, active, and past incidents, based on the Start and End times. |
UN-17, UN-59 |
High |
|
|
SR-97 |
Incident icons in the map view and corresponding text in the incident table view, shall flash (or be otherwise distinguishable) if the incident is both active (Start time is flagged as "actual" and is in the past, and End time is not flagged as "actual" or is in future) and the impact is set to "high" or "highest". |
UN-17, UN-59 |
High |
|
|
SR-98 |
In addition to the icon automatically assigned to every incident, an operator creating or editing an incident record shall be able to create and position a polyline or transparent filled polygon (fill color is operator choice) that shows on the Regional Display map, and which also serves as a clickable link to incident information in the same way as the normal incident icon. |
UN-27 |
Medium |
|
|
SR-99 |
The icon in the map view and text in the incident table view, for future "incidents", shall be color coded based on the whether the incident is scheduled to begin in the far future, near future (such as commencing in two days) or impending future (such as commencing in two hours). |
UN-17, UN-59 |
Medium |
|
|
SR-100 |
A Regional Display administrator shall be able to configure the time thresholds defining near future and impending future incidents. |
UN-17, UN-59 |
Medium |
|
|
SR-101 |
A Regional Display administrator shall be able to configure the icon/text color codes for displaying near future and impending future incidents (e.g., shades of the color assigned to "future" incidents). |
UN-17, UN-59 |
Medium |
|
Changeable Message Sign - Icon |
SR-102 |
Changeable message sign icons in the map view and text in the sign table view shall be color coded to indicate the sign's current status (see Definitions above). |
UN-17, UN-59 |
High |
|
|
SR-103 |
A Regional Display administrator shall be able to configure the icon/text color codes for displaying sign status. |
UN-17, UN-59 |
Medium |
|
Traffic Signal - Icon |
SR-104 |
Traffic signal icons shall be color coded to indicate the operating mode (see Definitions above). |
UN-17 |
High |
|
|
SR-105 |
A Regional Display administrator shall be able to configure the icon/text color codes for indicating traffic signal operating mode. |
UN-17 |
Medium |
|
CCTV - Icon |
SR-106 |
CCTV camera icons shall be color coded to indicate whether the camera/feed is; not available, available for viewing only, available (to this operator) for viewing and control. |
UN-17, UN-59 |
High |
|
|
SR-107 |
Upon selection of a CCTV camera icon or table row, a pop-up window shall open displaying a streaming live video feed from that camera. |
UN-6, UN-43 |
High |
|
Parking Garage- Icon |
SR-108 |
Parking garage icons shall be color coded to indicate whether the garage is: closed, and greater/less than x percent filled. |
UN-17, UN-59 |
High |
|
|
SR-109 |
A Regional Display administrator shall be able to configure the icon/text color codes for indicating parking garage icon color codes and percentages. |
UN-17 |
High |
|
|
SR-110 |
Upon selection of a Parking Garage icon or table row, a pop-up window shall open displaying all data available for that garage. |
UN-17, UN-59 |
High |
|
All Icons |
SR-111 |
"Not shown" shall be an optional "color" for all system configurable color codes for all objects. If this option is selected, the icon/text does not appear when the object is in the associated state. |
UN-17, UN-59 |
Medium |
|
|
SR-112 |
Color codes for icons and text shall be independently configurable for the Regional Display and 511 web page dynamic elements. |
UN-17 |
High |
|
CAMERA CONTROL |
SR-113 |
Upon selection of the CCTV camera icon, or table row, from the Regional Display a camera control dialog will appear, provided the operator has permission to control that camera and the camera currently is remotely controllable. Camera control is not available to the 511 web page dynamic elements and Third Party Data Feed. |
UN-4, UN-44, UN-48, UN-52 |
High |
|
|
SR-114 |
Camera control shall include: pan, tilt, zoom, iris, focus, and preset selection. Presets are set on the host system. |
UN-44 |
High |
|
|
SR-115 |
The camera control dialog shall include camera data (see Definitions above). |
UN-3 |
Medium |
|
|
SR-116 |
Camera pan and zoom control shall be accomplished via hover/drag/slide operations rather than repeated clicks. |
UN-45 |
Low |
|
|
SR-117 |
Presets shall be selectable from a list of preset descriptions. |
UN-46 |
High |
|
|
SR-118 |
Camera control contention shall be managed by locks and overrides. |
UN-56 |
Low |
|
|
SR-119 |
Locks and overrides shall expire after a system configurable period of time. |
UN-56 |
Low |
|
VIDEO |
SR-120 |
The Regional Display video distribution system shall exhibit a camera control latency of no greater than one second. Control latency is measured from the time a camera movement action is initiated (e.g., a mouse click or movement) to the time that the field of view of the on-screen video image is seen to start changing accordingly, when the client computer is on the same local area network as the video server thus eliminating the effects of network delays. |
UN-50 |
Medium |
|
|
SR-121 |
The video feed to the Regional Display shall be buffered to provide tolerance to network jitter. |
UN-51 |
Medium |
|
|
SR-122 |
If the streaming video does not automatically scale to available bandwidth, a Regional Display operator or 511 user shall be able to choose between at least two different bandwidth versions - one suited to a high bandwidth link and the other suited to a low bandwidth link. |
UN-53 |
High |
|
|
SR-123 |
The high and low bandwidth targets for the video links should be nominally 128 and 384 kilobits per second, respectively. |
UN-53 |
Medium |
|
VIDEO DISTRIBU-TION |
SR-124 |
The video distribution functions of the Regional Display shall support up to six operators viewing the same camera simultaneously, and allow all cameras to be viewed simultaneously by at least one operator. |
UN-47 |
Medium |
|
|
SR-125 |
Streaming video, without camera control and without the need to log in, shall be made available to 511 web page users. |
UN-52 |
High |
|
|
SR-126 |
The video distribution systems shall support multiple brands of video encoders, based on one or more popular video compression standards. |
UN-49 |
High |
|
|
SR-127 |
Distribution of streaming video to the public via the 511 web page dynamic elements and Third Party Data Feed, shall make use of a separate video distribution server and Internet feed from that used for video distribution via the Regional Display, or otherwise ensure that the level of service for video viewing for Regional Display operators is not limited or affected by public viewers. |
UN-52 |
High |
|
|
SR-128 |
On the 511 web page dynamic elements, if loading the video is expected to take longer than 5 seconds, a current snap shot image from that camera shall be immediately displayed along with a message that the live video is loading. |
UN-52, UN-53 |
Medium |
|
|
SR-129 |
The 511 video distribution system shall support the simultaneous viewing of 10 high speed and 20 low speed individual cameras (30 total). |
UN-52, UN-53 |
Medium |
|
|
SR-130 |
The 511 video distribution system shall automatically terminate a streaming video session after a system-settable timeout, unless the user refreshes the timeout timer. |
UN-52, UN-53 |
High |
|
|
SR-131 |
A Regional Display system administrator shall be able to set the 511 video stream timeout time. |
UN-52, UN-54 |
High |
|
|
SR-132 |
Each user of the 511 web page (each instance of the web browser) shall be limited to viewing one video stream at a time. |
UN-54 |
High |
|
|
SR-133 |
Each operator of the Regional Display shall be able to view a minimum of six video streams simultaneously. |
UN-47 |
High |
|
|
SR-134 |
From a web-browser-based user interface, a Regional Display administrator shall be able to add or delete cameras, configure video feeds, assign different privileges to different operators or operator groups, and flag selected cameras to be excluded from the 511 web site. This same user interface shall also allow a Regional Display administrator to set permissions for incident creation, deletion, and editing. |
UN-7, UN-54 |
High |
|
|
SR-135 |
The 511 video distribution system shall automatically inherit relevant configuration parameters from the Regional Display video distribution system, such that an administrator need make a change only once to have the same affect on both systems. |
UN-54 |
Medium |
|
|
SR-136 |
The Regional Display shall allow a camera operator to temporarily stop the video feed to the public (via the 511 web site) when the operator determines that the image is not suitable for public dissemination. |
UN-55 |
High |
|
|
SR-137 |
The user name of the operator that cut the public feed to a camera shall be recorded. |
UN-55 |
High |
|
|
SR-138 |
A list of currently cut cameras and the operator that cut them, from the public feeds shall be available from the Regional Display. |
UN-55 |
High |
|
|
SR-139 |
After a system configurable period of time, the video from a cut feed shall be re-established. |
UN-55 |
Medium |
|
|
SR-140 |
A Regional Display administrator shall be able to configure the threshold for when a cut video feed is re-established. |
UN-55 |
High |
|
|
SR-141 |
A Regional Display administrator shall be able to system wide disable the automatic re-establishment of cut video feeds. |
UN-55 |
High |
|
|
SR-142 |
The Regional Display shall allow an operator to re-establish the public feed to a camera. |
UN-55 |
High |
|
|
SR-143 |
On the 511 web page dynamic elements, the icons for the cameras unavailable for public viewing shall be color coded to represent their temporarily unavailable state. |
UN-17 |
Medium |
|
|
SR-144 |
Upon the 511 web page dynamic elements user selecting a camera that has been cut from the public feeds, a message shall be displayed that the camera is temporarily unavailable. |
UN-55 |
Medium |
|
INCIDENT TRACKER |
SR-145 |
The Regional Display shall include an incident tracker that automatically creates incident records based on incident data from other nodes, and allows operators with the appropriate permissions to manually create and edit incident records. A 511 web page dynamic elements user cannot create or edit incident records. |
UN-2, UN-22 |
High |
|
|
SR-146 |
A Regional Display administrator shall be able to assign different privileges to different operators or operator groups to limit their access to create or edit an incident. |
UN-7, UN-54 |
High |
|
Incident-Create |
SR-147 |
A unique incident identifier shall be automatically assigned to all newly created incidents, whether created manually or automatically. |
UN-24 |
High |
|
|
SR-148 |
The incident's creator's name and agency shall automatically be recorded and unless the operator otherwise indicates, the incidents owner defaults to the agency of the creator. |
UN-26 |
High |
|
|
SR-149 |
For incident records automatically created, "xxxxx yyyyy" shall be recorded as the creator, where "xxxxx" is the name of the node that was the source of the information used to create the incident record, and "yyyyy" is the ID of the incident in the source node. |
UN-26 |
High |
|
|
SR-150 |
The incident tracker shall create an incident, of type roadway incident, for each traffic signal that it detects is in flashing mode whether due to failure or police activity. Incidents are not created for signals in programmed flashing mode. |
UN-22 |
High |
|
|
SR-151 |
The incident entry form shall allow editing of: incident location (latitude, longitude), location description (free text), route, direction, area, incident description (free text), incident type (selection from a list), incident owner, impact (choose highest, high, moderate, low, or none), start date/time (can be in the future, and whether estimated or actual), end date/time (and whether estimated or actual), whiteboard entries (free text remarks), announce date/time, additional 511 phone message, and the generated 511 phone message (free text). |
UN-18, UN-25, UN-28, UN-29 |
High |
|
|
SR-152 |
The Regional Display and incident gateways shall recognize and translate standard abbreviations (such as Rd., JNO, and Blvd) and filter any inappropriate words and phrases prior to disseminating to the public as configured by an administrator. |
UN-30, UN-31 |
High |
|
|
SR-153 |
The type field in the incident entry form shall have pull down menus to enable the operator to select from the available incident types. |
UN-33 |
High |
|
|
SR-154 |
The impact field in the incident entry form shall have pull down menus to enable the operator to select from the available incident impacts. |
UN-33 |
High |
|
|
SR-155 |
The incident entry form shall allow the user the option to select standard phrases for the incident description, route, area, direction, cross street, and propositions (at, between, etc) and other fields as necessary to be used in scripting the 511 incident message. The standard phrases maybe used by the 511 phone system to generate concatenated speech for the voice announcement. |
UN-33 |
Medium |
|
|
SR-156 |
For an automatically created incident the impact shall default to the appropriate value depending on the incident's source, type, and words and phrases contained in the incidents description. |
UN-23 |
High |
|
|
SR-157 |
A Regional Display Administrator shall be able to configure default values for incidents based on the incidents source, type, and words and phrases in the description. |
UN-23 |
Medium |
|
|
SR-158 |
The Incident Tracker shall require that an incident type, incident description, and start time be provided in order to create an incident object. |
UN-29 |
High |
|
|
SR-159 |
Incidents with the start time set to within plus or minus (and not flagged as actual) the "impending future incident" range, shall be considered as impending future incidents. |
UN-17 |
Medium |
|
|
SR-160 |
Incidents with the start time in the past that is not flagged as actual, beyond the impending future range, shall be considered as far future incidents. |
UN-17 |
Medium |
|
|
SR-161 |
Manual entries to the incident fields shall be available for publishing and on shown on the Regional Display only after they have been saved. |
UN-29 |
High |
|
Incident-Edit |
SR-162 |
A Regional Display operator shall be able to edit existing incident records, including past incidents still available on the Regional Display map, and automatically created incidents, and change any field that is editable when manually creating a new incident. |
UN-18 |
High |
|
|
SR-163 |
The Regional Display shall provide a convenient means for an authorized operator to enter edit mode for a particular existing incident record form that incident's icon and from that incident's row in the incidents table. |
UN-18 |
Medium |
|
|
SR-164 |
During incident creation or subsequent editing, a Regional Display operator, by clicking on the map or dragging, shall be able to locate or relocate the incident icon on the map to reflect the location of the incident. |
UN-28 |
High |
|
|
SR-165 |
The latitude and longitude of the incident (editable fields in the incident record) shall be automatically adjusted to reflect the location of the incident icon when a Regional Display operator locates (by clicking) or relocates (by dragging) the incident icon. |
UN-28 |
High |
|
|
SR-166 |
A Regional Display operator shall be able to adjust the location of an incident icon by either dragging the icon or clicking on the map or by changing the value of the latitude and longitude. |
UN-28 |
High |
|
|
SR-167 |
Incidents that either don't have a latitude, longitude location associated, or whose latitude and longitude would locate it off the map, shall have their icon displayed in a corner of the map. |
UN-28 |
High |
|
|
SR-168 |
The icons for incidents located in the corner of the map, shall be stacked so as to be individually accessible. |
UN-28 |
High |
|
|
SR-169 |
A Regional Display incident record (object) shall be automatically created when a new incident becomes available from any of the following sources: CHP computer aided dispatch system (via XML feed), Sacramento Regional Fire/EMS Communications Center computer aided dispatch system, Yolo County Communications Emergency Service Agency computer aided dispatch system, Sacramento Regional Transit incident tracking system, City of Sacramento Police computer aided dispatch system, Yolo County Transit System, Sacramento County Lane Closure Database and Caltrans Lane Closure System. |
UN-22 |
High |
|
|
SR-170 |
For an automatically created incident record, where the location information does not include lat/long coordinates, the available location data shall be used to determine the latitude and longitude where such a conversion is feasible. |
UN-22 |
High |
|
|
SR-171 |
For an automatically created incident record the Regional Display shall use the available location data to populate the Route, Direction and Area fields of the incident record. To accomplish this requirement, free text data fields from the source node may need to be parsed and a set of rules developed to extract the necessary Route, Direction and Area data from the available data. |
UN-22 |
High |
|
|
SR-172 |
Useful material available from an automatic incident source, but not fitting into one of the other fields, shall be inserted in the whiteboard field. |
UN-22 |
High |
|
|
SR-173 |
When additional or changed information becomes available from the source of information for an automatically created incident, the relevant fields of the automatically created incident should be updated accordingly, except that a field that has been edited by an operator since its automatic entry should not be changed. Each entry in the Whiteboard should be considered a separate "field" for this purpose. |
UN-22 |
High |
|
|
SR-174 |
The Regional Display shall continually monitor the automatic incident source and shall automatically determine when to set the end time flag to actual. |
UN-22 |
High |
|
Whiteboard |
SR-175 |
The Regional Display shall allow operators to add textual information to a "whiteboard" history of remarks for each incident. |
UN-35 |
High |
|
|
SR-176 |
Regional Display and 511 web page users shall be able to disable the wrapping of text in the Whiteboard view. |
UN-35 |
High |
|
|
SR-177 |
The Regional Display shall allow operators to designate each whiteboard entry as suitable or unsuitable for public dissemination. |
UN-35 |
High |
|
|
SR-178 |
Only Whiteboard entries designated as suitable for public dissemination shall be available to the 511web page dynamic elements and Third Party Data Feed. |
UN-35 |
High |
|
|
SR-179 |
Each Whiteboard entry shall be automatically tagged with the author's (or source node if automatic) name, agency, and time of entry (to the millisecond) and this information shall be visible to operators viewing incident data in the Regional Display. |
UN-35 |
High |
|
|
SR-180 |
Operator name and agency information on Whiteboard entries shall be omitted from the 511 web page and all public data feeds and displays. The time of whiteboard entry is not omitted. |
UN-35 |
High |
|
|
SR-181 |
Incident record changes (other than Whiteboard entries) and time of such change (to the millisecond), shall be automatically entered in the Whiteboard as a new entry so as to be available for viewing by operators. (E.g.,"9Aug06 12:30PM Incident Description changed from "In Sacramento at the intersection of Greenback Lane and San Juan Ave." to "In Citrus Heights at the intersection of Greenback Lane and San Juan Ave"). |
UN-35 |
Medium |
|
|
SR-182 |
Deleted Whiteboard entries shall remain visible to the operators and are distinguished as deleted. |
UN-35 |
High |
|
|
SR-183 |
Deleted Whiteboard entries shall be unavailable to the 511web page and Third Party Data Feed. |
UN-35 |
High |
|
|
SR-184 |
The incident tracker shall include a spell checker to check the spelling in all free text fields. |
UN-22 |
Medium |
|
|
SR-185 |
The spell checker shall include in its dictionary the names of all streets, agencies, and landmarks the STARNET area. |
UN-22 |
Medium |
|
511 Message |
SR-186 |
The 511 Phone Message for each incident shall be automatically scripted using information from the following fields: area, route, direction, location description, incident type, incident description, last update time, and estimate end time (if appropriate) and additional 511 information. |
UN-33 |
High |
|
|
SR-187 |
For automatically created incidents, the 511 Message shall be scripted at the time the incident record is created. |
UN-33 |
High |
|
|
SR-188 |
For manually created or edited incidents, the 511 Message shall be scripted when the operator requests it be created or when the operator saves the incident record, whichever comes first. |
UN-33 |
High |
|
|
SR-189 |
The Regional Display incident editor shall allow the operator to disable the automatic updating of the 511 Message upon receipt of new information in one of the relevant fields. |
UN-33 |
Medium |
|
|
SR-190 |
The Regional Display incident editor shall allow the operator to view the derived 511 message. |
UN-33 |
Medium |
|
|
SR-191 |
When the 511 Message automatic update is disabled, the Regional Display incident editor shall allow the operator to edit the derived 511 message. |
UN-33 |
Medium |
|
|
SR-192 |
The last update time shall be set to the time when any of the fields used to create the 511 Message are edited either manually or by receipt of new information from the source. |
UN-33 |
High |
|
|
SR-193 |
The Regional Display incident editor shall allow the operator to preview the derived voice message generated by the 511 telephone system, that will be broadcast on the 511 phone system to test clarity and pronunciation. |
UN-33 |
High |
|
|
SR-194 |
The Announce Time for the 511 phone message shall default to the appropriate value depending on the incident’s type, location, impact and other applicable fields. |
UN-33 |
High |
|
|
SR-195 |
The Announce Time default values shall be system configurable by a Regional Display administrator by the incident’s type, source agency, and other applicable fields. |
UN-23 |
Medium |
|
|
SR-196 |
A Regional Display operator shall be able to edit the Announce Time. |
UN-23 |
High |
|
Incident - Merge |
SR-197 |
The Regional Display shall allow an operator to select any two incidents, designate one as the primary incident (the other thereby being deemed the secondary incident) and merge them into a single incident. |
UN-34 |
High |
|
|
SR-198 |
When two incidents are merged, the primary incident is retained in its entirety and the secondary incident is discarded in its entirety (removed from logs, displays, etc.), except that all entries in the secondary incident's whiteboard are added to the primary incident's white board, and intermingled with entries in the primary incident's whiteboard, in chronological order. |
UN-34, UN-35 |
High |
|
|
SR-199 |
The Regional Display shall continually monitor the secondary incident and record any updates in the whiteboard of the primary incident. |
UN-35 |
High |
|
|
SR-200 |
The incident identifier of the secondary merged incident shall be recorded as an automatically created entry in the whiteboard of the primary incident, and the secondary incident record appended to all whiteboard entries coming from that secondary incident record. |
UN-35 |
Medium |
|
Incidents-Past |
SR-201 |
Past incidents shall be removed from the Regional Display and 511 web page dynamic elements after a system configurable period of time. |
UN-37 |
High |
|
|
SR-202 |
Past incidents shall be logged (see separate requirements) and the incident record shall be otherwise permanently removed from the Regional Display after a system configurable period of time. Incidents shall be accessible by users from either the Regional Display or the Incident log, but never both. |
UN-37 |
High |
|
|
SR-203 |
Prior to removal and logging, past incidents still on the Regional Display shall be able to be edited, including changing the End Time so that they become active again. |
UN-37 |
Medium |
|
|
SR-204 |
The complete record, including whiteboard, of incidents removed from the Regional Display shall be provided to the SACOG Transportation Planning Database for archival. |
UN-37 |
High |
|
|
SR-205 |
The Regional Display shall allow an operator to remove (and log) an incident immediately from the Regional Display. |
UN-37 |
High |
|
|
SR-206 |
Automatically created incidents should be considered past (the End Time set to the past and flagged as "actual") when the source node marks that incident as closed or equivalent, or when that incident is no longer available from the source node, whichever occurs sooner. |
UN-37 |
High |
|
|
SR-207 |
The Incident Tracker shall allow the operator to indicate that the start and end time of an incident is "actual" rather than "estimated". |
UN-24 |
High |
|
Incident-Paging & Messages |
SR-208 |
When an incident's status changes to active, the Regional Display system shall send a text message to the cell phones of those operators who have subscribed for such notification. |
UN-36 |
Medium |
|
|
SR-209 |
The Regional Display system shall allow an operator to configure the system to send cell phone text messages, based upon the type of incident, an incident icon location rectangle defined by the latitude/longitude pairs of two points, and impact, to the operator's cell phone. |
UN-36 |
Medium |
|
|
SR-210 |
While creating or editing an incident, an operator shall be able to send a message to selected currently logged-in operators, by selecting from a list of logged-in operators automatically displayed in the incident entry form. |
UN-32 |
High |
|
|
SR-211 |
The list of logged-in operators shall identify the operator by name and agency. |
UN-32 |
High |
|
|
SR-212 |
The message for logged-in operators shall take the form of a pop-up or other dynamic display on the user's interface. |
UN-32 |
High |
|
|
SR-213 |
The incident message originator shall be presented with the incident's ID and 511 phone message to which they are allowed to edit the text for display in the message. |
UN-32 |
Medium |
|
|
SR-214 |
Operators are also able to send a text message and/or email to selected operators, including those not logged-in as available from a list of operators. |
UN-32 |
Low |
|
|
SR-215 |
Alert recipients shall be required to manually acknowledge receipt of the pop-up message, perhaps similar to an e-mail receipt. |
UN-32 |
Medium |
|
|
SR-216 |
The incident message originator can cancel the need for acknowledge at any time. |
UN-32 |
|
|
|
SR-217 |
The incident message originator shall receive notification that their message has been acknowledged, or after a system configurable period of time, that their message has not been acknowledged. |
UN-32 |
|
|
|
SR-218 |
The incident message originator upon receiving notification that their message has not been acknowledged shall have the option to continue monitoring or to cancel monitoring. |
UN-32 |
|
|
|
SR-219 |
The actions of sending alerts and receiving alert acknowledgments, and the time of such actions, and any unique message content, shall each be included in separate entries in the whiteboard for that incident. |
UN-32 |
High |
|
511 SYSTEM - GENERAL |
SR-220 |
The 511 system shall contain a data feed for third parties, a relay CCTV video stream server, web page dynamic elements, and a 511 telephone system gateway. An interactive phone service is provided by others under a separate contract. |
UN-57, UN-63 |
High |
|
|
SR-221 |
The 511 Third Party Data Feed shall be configured to exclude from publishing data received from commercial companies. |
UN-63 |
|
|
511 Telephone - Slowdowns |
SR-222 |
The Regional Display shall use freeway detector data to identify areas of slow traffic on freeways, and report this "slowdown" information to the 511 telephone system where it will be announced. |
UN-58 |
High |
|
|
SR-223 |
In identifying freeway slowdowns, the Regional Display shall detect whether a minimum number of vehicle detectors are reporting speeds of less than 40 miles per hour. |
UN-58 |
High |
|
|
SR-224 |
The minimum number of detectors used to identify speed slowdown areas shall be system selectable. |
UN-58 |
Medium |
|
|
SR-225 |
The Regional Display shall determine the location of slowdown areas by using an algorithm similar to the following: identify the extents of consecutive vehicle detector stations reporting an average speed of 40 miles per hour or less with less than x miles spacing between them; average the speed across the stations, if the average speed is less than 25 miles per hour then report speeds are less than 25 miles across the extents, if the average is greater than 25 miles per hour, then report that the speeds are between 20 and 40 miles per hour across the extents (from point A to point B). |
UN-58 |
High |
|
|
SR-226 |
The distance used to identify the location of gaps in slowdown calculations, "x", shall be system settable. |
UN-58 |
Medium |
|
SUB-SCRIPTION MANAGE-MENT |
SR-227 |
Nodes, including Regional Display, the 511 Third Party Data Feed, and 511 telephone system gateway, shall provide for the following types of subscriptions for each center-to-center message: one-time transmission of the message, continued automatic delivery of the message by time period, or continued automatic delivery of the message upon a change in any data contained within the message (see NTCIP 2306). |
UN-39 |
High |
|
|
SR-228 |
Subscriptions shall be available for all objects of a specified type without having to list their IDs or other attributes other than object type, and by selecting from a list of objects those IDs to include. |
UN-39 |
High |
|
|
SR-229 |
Each node shall have a user interface enabling an administrator to establish and maintain subscriptions for center-to-center messages to be sent from other nodes, and to accept or reject pending (requested) subscriptions for messages to be sent to other nodes on a per node and per message type basis. |
UN-40 |
High |
|
|
SR-230 |
A denied subscription (center-to-center message request) shall be returned with a "Permission denied" exception. |
UN-40 |
High |
|
|
SR-231 |
All data received by the 511 Third Party Data Feed, for which the source agencies have agreed can be released to third parties, shall be made available to third parties by both an NTCIP XML-Direct feed, and by an NTCIP XML-SOAP feed. |
UN-63 |
Medium |
|
|
SR-232 |
The 511 Third Party Data Feed shall be sized to accommodate at least 10 simultaneous third party subscribers that have enabled subscriptions to all available data. |
UN-63 |
Medium |
|
|
SR-233 |
A node A administrator shall be able to obtain from each other node, a list of current subscriptions (the ID and basic parameters for each such subscription) they hold for node A (i.e., subscriptions that require the other node to publish a center-to-center message to node A). |
UN-41 |
Medium |
|
|
SR-234 |
The list of current subscriptions shall be available in a node user interface. |
UN-41 |
High |
|
|
SR-235 |
As an agency adds, changes, or deletes objects in their system, their node shall automatically send the relevant changes to all other nodes that subscribe to that type of data (that center-to-center message). |
UN-41 |
Medium |
|
DATA EXCHANGE |
SR-236 |
Data exchanged between STARNET nodes, including the Regional Display, 511 Third Party Data Feed and the 511 telephone system gateway, shall be based on the NTCIP 2306 Center-to-Center XML standard, IEEE 1512 standard, and the Traffic Management Data Dictionary standard as appropriate, with customization as necessary. |
UN-64 |
High |
|
|
SR-237 |
Custom center-to-center messages or custom fields or enumerations within otherwise standard center-to-center messages, shall be used when necessary due to limitations of the standard, to accommodate all available required data for each object. |
UN-64 |
High |
|
|
SR-238 |
The translation of data into and out of center-to-center messages shall be done in a way that does not lose available information pertaining to required data. |
UN-64 |
Medium |
|
|
SR-239 |
When needed, the translation of data to or from a center-to-center message shall take information from multiple source fields and combine it into one destination field, and take information from one source field and split it into multiple destination fields. |
UN-64 |
Medium |
|
|
SR-240 |
If a host system does not provide an element of the universal data as defined in SR-1, then its gateway shall have a means of obtaining the missing data, either by calculation or manual entry. Manual entry is not acceptable for incidents and light rail vehicle location data (lat/long). |
UN-64 |
High |
|
|
SR-241 |
All newly installed computers involved in STARNET shall automatically synchronize their clocks relative to Universal time to within 100 milliseconds. |
UN-81 |
Medium |
|
|
SR-242 |
Gateways shall be developed such that their exchanging data with the host system does not negatively impact the performance of the host system. |
UN-64 |
High |
|
|
SR-243 |
Data provided by a source shall be the same value as delivered to a sink. |
UN-21 |
High |
|
SECURITY |
SR-244 |
Appropriate measures should be used to prevent unauthorized access to nodes and data flows, assuming at least some communication links will use the Internet. |
UN-69, UN-93 |
High |
|
|
SR-245 |
An operator of the Regional Display system with administrator privileges shall be able to define and maintain a user name, password, and privileges (e.g., via user groups) for each authorized operator. |
UN-69 |
High |
|
|
SR-246 |
Individual operator accounts, or groups of operator's accounts, shall automatically disable (e.g. through password expiry, etc) after a configurable period of days, where the number of days can be set from one to infinity. |
UN-69 |
Medium |
|
|
SR-247 |
Authentication data shall be inaccessible by unauthorized users. |
UN-69 |
High |
|
|
SR-248 |
The STARNET interface to each node should be implemented in accordance with the owning agency's information technology policies. |
UN-69 |
High |
|
NODE STATUS MONITORING |
SR-249 |
To avoid the appearance of being non-responsive, a node A that is publishing center-to-center messages to another node in accordance with one or more continuous subscriptions (e.g., periodic or "on change") shall send a "keep alive" message to that other node if no message has otherwise been sent to that node within a configurable time limit. |
UN-68 |
High |
|
|
SR-250 |
Upon detecting a lack of communications, or restoration of communications, with another node, each node shall update its stored list of non-communicative nodes. |
UN-68 |
High |
|
|
SR-251 |
When the Regional Display receives notification that Node A has determined that node B has become non-communicative, or the Regional Display detects a lack of communications itself, then the Regional Display system shall send a text message explaining the two nodes involved, to the cell phone of one or more designated maintenance persons, after a system configurable period of time. |
UN-68 |
High |
|
|
SR-252 |
An operator of the Regional Display shall be able to define the primary and backup maintenance persons for various times of the day and days of the week, and configure the time threshold for a primary maintenance person to respond to a page and the delay time after which a maintenance person is contacted. |
UN-68 |
Medium |
|
|
SR-253 |
If a maintenance person so notified does not confirm receipt of the alert within a system configurable period of time, the Regional Display system shall send the text message to the designated backup maintenance person. |
UN-68 |
Medium |
|
|
SR-254 |
A Regional Display administrator shall be able to configure the wait time when a node is reported non communicative between when the primary maintenance person and back up maintenance person is called. |
UN-68 |
Medium |
|
|
SR-255 |
All nodes shall accept a subscription from the Regional Display for node data, even if they have no subscriptions with other nodes and are therefore unable to monitor communications with other nodes. |
UN-68 |
Medium |
|
|
SR-256 |
If a node accepts a persistent (periodic or on-change) subscription from another node, it shall send keep alive messages to that subscribing node even if that is the only subscription from that subscribing node and the publishing node is not currently, or ever, gathering the data subscribed for. |
UN-68 |
Medium |
|
LOGGING |
SR-257 |
From the Regional Display user interface, operators shall be able to export any log or subset of a log, including field headings, in CSV (comma separated variable) file format thus enabling analysis using third party software such as Microsoft Excel. |
UN-66 |
Medium |
|
|
SR-258 |
For all logs, a system administrator shall be able to manage the size or duration of the log. |
UN-66 |
Medium |
|
|
SR-259 |
Accessing the logs shall not reset the cumulative counters. |
UN-66 |
Medium |
|
|
SR-260 |
From the Regional Display user interface, operators shall be able to select a log and a time period for which the contents of the applicable log will be displayed. |
UN-66 |
Medium |
|
|
SR-261 |
All fields within the log view shall be sortable. |
UN-66 |
Medium |
|
Center-to-Center Message Log |
SR-262 |
For each center-to-center message sent and received by a gateway, the gateway shall store on disk a historical record containing the message type, direction of transmission (sent or received), ID of the destination or origin gateway, and date/time of transmission (to the millisecond), called the Center-to-Center Message Log. |
UN-66 |
Medium |
|
Node Status Change Log |
SR-263 |
For each node status change that the Regional Display becomes aware of, by its own monitoring of communications with other nodes and via node data received from other nodes, the Regional Display shall store on disk a historical record containing the node name, and the date/time of the status change (to the millisecond). This log is called the Node Status Change Log. |
UN-68 |
Medium |
|
Incident Log |
SR-264 |
For each incident record created, the Regional Display shall store on disk a historical record containing the entire record of the incident. This log is called the Incident Log. |
UN-37 |
Medium |
|
|
SR-265 |
For each incident being logged, the system shall record the entire incident record including: whiteboard, date/time incident record was created, date/time it became active, the date/time it was removed and logged, whether start time was ever set to "actual", whether end time was ever set to "actual", the number of times the impact was changed, the highest impact ever set, the number of times it changed from "past" to active", the number of times it was merged, whether it was primary or secondary in the last merger if any, the maximum number of whiteboard entries, the number of different 511 phone messages entered, and the last 511 phone message if any. |
UN-37 |
Medium |
|
511 Usage Statistics Log |
SR-266 |
The Regional Display shall log 511 web usage statistics in accordance with Appendix B of the Implementation and Operational Guidelines for 511 Services Version 3.0 (or later), Published by the 511 Deployment Coalition. |
UN-65 |
Medium |
|
Objects Count Log |
SR-267 |
At the end of each day the Regional Display shall store on disk a historical record containing the minimum and maximum number of objects of each type displayed in the Regional Display during that day. This log is called the Objects Count Log. |
UN-67 |
|
|
SYSTEM UPGRADES AND EXPANSION |
SR-268 |
STARNET nodes shall be able to be added, removed, upgraded, or replaced without disrupting operations to the remainder of the system except for communications with that node. |
UN-73 |
High |
|
|
SR-269 |
A node administrator shall be able to enter the name of a new node in a configuration database and then select the new node in subscription configurations. |
UN-75 |
Medium |
|
SYSTEM START UP |
SR-270 |
When the Regional Display service starts up current information for all objects shall be available for display to Regional Display Operators within ten (10) minutes. |
UN-21 |
High |
|
|
SR-271 |
The Regional Display shall provide a single web based user interface to configure operator's access create and edit incidents, control cameras and configure the system. |
UN-54 |
High |
|
SYSTEM RELIABILITY |
SR-272 |
Battery-based uninterruptible power supplies shall be provided at each node to power center located field communications equipment, the host system, the gateway and the STARNET communications equipment for at least two hours. |
UN-82 |
High |
|
|
SR-273 |
The Regional Display, 511 phone system, 511 web page, 511 Third Party Data Feed shall be located at the Caltrans/CHP Regional TMC which has 8 hours of battery backup and dual diesel power generators. |
UN-83 |
High |
|
|
SR-274 |
Duplicate Internet links shall be provided at the Regional Display and 511 nodes, with different Internet links using different Internet service providers, with manual switch-over if necessary. |
UN-84 |
High |
|
|
SR-275 |
The STARNET system integrator shall provide for remote access for owning agency’s system administrators for all gateways and the Regional Display. |
UN-85 |
Medium |
|
|
SR-276 |
The STARNET system integrator shall provide remotely located replica servers for the Regional Display and 511 nodes, with manual switch-over. The remote servers can also serve as test and training systems. The remote location does not require backup generator. SACOG to recommend a location. |
UN-86 |
Low |
|
|
SR-277 |
Automated critical data backups with off-site storage shall be provided for all STARNET computers (new components provided by the STARNET system integrator). |
UN-87 |
Medium |
|
|
SR-278 |
RAID disks shall be provided for the Regional Display and 511 nodes. |
UN-88 |
Medium |
|
|
SR-279 |
All STARNET equipment shall be installed in a locked room or cabinet. |
UN-90 |
High |
|
|
SR-280 |
Firewall or VPN and malware protection software shall be provided for new components provided by the STARNET system integrator at all STARNET nodes. |
UN-93 |
High |
|
|
SR-281 |
Where practical, communications components’ capacity shall be sized to accommodate the current expected peak demand plus an additional 50%. This applies to Internet service, other wide area network, local area network, and servers’ communication interfaces (application level). |
UN-92 |
Medium |
|
|
SR-282 |
Servers and communications equipment shall be sized to accommodate the current expected load plus an additional 50%. |
UN-92 |
Medium |
|
|
SR-283 |
Spare power supplies shall be provided in a ratio of one spare supply every five power supplies contained in the deployed gateways, Regional Display and Third Party Data Feed nodes. |
UN-89 |
Medium |
|
|
SR-284 |
At least one spare power supply shall be provided for each type of supply contained in the deployed system. |
UN-89 |
Medium |
|
|
SR-285 |
Spare interface cards shall be provided in a ratio of one card for every five cards contained in the deployed gateways, Regional Display and Third Party Data Feed nodes. |
UN-89 |
Medium |
|
|
SR-286 |
At least one spare interface card shall be provided for each type of interface card contained in the deployed system. |
UN-89 |
Medium |
The following table defines acronyms and uncommon terms used in this document .
Table 4 Terminology
|
Term |
Meaning |
|
511 |
The national travel information telephone number, also used as an adjective for related items, as in “the 511 web site”. |
|
Active Incident |
An incident with an actual Start Time in the past and an End Time that is in the future or estimated. |
|
ATMS |
Advanced Traffic (or Transportation) Management System |
|
Average Trip Length |
Average Trip Length is the average distance ridden for an unlinked passenger trip by time period (weekday, Saturday, Sunday) computed as passenger miles divided by unlinked passenger trips. |
|
Caltrans |
California Department of Transportation |
|
CAD |
Computer Aided Dispatch system that records incident information |
|
CCTV |
Closed Circuit Television |
|
CHP |
California Highway Patrol |
|
Far Future Incident |
An incident with a future Start Time that is not within the configurable Near Future Incident time limit. Also, an incident with an estimated past Start Time that is not within the configurable Impending Future Incident time limit. |
|
FHWA |
Federal Highway Administration |
|
FTP |
File Transfer Protocol |
|
Gateway |
That portion of a STARNET node (computer system) that provides the STARNET interface (see also Host System, Node) |
|
Host System |
That portion of a STARNET node (computer system) that excludes the STARNET interface (also see Gateway, Node) |
|
IEEE |
Institute of Electrical and Electronics Engineers |
|
Impending Future Incident |
An incident with a future or past Start Time that is within the configurable Impending Future Incident time limit. |
|
Incident |
An event of interest to operators (see below) or the traveling public. E.g., an accident on a roadway, a planned lane closure, a building fire, a truck height or weight restriction, a transit service disruption, an air show, etc. Also see Far Future Incident, Near Future Incident, Impending Future Incident, Active Incident, and Past Incident. |
|
Incident Start Time |
The date and time at which an incident started – can be estimated or actual. |
|
Incident End Time |
The date and time at which an incident ended – can be estimated or actual. |
|
Interface Card |
Any removable hardware module used in a computer’s communications interface. |
|
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. |
|
Latency |
In a network, latency, a synonym for delay, is an expression of how much time it takes for a packet of data to get from one designated point to another. |
|
Message |
Structured set of data transmitted between computer systems. OR The text displayed on a changeable message sign. |
|
Near Future Incident |
An incident with a future Start Time that is within the configurable Near Future Incident time limit but not within the Impending Future Incident time limit. |
|
Node |
A computer system connected to the STARNET network (see also Host System, Gateway) |
|
NTCIP |
National Transportation Communications for ITS Protocol |
|
Object |
A logical entity for which associated data are sent over the STARNET network (e.g., traffic signal, light rail vehicle, incident, node, etc.) |
|
|
|
|
Operator |
An agency employee or contractor configuring or using a STARNET node for transportation or emergency management (also see Traveler). |
|
Passenger Miles |
Passenger Miles is the cumulative sum of the distances ridden by each passenger. |
|
Past Incident |
An incident with an actual End Time in the past. |
|
Regional Transportation Management Display |
A STARNET node to be provided by the STARNET integrator that will, among other things, automatically create incident records based on incident data from other nodes, allow operators to create and edit incident records, and display current data and live video. Also referred to as Regional Display. |
|
RT |
Sacramento Regional Transit District – largest transit operator in the Sacramento region. |
|
SACOG |
Sacramento Area Council of Governments |
|
SOAP |
Simple Object Access Protocol |
|
STARNET |
Sacramento Transportation Area Network |
|
Start Time |
The start time of an incident (can be either estimated or actual). |
|
Traveler |
A person interested in information about current travel conditions in the Sacramento region. |
|
Unlinked Passenger Trips |
Unlinked Passenger Trips is the number of passengers who board public transportation vehicles. Passengers are counted each time they board vehicles no matter how many vehicles they use to travel from their origin to their destination.
|
|
XML-Direct |
A simple XML document retrieval standard defined in NTCIP 2306 |
|
XML-SOAP |
A web services based XML data transfer standard defined in NTCIP 2306 |
|
|
|
-oOo-