HomeMy WebLinkAbout05 - OCTA TravelTip ProgramApril 25, 2000
CITY COUNCIL AGENDA
ITEM NO. 5
TO: Mayor and Members of the City Council
FROM: Public Works Department
SUBJECT: AGREEMENT WITH THE ORANGE COUNTY TRANSPORTATION
AUTHORITY FOR TRAVELTIP PROGRAM
RECOMMENDATION:
Authorize the Public Works Director to sign an Agreement with the Orange County
Transportation Authority to formalize the initial installation of TravelTip equipment and
define the City's role in the TravelTip Program.
DISCUSSION:
The Orange County Transportation Authority (OCTA) is preparing to introduce a new
countywide, multi - modal, Advanced Traveler Information System (ATIS), which will be
known as TravelTip. The primary purpose of TravelTip is to provide up -to -date traffic
information to the traveler. TravelTip software will interface with a number of City traffic
signal computer controllers and will gather congestion information from those systems.
The TravelTip Program will translate this information into traffic speed and predict travel
times for freeways and major arterials in the county. Participating cities and agencies
will provide current information to the TravelTip Program regarding accidents,
construction lane closures, special events, and any situation impacting local traffic. The
public will be able to access this information through the Internet (www.traveltip.net), a
highway advisory phone answering system, remote field kiosks (that include user -
friendly touch screen computers), and possibly through community access television.
The Agreement with OCTA outlines the responsibilities of OCTA and the City with
regard to the installation of TravelTip equipment, and ongoing system operation and
maintenance. All costs associated with the TravelTip program are the responsibility of
OCTA. The City will be responsible for working with OCTA on the installation of the
equipment. OCTA will be responsible for the on -going operation and maintenance of
the program. The City will also be required to consistently participate in the program by
entering accidents, road construction information, special events, and any other events
impacting traffic conditions. The Remote Workstation computer equipment will be
installed in the Public Works Department. This workstation will be connected directly to
the City's Traffic Signal Master computer.
SUBJECT: Agreement with OCTA for TravelTip Program
April 25, 2000
Page 2
Staff has been involved in the development of the TravelTip program with OCTA over
the past two years and believes TravelTip is a beneficial program for the community,
Respectful
oo su11bmitt d,
W
PUBLIC WORKS DEPARTMENT
Don Webb, Director
By: a� 2- c
Antony Brine, P. .
Transportation Engineer
Attachment: Agreement
F:1Usems PBIM Shared\ COUNCIL Ty99- 00Wpril- 251TravelTip.doc
1
2
3
4
5
6
7
8
9
10
it
12
13
14
is
16
17
18
19
20
21i
22
23
24
25
26
KP:kp
L%CAMM1CLE
COOPERATIVE AGREEMENT C -0 -0170
BETWEEN
ORANGE COUNTY TRANSPORTATION AUTHORITY
AND
CITY OF NEWPORT BEACH
THIS AGREEMENT, made and entered into this
day of 2000, by
and between the City of Newport Beach, a California municipal corporation in the State of California,
(hereinafter referred to as "CITY "), and the Orange County Transportation Authority, a public
corporation of the State of California, (hereinafter referred to as "AUTHORITY ").
WITNESSETH:
WHEREAS, AUTHORITY is the lead agency in the development of a county wide multimodal
Advanced Traveler Information System (ATIS), (hereinafter known as "TraveITIP "), and
WHEREAS, AUTHORITY currently has a TraveITIP System Integrator Consultant under
contract who will assist AUTHORITY in installing a connection to the CITY's Traffic Signal Master
Controller System as a means of collecting arterial traffic information as identified in Attachments B
and C hereinafter referred to as ( "PROJECT "). The TraveITIP System Integrator Consultant will be
responsible for TraveITIP operations & maintenance for a period of twelve (12) months from date of
TraveITIP system acceptance.
WHEREAS, AUTHORITY agrees to fund the TraveITIP connection with CITY as identified in
Attachments B and C at no cost to the CITY; and
WHEREAS, the TraveITIP connection will be constructed by and in accordance with
Attachments A, B and C and shall be subject to technical direction and approvals by AUTHORITY, its
Consultant(s), and CITY ; and
WHEREAS, CITY and AUTHORITY desire to herein specify their respective responsibilities for
performance of work outlined in Attachments B and C; and
WHEREAS, CITY and AUTHORITY each has full authority to enter into this Agreement;
Page 1 of 5
KMP
LAC'
AGREEMENT C -0 -017 "u
1 NOW, THEREFORE, it is mutually understood and agreed by both parties hereto as follows:
2 ARTICLE 1. RESPONSIBILITIES OF CITY
3 CITY agrees to the following responsibilities:
4 A. To allow AUTHORITY and its Consultant(s) access to CITY's Traffic Signal Master
s Controller in the manner directed by CITY Traffic Engineer.
6 B. To ensure that the PROJECT is constructed in accordance with Attachments B and C
7 and;
s C. To provide staff, as required to assist with the construction of PROJECT.
9 D. To work with AUTHORITY and its Consultant(s) on coordination and scheduling of
10 equipment installation and scheduling in accordance with Attachments B and C including ongoing
11 system operation and maintenance.
12 E. To exercise reasonable care in protecting the physical and logical connections between
13 the CITY's Traffic Signal Master Controller and TraveITIP remain intact. Equipment installed by
14 AUTHORITY may be used by CITY authorized personnel only for the intended purposes.
15 F. To advise AUTHORITY in advance of all CITY modifications of hardware and/or
16 software for the Traffic Signal Master Controller that may impact the TraveITIP System connection.
17 ARTICLE 2. RESPONSIBILITIES OF AUTHORITY
is AUTHORITY agrees to the following responsibilities:
19 A. To serve as lead agency for the PROJECT, as described in Attachments B & C,
20 including the initial connections and operations and maintenance.
21 B. To ensure that the PROJECT is constructed in accordance with Attachments A, B and
22 C.
23 C. To be responsible for review and input regarding preparation and processing of all
24 necessary documentation related to the installation and ongoing operations and maintenance.
25 D. To contact CITY, twenty -four (24) hours in advance to gain access to CITY's Traffic
26 Signal Master Controller System
I\KAT LEL 0110
Page 2 of 5
AGREEMENT C -0 -0170
1 E. To be responsible for the coordination, scheduling and costs associated with the
x performance of Work identified in Attachments A, B and C.
3 ARTICLE 3. MUTUAL AGREEMENTS
4 It is mutually understood by the parties hereto that:
s A. Unless otherwise agreed upon by CITY and AUTHORITY, all work shall be completed
6 by February 1, 2001, unless earlier terminated as provided for in this Agreement.
7 B. Every notice, demand, request or other document or instrument delivered pursuant to
s this Agreement with the exception of those items noted in Attachment C, shall be in writing and shall
9 be either personally delivered, sent by Federal Express or other reputable overnight courier, sent by
10 facsimile transmission with the original subsequently delivered by other means in accordance with this
11 section, or sent by certified United States Mail to the address set forth below or to such other address
12 as a party may designate from time to time.
13 TO CITY: TO AUTHORITY:
14 City of Newport Beach Orange County Transportation Authority
1s 3300 Newport Boulevard 550 South Main Street
16 P.O. Box 1768 P.O. Box 14184
17 Newport Beach, CA 92658 -8915 Orange, CA 92863 -1584
1s Attn: Don Webb Attn: Kathleen Perez
19 Director of Public Works Sr. Procurement Administrator
20 Tel: ( 949 ) 644 -3311 Tel: (714) 560 -5743
21 kperez @octa.net
zz C. AUTHORITY shall indemnify, defend and hold harmless CITY, its officers, directors,
23 employees and agents from and against any and all claims (including attorney's fees and reasonable
24 expenses for litigation or settlement) for any loss or damages, bodily injuries, including death, damage
zs to or loss of use of property caused by the negligent acts, omissions or willful misconduct by
26 AUTHORITY, its officers, directors, employees or agents in connection with or arising out of the
RAT LEL kamm,ciencanwordprocessingWgO -0170
Page 3of5
r.
KUP hmp
AGREEMENT C -0 -01 70
I performance of this Agreement.
2 D. CITY shall indemnify, defend and hold harmless AUTHORITY, its officers, directors,
3 employees and agents from and against any and all claims (including attorney's fees and reasonable
4 expenses for litigation or settlement) for any loss or damages, bodily injuries, including death, damage
5 to or loss of use of property caused by the negligent acts, omissions or willful misconduct by CITY, its
6 officers, directors, employees or agents in connection with or arising out of the performance of this
7 Agreement.
s E. This Agreement may be terminated by either party upon giving sixty (60) days written
9 notice. Should CITY decide to terminate Agreement, CITY shall promptly return TravelTIP equipment
10 to AUTHORITY.
11 F. This Agreement may be amended in writing at any time by the mutual consent of the
12 parties. No amendment shall have any force or effect unless executed in writing by the parties.
13 G. The persons executing this Agreement on behalf of the parties hereto warrant that they
14 are duly authorized to execute this Agreement on behalf of said parties and that, by so executing this
is Agreement, the parties hereto are formally bound to the provisions of this Agreement.
16 This Agreement shall be made effective upon execution by both parties.
17 /
18 /
19 /
20 /
21 /
22 /
23 /
24 /
25 /
26 /
IKAL LCL camm'.clerlC lkwar0processtng. 90 0170
Page 4 of 5
i
1
2
3
4
5
6
7
8
9
10
11
12
13
14
IS
16
17
18
19
20
21
22
23
24
25
26
AGREEMENT C -0 -0170
IN WITNESS WHEREOF, the parties hereto have caused this Agreement C -0 -0170 to be
executed on the date first above written.
CITY OF NEWPORT BEACH ORANGE COUNTY TRANSPORTATION AUTHORITY
A Municipal Corporation
By
Mayor
By
Corey Creasey
Section Manager- Procurement
Date:
ATTEST: APPROVED AS TO FORM:
By By
City Clerk Kennard R. Smart, Jr.
General Counsel
Date:
Page 5 of 5
AGREEMENT C- 0-0170
ATTACHMENT A
Attachment A
TraveITIP System Description
AGREEMENT C -0 -0170
ATTACHMENT A
A major trend in the transportation field is the use of technology to help solve mobility
and traffic congestion problems. This field is commonly referred to as Intelligent
Transportation Systems (ITS). The Orange County Transportation Authority (OCTA)
has developed an ITS Master Plan for Orange County. A major element of that Master
Plan is the TraveITIP system. TraveITIP is an Advanced Traveler Information System
currently under development at the direction of OCTA.
OCTA has received a federal grant to design and deploy this innovative computer
system that will help Orange County residents and visitors plan their trips in and around
the county. Since TraveITIP is being developed using the National ITS Architecture as
a guide, this project is one of the first of its kind in the nation. With this grant, Orange
County joins a small network of American urban centers that have made a strong
commitment to providing better traveler information to their residents and visitors.
TraveITIP will allow travelers to receive information about:
• Traffic congestion on freeways and selected surface streets throughout Orange
County
• Train or bus schedules and routes
• Other events that may affect traffic conditions such as road construction projects or
special events such as parades, street fairs or major sports events
• Limited transit and auto trip planning capabilities based on existing traffic and road
conditions.
TraveITIP will receive its data from sources such as:
• Caltrans and other local Transportation Management Centers
• City Traffic Signal Master Controllers
• Law enforcement agencies reporting incidents
• Partner Agencies entering Advisories into the TraveITIP system via the internet or a
dedicated TraveITIP workstation located at their facility
TraveITIP information will be provided to a variety of sources and products. The
primary outlets will be an Internet website (www.traveltip.net), a highway advisory
telephone system and kiosks strategically placed throughout Orange County. Other
outlets may include radio and television reports. OCTA will also be seeking other
private sector participants that can disseminate TraveITIP information through other
products or services such as pagers and other wireless handheld and in- vehicle
devices.
OCTA has contracted with a team of private sector firms to develop, deploy and market
the system. The System Integrator contractor will operate and maintain the system for
the first year of operation, after which OCTA will assume those responsibilities.
TraveITIP is expected to be operational in Spring 2000.
ti
AGREEMENT C -0 -0170
ATTACHMENT B
Attachment B
Partner Agency Interface Description*
Interface descriptions for the Multisonics VMS 330 and Econolite traffic signal
systems are excerpted from the TraveITIP Design documentation set (Task 6.4.5 — Data
Monitoring Subsystem Working Paper, Chapter 2, (Rockwell, 1996))
Additional (vehicle /occupancy /speed — remote procedure call) VOS RPC documentation
for the Multisonics VMS 330 interface is provided by Intersection Development
Corporation (IDC).
AGREEMENT C -0 -0170
ATTACHMENT B
2. Traffic Management System & TMC Interfaces
The current traffic management systems within the county dictated to a great extent the
method where upon the traffic data shall be obtained for TraveITIP. Since there are a
variety of systems already in place, and each has an unique method by which data can
be extracted without making significant changes to the system or incurring significant
costs associated with the change, multiple approaches to extracting the data will be
recommended. For systems that come on line in the future, it is recommended that they
communicate with TraveITIP via the interface specification included in Appendix I.
The TraveITIP database will be dependent on the current TMS's for data accessibility.
An inventory of the each city had to be taken to determine the TMS type and model to
determine the feasibility of accessing the data required for the derivation of traffic
congestion.
Four systems are currently in use within the county; Multisonics, TracoNet, BI Tran,
and Econolite. Each of these systems are described in section 2. Modifications,
improvements, or replacement is recommended as required to provide for the data
collection of all the TraveiTIP prioritized information gaps.
Table 2.1 summarizes the Traffic Management Systems currently in each Orange
County city with the following paragraphs giving system descriptions and modifications.
AGREEMENT C -0 -0170
ATTACHMENT B
Table 2.1 Current County System Detection
City
Existing TMS
Manufacturer
Anaheim
UTCS
Brea
Multisonics
Buena Park
Multisonics
Costa Mesa
Multisonics
Cypress
TracoNet
Dana Point
Multisonics
Fountain Valley
Multisonics
Fullerton
Multisonics
Garden Grove
Multisonics'
Huntington Beach
BI Tran
Irvine
Multisonics
Laguna Beach
None
Laguna Hills
Multisonics
Laguna Niguel
None
La Habra
TracoNet
Lake Forest
None
La Palma
Unknown
Los Alamitos
TracoNet
Mission Viejo
Multisonics
Newport Beach
Multisonics
Orange
Multisonics
Placentia
Econolite
San Clemente
Multisonics
San Juan Capistrano
Econolite
Santa Ana
Multisonics
Seal Beach
TracoNet
Stanton
None
Tustin
Econolite
Villa Park
Multisonics
Westminster
Multisonics
Yorba Linda
Econolite
Unincorporated
Multisonics
Caltrans Maintained
Arterials (State
Routes
BI Tran
' In 1999 the City of Garden Grove completed their migration from Multisonics to Econolite
AGREEMENT C -0 -0170
ATTACHMENT B
2.1 Multisonics
2.1.1 System Description
A majority of the cities in Orange County use the Multisonics line of traffic management
systems and controllers. A couple of models of the system are currently being used;
the VMS330 and VMS220. The VMS220 is easily "upgradeable" by providing a new file
server system, which increases speed and reliability, and providing a platform for future
VMS330 enhancements and features. The VMS330 provides for centralized control,
monitoring, and database management for up to 256 intersections via the Multisonics
911 or 820 controllers.
2.1.2 VMS - 330/220 TraveITIP Interface
As the single centralization point for the controller information, the VMS shall provide
the TraveITIP interface. IDC has developed software package, as part of the latest
VMS330, which runs in the form of a Windows NT service on a DMA File server and
provides a Network Access Port. This allows applications running on other computers
on a LAN to obtain real -time data from the VMS -330 system. The port is accessed via
the NetBIOS protocol and uses a client -server architecture.
A newer software package is now available for the VMS -NT DMA/file server (DFS -NT)
which will provide for data sharing of volume, occupancy, and speed for pre - defined
detectors on the system. This option allows a client application to make Remote
Procedure Calls (RPC) to read accumulated data from the VMS as it is accumulated,
which is about once per minute. The client would be required to provide a dedicated
line and a network bridge (or router) for network communications. The cost of this
software upgrade to this file server is $10,000 per systems.
Most of the VMS -330 systems in the county do not have the configuration that provides
the RPC option for the uploading of Volume, Occupancy, and Speed (VOS) traffic data
except Santa Ana and Irvine. Westminster is in the process of buying one.
2.1.3 Interface Protocol
Appendix II contains a programming guide to the network packet definitions to obtain
the real -time information and the RPC service for periodic data collection from the VMS -
330 system including detail examples of the data exchange procedures.
2.2 Econolite
2.2.1 System Description
Traffic surveillance and management for regions /cities using Econolite traffic
management systems (e.g., Placentia, Tustin, San Juan Capistrano, and Yorba Linda)
is provided by the Zone Monitor IV software package hosted by a PC. The Zone
Monitor is used for real -time remote monitoring of intersections, the downloading of
' The DFS /NT upgrade was performed and the RPC service installed in 1996 for all of the VMS TraveITIP
Partner Agencies. This effort was arranged and funded by OCTA in preparation for the TraveITIP project.
AGREEMENT C -0 -0170
ATTACHMENT B
signal control patterns /modes, and the time synchronization of all traffic equipment in
the field. Monitored traffic data files are provided to the zone monitor via a 1200 or
2400 bps modem from the field installed ASC /2M or the older version KMC -10000
master controller.
Coordination of the intersections' signaling. is performed by masters controllers (or Zone
Masters), each controlling a zone. Each master can perform time -of -day or responsive
control for up to 24 intersections. Both the ASC /2M and KMC- 10,000 master controllers
can collect volume and occupancy logged data from up to 32 sampling detectors.
System detector volume and occupancy data is continuously collected by a master
which stores the latest 15, 30, or 60 minute log interval. The log interval time duration is
typically set at the zone master. However, access by zone monitor to the zone master
to change the log interval is provided when the system is set in the time of day (TOD)
mode.
2.2.2 Econolite TraveITIP Interface
The log interval data from the masters can be transmitted to the zone monitor upon
manual command or automatically according to schedule every 6, 12, or 24 hours.
Since TraveITIP requires system update at no more than a 5 minute update rate (and
more preferably at 5 minute logs), it is required that the TraveITIP real -time sample
period logs be requested directly from the zone master controllers.
Due to the limitation of the master controllers of only being able to monitor 32 detectors
per zone, the only viable option would be to extract logged data straight from each local
controller which is capable of monitoring 64 detectors per intersection for volume and
occupancy. This would be done in parallel to the normal traffic control /monitoring
operations (i.e., the controller will still be connected to the master controller and not
effecting the current traffic operations by the cities). The ASC /2 local controllers are
manufactured with a second RS232 :standard output port from which a direct data
request can be made. This data request can be made per the data exchange protocol
requirements of AB3418. The development for this interface has recently been
completed and is available with the purchase of any new ASC /2 controller at this time.
ASC /2 controllers in the field already, will however require the installation of additional
firmware into the controller.
Data Acquisition from multiple controllers can then be accomplished using an RS232
modem or multi -drop devices, or preferably by using Programmable Logic Controllers
(PLC). PLC technology is essentially the way in which Econolite currently
communicates between master and local controllers via their so called "telemetry' line,
and although their protocol is proprietary, it is based on standard PLC /telemetry industry
practice. This method of data acquisition is widespread and proven in the data
communications field and is often referred to as Supervisory Control and Data
Acquisition (SCADA). This approach will provide centralization of data collected from
multiple local controllers to fewer collection points.
AGREEMENT C -0 -0170
ATTACHMENT B
The aforementioned option is only available on Econolite's newest product line, the
ASC /2 controllers, which will provide volume & occupancy logs from the raw volume
and occupancy data received from the detectors. The controller will be provided with a
buffer dedicated for the raw volume & occupancy data from which a log will be
generated. At the time a request from TraveITIP is made for the log, the buffer is
cleared, thus starting the collection of data for a new log. The log interval is therefore
always determined by the length of time since the last data request. This is the case
unless the elapsed time has exceeded 255 seconds., which is the maximum allotted
time before the buffer is full. The message size from each controller will not exceed 100
bytes and will therefore not require high -speed communication (i.e., more than a 1200
baud modem for the minimal number of Econolite controllers on the prioritized
information gaps).
An ASC /2 controller costs approximately $4,000. The Orange County cities have a mix
of ASC /2, ASC /8, and KMC 8,000 local controllers. The KMC 8,000 and ASC /8
controllers would have to be replaced with the ASC /2 controller (already containing the
new firmware) and the ASC /2s currently in the field would require a firmware
replacement (which would cost $130).
To do a survey of the "type" of Econolite equipment at an intersection, the city's Zone
Monitor Workstation can used to determine all pertinent information except detector
placement. The number of system detectors, number of presence detectors, master
model number, controller model number, etc. can be extracted. Approximately half of
the controllers in the city of Tustin are ASC -2 controllers with plans to eventually
upgrade all controllers. It is unknown at this time what Placentia and San Juan
Capistrano (the two other cities with Econolite systems) have for controller models.
2.2.3 Econolite Data Format
As stated above, the second output port of the controllers (used by TraveITIP) meets
the standard communications protocol required by A133418.
Fran: Wart Tawneend TO: Mike E\ Cede: 11/113 TUn4: 23:14:77 t'pe 3 a113
IDC Network Access Port Definition
Version 1.1
Programming Guide
Network Packet Definitions
Intersection Oevelopment Corporation
Copyright O 1994 Intersection Development Cotporatioa tae.
PROJECT: Intelligent Transportation Management System
NAME: ITMS
P.EVISION HISTORY:
5.26.93 wrt. initial Document
2 -11 -94 wrt. Revised to match new packet header formats
6 -08 -95 mwa. Corrected to match `as -built" foilowing integration.
c:1.•l��vnoT MV'I111.n1.o<\ qr�
,,em: anar To.+ To: ",us fiv DM•: IIMM Mo : 23.13:07 Ppe a or is
1. ITMS Network Access Port Operation
The VMS DFS -330 provides a Network Access Port that allows applications turning on other computers on a IAN to obtain real -
time information from the VM0-330 system The port is accessed via the NetBIOS protocol and uses a client - server atrhhecrre.
The DFS -330 establishes a NetBIOS name an the IAN, and client applications can establish sessions with it and request data. All
information is exchanged within standard NetBIOS packets. This document describes the format of the packets used to request
and receive heal -time data
To identify each type of request and response packet the first four byte oreach packet will contain a unique text sequence used as
a packet identifier. After the parker identifier there will be a two byte version field for the packet If packet snvetturs ate changed
in later versions of so$ware, the Fr-- — version will be incremented. Neu there is an eight byte field containing the application
name, another two byte field for Utc application version, and a two-byte application number field. Thee fields will be collectively
referred to as the packet header. The application name and version fields we not used by the server, but the application number in
a request packet will be returned in the eonwponding response packet. The remainder of the block is application dependent but
cannot exceed the maximum block size supported by the NetBIOS connection type.
Real -time data can be requested from a DES -330 over the network as follows:
• A remote client establishes a NeLMOS session with ore or more DFS -330s cuing predefined NeLMOS as
(VM.SI, VMS2, etc.)
The remote client sends a data request packet (RT DATAREQ) which specifies the number of intersections (I -256)
for which data is desired.
• The DFS will then begin sending RT DATA packets to the remote client The packet will contain 64 bytes for each
i mrseetion requested, up to a maximum packet length of 16,384 bytes (for 256 intersections).
The remote client can stop the transmissions by hanging up the session or sending an RT DATAT:EQ for 7ero
intersections.
Recommended access method from non- NetBIOS network:
Install a dedicated - bridge- PC that can access both networks.
Write a simple program to rum on the bridge PC that establishes a NetBIOS session with each DFS on the network;
and sets up the data requests for ail desired data.
The bridge program can then collect real -time data from all DFSs, buffer it, and transmit it to the non- NetBIOS
network by any method desired.
Definitions for this document.
-Server' refers to a VMS DMA/File Server (DFS -330)
-BYTE' is a standard eight -bit byte
- WORD- is two bytes. The least-significant byte is frn.
,9
crown: Wait Ta..""nd Ta: Mike E~, Dan: 77MtY3 Ttm: 23:73:35 pu"-5 at 15
2. Network Packet Summary
RT NAK 'RNAK' Server negative acknowledgment.
RT DATAREQ °NREQ' Client recuest for data. The contents of the block specify
the data desired. The server will send RT_NAK if the
request is invalid.
RT_DATA 'RDAT' Server data block The server will continue sending data
blocks until RT REQUEST is received or the session is
disconnected.
RT HANGUP 'ZHNG- Sent by the server when it decides to hang up a session.
This can occur when the session times out after five
minutes or inactivity, or when the server program is shut
down. The client application should send a RT HANGUP
packet to the server before it closes a session.
rn- ueonor nnr nn.nLO <� o..•
From: Wan Te\.tM«W To: WYe Ev DwaT 11MMs n�: 21:16:27 tte" 6 or is
3. Network Packet Contents
RT NAK
TYPE: Server Response
FORMAT:
PACKET ID 'RNAK'
BYTE [4)
Packet version
WORD
Application Name
BYTE [8)
Application version
WORD
Application Number
WORD
Error type
WORD
Reserved (0)
WORD
NOTES.
Negative acknowledgment from the server. Toe server returns this if it received an invalid packet. or if a packet contains
invalid data The server tiny also NAK the request if it don not have enough memory to establish another session.
RT DATAREQ
TYPE: Client Request
FORMAT:
PACKET ID -NREQ'
BYTE [4)
Pat ket ve:ion (0)
WORD
Application Name
BYTE [8)
Application version
WORD
Application Number
WORD
System number (0 for VMS)
WORD
Number of Intersections (1 -258)
0 = none
WORD
NOTES:
This beats the collection of real-time data. The server will begin sending RT_DATA packets. A request for
zero intersections will rum off data collectior..
C:1 -. 1110l�OM NV� /I AI\l.Ot\ 0..
from: Wait To: MIY• E. va w 11nm n1 :23:17:00
RT DATA
TITE: Server Response
FORMAT:
Packet ID 'RDAT'
BYTE 4
Packet Version Q
WORD
Application Name
BYTE FBI
Application Version
I WORD
Application Number
WORD
System numoer
WORD
Data byte (1) — Intersection 1
BYTE
Data b,rte
BYTE
Data byte 64 — Intersection 1 '
BYTE
Data byte 1
BYTE
Data byte 2)
BYTE
Data byle (64 ) — Intersection 2
BYTE
Data byte 1) — Intersection N
BYTE
Data byte %2
BYTE
Data byte 64 — Intersection N
I BYTE
NOTES:
This packet is the response to an RT REQUEST. The packet contains 6e bytes of de
intersection number requested in the RT_DATAREQ packet The DFS polls the NPU
If the data has chanced since the last tran^ni^ ion, an RT_DATA packet will be trans:
co!lect and transnut data until it receives an RT_DATAREQ corarrand for zero inters.
the Real -Time Data Definition table for a list of the data contained in this paatet
c:�.. �.onor rvv nnra.00 w— <
from: Well Toweeeend To: Mike Ey Done: 11AAa Terse: 23'17:31
4. Reai =Time Data Definition
This table describes the contents or the data area of m RT DATA packet 5orn a DFS -330.
ByteN
Ofrset
Data Name
Data Definition
VMS
I
OOh
state
-
mmteria
x
0 standby
x
I flesh
x
2 free
x
3 coord
x
4 LOS coord
x
5 transition
x
6 sig event
x
7.preempt
x
8 remote
9 TBC
10 Tane -o[Day
11 Xsect plmt mode
2
Ol h
mode
m mcric
I -11: am as `state"
12 ICU LOS
x
3
02h
star" 1
bit map
x
d0 flash
x
dl conflict
0 ding failtac
d3 conmr caw
x
d4 caotroller a—
d5 manual operation
d6 cab door open
d7 short power down
4
03h
status 2
d0 long power down
dl cycle error
d2 coord error
d3 failed detector
d4 phase demand mon
x
d5 pit standby
•
x
d6 stop time
x
d7 date default
x
5
04h
phase greens
bit/phase
x
6
05h
phase yellows
brr/phase
x
O6h
phuercds
bitlphwe
x'
8
07h
ped walks
bit/phase
x
9
08h
pod clearances
bit/pbase
'x
10
09h
ped don't walks
bit/phase
x
1 1
OAh
overlap greens
bit/phase
x
12
OBh
ovcrlap yellows
bn/phwc
x
13
OCh
overlap reds
bit/phase
x
14
ODh
ped calls
bn/phase
x
15
OEh
veh calls/checks
bn/phase
x
16
OFh
local det act'ns
I brt/phase
C:b. 1J�D!\DT IYV`l1fLM.0<\ 0..R
Pepe a at 15
Firm: Wdr TO -naerd To: Mlk- Evans yea: 11MM5 llme: 27:13.'10
Byte#
OtTset
Data ?game
Data Deflultioo
VMS
17
l0h
aux det aeons
bitrphase
18.25
1 1 -18h
sys del vol
nummc
x
26-33
19 -20h
sys det oee
irrmeric
x
34
21h
local cycle timer
nit me
x
35
2h
cycle length
manene
x
36
23h
ring starts
bu map
x
d0-d2 ring 1, d3 umssed
x
d4-d6 ring 2, d7 unused
x
37
24h
spec fimc cord
btVSFC
x
38
25h
spec fine fdok
bicrSFF
x
39
2671 -
spec func num
numeric
x
1 40
27h
command source
numeric
0- default
x
1 -ICU evrd
x
2-pp ovrd
x
3 -ICU TIC
x
4 -grp TIC
x
41
28h
panern/plan aunt
word numeric
x
42
29h
high byte of pattern
x
43
2Ah
panem ripe
numeric
x
44
2Hh
group number
numeric
x
45
2Ch
Current dial
numeric
- .16
2Dh
current offset
numeric
47
2rh
c=ent split
I numeric
483
2Fb
sync phases
bit/phase
x
49
30h
fixed phases
bo/phase
x
50
31h
phase sequence
numeric
s:
51
32h
can start
bit/phase
x
52
33h
can stay
bit/phwe
x
33
34h
must hold
( bit/phsse
x
54
35h
pref can start
bit/phase
x
55
36n
hour
numeric
x
:G
37h
minute
numeric
57
38h
second
numeric
58
39h
local tiled dets
I bit/detector
59
3Ah
sys failed dets
be/detector
60
3Bh
telem valid%
numcTie
x'
61
3Ch
telem back%
n,',m Cnc
x'
62
3Dh
5 min volume
numme
03
3Eh
reserved
64
3Fn
reserved
' I•.cros marked are generated in the server, not the local controller
Totes regarding the Real -Time Data Definition:
ra" 2 0713
1. System Detector Occupancy values (bytes 26-33 of packed are normally reported in percentage (0.100). Suspect Detector
information may be flagged end renurted m the Gccupancy byte positions if the high bit if the byre is set. The following 5trfpecx
Detector codes are possible in each System Oczupancy byte position
rAr y�OnDT TYV` /I n.n1.OH A.]
From; Wan Tovamene TO: YI4e Ev DND: 11011115 71me: D:ta:50 ►q* 10 at 15
1000 Y- /-Vl NO CALL.
1001 Y<).'uC CONTMEJOUS CALL
1010 YXXX: EXCESSIVE COUNTS
1011 YXXX: MAN PRESENCE
In each case, Y-0 indicates System Detector, y-1 indicates Phase Detector. X70( indicates detector number (0-7).
3. Ring Starus (byte 36 of packet) provides a 'limited NEMA Coded Starts' value for each in* T"a s. nss i1 peeked imo three
bits per ring (bits 0-2 for Ring 1, bits 4.6 for Ring 2). Bits 3 and? are tmused and set to 0 by the VMS. The possible values for
each 3 -bit Coded Status are:
0 (000) -GREEN INITIAL
1 (001) - GREEN EXTENSION
3 (010) - undefined
3 (011) ° GREEN REST
4 (100) -YELLOW CRANGE
5 (101) - RID CLEARANCE
6 (110) - RED REST
7 (111) - undefined
3. Pancm Type (byte 43 of packct) indicates the type of pattern currently selected for the ICU. Possible values are:
1 - BACKGROUND (standard coordination with cycle timer, splits, o&ets, etc)
2 - PREEMPT (specialized pattern runs timings for delay/hold/preempt phases, etc)
3 - FLOW (platoon recognition, whereby upstream intersections relay traffic iaforrmtion dowrutrearm)
4. Phase Sequence (byte 50 of packet) indicates the coordination -based selection for the fill- demand sequencing chancteristim of
the ICU. The sequence allows lead/lag modification for each phase pair. The possible values for the phase sequence are:
seo= RANG 1 RANG 2 seq# RING 1 RING 2
1- 1234 5678 9- 1234 5687
2- 2134 5678 10- 2134 5687
3Y 1243 5678 11- 1243 5687
4- 2143 5678 12- 2143 5687
5- 1234 6578 13- 1234 6587
6- 2134 6578 14- 2134 6587
7- 1243 6578 15- 1243 6587
8� 2143 6578 16- 2143 6587
C:1-� 41 Dl�DT Il(1!• /I I1.I1] Ct, 0.. C
�3
General Notes and Keys to Codes
1. ID Key
01 WB02
Arterial No.'I I— r <:'ctorS •n No.
Traffic lanes (NB,SB,EB.%.,
2. Detector Status
E = existing, in each lane
S = existing, single -lane (only one lane of mufti-lane arterial covered)
M = existing, multilane (one detector covering more than one lane)
N = new installation
3. Controller Type
170(M) = Cattrans Standard 170,170A, 170E, 170-C8
MS###[M) = Muttisonics 820, 820A, 911, 9118
Econ = Econolite
T1 = Computer Service Company 1'1
Trac = Traconex
4. Location of Master
a. If signal controller is isolated, note as 'none"
b. If signal controller is connected to a field master, note intersection where master is located
c. If signal controller is connected to a central master, note 71VIC'
.ram: ".I lo• To: M... nwrs ..w•: nnua um•. r� :ors.
VOS RPC Service for VMS
Version 1.0
30 August, 1995
Intersection Development Corporation
Product Documentation
..vim ......-
The VOS RPC Service provides traffic Volume, Occupancy, and Speed information
acquired by a VMS -330 system to client programs on a network via the RPC (Remote
Procedure Call) standard. This allows clients running on any operating system and any
network to access the data in a standard format. The VOS RPC Service runs in the form
of a Windows NT service, on the DFS -NT (DVL4/File Server -NT) which is part of the
VMS -300 system.
Ima.en..vmnn fL..��..n.n�nr ('nrr..asnnn . Vne D..� M�u...�neannn Dante 1
ream: WWI T•"nw+a To: r•we tvv.a .Tile: lln /1p I.fr.e. a+;[L1:W - Y•ye 12 m 15
1. Installation
The VosRpc service requires MNct service version 3.01 or later to be insulted on the DFS. The date
on the DfsNetSv.exe file in the c :\utserslidc directory should be 8(30/95 or leer.
To install the VosRpc service, put the installation disk in the floppy drive on the DFS -NT and run
-sctup.bat ". You can do this from the Program Manager, File Manager, or from a eontmatd prompt.
Scrup will copy the vosrpc.exe file to the c. \users\idc directory, install it as a service, and start it. The
scr icc will automatically start each time the swum is booted.
A configuration option setting is required to turn on VOS buffer generation in the DfiNet Service. In
the VMS-M file (in the \VVM4KI directory), the option "Share" in section "lDfsVos]" should be set to
a "I ". This is automatically done when the service is installed VOS buffer generation can be disabled
by setting this option to "0 ".
2. Command Line Options
The %wrpc.exc program is not normally run from the command line. However. the following
command line options are available:
• imsull Installs the program as a service.
• :remove Removes the service.
• !debug Rums the service :s a console application.
A message is printed to the console each time an RPC can is processed.
(use Control -C to e)dt)
3. Enrors
The VosRpc service reports errors in the NT Event Log and in the DFS event log (cun=dy, the
dayMcs in c:\day.) When the service starts, it puts an information message in the DFS event log for
each of the protocol sequences that it attempts to use. The message will indicate whether the protocol
was loaded successfully or not.
4. Data collected
The VosRpc service uses a data buffer collected by the DFS VOS Monitor service, which is pan of the
Dfs \etSv service. This data is collected once every mutuu, on the minute boundary, directly from the
NPUs. The NPUs collect data from the controllers once per minute or once per cycle, if the controller
is in coordination. The controller normalizes its data to `counts per minute" even if it is running a cycle
longer than a minute. This can lead to results which do not quite match the actual counts, but these
numbers are actually more useful for traffic - responsive calculations since they shown an average for a
whole cycle, instead of dropping to zero when the light turns red.
For the NPUs to collect data for an intersection, the detectors must be set up in Detector Geometries
on the VMS. However, the VMS does not have to be running a VOS monitor. The data collection is
also independent of the rIMS VOS Data Collection service.
Inn "T�•nn rL....nn•..�n. ('i...v.. — - Vn D.v rl.Y.n.. "n.-innn P.n.
5. Usage
To access the data collected by NosRpc, an application should make an RPC call in the following
format: (Also sec the 11DL file at the end of this document)
error szat'�s
VmsGe.Vos(
handle —t Banding,
unsigned long dwSvstemNumber,
unsigned long dwTimestar..,
._ioned short wNumintersec =iens,
_tee :DataBu_ffer(j,
unsigned long - pdwSizeOfBuffer
Ir '
• Binding is the RPC binding handle
• dwSvstemNumber is ahvays zero on VMS systems. It maybe used on CoinServcrsys[ents to
choose an on -str=1 master.
• dwTimestam p is the Unix timestamp (seconds since Jan 1, 1970) of the previous buffer of data
returned_ VmsGetVos will not return another buffer until one is available which is later than this
timestamp. Call with this set to zero the fast time, then use the timestanip returned in the buffer.
• wNum Intersections detcrmires the number of intersections for which data is to be returned
bDatiMufrer is a pointer to the buffer in which the data is to be placed.
• pdwSireOfBuf%r is a pointer to a DWORD containing the size of bDaraBu$er. If necessary,
the server will change this number if it returns a different -sized buffer than requested
The return code from the function is a standard RPC error status code. If the VosRpc server has no
data available, it will return no data in the buffer and set •1 d izeOfBu$er to zero. If the data is
available but it is not newer than the passed timestamp, the server will rerun is current timcstampi in
the data buffer (4 bytes). If there is new data to return, it will copy it into the buffer provided If you
make the caD with tiwTimcstamp set to -1, then the server w(D wait until new data is available before
returning This can take up to one minute.
The returned data contains a rwo-bytc volume count, a sindc -byte occupancy, and a single -byte speed
for every detector on the system. The volume is in cars per minute. The occupancy is in percent (f}
99 %). If the high bit in the occupancy byte is set (> 127) , then that detector has been declared suspect
by the VMS and the data for that detector is not valid. The speed is in miles per hour.
On the VMS, not all the elements in this array will be used. The first 8 dc=tors an the system
detectors, the next 8 arc the phase detectors, and the next 8 art the ped detectors. The last 8 arc not
currently used. System detectors collect volume, occupancy, and speed Phase detectors only collect
volume and occupancy. Ped detectors only collect volume. Elements in the array which arc not used
will be zero. When system types are added which return more data, the same API and tomcat will be
used to acquire data from[ them.
6. Protocol Support
The VosRpe smite automatically listens on the following protocols:
• ncalrpc - Local RPC. Works only on same [machine.
• ncaen_np - NCA connection over Named Pipes
rte,. —,a _ v,O.v hv,�...•..,a,.....
f1
From: WW Tor.~ d To: Ylh. Ev Du.; 11nio Mn : 21;21;39 ti9. tl of 1s
nracn_ip_tcn - NCA connection over TCP.IIP
• ncadg_ip_udp - TCP/IP daugam
The TCP/IP protocols require TCP/IP to be installed on the DFS. It is not installed by default To
install TCP/IP, go to the Network icon in the NT Control Panel. Push the "Arid Solis= " button and
choose "TCP/IP protocol" from the list. You will need to obtain an IP address for the machine from
your network administrator.
7. Sample Code
A sample client program, vrpcc.exe, is supplied to permit testing of the RPC eonnectian. The source to
this program is provided on the installation disk. It is a Wm32 console application. so it can only be nut
on a Windows NT machine. This progan has the following eommmand -Ime options:
-n <urvcr addr>
- Dcfauhs to local machine
-t <protseq>
- Defaults to ncalrpc (fast, local only)
-w
- waits for data
-i <Nicus>
- limits X ices to collect data for ( defauh = 256)
You can run this on the same machine by }atst running "vrpec" with no options. To tun it on another
Windows NT machine, use wrpcc -t ncacn_np -n VMSI ", where VMS1 is the network frame of the
DFS -N7 running the VosRpc service.
The program will can VrruGetVos every ten seconds (rayless you use the -w option). When it gets a
data buffer from the server, it prints out the: volume, occupancy, and speed for each detector which had
non -zero data. To exit the program, hit Me key.
In,..�vr.nn rl�wln.,..,.n, (�nn,nnannn . Vic O.r rYr,,.n.nbl,nn Can. 6
-rR
rra "m leers. 10: t.u. ov.n. Da.: lima* It n :3]S.-77 . Pow 13 at is
Use this ML 5[e to build a client application:
idl for vosrpc
I
uuid(d58fc5e0 -de20- lice- 9c4c- 080009la54c7),
version(1.0)
interface VosRpcService
(
error status_t
Ping(
[in] handle-z Binding
error status t
VmsGetVOS(
[in] handle _t Binding,
[in] unsigned long dwSystemNumbez,
[in] unsigned long dl>= imestatap,
tin] unsigned short wNumtntersections,
[out, size is(- polSizeO= Buffer)] byte bDataBuffez[],
[in, out] unsigned Iona - pdwSizeofBUffer
The data buffer is formatted as follows:
/• vos -:mf.h - structures for XIS VOS mmf sharing •/
#pragma pack(1) /• single -byte structure alignment •/
typedef struct
WORD volume;
BYTE occupancy;
BYTE speed;
! DNTVOSDATA; // structure is 4 bytes long
typedef struct I
D= TVOSDRTA det[321;
! INTVOSDATA;
typedef struct (
DWORD dwTimeStamn;
INTVOSDATA icu[256];
VOSSY.BUF;
#pzagea pack()
/- end of vosmmf.n •/
i/ max 32 detectors per intersection
ii 128 bytes per intersection
// t °_me when data was collected
/i the data 128 • 256 - 32768
// tctal size will be 32772
AGREEMENT C -0 -0170
ATTACHMENT C
Attachment C
Partner Agency:
Floor Plan
System Block Diagram
Contacts (technical /operating)
N
m
u
a
NJ
lit
go
ir
�s
I
N
® H
X x
U
Q
0 ZZ
�13C. 6
W C
O
Z 4
F
U
ju
w
w
r
r
P,
0
F
Y: 6
O
H i
O
I I-
o _ I$E
I "iK IE8
I
I
i
I
I "
I
I m
I b
I
I
I o
I
I
I
LY
4
a
a
I I�
I
I
L—
>,2
J �
6
N
�Cv
0
1 W
I
I
I
I
I
I
I
1
I
I
I
I
I
I
I
1
I
I
I
I
I
I
I
JY 4[
1m I Cr
O £
u .2'a
I �
�a
�i
H
yp�
Y
3
U6
W
m
0
0
3
4
0
U
N
Q
0
El
0
w
Y
6
eli
>I
Contacts
Primary TraveITIP Staff Contact
Tony Brine
Ph 949/644 -3329
Secondary TraveITIP Staff Contact
Jim Brahler
Ph 949/644 -3346
City Traffic Engineer
Rich Edmonston
Ph 949/644 -3345
-� 3
AGREEMENT C - "170
ATTACHMENT C