HomeMy WebLinkAboutC-3342 - Amendment No. 1; TravelTip Program Cooperative Agreement No. C-0-01701 AMENDMENT NO. 1 TO
2 COOPERATIVE AGREEMENT NO. C -0 -0170
3 BETWEEN
4 ORANGE COUNTY TRANSPORTATION AUTHORITY
5 AND
6 CITY OF NEWPORT BEACH n
7 THIS AMENDMENT NO. 1 is made and entered into this � day of -�SWr X— , 2001
8 by and between the Orange County Transportation Authority, a public corporation of the state of
9 California (hereinafter referred to as "AUTHORITY ") and the City of Newport Beach, a municipal
10 corporation in the State of California (hereinafter referred to as "CITY ").
11 WITNESSETH:
12 WHEREAS, by Cooperative Agreement C -0 -0170 dated May 19, 2000, AUTHORITY is the
13 lead agency in the development of a county wide multimodal advanced traveler information system
14 (ATIS), (hereinafter known as'TravelTIP "); and
15 WHEREAS, AUTHORITY has completed development of the TraveITIP system which requires
16 a connection to the city's traffic signal master controller system as a means of collecting arterial traffic
17 information as identified in attachments A, B, and C of original Agreement; and
18 WHEREAS, CITY agrees to continue to provide AUTHORITY access to the city's traffic signal
19 master controller system in support of TraveITIP;
20 NOW, THEREFORE, it is mutually understood and agreed that the Agreement No. C -0 -0170
21 between the AUTHORITY and CITY is hereby amended in the following particulars only:
22 Amend Article 3. MUTUAL AGREEMENTS, Page 3 of 5, paragraph A, to delete paragraph A
23 in its entirety and in lieu thereof insert the following:
24
25
26
IDDK
!:IC..mC RICA IWORDPROCIAGREE"END1am100170.do
Page 1 of 2
1'
2
3
a
5
6
7
s
9
10
11
12
13
14
15
16
17
is
19
20
21
22
23
24
25
26
• . AMENDMENT NO. 1 TO
AGREEMENT NO. C -0 -0170
ARTICLE 3 MUTUAL AGREEMENTS
It is mutually understood by the parties hereto that:
A. This agreement shall commence upon execution by both parties and continue
in full force and effect unless earlier terminated as provided elsewhere in this agreement.
The balance of said Agreement remains unchanged.
Upon execution by both parties, this Amendment No. 1 shall be made effective on
February 1, 2001.
IN WITNESS WHEREOF, the parties hereto have caused this Amendment No. 1 to
Agreement No. C -0 -0170 to be executed on the date first above written.
CITY OF NEWPORT BEACH
A Municipal Corporation
By Cf+
Gary Adams
Mayor I
Date: 3
ATTEST:
By ,�, nE, M.
LaVonne Harkless
City Clerk
Date: �/ 3�C1
ORANGE COUNTY TRANSPORTATION AUTHORITY
APPROVED AS TO FORM:
By
Kennard R. Smart, Jr.Qj
General Counsel
Page 2 of 2
C - 33 %-la-
March 13, 2001
CITY COUNCIL AGENDA
ITEM NO. 6
TO: Mayor and Members of the City Council
FROM: Public Works Department {{��PPPPRRQQVV
SUBJECT: AMENDMENT NO. 1 TO THE TRAVELTIP PROGRAM COOPERATIVEED
AGREEMENT NO. C -0 -0170 BETWEEN THE ORANGE COUNTY
TRANSPORTATION AUTHORITY AND THE CITY OF NEWPORT BEACH
RECOMMENDATIONS:
Approve Amendment No. 1 to the TravelTip Program Cooperative Agreement No. C -0 -0170
between the Orange County Transportation Authority (OCTA) and the City of Newport
Beach.
2. Authorize the Mayor and the City Clerk to execute Amendment No. 1 to the Agreement.
DISCUSSION:
On April 25, 2000, the City Council approved Cooperative Agreement No. C -0 -0170 between
the OCTA and the City of Newport Beach. This Agreement outlines the responsibilities of
OCTA and the City with regard to the TravelTip Program, which is a countywide traveler
information program. A remote workstation computer has been installed in the Public Works
Department by OCTA for the City's use in entering up -to -date traffic conditions as a part of the
TravelTip Program. OCTA is continuing with their installation of TravelTip equipment, and the
connection to the City's traffic signal master computer controller.
The Cooperative Agreement No. C -0 -0170 stated that all work associated with the installation of
the TravelTip equipment would be completed by February 1, 2001. Amendment No. 1 to the
Cooperative Agreement revises the section referring to a completion date, and simply states
that the Agreement will continue in full force and effect unless mutually terminated.
Res" fully subm4ted,
�� I�J4
PUBLIC WORKS DEPARTMENT
Don Webb, Director
By: 7 �%-h vk /u ,__E_�
Antony Brine, P.E.'
Transportation Engineer
Attachments: Cooperative Agreement
Amendment No. 1
9
IT'I L4111,14.hf1,[•afife
i
COOPERATIVE AGREEMENT NO. C -0 -0170
BETWEEN
ORANGE COUNTY TRANSPORTATION AUTHORITY
AND
CITY OF NEWPORT BEACH
THIS AMENDMENT NO. 1 is made and entered into this day of 2001
by and between the Orange County Transportation Authority, a public corporation of the state of
California (hereinafter referred to as "AUTHORITY ") and the City of Newport Beach, a municipal
corporation in the State of California (hereinafter referred to as "CITY ")
WITNESSETH:
WHEREAS, by Cooperative Agreement C -0 -0170 dated May 19, 2000, 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 has completed development of the TraveITIP system which
requires a connection to the city's traffic signal master controller system as a means of collecting
arterial traffic information as identified in attachments A, B, and C of original Agreement; and
WHEREAS, CITY agrees to continue to provide AUTHORITY access to the city's traffic signal
master controller system in support of TraveITIP;
NOW, THEREFORE, it is mutually understood and agreed that the Agreement No. C -0 -0170
between the AUTHORITY and CITY is hereby amended in the following particulars only:
Amend Article 3. MUTUAL AGREEMENTS, Page 3 of 5, paragraph A, to delete paragraph A
in its entirety and in lieu thereof insert the following:
ID.DK
C Xind.s\TEMP\ mt W170. d=
Page 1 of 2
• • AMENDMENT NO. 1 TO
AGREEMENT NO. C -0 -0170
ARTICLE 3. MUTUAL AGREEMENTS
It is mutually understood by the parties hereto that:
A. This agreement shall commence upon execution by both parties and continue
in full force and effect unless earlier terminated as provided elsewhere in this agreement.
The balance of said Agreement remains unchanged.
Upon execution by both parties, this Amendment No. 1 shall be made effective on
February 1, 2001.
IN WITNESS WHEREOF, the parties hereto have caused this Amendment No. 1 to
Agreement No. 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
ID'. OK
C9w,ndows1TEMP1am 100170.dO
Page 2 of 2
1
2
3
a
5
6
7
8
9
10
11
12
13
14
Is
16
17
18
19
20
21
22
23
24
25
26
KP kp
L ICAFIWCLE
0 0
COOPERATIVE AGREEMENT C -0 -0170
BETWEEN
ORANGE COUNTY TRANSPORTATION AUTHORITY
AND
CITY OF NEWPORT BEACH
THIS AGREEMENT, made and entered into this `191 day of K 2000, by
and between the City of Newport Beach, a California municipal corporation in the Stat alifornia,
(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;
PM
Page 1 of 5
1
2
3
a
s
6
7
8
9
10
11
12
13
14
is
16
17
18
19
20
21
22
23
24
25
26
KMPAmp
• AGREEMENT C -0 -0170
NOW, THEREFORE, it is mutually understood and agreed by both parties hereto as follows:
ARTICLE 1. RESPONSIBILITIES OF CITY
CITY agrees to the following responsibilities:
A. To allow AUTHORITY and its Consultant(s) access to CITY's Traffic Signal Master
Controller in the manner directed by CITY Traffic Engineer.
B. To ensure that the PROJECT is constructed in accordance with Attachments B and C
and;
C. To provide staff, as required to assist with the construction of PROJECT.
D. To work with AUTHORITY and its Consultant(s) on coordination and scheduling of
equipment installation and scheduling in accordance with Attachments B and C including ongoing
system operation and maintenance.
E. To exercise reasonable care in protecting the physical and logical connections between
the CITY's Traffic Signal Master Controller and TraveITIP remain intact. Equipment installed by
AUTHORITY may be used by CITY authorized personnel only for the intended purposes.
F. To advise AUTHORITY in advance of all CITY modifications of hardware and /or
software for the Traffic Signal Master Controller that may impact the TraveITIP System connection.
ARTICLE 2. RESPONSIBILITIES OF AUTHORITY
AUTHORITY agrees to the following responsibilities:
A. To serve as lead agency for the PROJECT, as described in Attachments B & C, li
including the initial connections and operations and maintenance.
B. To ensure that the PROJECT is constructed in accordance with Attachments A, B and
C.
C. To be responsible for review and input regarding preparation and processing of all
necessary documentation related to the installation and ongoing operations and maintenance.
i
D. To contact CITY, twenty -four (24) hours in advance to gain access to CITY's Traffic
Signal Master Controller System.
�camm <iencakwompropessmgUgO -01 70
Page 2 of 5
' • AGREEMENT C -0 -0170
1 E. To be responsible for the coordination, scheduling and costs associated with the
2 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:
5 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
15 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
18 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
22 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
25 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
L 1CAMMIXATW L\camm� ieri al\wordpoce$S,n9UgO -01]0
II Page 3 of 5
.... ........ .
• • AGREEMENT C -0 -0170
t 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 TraveITIP 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
15 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 /
KMP km
L\CAMWI T LEL'U MMm Cleat RWO�Wp esing1900170
Page 4 of 5
0 • 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 ^ By
Ma Corey sey
Section Manager -P ment
Date:
ATTEST:
By
City Clerk
Date: -� .?
Le, 0
APPROVED AS TO FORM:
By
Kennard R. Smart, Jr.
General Counsel
KMP:kMp
L lclmm� T LEL
Page 5 of 5
I COOPERATIVE AGREEMENT C -0 -0170
2 BETWEEN
3 ORANGE COUNTY TRANSPORTATION AUTHORITY
a AND
s CITY OF NEWPORT BEACH
6 THIS AGREEMENT, made and entered into this ) OIL Yt-1 day of 2000, by
7 and between the City of Newport Beach, a California municipal corporation in the Stat alifornia,
s (hereinafter referred to as "CITY "), and the Orange County Transportation Authority, a public
9 corporation of the State of California, (hereinafter referred to as "AUTHORITY ").
10 WITNESSETH:
11 WHEREAS, AUTHORITY is the lead agency in the development of a county wide multimodal
12 Advanced Traveler Information System (ATIS), (hereinafter known as "TraveITIP "), and
13 WHEREAS, AUTHORITY currently has a TraveITIP System Integrator Consultant under
14 contract who will assist AUTHORITY in installing a connection to the CITY's Traffic Signal Master
15 Controller System as a means of collecting arterial traffic information as identified in Attachments B
16 and C hereinafter referred to as ( "PROJECT "). The TraveITIP System Integrator Consultant will be
17 responsible for TraveITIP operations & maintenance for a period of twelve (12) months from date of
is TraveITIP system acceptance.
19 WHEREAS, AUTHORITY agrees to fund the TraveITIP connection with CITY as identified in
20 Attachments B and C at no cost to the CITY; and
21 WHEREAS, the TravelTIP connection will be constructed by and in accordance with
22 Attachments A, B and C and shall be subject to technical direction and approvals by AUTHORITY, its
23 Consultant(s), and CITY ; and
24 WHEREAS, CITY and AUTHORITY desire to herein specify their respective responsibilities for
25 performance of work outlined in Attachments B and C; and
26 WHEREAS, CITY and AUTHORITY each has full authority to enter into this Agreement;
\CLE�ICAL'I.VlOROPROC,AGREE1001 ]0,000Oa105i003:52 PM
Page 1 of 5
• • wrr�rrnnvur r n nw an
I 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
5 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.
v 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
19 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 J1 Signal Master Controller System
KMP:kmp
Page 2 of 5
• • AGREEMENT C -0 -0170
1 E. To be responsible for the coordination, scheduling and costs associated with the
2 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
15 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
18 Attn: Don Webb Attn: Kathleen Perez
i
19 Director of Public Works Sr. Procurement Administrator
20 Tel: ( 949 ) 644 -3311 Tel: (714) 560 -5743
21 kperez @octa.net
22 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
25 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
KNIR: mp
L:ICAMMIXAT LEL:. camm .dencanwprdpmceseing,ag0 -Ot]0
Page 3 of 5
• AGREEMENT C -0 -0170
1 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 TraveITIP 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
15 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 /
KMP:kmp
L:?OAMMIMT LEL. �cammiNer ¢aRworCpmcessingtag00RO
Page 4 of 5
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
• 0 AGREEMENT C -0 -0170
IN WITNESS WHEREOF, the parties hereto have caused this Agreement C -0 -0170 to be
i
executed on the date first above written.
CITY OF NEWPORT BEACH ORANGE COUNTY TRANSPORTATION AUTHORITY
A Municipal Corporation
By By G
May Corey r s e y
Section Manager P ement
Date: ) U C
ATTEST:
By ����
City Clerk
Date: , /����-, 0
APPROVED AS TO FORM:
By L—,/(2-&,4
Kennard R. Smart, Jr.
General Counsel
L iCAMM,N T 170
II Page 5 of 5
• 9GREEMENT C -0 -0170
ATTACHMENT A
Attachment A
TraveITIP System Description
• IGREEMENT 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.
• 4PGREEMENT 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).
• %REEMENT 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.
0
OGREEMENT C -0 -0170
ATTACHMENT B
Tible 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
• CEEMENT 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 system'.
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.
0
aREEMENT 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.
• OREEMENT 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 AB3418.
From: Wen Te .Md To: MIME Ev v Daa: 11HA5 71 �: 2]Yl:]7
!DC Network Access Port Definition
Version 1.1
Programming Guide
Network Packet Definitions
Intersection bevelopment Corporation
Copyright O 1994 Intetsectiott Development CorporatiatL Inc.
PROJECT: Intelligent Transportation Management System
NAME: ITMS
REVISION HISTORY:
5 -26.93 wrt. Initial Document
2 -11 -94 wn. Revised to match new packet header formats
6 -08-95 mwa. Corrected to match "as- built' following integration.
r:�.. woner� rw•nn.na.en o.. �
page ] 01 15
0 0
rrom: wwt To.,ns.no TD: M,k• Evrna DM.: limn Tim.: 23:15.07 ►aq. a of 13
1. ITMS Network Access Port Operation
The VMS DFS -330 provides a Network Access Port that allows applications Waning on other computers on a LAN to obtain real -
time information from the VMS -330 system The port is accused via the NetBIOS protocol and toes a elieat -sorer arehitecnae.
The DFS -330 establishes a NetBIOS nmme on the LAN, 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 real -time data
To identify each type of request and response packet the first four bytes oreach packet will contain a unique text sequence used as
a packet identifier. After the packet identifier there will be a two byte version field for the packet If packet structures are changed
in late versions of software, the pr -t. — version will be inaemenud. Next there is an eight byte field containing the application
name, another two byte field for t:te application version, and a rwo-byte application number field. These fields will be collectively
referred to as the packet header. The application name and version fields are not used by the server, but the application malt r in
a request packet will be returned in the corresponding response packet The remainder of the block is application depeadertt but
cannot exceed the maximum block size supported by the NetBIOS connection type.
Real -time data can be requested from a DFS -330 over the network as follows:
• A remote client establishes a NetEOS session with one or snore DFS -3303 using predefined NetBIOS Dames
(VMSI' VMS2, etc.)
• The remote client sends a data request packet (RT DATAREQ) which specifies the number of intersections (1 -256)
for which data is desired.
• The DFS will then begot scrd ng RT DATA packets to the remote client. The packet will contain 64 bytes for each
intersection requested, up to a maximum packet length of 16,384 bytes (for 256 intersections).
• The remote client tarn stop the transmissions by hanging up the session or sending an RT_DATAREQ for zero
intersections.
Recommernded access method from non- NetBIOS network
Install a dedicated "bridge- PC that can access both networks.
Write a simple pr ogan to run on the bridge PC that establishes a NetBIOS session with each DFS on the network
and sets up the data requestu for all desired data.
The bridge program can then collect real -time data f: cm 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 DIvtA/File Scrvcr (DFS -330)
-B==- is a standard eigl;t -bit byte
"WORD- is two bytes. The bust- siz:uficant byte is firs..
,o : Wait Taw vend To: Mlk. Ew pal: 11MM Timm: 2215:55
2. Network Packet Summary
RT NAK 'RNAK' Server negative acknowledgment.
RT DATAREQ 'NREQ' Client request 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 of inactivity, or when the server program is shut
down. The client application should sena a RT HANGUP
packet to the server before it closes a session.
hpW 5 of 15
Pram: WNr Tb w,"nd Ta: YIMr. Evv Din: iimms Tor.: 2]:76:27 ►a" 6 of is
3. Network Packet Contents
RT NAK
TYPE: Server Response
FORMAT:
PACKET ID 'RNAK'
BYTE (41
Packet version
WORD
Application Name
BYTE 18)
Application version
WORD
Application Number
WORD
Error type
WORD
Reserved (0)
WORD
NOTES:
Negative acknowledgment from the server. The server rettcas this if it received an invalid packet, or if a packet contains
invalid data The server may also NAK the request if it does not have enough memory to establish another session
RT DATAREQ
TYPE: Client Request
FORMAT:
PACKET ID "NREQ'
BYTE 141
Packet version (0)
WORD
Application Name
BYTE (8)
Application version
WORD
Application Number
WORD
System number (0 for VMS)
WORD
Number of Intersections (1 -256)
0 = none
WORD
NOTES:
This be_mns the collection of real -time data. The sorer will begin sending RT DATA packets. A request for
zero intersections will r= of data collection..
C:1.4�V/IVT I'YY IIM1MAO 0..•
0
0
From: Wait Terroor d To: MIME E� tko: lln/25 'n r: 23:17:00
RT DATA
TYPE: Server Rrsponsc
FORMAT:
Packet ID 'RDAT-
BYTE f4l
Packet Version 0)
WORD
Aoolication Name
BYTE
r8l
Aoolication Version I
WORD
Aoolication Number
WORD
System numoer
I WORD
Data byte (1) — Intersection 1
BYTE
Data bvte
BYTE
Data b e (64) — Intersection 1 '
BYTE
Data byte 1)
BYTE
Data byte 2)
BYTE
FDita
b e (64 ) — Imersection 2
BYTE
I
Data byte 1) — Intersection N
BYTE
Data byte '2
BYTE
Data byte 64 — Intersection N
BYTE
NOTES:
This packet is the response to an RT REQUEST. The packet contains 64 bytes of da
interxaion number requ=ed in the RT_DATAREQ packet - The DFS polls the NPU
If the data has chased sinee the last trartsminion, an RT_DATA packet will be truss.
u !leci and trananu data until it receives an RTDATAiLEQ cottntatd for zero inters_
the Real -Tine Data Deuni6on table for a list of _ the data contained in this packet.
ca.. u<onor� nrv- ntinl.o <i 0.. <
0
0
From: Wary To and To: Mike Evens Date: 11M/a3 Tow: 23n7:3a P%" a of is
4. Real -Time Data Definition
This table describes the contents of the data area oran RT DATA packet from a DFS•330.
Bvtek
Offset
Data Name
Data Definition
VMS
1
00h
state
numeric:
x
0 standby
x
! flash
x
2 free
x
3 word
x
4 LOS co=d
x
5 transition
x
6 sig event
x
7 .preempt
x
8 remote
9 TBC
10 Time-of-Day
11 Xsect plat[ mode
2
01h
mode
n==c
1 - 11: sane as "state"
12 ICU LOS
x
3
02h
status 1
bit map
x
d0 flasb
x
dl conflict
d2 diag failure
d3 comm error
x
d4 controller access
d5 manual operation
d6 cab door open
V short power down
4
03h
stanis2
d0 long power down
dl cycic encr
d2 word error
d3 failed detector
d4 phase dcmatd mon
x
d5 put standby
x
d6 stop time
x
77 date default
x
5
04h
phase greens
bit/phase
x
6
05h
phase yellows
balphase
x
06h
phase reds
biUphase
x -
8
07h
ped walla
bit/phase
x
9
08h
ped clearances
bit/phase
x
10
09h
ped don't walla
bit/phsse
x
] 1
OAh
overlap greens
bedphase
x
12
OBh
overlap yellows
bn/phase
x
13
OCh
overlap reds
bu/phase
x
] 4
ODh
ped calls
balphase
x
15
OEh
veh ca1131eheck3
btvphase
x
16
OFh
local det acens
I bnfphase
e:l.•y1ellaT tW�(t hnl.ea\ p...i
0
0
From: Wan Tewrsend To: Mks Ev Doc II M5 raoe a m t5
Byte#. Offset
Data !dame
Data Definition
VMS
17 110h
aux det act'ns
bttrphase
19-2-5
11 -18h
sys det vol
ntanmc
x
26-33
19 -20h
sys der oec
n•.meric
x
34
21h
local cycle timer
numc=
x
35
22h
cycle length
mmc=
x
36
23h
ring sntus
bit map
x
dOd2 ring 1, d3 [mused
x
d4-d6 ring' d7 [mused
x
37
24h
spec ftmc cmd
bit!SFC
x
38
25h
spec ftmc fdbk
bit'SFF
z
39
26h
spec func num
n[cncric
x
140
i 27h
command source
numeric
0- default
x
1 -ICU ovrd
x
2 °grp oyrd
x
3 -ICU TIC
x
4 -grp TIC
x
41
28h
pattem/plan num
word man=ic
x
42
29h
high byre of pa==
x
43
24h
pattc= type
]rt MMC
x
44
2Bh
group n=bcr
numeric
x
45
?Ch
arrrertt dial
( ntuneric
o •16
2Dh
charm[ offset
I numeric
47
2Eh
current. split
numeric
48
2Fh
sync phases
baYphase
x
49
30h
fixed phases
bNphasc
x
50
31h
phase sequence
n,_ -ncric
x
51
32h
can star
bit/phase
x
52
33h
can stay
bit/phwe
x .
53
34h
must hold
bit/phaie
x
54
35h
prcfcan wart
br /phase
x
Z;5
36h
hour
numeric
x
56
37h
ninu[e
numenc
57
38h
second
numeric
58
39h
local failed dets
bit /detcctor
59
3Ah
sys failed dets
bwdetctor
60
1313h
telc:n valid%
numcnc
x'
61
3Ch
tcicm back°/
cutnmc
x'
62
3Dh
5 rhi[ voltane
ntunrsc
63
3Eh
reserved
64
3Fh
reserved
1•.cnu [narked are generated in the server, not the local controller
Totes regarding the Real -Time Data DCF.I eucn
1. System Detector Occupancy values (bytes 26-33 of packet) are normally reported in percentage (0-100). Suspect Detector
¢tformauon may be fiaMed and rcr=ed m the Occupancy byte positions if the high bit if the byte u set. The followttt¢ Suspect
Detector codes arc possible in each System Cr-;:pancy byte position:
C:LUIpllD Tl rYY` /I D,Oi.Dt• 0..7
Fro Watt To.Ot+ nd To: Mike Evans pee:ssnAS 71trr:23na:50 . Pape sootis
1000 Y.NEX : NO CALL
1001 YX)D-IC` CONTLNUOUS CALL
1010 Y)DCX EXCESSIVE COUN S
1011 Y= MEN PRESENCE
In each cam, Y=0 indicates System Detector, y=1 indicates Phase Detector. X)DDC indicates detector ntanber (0.7).
2. Ring Starw (byte 36 of packet) provides a 'liatited NcMMA Coded Status' value for each in* T.: b, rus is pecked imo three
bits per ring (bits 0.2 for Ring 1, bits 4-6 for Ring 2). Bits 3 and 7 are unused and set to 0 by the VMS. The ponble values for
each 3 -bit Coded Status arc:
0 (000) - GREEN INITLIL.
1 (001) - GREEN ExTE NSIO\
2 (010) - undefined
3 (011) = GREEN REST
4 (100) - YE2.LOW CHANGE
5 (101) - RID CLEARANCE
6 (110) - RED REST
7 (111) - uadefimd
3. Pandit Type (byte 43 of packet) irrdic,trea the type of patron currently selected for the ICU. Possible values are:
1 = BACKGROUND (standard coordination with cycle timer, splits, offsets, etc)
2 - PRA T (specialized pattern runs timings for delay/hold/prt empt phases, etc)
3 = FLOW (platoon reeo=ticn, whereby upstream intersections relay ttafae information downstream)
4. Phase Sequence (byte 50 of packet) indicates the coordination -based selection for the full -demand sequencing characteristics of
the ICI;. The sequence allows lead/lag modification for each phase pair. The possible values for the phase sequence are:
sea= RING 1 RING 2 segh RING 1 RING 2
1- 1234 5678 9- 1234 5687
2- 2134 5678 10- 2134 5687
3- 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
e:l. -1.:1 V^VIr 11A.M.04• 0. —C
0 0
General Notes and Keys to Codes
1. ID Key
01WB02
Arterial No. -n No.
Traffic Lanes (NB,SB,EB,WB)
2. Detector Status
E = existing, in each lane
S = existing, single -lane (only one lane of multi- lane arterial covered)
M = existing, multi -lane (one detector covering more than one lane)
N = new installation
3. Controller Type
170(M) = Cattrans Standard 170,170A, 170E, 170-C8
MS###(M) = Multisonics 820, 820A, 911, 911S
Econ = Econolite
T1 = Computer Service Company T1
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'TMC'
a
".: ".I l'.n To: M.R..vain ..ac ttnoa „�..�a •:an
VOS RPC Service for VMS
Version 1.0
30 August, 1995
Intersection Development Corporation
Product Documentation
9
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 (DM- k/Tile Server -NT) which is part of the
VMS -300 system.
Inrr.��. r�nn r1�.nn...rnt f n.� . Vncorr Dan. t
0
lrom: WNt iowo...n la: "'' . C.. . wcc llllflO urn.. v :Ltlaw . es" 12 W 15
Installation
The VosRpc service requires DSNet service version 3.01 or later to be installed on the DFS. The date
on the DfsNetSv.exe file in the c: \users\idc directory should be 8!30M or later.
To install the VosRpc service, put the installation disk in the floppy drive on the DFS -NT and run
-setup.bat ". You can do this from the Pro!�Lam Manager, File Manager, or from a command prompt.
Setup will copy the vcsrpc.exe file to the c: \uscts\idc directory, install it as a service, and start it. The
service will automatically start each time the system is booted
A configuration option setting is required to ran on VOS buffer generation in the DfsNet Service. In
the VMSMI I file (in the \WLNNT directory), the option "Share" in section "[DfsVos]" should be set to
a -1 ". 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 vvsrpc.cxc program is not normally run from the command line. However, the following
command line options are available:
• fmstall Installs the program as a service.
• ;remove Removes the service.
• :debug Riau the service as a console application.
A message is gritted to the console each time an RPC can is processed.
(use Control -C to exit)
3. Errors
The VosRpc service reports errors in the NT Event Log and in the DFS event log (currently, the
da }tiles 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 s_- rvicc, which is part of the
Dfs \ctSv service. This data is collected once every minute, 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 h is running a cycle
longer than a minute. This can lead to results which des 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 ?'PUs to collect data for an intmcction, the detectors must be set up in Detector Crometrics
on the VMS. However, the VMS does not have to be naming a VOS monitor. The data collection is
also independent of the UMS VOS Data Collection service.
t.....c..�- .:.... n....i......,. "r r........ h— . vn.c.... c.n. 7
6. Usage
To access the data conected by VosRpc, an applir2tion should make an RPC can in the following
formal: (Also see the IDL foe at the end of this docu m=)
e =ro= status -
VmsGetVcs(
handle —t Binding, .
unsigned long dwSVstemNumder,
unsigned long dWTimeata...,,
_.._icned shozz wNumIntersecticns,
_.-ecJate3uffer[j,
unsigned long - pdwSizeOfBuffer
• Binding is the RPC binding handle
• dwSvstemNumber is always zero on VMS systems. It may be used on ComScrver systems to
choose an on -str=t master.
• dwTimestam p is the Unix timestamp (seconds since Jan 1, 1970) of the prnious buffer of data
returned- VmsGctVos will not return another buffer until one is available wiuich is later than this
timestamp. Call with this set to zero the first time, then use the timevamp returned in the buffer.
wNumIntersections determines the number of intersections for which data is to be returned.
• bDataBufTer is a pointer to the buffer in which the data is to be placed.
• pdwSizeOfBufier is a pointer to a DWORD containing the size of bDaiaBuffer. If necessary,
the server will change this number if it returns a different -sized buffer than r=p=tr4
The return code from the function is a standard RPC error status code. If the VosR.pc server has no
data available, it will return no data in the buffer and set `pdwSizeOfBuffer to zero. If the data is
available but it is not newer than the passed timestamp, the server will reran its current timcnamp 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 call with dwTimestamp set to -1, then the server will wait until new data is available before
retumin& This can take up to one minute.
The returned data contains a two-bvte volume count, a singe -b}2e occupancy, and a single -byte speed
for every detector on the system. The volume is in cars per minute. The occupancy is in percent (0-
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 detcctor is not valid. The speed is in miles per hour.
On the VVIS, not all the elements in this array will be used The fast 8 detectrns arc the system
detectors, the next 8 are the phase detectors, and the next 8 are the ped detectors. The last 8 arc not
currently used. System detector 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 format will be
used to arquae data from them.
6. Protocol Support
The VosRpc service automatically listens on the following protocols:
• ncalrp- - Local RPC. Works only on same machine.
• ncacn_np - NCA connection over Named Pipes
i........,...., rL...�.......�.,. r..,....",,,, . v...o„^ o....
- s,
rI
From: WWt Tovwwwnd To: Ylk. Ev DM@:11AN.5 '11 M :23:21:39 haa td of is
ncacn jp tcp - NCA connection over TCP.'IP
ncadg.ip_udp - TCP/IP datagaar
The TCP/IP protocols require TCP.2P 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 "Add Software" button, and
choose "TCP/IP protocol" from the list. You will nerd to obtain an IP address for the machine from
your network administrator.
7. Sample Code
A sample client program, vrpce.exe, is supplied to permit testing of the RPC connection. The source to
this prograrn is provided on the installation disk. It is a Win32 console application. so it can only be tun
on a Windows NT machine. This Program has the following cornmand -line options:
-n <server addr> - Defaults to local machine
-t <protscq> - Dcfauhs to ncahpc (fast, local only)
-w - waits for data
-i <#icus> - linits ° ictu to conect data for (default = 256)
You can run this on the same machine by just funning - wpcc" with no options. To fiat it on another
Windows NT machine, use 'vrpcc -t ncam_np -n VMSI ", where VMSI is the network name of the
DFS - \'T running the VosRpc service.
The program will can VmsGetVos every ten seconds (unless you use the -w option). When it gets a
data buffer from the s-rver, it prints out the volume, occupancy, and speed for each detector which had
non -zero data. To exit the program, hit any key.
0
It. men tar 10: .,•• .v
oa•: 11nRa l,rtw: i]:22:17
list this IDL filc to build a 6=1 application:
// idl for vosrpc
uuid(d58fc5e0 -de20- lice- 9c4c- 080009la54c7),
version(1.0)
]
interface VosRpcService
i
error status_t
Ping(
(ir.] handle-t Binding
error status _t
Vms GetVos(
Pep• la at 15
(in) handle -t Binding,
(in) unsigned long dwSystemNumber,
[in) unsigned long dw imestarnp,
[in] unsigned short wNumintersections,
(out, size is(- pdwSizeOfBuffer)) byte bDataBuffer[],
(in, out] unsigned long • pdwSizeOfBuffer
l;
The data buffer is formatted as foDolvs:
/• vos. -af.h - structures for VMS VOS mmf sharing •/
ppragma pack(1) /• single -byte structure alignment •/
typedef struct
WORD volume;
BYTE occupancy;
BYTE speed;
! DETVOSDP.TA; // structure is 4 bytes long
typ edef struct (
D -_ VOSDATA det[32];
) INTVOSDATA;
tvpedef strut; 1
DWORD dwTimeStamo:
INTVOSDATA icu(256);
! VOSSN.BUF;
ppragma pack()
/• and of vosmmf.n •/
i/ max 32 detectors per intersection
ii 12e bytes per intersection
// time when data was collected
/i the data 128 • 256 - 32768
// tctal size will be 32772
21
0
&REEMENT C -0 -0170
ATTACHMENT C
Attachment C
Partner Agency:
Floor Plan
System Block Diagram
Contacts (technical /operating)
0
U
K
w
O
a
w
C
a
R
n
I'
r
r
's
s
Q
0
� N
g H
t
U
Q
w Z
0 Q
� Ja
o rc
3 °o
w �
z �-
V
O
T
r
U
a�
0
Or
Oo
� z i
z
0
w
r
a
w
z
0
w
r
•
Contacts
Primary TraveITIP Staff Contact
Tony Brine
Ph 9491644 -3329
Secondary TraveITIP Staff Contact
Jim Brahler
Ph 949/644 -3346
City Traffic Engineer
Rich Edmonston
Ph 949/644 -3345
JOREEMENT C -0 -0170
ATTACHMENT C
(3 ;�
c- 339
April 25, 2000
CITY COUNCIL AGENDA
ITEM, NO. s
TO: Mayor and Members of the City Council ( k jR 2 5
FROM: Public Works Department _RP OVED
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 OCT�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,
Respectfully sub
mi d,
'::gD (
PUBLIC WORKS DEPARTMENT
Don Webb, Director
Antony Brine, P1.
Transportation Engineer
Attachment: Agreement
F:\ Users \PBVJ\Shared \COUNCIL \Fy99 -00W pril- 25 \TravelTip.doe
0 0
I COOPERATIVE AGREEMENT C -0 -0170
2 BETWEEN
3 ORANGE COUNTY TRANSPORTATION AUTHORITY
a AND
s CITY OF NEWPORT BEACH
6 THIS AGREEMENT, made and entered into this day of , 2000, by
7 and between the City of Newport Beach, a California municipal corporation in the State of California,
8 (hereinafter referred to as "CITY "), and the Orange County Transportation Authority, a public
9 corporation of the State of California, (hereinafter referred to as "AUTHORITY ").
10 WITNESSETH:
11 WHEREAS, AUTHORITY is the lead agency in the development of a county wide multimodal
12 Advanced Traveler Information System (ATIS), (hereinafter known as "TraveITIP "), and
13 WHEREAS, AUTHORITY currently has a TraveITIP System Integrator Consultant under
14 contract who will assist AUTHORITY in installing a connection to the CITY's Traffic Signal Master
is Controller System as a means of collecting arterial traffic information as identified in Attachments B
16 and C hereinafter referred to as ( "PROJECT "). The TraveITIP System Integrator Consultant will be
17 responsible for TraveITIP operations & maintenance for a period of twelve (12) months from date of
18 TraveITIP system acceptance.
19 WHEREAS, AUTHORITY agrees to fund the TraveITIP connection with CITY as identified in
20 Attachments B and C at no cost to the CITY; and
21 WHEREAS, the TraveITIP connection will be constructed by and in accordance with
22 Attachments A, B and C and shall be subject to technical direction and approvals by AUTHORITY, its
23 Consultant(s), and CITY; and
24 WHEREAS, CITY and AUTHORITY desire to herein specify their respective responsibilities for
25 performance of work outlined in Attachments B and C; and
26 WHEREAS, CITY and AUTHORITY each has full authority to enter into this Agreement;
KP kP
L ICAMM+CLE ICAUWORDPROC'IAGREE�00 170 D0 0 0 410 510 0 3'. 52 PM
Page 1 of 5
l
• AGREEMENT C -0 -0170
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;
a 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.
is F. To advise AUTHORITY in advance of atl 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
18 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.
\KAT lEl< amm :clencauworaprocessg\ag00i 70
Page 2 of 5
L
AGREEMENT C -0 -0170
1 E. To be responsible for the coordination, scheduling and costs associated with the
2 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:
5 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
8 this Agreement with the exception of those items noted in Attachment C, shall be in writing and shall
v 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
15 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
18 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
22 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
25 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
.KAT 11 EL lcamm :cieocallwomorocessinglago -oilo
Page 3 of 5
AGREEMENT C- 0 -01 70
1 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
s 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 /
1s 1
19 /
20 /
21 /
22 I
23 /
24 /
25 /
26 /
KAIP 4mp
L'CAMNI,.KFr� LEL cam,n.Oencaowotawo essmg`�90 of cU
Page 4 of 5
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
KNIP
L IC/
0
0
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 By
Mayor Corey Creasey
Section Manager- Procurement
Date:
ATTEST: APPROVED AS TO FORM:
By By
City Clerk Kennard R. Smart, Jr.
General Counsel
mammldencai'woraprpcess�ngag0 0170
Page 5 of 5
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.
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 TravelTIP. 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.
• • GREEMENT 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
,z
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 system'.
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 /21VI 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.
i
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 12s 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 AB3418.
0
From: Weft T~"nd To: Mike Evr.+e
tire*: WINS Time: 27:14:37
IDC Network Access Port Definition
Version 1.1
Programming Guide
Network Packet Definitions
Intersection Development Corporation
Copyright O 1994 Intmecion Ikvelopmeot Corporation. hs.
PROJECT: Intelligent Transportation Management System
NAME: ITMS
REVISION HISTORY:
5.26.93 wrL Initial Document
2 -11 -94 wrt. Revised to match new packet header formats
606.95 mwa. Corrected to match `as- built" following integration.
CA.• •:IOneT NY II n.MAtl 0.. t
41
►w* s at is
rrom: w•�< te.n• To: M~ Ev a. D•[•: ttetAS Tm•: x:75:07 rp•A cr tS
1. ITMS Network Access Port Operation
The V.MS DFS -330 provides a Network Access Port that allows applications running on other computers an a LAN to obtain real -
ume tufarmanon from the VMS -330 system The port is accessed via the NetBIOS protocol and uses a client - server arcbsteeturre.
The DFS -330 establishes a NetBIOS name on the LAN, 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 rexive real -time data
To identify each type of request and response packet the fast four bytes of each packet will contain a unique text sequence used as
a packet idemifier. AJia the packet identifier there will be a two byte version field for the packet If packet structures es ate changed
in later versions of sobsvare, the pr-: version will be inerememed Next there is an eight byte field containing the application
name, another two byte field for uit application version, and a two-byte application number field. Them fields will be collectively
referred to as the packet header. The application name and version fields are not used by the server, but the application ntmnber in
a request packet will be returned m the corresponding response packet The remainder of the block n application dependent but
cannot exceed the maximum block size supported by the NetBIOS connection type.
Real -time data can be requested from a DFS -330 over the network as follows:
• A remote client establishes a NetBIOS session with one or more DFS -330s ruing predefined NetBIOS names
(VMSI. VMS2, etc.)
• The remote client sends a data request packet (RT DATAREQ) which specifies the number of intersections (1 -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
intersection requested, up to a maxim ra 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_DATAI:EQ for zsro
intersections.
Recommended access method from non- NetBIOS network:
"Lail a dedicated -bridge- PC that can access both networks.
Write a simple program to nm on the bridge PC that establishes a NetBIOS session with each DFS on the network:
and sets up the data requests for all desired data.
The bridge program can then colicct real -time data from all DFSs, buffer it, and transmit it to the non- NetBIOS
network by any method desired.
Dcfmitiom for this document:
-Server" refers to a VMS DMA/File Sorer (DFS -3301
-BYTE- is a standard eight -bit byte
-WORD- is two byte. The byte is fns•..
ra -. .ono r, rw•nr�na,oa� aa-.
-rom: Wait Tam+web To: MIMo E~ws
0 0
Owe: IIAM 23.15:55
2. Network Packet Summary
RT_NAK 'RNAK' Server negative acknowledgment.
RT_DATAREO 'NREQ' Client request 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 of inactivity. or when the server program is shut
down. The client application should seno a RT HANGUP
packet to the server before it closes a session.
sa.. u<eno r. rvv� nn.n<.00 o..
IA
..o. $ or,s
EJ
0
Frem: Waft Ta+ Ta: WY. Ew Cale: 11f1163 Tl—: 22:16:27 r*" 6 of 15
3. Network Packet Contents
RT NAK
TYPE: Server Response
FORMAT:
PACKET ID 'RNAK'
I 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. The server remits this if it received an invalid packet, or if a packet eomitim
invalid data The server may also NAK the request if it does not have enough memory to establish another session.
RT DATAREQ
TYPE: Client Request
FORMAT:
PACKET ID 'NREQ-
BYTE (4)
Paa: <et version (0)
WORD
Application Name
BYTE (8]
Application version
WORD
Application Number
WORD
System number (0 for VMS)
WORD
Number of Intersections (1 -256)
0 = none
WORD
NOTES:
This be -lorn the collection of real -time data. The server will begin sending RT DATA packets. A request for
zero imenections will rum off data collectior..
r.�.. u�ono r+rw ntini.00 a.•
0
0
Fla t: Walt Tarwoftd TO: Wk. Eve+ ow.: ii rites 'nn : 23:17:aa
RT DATA
TITE: Server Response
FORMAT:
Packet 10 'RDAT'
BYTE r4l
Packet Version 0
WORD
Abolication Name
BYTE f8l
Acolication Version
I WORD
Aoolication Number
WORD
number
WORD
—System
Data byte (1) — Intersection 1
BYTE
Data bv!e
BYTE
Data byte 64 — Intersection 1
BYTE
Data byte 1
BYTE
Data byte 2)
BYTE
Data byte (64 ) — Intersection 2
BYTE
Data byte 1) — Intersection N
BYTE
Data byte '2
BYTE
Data byte 64 — Intersection N
BYTE
MOTES:
This packet is the response to tm RT REQUEST. The packet eonuuns 64 bytes of da'
intersection number requested in the RT DATAREQ packet The DFS polo the NPU
If the data has changed since the latt trarumi.ssiorL an RT_DATA packet will be trans
collect and trartsrrtst data until it receives an RT_DATAREQ cortanatd for =o inter
the Real•Time Data DeEnition table for a list of the data contained in this paetet
ca.. �.pno r+m.�nnn. oo a —r
-+n
From: Wen Tow.m nd To: Mike Everns tke: 11MA3 71 r : 23:17:34 rape I of 15
4. Real -Time Data Definition
This table describes the contents of the data area oran RT DATA packet from a DFS -330.
Bvte#
Offset
Data Name
Data Definition
VMS
1
OOh
state
numeic:
x
0 standby
x
1 flash
x
2 free
x
3 cooed
x
4 LOS cooed
x
5 umtsition
x
6 sig event
%.preempt
z
8 remote
9 TBC
10 Tvneor- -Day
11 Xseet plait mode
2
Ol h
mode
mmenc
1 - 11: sane as -state -
12 ICU LOS
x
3
02h
nano 1
bit map
x
d0 flash
x
dl conflict
Lure
d2 diag
0 corm aror
x
d4 conanller access
d5 mmtual operation
d6 cab door open
V short power down
4
03h
starts 2
d0 long power down
dl cycle error
d2 cooed error
d3 failed detector
d4 phase demand mon
x
d5 pin standby
x
d6 stop time
x
V data default
x
5
04h
phase greerts
btVphase
x
6
05h
phase yellows
bNphasc
x
%
1 06h
phase reds
biL'phwe
x -
8
07h
ped vralks
biVphwe
x
9
08h
ped eleaTL
bit/phase
x
10
09h
ped don't walls
bit phase
x
11
OAh
overlap greens
bi tphase
x
12
OBh
overlap yellows
bit/phase
x
13
OCh
overlap reds
btVpham
x
14
ODh
ped calls
btvphwc
x
15
OFh
veh rallatchecks
brvphase
x
16
OFh
local det acens
bNphaae
ra. u e onor rvr n n.ns.ea. 0.... a
0
Frwtu Welt Ter. rsd To: Mike Evens ore: 11M135 Time: 23:13:10
0
Byte#
Offset
Data Name
Data Derrnftioo
VMS
17
I Oh
aux det actns
bttrphase
18-_5
11 -18h
sys det Vol
none
x
26-33
19 -20h
sys det occ
n•.mmeric
x
34
21h
local cycle tiater
nutnenc
x
35
22h
cycle length
+rim+ -n^
x
36
23h
ring sums
bit map
z
dOd2 ring 1, d3 umtsed
x
d4-d6 ring 2, d7 unused
x
37
24h
spec ftmc clad
ba!SFC
x
38
25h
spec func fdbk
bictSFF
x
39
26h
spec func num
numeric
x
1 Oft
1 27h
eormnand source
numeric
x
0- default
x
1 -ICU ovrd
x
2-pp ovrd
x
3 -ICU TIC
x
4-Up TIC
x
41
28h
patterniplan mart
word man=ic
x
42
29h
high byte of pamcm
I
x
43
24h
pattem type
rtumeric
x
44
213h
group number
numeric
x
45
2Ch
currem dial
numeric
•16
2Dh
current offset
numerc
47
2Eh
current split
I numeric
48
2Fh
sync phases
bit phase
x
49
30h
fixed phases
bn/phase
x
50
31h
phase sequence
numeric
x
51
32h
can start
bit/phase
x
52
33h
can stay
bit/phase
x
53
34h
must hold
bit/phase
x
54
35h
prof can start
bidpbme
x
55
36n
hour
numeric
x
i 6
37h
minute
numeric
57
38h
second
ntmteric
58
39h
local faded dell
j bit/detector
59
3Ah
sys failed dets
brt/deteaor
60
3Bh
teiem valid%
numeric
X.
61
3Ch
teiem back°/.
nummc
X.
62
3Dh
5 rmn volume
n=cnc
63
3Eh
reserved
64
3Fh
reserved
' Items marked are generated in the sorer. not the local controller
Notes regarding the Real -Time Data Dermition .
rte a of 15
1. System Detector Occupancy values (bytes 26-33 of packet) are normally reported in percentage (0 -100). Suspect Detector
inforinauon may be Gagged and rerurned tat the Occupancy byte positions if the high bit if the byte is set. The following Suspec:
Detector codes are possible in each System Ocupancy byte position
c:6. 1J�Dl1nT TYV- nn.N.oa, R.'!
•
Fre Wan To.,vs no T0: Mike E~s Date: 11PIM5 'nn ' 21:18:50 Pa0e 10 of 15
1000 YX1C+C NO CALL
1001 Y1OX CONTINUOUS CAL'
1010 Y=. EXCESSIVE COUNTS
1011 YXX}C 14N PRESENCE
In each ease. Y-0 indicates System Detector, y-1 indicates Phase Detector. XXX indicates detector number (0-7).
2. Ring Status (byte 36 of packet) provides a •limi ed NEMA Coded Stants, value for each ru* T::a ,stw is packed itao three
bits per rung (bits 0-2 for Ring 1. bits 4.6 for Ring 2). Bits 3 and 7 arc unused and set to 0 by the VMS. The possible values for
each 3 -b¢ Coded Status; are:
0 (000) - GRMZ INITIAL
1 (001) - GREEN EXTENSION
2 (010) - undefined
3 (011) = GREEN REST
4 (100) -YELLOW CHANGE
5 (101) -RED CLEARANCE
6 (110) - RED REST
7 (l 11) - tndefm d
3. Pattern Type (byte 43 of packet) indiea— the type of pattern currently selected for the ICU. Possible values are:
1 - BACKGROUND (standard coordination with cycle timer, splits, offsets. cte)
2 - PREEMPT (specialised pattern rims tunings for delay/hold/preempt phases, etc)
3 - FLOW (platoon recognition, whereby upstream intersections relay traffic iaforaatlon downstream.)
4. Phase Sequence (byte 50 of packet) indicates the coordination -based selection for the full- demand sequencing characteristics of
the ICI;. The sequence allows Icad(lag modification for each phase pair. The possible values for the phase sequence are:
sea = RING 1 RING 2 scgh R NG 1 RING 2
1- 1234 5678 9- 1234 5687
2- 2134 $678 10- 2134 5687
3- 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 65 ?8 15- 1243 6587
8� 2143 6578 16- 2143 6587
Cil� 41 Pl p
�3
0
General Notes and Keys to Codes
1. ID Key
olwso2
Arterial No. — I I t r-• .' �!or S'-; -n No.
Traffic Lanes (NB,SB,EB,WB)
2. Detector Status
E = existing, in each lane
S = existing, single -lane (only one lane of multi -lane arterial covered)
M = existing, muftHane (one detector covering more than one lane)
N = new installation
3. Controller Type
17D(M) = Cahrans Standard 170,170A, 170E, 170-C8
MS###(M) = Multisonirs 820, 820A, 911, 9115
Econ = Econolite
T7 = Computer Service Company T1
Trac = Traconex
4. Location of Master
a. If signal controller is isolated, note as •none'
b. It 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 7MC'
0 0
rrcm: was Te.o..sw TO: Mu... ..a. �in�.a .. .. ";IV!,*
VOS RPC Service for VMS
Version 1.0
30 August, 1995
Intersection Development Corporation
Product Documentation
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 (DivLA/File Server -NT) which is part of the
VMS -300 system.
•••-- �•�•••.., • vncv.... , w��.n�nr.rw.n Pan. 1
Installation
Ibc VosRpc service rtquires DfsNct service version 3.01 or later to be installed on the DFS. The date
on the DfsNetSv.exc file in the c: \uscrsVdc directory should be 8/30195 or later.
To install the VosRpc service, put the installation disk in the floppy drive on the DFS -NT and Tort
-serup.bat ". ' You can do this from the Program Manager, File Manager, or from a coward prompt.
Soup will copy the vostpc.exe file to the c: \users\ide directory, install it as a service, and start it. The
service will automatically start each time the system is booted.
A configuration option setting is required to turn on VOS buffer generation at the DfsNet Service. In
the V%IS_I II fiat (in the \WLNNT directory), the option "Share" in section "[DfsVos]" should be set to
a'1 ". 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 vosrpc.exc program is not nomtally run from the command line. However, the following
coumtand line options arc available:
• iinstall Installs the program as a service.
• ,remove Removes the acr Ace.
!debug Runs the service as a console application.
A message is printed to the console each time an RPC can is processed.
(use Control -C to exit)
3. Errors
The VosRpc service reports errors in the NT Event Log and in the DFS event log (ctmendy, the
datfles in cAday.) When the service starts, it puts an information message in the DFS event log for
each of the protocol scqu_ -nces that it attempts to tic. The mcssaot w91 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 part of the
Dfs\etSv service. This data is collected once every minute, 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 controUcr normalizes is 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.
'r !7
0•�" 7
rrom: wmt iwn••+b la: r.w• evens
ua•: i5nro umw. .�:[o:u.
frgw 52 m U
Installation
Ibc VosRpc service rtquires DfsNct service version 3.01 or later to be installed on the DFS. The date
on the DfsNetSv.exc file in the c: \uscrsVdc directory should be 8/30195 or later.
To install the VosRpc service, put the installation disk in the floppy drive on the DFS -NT and Tort
-serup.bat ". ' You can do this from the Program Manager, File Manager, or from a coward prompt.
Soup will copy the vostpc.exe file to the c: \users\ide directory, install it as a service, and start it. The
service will automatically start each time the system is booted.
A configuration option setting is required to turn on VOS buffer generation at the DfsNet Service. In
the V%IS_I II fiat (in the \WLNNT directory), the option "Share" in section "[DfsVos]" should be set to
a'1 ". 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 vosrpc.exc program is not nomtally run from the command line. However, the following
coumtand line options arc available:
• iinstall Installs the program as a service.
• ,remove Removes the acr Ace.
!debug Runs the service as a console application.
A message is printed to the console each time an RPC can is processed.
(use Control -C to exit)
3. Errors
The VosRpc service reports errors in the NT Event Log and in the DFS event log (ctmendy, the
datfles in cAday.) When the service starts, it puts an information message in the DFS event log for
each of the protocol scqu_ -nces that it attempts to tic. The mcssaot w91 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 part of the
Dfs\etSv service. This data is collected once every minute, 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 controUcr normalizes is 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.
'r !7
0•�" 7
S. Usage
To access the data collected by VosRpc, an application should make as RPC can is the following
format: (Also sec the IDL file at the end of this doc=ent)
e_rot szazc:s
VmsGetVcs(
handle —t Binding,
unsigned long dwSystemNumber,
unsigned long c1 Timestarys,
_.._ianed short wNumIntersecziens,
-tee :Jata3uffer[i,
unsigned long • pdwSizeOfBuffer
• Binding is the RPC binding handle
• dwSvstem Num ber is ahvays zero on VMS systems. It airy be used on ComServer systcros to
choose an on -street master.
• dwTimestam p is the Unix titnesump (seconds since Jan 1, 1970) of the previous buffer of data
retuned VmsGotVos will not return another buffer until one is avatilabic which is later than this
timestsmp. Call with this set to zero the fast time, then use the timestamp retuned in the buffer.
• wNumIntersections detcrmires the number of intersections; for which data is to be returned.
• bDataBurrer is a pointer to the buffer in whch the data is to be placed.
pdwSizeOfBurrer is a pointer to a DWORD contain u the size of b'DamBu$er. If necessary,
the server will change this number if it returns a differcrut -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 'pdwSizcOfBu$er to zero. If the dam is
available but it is not newer than the passed timcstamp, the server will tenon its current timestamp in
the data buffer (4 bytes). If there is new data to return, it will copy it into the butffer provided If you
make the call aith dwTimesamp set to -1, then the sorer will wait until new data is available before
returning This can take up to one minute.
The returned data contairts a ttvo-byte volume count, a single -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 (0-
99 %). If the high bit in the occupancy byte is set (> 127) , then that detector has been declared suspect
by the VNIS and the data for that detector is not valid. The speed is in miles per hour.
On the V.MS, not all the elements in this array will be used The first 8 detectors arc the system
detectors, the next 8 are the phase detectors, and the next 8 are the ped detectors. The last 8 are not
currently used. System detectors collect volume, occupancy, and speed Phase detectors only coDeet
volume and occupancy. Ped detectors only collect volume. Elements in the array which arc not used
will be zero. When system types arc added which return more data, the same API and format will be
used to acquire data from them.
6. Protocol Support
Th: %'osRpc service automatically listens on the following protocols:
• ncalrpc - Local RPC. Works only on same machine.
• ncacn np -'ACA connection over Named Pipes
r..,.u.ran..n - vMo— fWii...�nnn..n
From: Won Tavrm•b To: Mike E,r z 0014: 1111125 Mm•: 2]:21:]11 Ftipo la o} 1s
• ncacn_ip_tep - NCA connection over TCP/IP
nc2dg_ip_ttdp - TCP/IP dauvs am
The TCP/IP protocols require TCP/IP to be installed on the DFS. It is not instilled by default To
install TCP/IP, go to the Network icon in the NT Control Panel. Push the "Add Software" 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, vrpec.exe, is suppbcd to permit testing of the RPC connection. The source to
this program is provided on the installation disL• It is a W'm32 console application- so it can only be tun
on a lVindows NT machine. This program his the following command-line options:
-n < server addr>
- Defauks to local machine
-t <protscq>
- Dcfauhs to nuhpc (fast, local only)
-w
. wars for data
-i <Nicus>
- limits X ices to collect data for (defauh = 2507
You can run this on the same machine by j= running "vMcc" with no options. To run it on another
Windows NT machine, use "vrpcc -t ncacn_np -n VMS I", where VMS is the network name of the
DFS -NT running the VosRpc service.
The program will call VmsGctVos every ten seconds (unless 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 -2rro data. To exit the program, hit any key.
Inr�rc.. -nnn rLwln..r..�nr ('nrw�r -�nnn . Vr�c D.v rMrur"�ntapnn Dante d
rFr
,lQ AN 1Ow 70: "... Gv
• •
0a4:1innn 11m:n:=17
Use this IDL file to buRd a cfient application:
idl for vosrpc
uuid ( d58fc5e0 -de20- lice- 9c4c- 0800091a5Sc7),
version;l.0)
)
interface VosRpcService
error status_t
Ping(
handle_- Binding
);
error status t
VmsGetVOS(
Pp"toM 11
(in) handle —t Binding,
[in) unsigned long dwSystemNumber,
[in] unsigned long dw:sestamp,
[in) unsigned short wNuxlntersectiors,
[out, size is(- pdwSizeO`Buffer)] byte bDataBuffer(),
[in, out) unsigned long • pdwSizeOfBuffer
The data buffer is fonnatrcd as foDows:
/• vos -zrf.h - structures for VMS VOS mmf sharing •/
/oragma pack(1) /• single -byte structure alignment •/
typedef struct i
WORD volume;
BYTE occupancy;
BYTE speed;
! DETVOSDA.TA; // structure is 4 bytes long
typedef struct (
D= TVOSDATA det[32);
) IN':'VOSDATA;
typedef strut- (
DWORD dwTimeStamo;
INTVOSDATA icu[256);
VOSSFBUF:
Nnragra pack( )
/" end of vosmmf.n •/
i/ max 32 detectors per intersection
ii 12S bytes per intersection
t_.re when data was collected
/i the data 128 • 256 - 3276B
tctal size will be 32772
tC
Gsn. S
Attachment C
Partner Agency:
Floor Plan
System Block Diagram
Contacts (technical /operating)
yD
AGREEMENT C- 0-0170
ATTACHMENT C
0
a
W
O
m
r
C
Y
xBY
eC
Y
2
s
6
K
O
O
J
W
ju
w
s
0
w
r
■
V
s
e
a�
Fa
0
�S
r
I
I
I
I
I NF RC■ �
�2
I
,.y
I
I
I �
1
� e8
J 1 U
I �
T
T
t]
Al
lit
141
ja
Q
s
�s
Y
0
w
r
r
3
u
W
0
H N
O <
6 �
3 O
W
Z
V
O
T
E41
�Illf
0 w
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
..T
AGREEMENT C -0 -0170
ATTACHMENT C