HomeMy WebLinkAboutResolution - 6015 - Contract-Daniel, Mann, Johnson, & Mendenhall-Advanced Traffic Management System - 09_24_1998Resolution No. 6015
Item No. 35
September 24, 1998
RESOLUTION
BE IT RESOLVED BY THE CITY COUNCIL OF THE CITY OF LUBBOCK:
THAT the Mayor of the City of Lubbock BE and is hereby authorized and
directed to execute for and on behalf of the City of Lubbock a Contract for Advanced
Traffic Management System, by and between the City of Lubbock and Daniel, Mann,
Johnson & Mendenhall of Colorado Springs, Colorado and all related documents. Said
Contract is attached hereto and incorporated in this Resolution as if fully set forth herein
and shall be included in the minutes of the Council.
Passed by the City Council this 24th day of September '1998.
4SIT'1A
T A
ATTEST:
Kavtffla Darnell, City Secretary
APPROVED AS TO CONTENT:
Q&q K&AA�t,
Victor Kilman, turchasing Manager
APPROVED AS TO FORM:
William de Haas
Competition and Contracts Manager
W&A/Advanced Traffic.Rl S
ccdocs/September 15, 1998
Resolution No. 6015
Item No. 35
�September 24, 1998
ADVANCED TRAFFIC MANAGEMENT SYSTEM (ATMS)
CONTRACT
STATE OF TEXAS
COUNTY OF LUBBOCK §
This contract, (the "Contract"), effective as of September 24, 1998, (the "Effective
Date"), is by and between the City of Lubbock, (the "City"), a Texas Home Rule Municipal
Corporation, and Daniel, Mann, Johnson & Mendenhall, a California corporation with an office
at 1490 West Fillmore Street, Suite 101, Colorado Springs, Colorado, (the "Contractor").
WITNESSETH
WHEREAS, the City requires a new traffic management system; and
WHEREAS, the Contractor desires to develop the new traffic management system and is
familiar with computer hardware and software, telecommunications equipment, distributed
control systems, and technical services related to these items; and
WHEREAS, the City desires to contract with Contractor to provide this service.
NOW THEREFORE, for and in consideration of the terms, covenants and conditions set
forth in this Contract, the City and Contractor hereby agree as follows:
ARTICLE I
TERM
The term of this Contract commences on the Effective Date and continues without
interruption for a term of one (1) year from and after the Effective Date. The term may be
extended for one (1) additional one (1) year terms with the written consent of both parties.
ARTICLE II
COMPENSATION
A. General. For its services performed hereunder, Contractor shall receive the following
payment:
1. System software a lump sum of $175,000.00,
Page 1
2. Installation and Integration of hardware a lump sum of
$41,000.00,
3. Contractor furnished hardware at a not to exceed price of
$76,200.00,
for a total contract amount of $292,000.00, payable monthly based upon percentage complete not
to exceed percentages listed in Article V..
B. Invoicing. The City shall pay Contractor within thirty (30) days from the date of
Contractor's invoice. Amounts remaining unpaid thirty (30) days after the invoice date shall
bear interest at the rate of 12% per annum, or the maximum legal rate, whichever is less.
Additionally, Contractor shall be entitled to suspend its Services on the Project until payment in
full, including interest, is received. Should such suspension exceed sixty (60) consecutive days,
Contractor may elect to terminate this Agreement and shall be entitled to payment for all
Services performed prior to the date of termination.
C. Project Suspension. If the City suspends the Project for more than thirty (30)
consecutive days, Contractor shall be compensated for all Services performed prior to the
effective date of suspension. Upon resumption of the Project, Contractor's compensation shall
be adjusted by mutual agreement of the Parties to compensate Contractor for expenses incurred
as a result of the interruption and resumption of Contractor's Services.
D. Modification. If, through no fault of Contractor, Contractor's services have not been
completed within twelve (12) months of the effective date of this Contract, Contractor's
compensation shall be adjusted by mutual agreement of the parties.
ARTICLE III
TERMINATION
A. General. In the event the Contractor breaches any term and/or provision of this
Contract the City shall be entitled to exercise any right or remedy available to it at law or equity,
including without limitation, immediate termination of this Contract and assertion of action for
damages and/or injunctive relief. The exercise of any right or remedy shall not preclude the
concurrent or subsequent exercise of any other right or remedy and all other rights and remedies
shall be cumulative.
B. Termination. The City may terminate this Contract at any time by giving thirty (30)
days written Notice of Termination to Contractor. Upon receipt of Notice of Termination,
Contractor shall immediately cease performance of its services. Contractor shall be compensated
for its services performed up to the effective date of termination and all reasonable termination
related expenses.
ARTICLE IV
REPRESENTATIONS AND WARRANTIES
Page 2
A. Existence. Contractor is a corporation duly organized, validly existing, and in good
standing under the laws of the State of Texas and is qualified to carry on its business in the State
of Texas.
B. Corporate Power. Contractor has the corporate power to enter into and perform this
Contract and all other activities contemplated hereby.
C. Authorization. Execution, delivery, and performance of this Contract and the
activities contemplated hereby have been duly and validly authorized by all the requisite
corporate action on the part of the Contractor. This Contract constitutes legal, valid, and binding
obligations of the Contractor and is enforceable in accordance with the terms thereof.
D. Contractor. Contractor maintains a professional staff and employs, as needed, other
qualified specialists experienced in computer software and hardware technology, and are familiar
with all laws, rules, and regulations, both state and federal, including, without limitation the
applicable laws, regarding the activities contemplated hereby.
E. Performance. Contractor will and shall conduct all activities contemplated by this
Contract in a good and workmanlike manner, and comply with all laws, rules, and regulations,
both state and federal, relating to computer software and hardware technology, as contemplated
hereby. If any of the activities of the Contractor, or omissions of the activities required herein,
are defective or deficient, it shall be deemed that the Contractor did not perform said activities
(or omitted the performance of said activities) in a good and workmanlike manner. However,
contractor shall be given notice by City, in writing, of any deficiency or defect within a
reasonable period of time after discovery and Contractor shall be given a reasonable period of
time to cure the deficiency or defect.
F. Use of Copyrighted Material. Contractor warrants that any materials provided by
Contractor for use by City pursuant to this Contract shall not contain any proprietary material
owned by any other party that is protected under the Copyright Act or any other similar law,
except as stated in Article V A 3. Contractor shall be solely responsible for ensuring that any
materials provided by Contractor pursuant to this Contract satisfy this requirement and
Contractor agrees to hold City harmless from all liability or loss to which City is exposed on
account of Contractor's failure to perform this duty.
ARTICLE V
DUTIES OF CONTRACTOR
A. Software Terms and Conditions.
1. Terms of Payment:
Payment of the base system will be made based upon milestones reached:
Page 3
0 10% of the base system price will be paid at time of TCS-II software and server
delivery.
• 20% of the base system price will be paid at the time of installation of server,
TCS-II software, communications equipment, and remainder of base system
hardware.
• 45% of the base system price will be paid upon successful completion of
acceptance test.
• 25% of the base system price paid upon delivery of documents and completion of
training.
Payment for additions to the base system will be made based upon the following:
• 50% of the price will be paid at time of delivery.
• 40% of the base system price will be paid upon successful completion of
acceptance test.
• 10% of the base system price paid upon delivery of documents and completion of
training.
2. Changes. No changes will be made to the requirements of this Agreement without the
mutual written consent of the parties.
3. Ownership. ACT, Inc. is the owner of the Software and all copyrights in the Software.
The Software is protected by title 17 of the United States Code (the Copyright Act), and the City
and any agent, employee, independent contractor, or official of the City (collectively "City
Agents") must honor all rights established by the Copyright Act with respect to the Software.
The Software embodies substantial creative efforts and confidential information, ideas, and
structure, which have not been revealed to the public. ACT licenses the Software's use in the
United States of America only, subject to the terms of this License Agreement. ACT has granted
Contractor exclusive rights to the TCS-II software.
4. Use of Software. The City and its Agents may use the Software on multiple
computers, provided that all such computers are owned by the City or the Texas Department of
Transportation (TxDOT). In no event may the Software be installed on any computer, which is
not owned by the City or TxDOT without Contractor approval. The City may copy the Software
and its related documentation for internal support, training and backup purposes only.
The City shall only use the Software to monitor, coordinate and collect data from those
traffic signal control, monitoring or data collection devices (hereinafter referred to as "Device" or
"Devices") which are within the City's E.T.J. (i.e. 5 miles outside the corporate limits). Should
the City be required to monitor, coordinate or collect data from any Devices that are maintained
by others outside the E.T.J., Contractor shall be compensated by the City at a cost of nine -
hundred dollars U.S. ($900.00) for each additional Device. This compensation shall not exceed
forty five -thousand dollars U.S. ($45,000.00) and the City shall not simultaneously monitor,
coordinate or collect data from more than Fifty (50) Devices outside of the City's E.T.J. at any
given time period.
Page 4
Notice of such intent to connect a Device or Devices shall be provided to Contractor in
the form of a purchase order. Contractor shall then respond within ten (10) calendar days in
writing to the City's request to purchase. Contractor reserves the right to refuse any request to
purchase that exceeds or violates the limits set forth by this Agreement. Contractor also reserves
the right to audit, at its expense, the system at any time to ensure proper enforcement of this
license agreement.
5. Assignment. The City may not transfer, lease, assign, or sub -license this license or the
Software. Any attempted transfer, lease, assignment, or sub -license shall be void, and shall
immediately terminate the City's rights with respect to the Software.
6. Revisions. From time to time Contractor may issue revisions of the Software. If a
revision is sent to the City, the City agrees to replace the Software with the revised version and
acknowledge that the revision will be governed by the terms of this License Agreement.
7. Warranty. Contractor warrants that the Software, if properly installed and executed on
the City's central traffic control system hardware Server and Workstation PCs for which it is
designed, will perform substantially in accordance with the specifications set forth in the
Contract Document.
a. Warranty Obligations. During the five-year period commencing with the successful
completion of the 180-day burn -in test of the software by the City, Contractor will repair or
replace, at its sole option, without charge to the City, any portion of the Software which does not
meet the requirements of this warranty. To obtain service, the City must contact Contractor in
writing within that five-year period. A full written description of the problem shall be provided
to Contractor via facsimile, registered mail, or express courier, signed by either the Traffic
Design Engineering Supervisor/Design Engineer, City Traffic Engineer, or Director of
Transportation. Contractor shall acknowledge any such service request within seventy-two (72)
hours and shall, within five (5) calendar days from the date of acknowledgement, provide any
necessary repairs, replacements or modifications, or in the event that the problem is not
reasonably capable of being repaired within that time frame, a proposed alternate schedule
setting forth the date the repairs, replacements or modifications will be provided.
b. Hardware Issues. If the City identifies a problem with the performance of the
Software, but is unable to determine whether the problem is caused by the central traffic signal
and transportation management system hardware, Device hardware, or the Software, the City will
notify both Contractor and the hardware manufacturer of the problem. Contractor will use its
best efforts to work with the hardware manufacturer to resolve any such problem. However, if
Contractor did not provide the hardware, Contractor will have no responsibility for making
modifications to the Software or otherwise rectifying such problem.
c. Responsibilities of the City. All warranties of the Software are contingent on the
proper use of the Software by the City and do not cover damage due to accident, unusual
physical, electrical, or electromechanical stress, neglect, misuse, failure of electric power,
Page 5
environmental condition, transportation, operation with operating systems, media, other
software, or hardware not approved by Contractor or modification of or altering of the Software.
The City shall be responsible for all operational verification and performance testing of
the Software. The City shall insure that all Software functionality requirements set forth by the
Purchase Order are tested under controlled conditions within the confines of the City's internal
laboratories or maintenance shops before public use. A Contractor representative shall be
present during all verification and performance testing. Contractor reserves the right to halt any
use of the Software by the City should Contractor determine that there is a defect or potential
defect that could jeopardize the integrity of the system or safety of the public.
d. Indemnification. The City acknowledges that the software is not intended to
directly operate traffic signals at a traffic intersection or perform any traffic signal control
hardware verification testing or traffic signal control hardware operational diagnostics.
Therefore, the software shall not be used to directly control traffic signals at a traffic intersection
or perform any traffic signal control hardware verification testing or traffic signal control
hardware diagnostic testing on any traffic signal functioning at a traffic intersection.
e. There are no warranties that extend beyond those described herein.
8. Source Code. Contractor shall place a copy of all source code, object code libraries,
compilers, assemblers, linkers and locators necessary to reconstruct the executable image of the
Software in an escrow account that is maintained by a third -party software escrow provider.
Contractor shall be responsible for specifying the third -party software escrow provider.
9. Executable Code. Contractor will deliver to the City a copy of all the necessary
installation and executable code file images for the portion of the Software which resides on the
Server PC and workstation PC on floppy disk. The City will have the right to copy this
executable code onto computers owned by the City for the purpose of operating and interfacing
to the central traffic signal and transportation management system network. The City
acknowledges that any other dissemination or copying of the executable code is a default under
this Agreement. Furthermore, the City assumes responsibility for any failure of the Software for
which the executable code has been modified.
B. Contractor, upon receipt of written authorization to proceed shall commence
performance of the service set forth in Exhibit A attached hereto.
C. Ownership and Reuse of Documents. All data, information, reports, drawings,
specifications, computations, notes, renderings, or other documents or materials prepared by
Contractor under this Agreement as instruments of service shall remain the property of
Contractor and shall not be used on any other project or for extensions of this Project without
Contractor's written consent and without additional, mutually agreeable compensation in
consideration of Contractor's consent for reuse. If any portion of Contractor's services is
incorporated into any other project than that for which Services were performed, the City shall
save Contractor harmless from any claims or liabilities arising from such action, notwithstanding
Page 6
Contractor's written consent. The City further agrees to hold Contractor free and harmless from
and against any claims arising out of the City's use of Contractor's drawings, tracings, and
specifications on extensions to this Project. The provisions of this clause shall survive the
termination or completion of this Agreement and shall thereafter remain in full force and effect.
D. Hardware, Installation and Integration. Contractor shall purchase all hardware, install
and integrate the hardware in accordance with the requirements specified in Exhibit A of this
Contract.
Payment for Hardware, Installation and integration will be based upon the
following:
• 50% of the price will be paid at time of delivery,
• 40% of the price will be paid upon successful completion of acceptance test,
• 10% of the base system price paid upon delivery of documents and completion of
training.
ARTICLE VI
DUTIES OF CITY
The City shall provide criteria and complete information defining its requirements for the
Project, and shall make that information and related data available for Contractor's use during
the performance of this Agreement. The City shall render decisions required hereunder as
indicated, or if not specifically stated, with reasonable promptness so as not to unduly delay the
progress of Contractor's Services.
ARTICLE VII
INDEPENDENT CONTRACTOR STATUS
Contractor and City agree that Contractor shall perform the duties under this Contract as
an independent contractor. The Contractor has the sole discretion to determine the manner in
which the services are to be performed.
ARTICLE VIII
INSURANCE
A. General. Contractor shall procure and carry, at its sole cost and expense through the
life of this Contract insurance protection hereinafter specified, in form and substance satisfactory
to the City. City must approve all policies prior to the commencement of any activities whether
performed by the Contractor, subcontractor, agents, or third parties. The insurance carrier must
be an insurance company approved to transact business in the State of Texas and have a Best's
Financial rating of A:VH. A Certificate of Insurance specifying each and all coverage shall be
submitted to City prior to the execution of this Contract. All insurance shall be prepared and
executed by the insurance company or it's authorized agents and shall, with the exception of
Page 7
Worker's Compensation and Professional Liability insurance, contain an endorsement naming
the City of Lubbock an additional insured. Written notice of cancellation or any material change
will be provided thirty (30) days in advance of cancellation or change. All insurance, other than
Worker's Compensation and Professional Liability, shall provide a waiver of subrogation in
favor of the City of Lubbock, and shall contain cross liability and severability clauses.
B. Required Coverage. Contractor shall obtain and maintain policies of insurance
throughout the Contract term in limits specified below.
1. Worker's Compensation. The Contractor shall maintain Workers' Compensation and
Employer's Liability insurance coverage as required by statute or coverage approved by the City
Risk Management Coordinator.
2. Commercial General Liability. The Contractor shall maintain Commercial General
Liability coverage endorsed to include premises/operations, contractual liability, independent
contractors' and completed operations. The policy shall have a minimum. of One Million and
no/100 Dollars ($1,000,000) combined single limit in the aggregate and per occurrence.
3. Commercial Automobile Liability. The Contractor shall maintain Commercial
Automobile Liability coverage with a minimum of One Million and no/100 Dollars ($1,000,000)
combined single for Bodily Injury and Property Damage and shall include any auto or in the
alternative, owned autos, non -owned autos and hired autos.
4. Professional Liability Insurance. The Contractor shall maintain Professional Liability
Insurance coverage with a minimum of One Million and no/100 Dollars ($1,000,000) combined
single limit in the aggregate and per claim.
5. Umbrella Liability Insurance. The Contractor shall maintain Umbrella Liability
Insurance coverage in the amount of One Million and no/100 Dollars ($1,000,000) with coverage
corresponding to the Commercial General Liability, Commercial Automobile Liability and
Professional Liability policies.
C. Subcontractors. The Contractor shall require each subcontractor with whom it
contracts to provide activities as contemplated by this Contract, to obtain proof of insurance
coverage as set forth herein, and to provide to Contractor, prior to such person performing any
such activities, a Certificate of Insurance establishing such coverage except that subcontractors
not performing professional services shall not be required to carry Professional Liability
Insurance.
Page 8
ARTICLE IX
INDEMNITY
Contractor agrees to indemnify, hold harmless, and defend the City from and
against all claims, demands, damages, losses, costs, expenses (including attorneys' fees),
fines, or penalties to the extent caused by a negligent act, error, or omission of contractor
or its employees or subconsultants. Contractor shall not be liable for special, incidental, or
consequential damages.
ARTICLE X
EMPLOYMENT OF AGENTS
Contractor may employ or retain agents, consultants, contractors, or third parties, to
perform certain duties of Contractor under this Contract provided that Contractor is in no event
relieved of any obligation under this Contract. Any such agents, contractors, or third parties
retained and/or employed by Contractor shall be required to carry, for the protection and benefit
of the City and Contractor and naming said third parties as additional insureds, insurance as
described in Article VIII of this Contract.
ARTICLE XI
CONFIDENTIALITY
Contractor shall retain all information received from or concerning the City and the
City's business in strictest confidence and shall not reveal such information to third parties
without prior written consent of the City, unless otherwise required by law.
ARTICLE XII
COMPLIANCE WITH APPLICABLE LAW
Contractor shall comply with all applicable federal, state and local laws, statutes,
ordinances, rules and regulations relating, in any way, manner or form, to the activities under this
Contract, and any amendments thereto.
ARTICLE XIII
NOTICE
A. General. Whenever notice from contractor to City or City to Contractor is
required or permitted by this Contract and no other method of notice is provided, such notice
shall be given by (1) actual delivery of the written notice to the other party by hand, (2)
facsimile, or other reasonable means (in which case such notice shall be effective upon delivery),
Page 9
or (3) by depositing the written notice in the United States mail, properly addressed to the other
party at the address provided in this article, registered or certified mail, return receipt requested,
in which case such notice shall be effective on the third business day after such notice is so
deposited.
are:
B. Contractor's Address. Contractor's address and numbers for the purposes of notice
Daniel, Mann, Johnson & Mendenhall
Attn: Roger Miller, Associate Vice President
1490 West Fillmore, Suite 101
Colorado Springs, CO 80904
Telephone: (719) 471-9866
Facsimile: (719) 471-9063
C. City's Address. The City's address and numbers for the purposes of notice are:
City of Lubbock
Attn: Jeryl D. Hart, Jr. P.E.
916 Texas Avenue
Lubbock, Texas 79457
Telephone: (806) 775-2130
Facsimile: (806) 747-7657
D. Change of Address. Either party may change its address or numbers for purposes of
notice by giving written notice to the other parry, referring specifically to this Contract, and
setting forth such new address or numbers. The address or numbers shall become effective on
the 15th day after such notice is effective.
ARTICLE XIV
MISCELLANEOUS
A. Captions. The captions for the articles and sections in this Contract are inserted in
this Contract strictly for the parties' convenience in identifying the provisions to this Contract
and shall not be given any effect in construing this Contract.
B. Audit. Contractor shall provide access to its corporate books and records to the City.
The City may audit, at its expense and during normal business hours, Contractor's books and
records with respect to this Contract between the Contractor and City.
C. Records. Contractor shall maintain records that are necessary to substantiate the
services provided by the Contractor
D. Assignability. Contractor may not assign this Contract without the prior written
approval of the City.
Page 10
E. Successor and Assigns. This Contract binds and inures to the benefit of the City,
Contractor, and their respective successors, legal representatives, and assigns.
F. Construction and Venue. THIS CONTRACT SHALL BE GOVERNED BY AND
CONSTRUED IN ACCORDANCE WITH THE LAWS OF THE STATE OF TEXAS. THE
PARTIES HERETO HEREBY IRREVOCABLY CONSENT TO THE EXCLUSIVE
JURISDICTION AND VENUE OF THE COURTS OF THE STATE OF TEXAS, COUNTY OF
LUBBOCK, FOR THE PURPOSES OF ALL LEGAL PROCEEDINGS ARISING OUT OF OR
RELATING TO THIS CONTRACT OR THE ACTIONS THAT ARE CONTEMPLATED
HEREBY.
G. Severability. If any provision of this Contract is ever held to be invalid or ineffective
by any court of competent jurisdiction with respect to any person or circumstances, the
remainder of this Contract and the application of such provision to persons and/or circumstances
other than those with respect to which it is held invalid or ineffective shall not be affected
thereby.
H. Amendment. No amendment, modification, or alteration of the terms of this Contract
shall be binding unless such amendment, modification, or alteration is in writing, dated
subsequent to this Contract, and duly executed by the Contractor and City.
I. Entire Agreement. This Contract, including Exhibit A hereto, contains the Entire
Contract between the City and Contractor, and there are no other written or oral promises,
conditions, warranties, or representations relating to or affecting the matters contemplated herein.
EXECUTED as of the Effective Date hereof.
CITY OF LUBBOCK
DANIEL, MANN, JOHNSON &
MENDENHALL
BY:
Y T N, MAYOR
TITI
ATTEST:
Ka Darnell
City ecretary
Page 11
APPROVED AS TO CONTENT:
eryl P . Hart, Jr. P.E.
City Traffic Engineer
APPROVED AS TO FORM:
William de Haas
Competition and Contracts Manager
Page 12
Resolution No. 6015
Item No. 35
September 24, 1998
EXHIBIT A
SPECIFICATIONS FOR
ADVANCED TRAFFIC MANAGEMENT SYSTEM (ATMS)
SECTION 1
OVERVIEW OF THE PROJECT
1.1 Purpose and Scope of the Project
1.1.1 Project Phases
The Project will include the following phases:
Phase 1, the Implementation. During this phase, the Contractor shall furnish,
install, and integrate the required elements of the system in accordance with the
schedule specified (See exhibit A-1). As described below, certain elements of the
construction will be performed by City forces. The Contractor shall develop, and
submit for the City's approval, a detailed testing plan designed to demonstrate that
the system complies fully with all aspects of the specifications. The Contractor,
under the City's supervision, shall carry out this test plan prior to the completion of
Phase 1.
Phase 2, the 180-Day Observation Period. .Following completion of the work
required by the Contractor, the 180-day Observation Period shall take place. The
purpose of this period is to ensure that all Contractor -furnished elements of the
ATMS perform in accordance with the project specifications for an extended period
of time.
Phase 3, the Warranty Period. Upon successful completion of the Observation
Period, the Warranty Period shall begin. This shall include:
For five (5) years, full warranty and support for the ATMS software and all
other Contractor -furnished software; and
For two (2) years, full warranty and on -site service support for Contractor -
furnished components of the central hardware.
1.1.2 Field Construction To Be Performed by City Forces
All field construction for the Project will be performed by City forces. This will include:
Specifications for an ATMS Page A-1
Replacing certain existing NEMA TS I controllers and cabinets (which are currently
controlled by the City's existing UTCS signal system) with new City -furnished
Type 170 controllers and cabinets and connecting these new controllers to
functional pairs of the City's existing copper twisted -pair (TAT) communications
cable network.
Installing the initial elements of a new fiber optic (FO) communications system; and
Installing spread spectrum radio apparatus.
1.1.3 Other Services To Be Provided by the Citv
The City will provide to the Contractor, in standard traffic engineering terminology , the
necessary data for the initial signal timing plans and the initial time -of -day, day -of -week
(TOD/DOV) operational schedules. In the case of the timing plans, this will include phase
sequences and cycle lengths, splits, and offsets, all in seconds.
1.1.7 Overview of Contractor's Required Responsibilities
The Contractor shall be required to:
• Furnish the new ATMS central software and certain other software;
• Furnish recommended brands, model numbers, catalog data and prices for the core
elements of the new central control hardware;
• Furnish the various elements of central hardware unless the City, at its option, elects to
furnish an equivalent item.
• Install and fully integrate the new ATMS central software and hardware;
• Provide guidance and technical support to the City relative to the Feld work associated
with the integration of the following groups of intersection signal controllers into the
new ATMS:
0 Approximately thirteen (13) intersections to be connected by means of the City's
existing TWP cable network;
0 Approximately ten (10) intersections to be connected by means of a new City -
installed FO communications system; and
0 Approximately eleven (11) intersections to be connected by means of a new
City -installed spread spectrum radio system.
• Perform all work required at the central control facility to integrate the above -
described groups of intersection signal controllers into the new ATMS. Except as
Specifications for an ATMS Page A-2
otherwise provided for, this shall include the actual entry of the initial timing plans
into the system database.
1.2 General Description of the New ATMS
1.2.1 Central Hardware
Central hardware for the new ATMS shall be integrated to meet the functional specifications
contained in Section 2. The current UTCS system provides centralized second -by -second control
and monitoring of approximately 94 signalized intersections located within the area depicted in
Figure 1.2.1-1. In 1991, the City extended a less capable form of centralized control 'to 29
additional intersections, the majority of which are in southwest Lubbock, south of 50`h Street and
on or west of University Avenue. These intersections are depicted in Figure 1.2.1-2. Also,
Figure 1.2.1-3 illustrates the layout of the existing TOC, which is located with the City's Traffic
Engineering Department offices in the Municipal Square building at 916 Texas Avenue.
Generally, the equipment in the new TOC shall include the following:
• Anew 10/100BaseT local area network (LAN),
The new ATMS's central processor will be networked microcomputer servers. The
servers may be desktop, rack -mounted, or floor -standing tower type units. The
Contractor shall connect these computers in the TOC to provide communications,
processing, storage, and display capabilities across the new TOC LAN.
Additional personal computers (PCs), to be procured and connected to the new LAN by the City,
will ultimately be located at the desks of various Traffic Engineering Department employees.
These PCs shall access the TOC LAN through an ethernet switch, which shall be programmed to
allow only certain LAN addresses to access the TOC system.
One PC (furnished by the City) at the traffic signal maintenance shop (located at 321 North Ash)
shall also access the TOC LAN by means of a high-speed link to be provided by the City. The
new TOC LAN shall also provide concurrent dial -in access, over commercial telephone lines, to
a minimum of three (3) portable PCs to be furnished by the City. These portable PCs shall also
serve as direct access terminals for working with individual controllers in the field.
The central computers shall store all software and data relating to the ATMS. Their primary
function shall be to run the traffic management programs and graphics display system.
Additional functions shall be to serve as the dial -in access point and to run the programs needed
to operate future ATMS modules, such as a CCTV traffic surveillance system.
To provide a display suitable for viewing by groups of visitors, the Contractor shall furnish and
install a large -screen color display system. As provided for in Section 3, this shall consist of a
large CRT monitor.
Specifications for an ATMS Page A-3
FIGURE 1.2.1 -1
EXISTING UTCS SYSTEM
-v
As
to
m
n
FIGURE 1.2.1-2
EXISTING TYPE 170 SYSTEM
GRAPHIC SCALE
( IN FEET )
1 inch - 5 M
FIGURE 1.2.1-3
EXISTING TOC SPACE LAYOUT
Page A-6
The Contractor shall furnish and install a central control console, which shall generally be of the
size of the existing console. This new console may either be custom-built or modular computer
room furniture. The TOC layout must accommodate other accessories notwithin this contract.
This includes such equipment as printers, plotters, telephones, and two-way radios. The
Contractor shall accommodate concurrent operation of the existing and new systems.
1.2.2 Central Software
The operating system and ATMS application software to be provided by the Contractor shall be
as described below.
1.2.2.1 Operating System
The Contractor shall provide a real-time, multi -tasking operating system that fully supports the
functional specifications of the application software described herein. The Contractor shall
provide all support programs required to operate and modify the application software. This shall
include, but is not limited to, all required programming language compilers and linkers required
to modify and rebuild the application software, a text editor, a print spooler, and diagnostic
programs.
LZZ2 ATMSApplications Software
The ATMS software shall enable the computers to function and operate in accordance with the
functional specification described herein. It may be based on the contractor's existing system
software with modifications to meet these specifications, or may be produced specifically for this
project and application. The delivered software shall be of modular and expandable design,
enabling future enhancements to be easily integrated. The software for the main server and
support server shall be identical. A functionally scaled -down version of the software will be
made available for loading onto remote computers which typically have smaller hard disk drives
than the TOC computers. The Contractor shall provide the City of Lubbock with license to
reproduce the software for the City's own use (i.e. make back-up copies) and for future portable
units.
LZZ3 Software Licenses
The Contractor shall provide to the City a non-exclusive, non -transferable, perpetual and
irrevocable license which grants to the City the right to use and copy (for back-up purposes) the
ATMS applications software. Such license shall grant the City the right to use the software, for
the purpose of traffic management and/or traffic signal control throughout the Lubbock
metropolitan area, at the TOC or at any other office which the City or the Texas Department of
Transportation may establish for the purpose of traffic management and/or traffic signal control
Specifications for an AIMS Page A-7
within the Lubbock metropolitan area. Furthermore, the license shall grant the City the right to
modify the software but only in the event that the Contractor goes out of business or is unable or
unwilling to make desired software modifications at a reasonable and justifiable price.
For the ATMS software, central. communications software, workstation software, and remote
communications software, two (2) copies on suitable magnetic or optical media shall be
delivered to the City at the same time the software is delivered.
The ownership of the copyright in such software as furnished by the Contractor to the City under
the Contract shall remain with the licensor. The ATMS software is proprietary information and
property.
The Contractor shall also transfer to the City the licenses for any and all third -party software
which is implemented by the Contractor.
1.2.3 Central -to -Field Communications
The required communications architecture is depicted in Figures 1.2.3-1, 1.2.3-2, 1.2.3-3.
Figure 1.2.3-4 depicts an alternate configuration with a dedicated communications link between
the TOC and the Signal Shop. The central system elements shall support RS-232 field channels
suitable for polled communications with groups of controllers. As part of the initial system
deployment called for under this Contract, at least two (2) and possibly three (3) different field
communications mediums shall be used to accomplish this function.
The new ATMS shall use polled communication to provide continuous (although not necessarily
once -per -second) monitoring of all controllers and other connected devices. The time required to
poll all devices on a channel shall depend on the communications medium and on the number of
devices. For each medium, the Contractor shall determine a configuration (e.g., number of
devices per channel) that will assure that each device is polled at least once per minute during
normal operations. When one or more intersections are being displayed in detailed mode, the
software shall vary the polling sequence to assure that each such detailed display is refreshed on
a once -per -second basis.
The proposal shall state for each of the three proposed communications mediums (i.e., twisted -
pair, fiber optics, and spread spectrum radio), the maximum number of intersections that can be
assigned to a channel and still provide for once -per -second detailed monitoring of up to three (3)
of the intersections on that channel.
Specifications for an AIMS Page A-8
SEE FIGURE 1.3.3-3
•f��ffffffffffffffffff�fffffffffffffffflf f�
• CONTRACTDR-FURNISHED EOUIPI.IENT •
r AT SIGNAL MAINTENANCE SHOP
SEE FIGURE 1.3.3-3
FIGURE 1.2.34
SONET NETWORK
(TO BE INSTALLED BY CITY OF LUBBOCK)
'-FURNISHED
(KM AND
HERALS
FIGURE 1.2.3.1-1
INTERSECTIONS TO BE CONNECTED BY
EXISTING TWISTED PAIR CABLE
FIGURE 1.2.3.2-1
INTERSECTIONS TO BE CONNECTED BY FIBER
Page A-9.3
W
Ra
O
E4
z
a
0-4
E4
U
w
cn
a
w
EF
z
0-4
Ej
a
w
a
CD
4r 9, Lu pO/Nfl3.s%l t Klcr% 0
f
NTSC
$ YOTR
l•
0
EN-232 TO VIDEO CONTROLLER CAMERAS EAR TOC
(IF ANY)
NTSC
i/
ELA-232 TO VIDEO CONTROLLER
OPTICAL E•A 170/NTSC VIDEO DISPLAY '
BACKBONE 2 DOTAL
VIDEO CODEC
RECENER
VIDEO
7DS-1 HYBRID .
OS- T SWITCH
OC-12 1 I OC-3
v
OPTICAL.
BACKBONE
n•■■■■■■■■■.■.....r..■■■■■■..■■r■.■■.■��
_�
I
CONTROLLER TO BE CONNECTED •••
•••�
rr�
VIA. Ex. TWISTED PAIR CABLE
.�
O:
TC TC TC
MODEM MODEM MODEM
TWP
MODEM
•
•
i
■
■
MODEM MODEM MODEM
TWP
MODEM
,
•M
TC TC TC
�tw■■.■■■■■■�■■■■■
�■■.■■■■■■ �.■w■■■•�•••••••••••••
�w■■.■.■■.■..■.■■■■■.■■•■■■■...•..■..•••
EIA-232
TC TC TC+•••■�•.+
OTR / OTR OTR
OTR
OTR / OTR OTR
OTR
;
■
■
TC TC TC
OS-1. 1 PER NODE
B &a.
IV&
._
IMIL
IMLIX
(INTELLIGENT
MULTIPLEXER)
V.34MODI MODEM
IOPERATOR I
EIA-232
I CONTROL I
TO VOTR
I PANEL r —
L___J I
L
VIDEO
r
CONTROLLER
r---1 I
IOPERATORI I
I CONTROL
I PANEL I
t_---�
f
PRINTER
OTHER PC WORKSTATIONS
AND COMMON PERIPHERALS
(CITY -FURNISHED)
CITY -FURNISHED OR FUTURE
CONTRACTOR -FURNISHED
ETHERNET
SWITCH 1 BASE TX SERVER
ETHERNET 100BASE T (FAULT PRIMARY
TOLERANT)
100 BASE TX
00 TO PUBLIC TELEPHONE NETWORK FIGURE i.2.3-2
NEAR BY CONTROLLER TO BE ����
CONNECTED WITH FIBER OPTIC CABLE TOC
(FUTURE) ���
PRIMARY
PC WORKSTAK?N
SERVER
TC TRAFFIC CONTROLLER
PTI PAN, TILT, ZOOM
FIGURE 1.2.3-3
FIELD HUB
OPTICAL
BACKBONE
OC-12
C:9►]
2 DIGITAL
VIDEO -
NTSC
VOTR
EIA-232 TO VIDEO CONTROLLER
NTSC VOTR
CCTV
CAMERAS NEAR TOC
(IF ANY)
EIA-232 TO VIDEO CONTROLLER
EIA 170/NTSC VIDEO DISPLAY
OS-1 F1Y8R10
DS-1 VIDEO
SWITCH
w OPTICAL 8 1 PER NODE —s
�p BACKBONE
�■■rrwr■■■rrw•r■rwrtrrw■ww■r■■■■r■■r■.rrr■rwrr■
I CONTROLLER TO BE CONNECTED �1+
VIA. EX. TWISTED PAIR CABLE 400
ro: T c___l TC TIC 000.....
: MODEM MODEM MODEM •
MODEM . •
■ ■
■ MODEM MODEM MODEM
EM
MODEM �■
TC TC TC ssssss•'r• • `
■s■■r••■rr•■r.r■.rw■■rr■■rrrrrrrrr.■rs�
���•••••■■■■rrr■■r■■rrrrrr•rw■wrrr■w■war EIA-232
■ TC TC TC ■ sr■sr r'
■
T.
OTR // OTR / OTR OTR
■
■ :
OTR r/ OTR / OTR OTR :
■
TC TC TC �410
NEAR BY CONTROLLER TO BE
■ CONNECTED WITH FIBER OPTIC CABLE
(FUTURE)
.s■r�rrrrrrrrr■•rrrrrrrrrrrrrrrrrrrrr:rr�■s
M
CONTRACTOR-MITNISHEO EQUIPMENT sr
•
AT SIGNAL MAINTENANCE SHOP
■
■
GROUTER
10 BASE T
ETHER
:
•
■
WORKSTATION
r
■
■
�
■
r
2 DS-1
OTHER CITY -FURNISHED
WORKSTATIONS AND
• PERIPHERALS
PRINTER
•■■w■■rrr■r■■rr
_
r — —
u
OTHER PC WORKSTATIONS
OPERATOR (
EIA-232
AND COMMON PERIPHERALS
(CITY -FURNISHED)
•
I CONTROL I
TO VOTR
GROUTER
i PANEL r
1111
•
L___J i
r
L
■
■
CITY —FURNISHED OR FUTURE
r
VIDEO
■ ■rr■■.rw■■.■w■■r■■r■■r■r••.
CONTROLLER
CONTRACTOR —FURNISHED
r — — — -i
r
:
OPERATORI i
0PRIMARY
CONTROL t- —�
:
PC WORKSTAM
iI
PANEL I f■■■■r■■
■■.roil
■
L—_—J ■
ENT 4■■■■rwr■■■■r■�
_
E(
cER)
ETHERNET 10 BASE T
ITCH
too am Tx
SERVER
PRIMARY
TOLERANT)
100 BASE T%
V.34 1 10 BASE T
MODEM MODEM KR
O TELE TPHONE NETWORK FIGURE 1.2.34
ALTERNATE TOC CONFIGURATION
WITH DEDICATED LINK TO SIGNAL SHOP
FIGURE 1.2.3- 4A
TOC
OPTICAL
BACKBONE
OC-12 I J OC-3
OPTICAL GROUTER
BACKBONE
CITY -FURNISHED OR FUTURE
- � � � � � � � � .. � � � � � �. � - EIA-232
CONTRACTOR -FURNISHED TO VOTR
CONTROLLER TO BE CONNECTED PRINTER
VIA. EX. TWISTED PAIR CABLE
TC � TC--1 I TC I OTHER PC WORKSTATIONS
MODEM MODEM MODEM
MODEM MODEM MODEM
TC TC TC
MODEM
TWP
MODEM
AND COMMON PERIPHERALS
CONTROLLER (CITY -FURNISHED)
I I I]-
CITY-FURNISHEDORF RE_
CONTRACTOR -FURNISHED
Cabs I PC PRIMARATION
EIA-232
TC TC TC
SERVER
OTR OTR OTR OTR PRIMARY
V34 V34
OTR OTR OTR OTR MODEM MODEM
TC TC TC
TO PUBLIC TELEPHONE NETWORK
NEAR BY CONTROLLER TO BE
CONNECTED WITH FIBER OPTIC CABLE
(FUTURE)
ETHERNET 100 BASE TX
SWITCH
SERVER
SECONDARY
Page A-13
1.2.3.1 Existing Copper Twisted -Pair Cable Network
Approximately 94 intersections are currently linked to the existing UTCS system by means of an
existing City -owned and maintained copper twisted -pair (TWP) cable network. Although
installed in 1984, this cable network is still in reasonably good condition as evidenced by the fact
that it is satisfactorily supporting the once -per -second command and control requirements of the
UTCS system.
The Contractor shall provide and install in the TOC the central apparatus necessary to interface
the new ATMS central hardware with the certain pairs of the existing TWP cable network. As
part of the initial system deployment called for under this Contract, the existing TWP cable
network shall be used for communications with thirteen (13) intersections along and south of
50th Street, as depicted in Figure 1.2.3.1-1. At each of these intersections, the City shall remove
the existing NEMA TS 1 controller and cabinet (which is controlled by the UTCS system) and
replace it with a City -furnished Type 170 controller that will be controlled by the new ATMS.
The existing TWP cable termination facilities in the TOC shall be reused as shall the existing
lightning and surge suppression apparatus. The Contractor shall furnish and install new rack -
mounted central modems that are compatible with the internal modems in the City -furnished
Type 170 controllers.
LZ3.2 New City -Installed Fiber Optic Communications System
The City of Lubbock is installing a new fiber optic (FO) communications system, the overall
architecture of which is depicted in Figure 1.2.3-1. As part of the initial system deployment
called for under this Contract, this new FO communications system shall be used for
communications with approximately ten (10) intersections along and between South Loop 289
and 82nd Street, as depicted in Figure 1.2.3.2-1. In the event the SONET network depicted in
Figure 1.2.3-1 is not operational, the connection of these intersections will be accomplished by
making temporary use of two of the City's "ring" fibers to create one multi -drop field channel.
At each of these intersections, the City will install new City -furnished optical transceivers
(OTRs) and connect the RS-232 output to the existing Type 170 controller. At the closest field
hub, the City will install a FO communications rack and furnish and install a rack -mounted OTR
compatible with the OTRs at the intersections.
1.2.3.3 New City Installed Spread Spectrum Radio System
It is anticipated that new City -installed spread spectrum radio communications will be used to
interface approximately eleven (11) intersections located on or west of Slide Road, as depicted in
Figure 1.2.3.3-1.
Specifications for an ATMS Page A-14
It is presumed that the master radio will be located in Southwest Lubbock. At least three options
are being considered for the communication between the master radio and the TOC:
Use of pair(s) on the existing TWP network, in which case the master radio would
presumably be located at 50th & Utica (which is the western -most intersection
served by the existing TWP network on 50th Street).
Operation of these intersections as a wireless extension of this same
communications channel which will serve the fiber -connected intersection on 82nd
Street. In this case, the master radio would presumably be located at 82nd &
Vicksburg (which is the western -most intersection traversed by the FO cable on
82nd Street).
Use of a new wireless link between the Municipal Square building and Southwest
Lubbock. Line of sight is thought to exist between a radio tower at Municipal
Square and a radio tower located near the intersection of Slide Road and 79th Street.
1.2.4 . Growth and Expansion Requirements
The ATMS applications software and the core elements of the central hardware and software
shall be capable of operating at least 350 intersections without wasteful modification or revision
to the basic system. The modular hardware as initially installed shall accommodate a minimum
of 200 intersections. Modular expansion of the hardware shall be provided to accommodate 350
intersections at an average of sixteen (16) intersections per RS-232 field communications
channel.
The TOC hardware shall provide open architecture for future expansion to provide features such
as closed-circuit television (CCTV) traffic surveillance, variable message sign (VMS) control,
and inventory database connectivity. Communications and interoperability with the traffic
management systems of other jurisdictions shall also be accommodated in the future.
The overall system architecture shall be modular in design, allowing economical upgrading of
components without significant wastefulness as newer technology becomes available. This may
include but not be limited to faster microprocessors, additional communications mediums, and
the need to increase the number of computers connected to the system. Thus, to accommodate
future expansion, the initial equipment (e.g., rack slots) must have capacity in excess of that
required to meet the minimum initial requirements.
Specifications for an ATMS Page A-15
SECTION 2
FUNCTIONAL REQUIREMENTS OF THE NEW ATMS (TCS-II) CENTRAL
SOFTWARE
2.1. System Overview
2.1.1 Computer Type
The TCS-II server shall be at least a Pentium II - 300 MHz machine, the workstations must be a
minimum of Pentium II - 166 MHz machines. By means of a local area network (LAN), the
system shall support multiple terminals (including remote terminals) and shall be designed to be
compatible and compliant with emerging industry standards for system interconnectivity,
interoperability, and expandability.
The networked computer(s) and terminals which comprise the heart of the TCS-II shall
intelligently interact to provide an integrated management system for the traffic signal controllers
and other system elements. The TCS-II software is responsible for integrating the TCS-II central
equipment to operate the controllers.
The system shall include a graphic user interface (GUI) as an integrated function within the TCS-
II software. The GUI shall provide graphic displays such as dynamic maps.
2.1.2 System To Provide Distributed Control and Centralized Monitoring
The new TCS-II shall provide distributed control and centralized monitoring:
• Control shall be distributed to intelligent local intersection controllers. The central
system shall command the operation of a particular timing plan, but the timing plan
itself shall be stored within and executed by the local controller.
• The central system shall provide polled monitoring of all controllers and other
connected field devices.
2.1.3 Field Communications Protocol
The Server shall provide a "device independent" communications front-end. This shall allow the
Work Stations to remain independent of the Device protocol requirements, thus allowing a mixed
variety of protocols (i.e. W4IKS, ACT, NTCIP, etc.) to be supported simultaneously. Other
Devices such as variable message signs and weather stations will also be supported by the Server
without regard to protocol requirements.
CALTRANS AB3418 (NTCIP Protocol available today) will be provided with the initial
software. Full NTCIP will be provided when available at no additional cost.
Specifications for an ATMS Page A-16
2.1.4 Automatic Detection of System Malfunctions
A traffic signal system's effectiveness is primarily a function of the timing plan which it
ultimately imposes on the street. This effectiveness is increased when adequate provision is
made for the early detection and efficient diagnosis of component malfunctions. A facility for
doing this shall be included in the new TCS-II. Malfunction detection and diagnosis and
automatic status logging shall be provided to minimize the time -to -repair of critical components
of the TCS-II.
In order to meet this requirement, the following table lists the alarms that are maintained by the
Server:
Alarm Reference
Alarm Description
1
Communications failure with one or more slave controller(s)
2
System detector failure
3
Slave controller in flash
4
Local cabinet in flash
5
Local controller in transition
6
Local controller in time base backup
7
Local controller hung -up in a loop
8
Local controller stop time active
9
Local controller local detector failure
10
AC power is low
11
Cabinet 24VDC failure
12
Local controller conflict detected
13
Local controller red monitor light out
14
Local controller watchdog trip
15
Local controller special monitor error
16
Local controller police switch active
17
Special function #1
18
Special function #2
19
Special function #3
20
Special function #4
21
Local controller keypad activity
22
Local controller power out greater than 255 minutes (RTC lost time)
23
Local controller hardware failure - SRAM
24
Local controller hardware failure - EPROM
25
Other local controller hardware failure
26
Traffic responsive occupancy threshold exceeded
27
Local controller preempt
28 - 32
reserved
33
* Vlink module secured access denied
34
* Vlink module serial port failure
35
* Vlink module C1 input active
Specifications for an ATMS Page A-17
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58-64
2.1.5
* Vlink module excessive RTC drift
* Bad Vlink communications line
* Vlink module configuration error
System detector log almost full
Split monitor log almost full
Plan log almost full
Traffic responsive plan log almost full
Function log almost full
Alarm log almost full
Event log almost full
System detector failure
* Vlink extent A configuration data corrupted
* Vlink extent B configuration data corrupted
* Vlink extent C configuration data corrupted
* Vlink extent D configuration data corrupted
* Vlink extent E configuration data corrupted
* Vlink module hardware failure
* Vlink module dual port RAM failure
* Vlink module RTC stopped
Oversized vehicle (greater than max. vehicle length in Table A01)
* Vlink module power failure (master running on battery backup)
* Vlink module power restored
reserved
* Indicates these are add -on features
System Sizing Requirements
The new TCS-II software, as furnished and installed by the Contractor, shall accommodate
expansion up to the following minimum limits:
• 350 Signalized Intersections;
• 350 Control Sections
• 600 System Detectors
• 2,400 Local Detectors
• 600 Count Stations
The Server shall communicate with intelligent local intersection controllers, detector count
stations, weather stations, etc.(hereinafter referred to collectively as "Devices") on a real-time
basis. The capabilities of each Server PC shall provide:
• Support of up to 4096 Devices connected via leased -line (FSK), hardwire, fiber optics
or radio
• Support a maximum data rate between each Device of 38.4K baud
• Support for more than 32,000 system detectors
Specifications for an ATMS Page A-18
• The capability of dividing the traffic network into a minimum of 350 sections.
Intersections and detectors shall be dynamically/online-assignable to any section. It
shall be possible to have intersections/detectors assigned to different sections, for
different times of the day, either by operator command or the TOD/DOW command
scheduler
• Provide real-time feedback (e.g. all status is processed and returned to the server
system at one second intervals
• Maintain a historical log of all real-time events that occur
2.1.6 Geographic and Functional Expansion
The system design shall provide for expandability, both geographical and functional. The system
as initially implemented shall provide for the easy addition of intersections, system detectors, and
other field elements. The software design shall also facilitate the future incorporation of
functional elements (e.g., closed-circuit television, automated incident detection, etc.) which are
not required as part of the initial project.
2.2 Required Features and Functionality
Subsection 2.1.provided an overview of the requirements for the new TCS-II. This Subsection
2.2 defines additional required features and functionality which the initial system must provide.
2.2.1 Graphical User Interface
The TCS-II graphical user interface (GUI) software shall provide the operator with a graphical
operating environment of the type commonly found on today's desktop computers. The GUI
shall be easy to use while providing a fast and efficient way to control and monitor the TCS-II in
real time. The GUI shall allow the operator to intuitively select objects on the screen by point -
and -click manipulation with the mouse, thereby minimizing typing and the need to memorize
lengthy commands. The system shall also provide hot keys for commonly used functions. The
GUI shall incorporate the following:
• Pop-up multiple display objects and windows;
• Menu icons and controls;
• Dialog boxes;
• Push button and other active commands;
• Visual and audio alarms; and
• Use of object characteristics such as colors, highlighting, and flashing to alert
operators of status changes
The GUI interface shall be oriented around graphic tools and based on the principle of direct
manipulation. Several windows may be active at the same time and may overlap on the screen.
However, the operator shall be able to interact with only one window at a time. The operator
shall be able to easily switch from one window to another, such as by pointing with the mouse
Specifications for an ATMS Page A-19
cursor to the uncovered part of another window. The operator shall be able to move any window
on the screen, to change window size, and to collapse a window to an icon. When an exception
condition (such as a device failure) exists, an inactive window shall attract the operator's
attention by beeping and/or flashing its icon or title bar.
Any WorkStation shall be able to display the status of the signals at an intersection or multiple
intersections using a graphical display that shows the approximate layout of the intersection with
colored signal heads. The WorkStation shall also provide a zone (group of related intersections)
display, where a number of Devices can be observed (in real-time) in relation to each other. The
map, regardless of whether it is showing a single Device, multiple Devices, or a zone, or the
entire City, shall be fully updated once per second.
For purposes of zooming in on the map, the operator shall be able to select a smaller area of the
map to expand to the current window size, or expand to fill a new window, which can be resized.
The zoom capabilities shall also allow for returning to the entire graphic image, as well as
redisplaying the previous view's scaled image.
The Contractor shall provide a static background base map using a user-friendly utility for import
and generation of these graphic images allowing them to be updated whenever new source files
are available.
Detailed intersection displays from AutoCAD-based design files or rasterized aerial ortho-
photographs can be used for the intersection and area maps. From the graphic generation utility,
the City shall be able to create and revise all the maps and intersection drawings. A library of
typical intersection files will be provided to enable the City to use and customize the library files
for specific use
The intersection area -wide layout (using a MapInfo base map) shall be part of the static base
map. At the top level, all intersections shall be displayable within one window. The operator
shall be able to configure the different displayable layers along with the displayed map scale that
these layers become visible. If real-time information is not available for display at certain top
level displays, the default condition for that layer shall be disabled.
The same icon shall be used as much as possible to display information. All colors shall be
selectable by the operator. A legend shall be available within the display window, describing
what each icon/color signify. As a minimum, this information shall include:
• street names;
• controller signal indication (coordinated movement only);
• controller status or mode & color:
in transition
pre-empted
flash
communication failure
no comm (off-line)
Specifications for an ATMS Page A-20
coordination failed
real-time feedback pre-empted
TOD/DOW coordination
manual control
free operation
traffic responsive
disabled by operator
• section assignments each displayed in a different color;
• communication layout;
• link detector information;
• individual detector information;
• all intersection returns (greens, yellows, reds, peds);
• system detector data; and,
• video surveillance locations.
By double clicking on the intersection icon on the overview map at any zoom level, the operator
shall be able to display an individual detailed intersection in a window of the traffic display. The
window size shall default to one -quarter size of the available display screen size. The operator
shall be able to change this default.
Multiple intersection display windows shall be available for the operator. The number of display
windows shall only be restricted to the number that can be feasibly displayed on the monitor.
The operator shall be able to minimize and maximize a detailed intersection display. This shall
enable the operator to have multiple displays available. The information available for
intersection displays shall include all information available for that intersection. At a minimum
these shall include the following:
• street names;
• current timing plan in use;
• signal display (vehicle & pedestrian);
• current communications status;
• control mode;
• vehicle calls per phase;
• ped calls per phase;
system detector actuation;
special functions;
timing plan parameters (based on central database);
•dector MOE information;
•dector status;
-transition status;
• cycle clock; and,
intersection MOE information.
2.2 System Access
Specifications for an ATMS Page A-21
2.2.2.1 Multi-user Access Required
The Contractor -furnished operating system and TCS-II software shall support a multi -terminal,
multi-user interface and the TCS-II software shall allow access to multiple levels of the system
simultaneously.
The base TCS-II software package shall support 8 external Work Stations simultaneously with
each user being able to be assigned a specific level of access privilege. The number of external
Work Stations shall have the ability to be increased to 12 by purchasing additional Work Station
licenses each one of who can be assigned a specific level of access privilege and be able to access
the system concurrently. The Texas Department of Transportation, Lubbock District Office shall
be considered part of the City of Lubbock's users within the above listed eight(8) and/or the
additional four (4). However, this use shall be limited to the Lubbock metropolitan area (i.e.
within the City's 5 mile E.T.J.) only. This license is limited only to simultaneous usage and not
platform installation. Each additional seat beyond the eight (8) may be purchased at a cost of
$4,000.00.
2.2.2.2 System Security
The TCS-II software shall provide and maintain a security system to prevent unauthorized access
to the system. This shall apply to executable files as well as text and database files. Operator
privileges shall be definable on a functional level. Each operator shall have a privilege level
mask defined for him/her by the system administrator. The mask shall define the specific
functions that the particular operator is authorized to perform. For example, a particular operator
may be given the ability to view all reports, but not to modify some or all levels of the database.
This shall allow for any number of different levels of operator access capability. The system
administrator level shall have full access to the system as well as the responsibility for
maintaining account passwords and privilege level masks. A dialog box shall be provided for the
system administrator to set up a database of users and their privileges. Check boxes shall be
shown for each defined area of system access, with separate entries for view and modify
privileges. Several default sets shall be available, including such categories as "system
administrator," "maintenance," and "traffic engineer." After a default set has been selected the
privileges shall be further customized for the individual. The software shall allow access to
multiple levels of the system simultaneously.
System security shall be ensured through the use of User ID numbers (social security numbers, or
any other unique identifying number), user changeable passwords, and user specific view and
modify privilege categories. All significant operations performed by the user or occurring while
the user is logged in shall be recorded in the Servers' event log and shall be tagged with the
user's ID, creating a system activity audit trail. Unsuccessful log -in attempts shall be logged to
the system log. All passwords shall be fully encrypted to help guard against outside "hacker"
invasion. Successful completion of the log -in shall result in execution of a session start-up
procedure.
Specifications for an AIMS Page A-22
The start-up procedure shall establish the privileges, object menu options, windows, and tools an
operator may utilize. Any functions that a operator does not have access to shall either not be
shown or be grayed out so the operator can easily distinguish what functions he has access.
The system administrator will also be capable of setting an automated log -out for inactivity of a
workstation. The system administrator shall have the capability to reduce the access capabilities
of operators when they log onto the TCS-II software via a remote computer.
LAN access shall be limited to those activities that support the TCS-II. Any activity that hinders
or does not directly support the operation of the TCS-II shall be restricted or eliminated. Any
executable files that are not needed in support of the TCS-II shall be eliminated from the system
or otherwise protected from access, thus minimizing any risk associated with unauthorized
access. Operating system tasks that impede system response shall also be eliminated (i.e. clock,
calendar manager, file manager, etc.).
2.2.2.3 Remote Access
The TCS-II software shall have the capability of providing access to the system for remote
operators. The remote access capability shall include workstations which are physically
connected to the LAN as well as dial -in computers. All connected computers, including those
connected by dial -in, shall be capable of concurrent operation.
The system administrator shall have the capability to reduce the access capabilities of operators
while they are logged into the TCS-II software from a remote computer. For example, someone
who would normally have full access privileges while inside the TOC might be granted lesser
capabilities if using a computer connected by means of dial -in modem.
2.2.2.4. Remote Computer Software.
The Contractor shall furnish a version of TCS-II software that runs on portable computers. Such
software shall be capable of performing all operator -allowed command and monitoring functions
available to operators within the TOC.
The software of the remote access computers will be the same version that is resident in the
workstations. Each remote computer shall have all graphics files resident. All other database
items shall reside only on the TCS-II server. The remote computers shall be able to monitor real-
time operations of a minimum of six intersections.
Remote access computers will have security features to prevent unauthorized access to the TCS-
II server.
Specifications for an AIMS Page A-23
2.2.2.5 Direct -Connect Access to Local Controllers
The Contractor -furnished portable computer software shall enable a portable computer to be
connected directly to the Type 170 local intersection controller. Field technicians shall thereby
have the ability to access and modify the local controller database without directly accessing the
TCS-II central software. This shall give the field technicians the ability to directly
upload/download controller timing parameters and to set the time and date.
Field technicians shall also have remote access to the TCS-II by means of a dial -up connection.
This function shall allow the technician to:
• Download the current ATMS parameters for any controller to a controller or
portable computer; and
• Upload newly established local controller parameters to the ATMS.
2.2.2.6 Automatic Paging
The TCS-II software shall have the capability of automatically sending alphanumeric messages
to pagers. The paging function of the software shall maintain a database of at least 100 system
event messages and at least 500 physical cross street addresses of devices. Upon detection of a
critical event, an alarm shall be sent to the pager of a designated operator. This feature shall be
fully programmable allowing designation of those events which will trigger a page and the
operator to be paged by time -of -day, day -of -week (TOD/DOW). If the operator to be paged is
logged onto the system at the time of the critical event, a general alarm to that operator will be
initiated instead of a page. The TOD/DOW function shall allow specified events to initiate a
page only during a specified time frame.
The paging system shall have a call back confirmation function to assure that the call was
received. If the confirmation does not occur, the paging system shall continue to page at an
operator -selectable time interval until confirmation occurs or the alarm is acknowledged. The
operator shall be able to enable/disable individual paging functions remotely by portable
computer or phone keypad. However, such actions shall be logged onto the system log.
The Server shall be capable of storing up to sixty-four phone numbers. The phone numbers shall
be used to alert a personnel pager or pager group when an alarm condition or event occurs. Each
phone number shall have the following programmable parameters:
• 16 byte pre -dial modem command string
• 16 byte phone number
• 16 byte text pager number/post-dial modem command string
• Modem/pager descriptor
• Pulse or touch tone dialing
Specifications for an ATMS Page A-24
• Maximum retries if phone calls are unsuccessful
• Wait period between retries
• Pager message acknowledge period
• Next phone number to use
The primary phone number can be any one of the sixty-four phone numbers. This phone number
can be changed to another by time of day or WorkStation intervention. If a phone number is not
specified by an alarm then the primary phone number is the first number used. If the phone calls
are unsuccessful and the maximum retries have been exhausted, then the Server shall use the next
phone number parameter to select a second phone number. If all of the calls using the second
phone number are unsuccessful then it uses the next phone number parameter of the second
phone number to select a third phone number. This process continues according to how the user
programmed all of the next phone number parameters until either a successful call is completed
or no next phone number is specified.
All events tracked by TCS-II can be sent to the pager. A database of 500 addresses of field
devices will be supported.
2.2.3 Time/Date Synchronization
2.2.3.1 Synchronization with Universal Time
The Contractor shall provide the means by which the system's Central Time clock is
automatically synchronized with universal time, either through the WWV radio broadcast or by
other City -approved means. Such automatic synchronization shall occur at least once per hour.
The capability shall also be provided for the operator to disable and re -enable this function.
The Server shall provide the sync pulse and adjust the real-time clock for each local intersection
controller on an operator selectable schedule. In addition, the server shall also be responsible for
synchronizing it's own internal clock and the WorkStation clocks using the world standard time
sync received from a Trimble GPS receiver.
2.2.3.2 Synchronization of Existing UTCS System with New TCS-II
To provide for seamless on -street operation, the Contractor shall provide the means by which the
old system and the new system can be synchronized with each other. The Contractor shall
analyze the existing ATMS central clock, and the Contractor shall provide an option to
completely replace the existing system with an expansion of the TCS-II system.
The Contractor will replace the existing clock with a Chrono-log K-Series Clock with internal
GPS for time synchronization and use it as the time sync for both systems. (This is included in
the list of contractor furnished equipment, section 4.1.2)
Specifications for an ATMS Page A-25
2.2.3.3 System -wide Clock Updates
The system shall provide for the automatic downloading of clock updates to each field clock.
The frequency of such updates shall be operator -programmable within a minimum range of once
per day to once per hour. Additionally, unless the operator has disabled the feature, the system
shall transmit a clock update in conjunction with the command for implementation of a different
timing plan.
2.2.3.4 Verification of Field Clocks
The TCS-II software shall also upload, on periodic basis selectable by the operator, the date/time
from local controller and other field clock. If the time/date in the field clock has drifted beyond
an operator -defined amount, then:
• The system shall automatically download the true time to the field clock; or
• The system shall report the clock drift to the operator.
In either case, the event and action taken shall be logged.
The frequency of this verification shall be set by the operator in the event scheduler.
2.2.3.5 Accommodation of Daylight Savings Time, Leap Year, etc.
The TCS-II software has the ability to disable daylight savings functions, handle leap years, and
handle crossover to the year 2000 and beyond. The W4IKS firmware also has been checked to
assure that no problem will arise at Y2K.
2.2.4 Control Modes
2.2.4.1 General
The TCS-II software shall operate in a distributed mode, fully making use of the intelligence in
the local intersection controllers. The intelligent local controllers shall be programmed with
timing plans, time-of-day/day-of-week (TOD/DOW) schedules, and all other parameters required
to operate the local intersection. All intersection controllers shall be monitored on a real-time
basis by the TCS-II software. Upon system startup, the TCS-II software shall establish
communications with all intersection controllers and begin real-time monitoring. The TCS-II
software shall start to process both incoming data and operator requests. Any upload, download,
or time/date requests shall take precedence over real-time monitoring. The TCS-II shall be
designed for unattended operation 24 hours per day, seven days a week, without requiring an
operator to be logged into the system.
Specifications for an AIMS Page A-26
The TCS-II shall provide system control by coordinating intersection operation on an individual,
section, or system -wide basis. The software shall include at least the following control modes,
which shall be operator -selectable from the GUI.
Upon system startup, the control mode shall always be local TOD/DOW. If the event scheduler
is calling for traffic responsive mode at the time of system restart , the system shall transfer to
traffic -responsive mode after an operator -selectable amount of time.
Because Lubbock has recurring traffic patterns on a daily basis, the new TCS-II will typically
operate in TOD/DOW mode. Traffic -responsive mode will primarily be used in areas with
unpredictable traffic and during special events.
For commanding an intersection to a timing plan different than the TOD/DOW, either by manual
override or through the traffic -responsive algorithm, the controller shall be commanded to the
appropriate plan. In the event that, while in software -commanded override, a controller does not
receive a valid timing plan number from the TCS-II software within an operator -defined time
frame, it shall revert back to its local TOD/DOW schedule. The central override shall be
allowable on an intersection, section, or system -wide basis.
2.2.4.2 Manual Control
The operator shall be able to invoke manual override of the plan currently in effect for the entire
system, for a subsection of the system, or for individual intersections. Manual selection of
timing plans shall have a higher priority than all other modes of timing plan selection. The
operator shall have two options for implementing manual override:
1. Setting the manual override and later releasing the override manually; or
2. Setting the manual override with a specified time frame for automatic termination.
Under the second option, the manual override shall terminate automatically at the end of the
specified time. When manual override is terminated, each affected controller shall revert to one
of the following modes of operation based on its normally scheduled operation.
2.2.4.3 Time-Of-Day/Day-Of-Week Control
TOD/DOW mode shall be used for controlling traffic conditions that occur regularly. In this
mode, each controller shall automatically select and implement traffic signal timing plans in
accordance with the defined schedule, locally stored, on a TOD/DOW basis. TOD/DOW plans
shall be downloadable from the TCS-II software to the controller in the field. The number of
timing plans available in the TCS-II database shall be limited only by the amount of disk space
available. Any plan located at the TCS-II shall be downloadable to any slot in the local
controller's database. The timing plans that are being stored in the local controller shall be
tagged in the TCS-II database so that the TCS-II software always knows which plans are stored
Specifications for an ATMS Page A-27
at the controller. In order to download a timing plan to a controller, the operator shall select the
plan from the TCS-II database and the controller memory slot where the plan will reside. The
user interface shall allow the operator to choose timing plans for all available memory slots at
once. This shall enable the operator to initiate one download per controller to download all
timing plans and time -of -day events.
2.2.4.4 Traffic -Responsive Control
In the traffic -responsive mode of operation, the TCS-II software shall select the timing plan that
is best suited to the existing traffic conditions as measured by the system detectors and analyzed
by the TCS-II software's traffic -responsive process. Once the traffic -responsive process has
selected the appropriate timing plan, the plan number shall be commanded to the intersections
on a continuous basis until the traffic -responsive process recognizes, based on sufficient change
in traffic conditions, the need to command a different timing plan.
The traffic -responsive algorithm shall be based on the UTCS algorithm or other traffic -
responsive algorithm approved by the City. In order to enhance traffic responsive operation, the
following three traffic -responsive process points shall be implemented:
• Each section shall be associated with zero to a maximum of ten other sections, one
of which shall be designated as the master section. When traffic conditions warrant
a traffic -responsive timing plan change for the master section, the TCS-II shall
automatically change the timing plans for the other associated sections. If no other
sections are associated with a section, only that section shall change timing plans.
• The operator shall be able to define a single detector station as a section. When the
traffic -responsive process detects that this station has exceeded operator -defined
thresholds, the associated sections shall automatically change to the appropriate
traffic -responsive plan. This process is intended for use in conjunction with special
events (such as to detect and respond to a surge of traffic leaving the parking facility
of a stadium or arena following the end of a sporting event).
• Section definitions shall be changeable on a time -of -day basis. The intersections
within a section shall be changeable, allowing intersections to be in different
sections depending on the time -of -day. Definition of master sections and associated
sections shall be changeable, allowing sections to be associated with different
master sections depending on the time -of -day.
Specifications for an ATMS Page A-28
The following traffic -responsive algorithm shall be used:
The Server executes a traffic responsive algorithm that implements plans for a group of
local intersection controllers according to monitored traffic flow through a corridor.
Volumes and occupancies of system detectors assigned to inbound, outbound, and side
street traffic are scaled and monitored by the algorithm. Volume thresholds are set for
three bands (three sets of plans), and three traffic flow compensation thresholds are set for
each band. The algorithm implements plans one through nine according to the current
band and compensation. Inbound, outbound and side street occupancy thresholds are also
set. The algorithm implements plans ten through seventeen when monitored occupancies
exceed the set thresholds.
All of the algorithm's plan changes are logged and can be accessed by the WorkStation
for review at a later time.
Should communications be lost to one or more intersections in a section operating in
Traffic -Responsive mode, for an operator -defined time frame, the whole section will drop
back to its local TOD/DOW schedule.
2.2.4.5 Free Operation/Remote Flash Mode
In the free mode, the controller shall run uncoordinated. To initiate flashing operation remotely,
the controller shall be commanded to flash from the TCS-II software.
2.2.5 Signal Timing Plan Implementation and Monitoring
2.2.5.1 Control Sections (Subsystems)
The new TCS-II shall enable the operator to define a minimum of 350 control sections, or
subsystems, each of which shall be completely independent of the connection of any particular
intersection to the communications network. The number of intersections in. a particular
subsystem shall be programmable from a minimum of one to a maximum of the total number of
intersections in the system. Intersections and detectors shall be dynamically/on-line assignable to
any section. It shall be possible to have intersections and detectors assigned to different sections
by time of day, either by operator command or through the event scheduler.
A dialog box shall be provided to define "control groups," which are groups of coordinated
intersections. The parameters for a control group shall be the name and a user -defined text
description of the control group. From the control group setup dialog the user shall also be able
to run a particular timing plan for the entire control group, and generate a report on the existing
control groups in the system.
Specifications for an ATMS Page A-29
2.2.5.2 Local Intersection Control and Control Modes
Local traffic signal control functions shall be provided by the local controller firmware. The
intersection controller shall determine the coordination cycle synchronization point from the
current time -of -day. All offset, split, and transition timings shall be determined and
implemented locally.
Under normal operation, intersection control shall follow the local controller TOD/DOW
schedule. When the operator or TCS-II software determines that a different timing plan should
be implemented, the system shall download the timing plan, if required, and command the
intersection to that plan by sending the plan number to the controller. If communication is lost
between the intersection and the TCS-II software, the intersection shall revert back to its original
TOD/DOW schedule. The downloaded special plan shall not overwrite any plans that are used
by the TOD/DOW schedule. The operator shall be able to select controller timing plan slots to
be used as temporary locations and the remaining slots for TOD/DOW usage.
2.2.5.3 Type 170 Local Controller Software
The new TCS-II shall provide the capability to control Type 170 controllers. The Contractor
shall upgrade the City of Lubbock's Wapiti license to Version 44a. With this upgrade the
intersection software will fully integrate with TCS-II
The Contractor shall ensure that the Type 170 local controller firmware (either existing or
Contractor -furnished), in conjunction with the new Contractor -furnished TCS-II central software,
fully accomplishes the local control and monitoring functions required by this specification.
2.2.5.4 Number of Timing Plans Required
The TCS-II system will handle an unlimited number of timing plans in its database with a
minimum of 32 timing plans for each intersection. At any one time, it shall be possible for a
minimum of eighteen (18) of these plans to be stored in the controller's database and
implemented upon command by the new ATMS. The TCS-II will handle an unlimited number
of timing plans in its database. The number of available cycle lengths shall be at least six (6).
Each timing plan shall include uniquely programmable values for cycle length and offset, a
uniquely programmable phase sequence, and uniquely programmable split values. The software
shall provide both the automatic calculation of permissive periods (based on split values) and the
ability for the operator to input desired values for the beginning and end of permissive periods.
The new system shall also provide the capability to handle special signal and/or timing plans to
accommodate unusual traffic flow patterns during special events, parades, etc. These special
event timing plans may be included within the thirty-two timing plans.
Specifications for an ATMS Page A-30
2.2.5.5 Accommodation of Phase Sequences
The new TCS-II software shall provide for the independent control of each phase of an eight -
phase, dual -ring controller. For example, in normal quad -left operation, it shall be possible to
program the force -off for Phase 1 independently from the force -off for Phase 5. The new TCS-II
shall also provide for the control of lead -lag phase sequences. In conjunction with each timing
plan, the software shall enable the independent programming of each odd numbered phase to be
either leading or lagging with respect to its associated even numbered phase. (For example, for
each timing plan, it shall be possible to program the lead -lag status of the 1-2 phase pair
independently from that of the 5-6 phase pair, the 3-4 phase pair, and the 7-8 phase.)
The new TCS-II software shall also provide for the control of standard three-phase and four -
phase (e.g., TTI diamond interchange phasing, the latter of which is currently in use in Lubbock
at the diamond interchanges along Loop 289.
2.2.5.6 Preemption
The new TCS-II software shall recognize the occurrence of locally -initiated preemption and
thereby not erroneously diagnose a ?coordination failure because the local controller has been
preempted.
2.2.5.7 Accommodation of Pedestrian Services Which Violate Normal Split Times
Several locations in Lubbock have unusually wide streets and the cross -street split times (which
are based on vehicular needs) do not accommodate a pedestrian service. Accordingly, whenever
a pedestrian actuation does occur, the intersection will get out of step. The TCS-II software shall
not fail the intersection as a result of a normal force -off time being exceeded to service a
pedestrian call. It shall be permissible for such a pedestrian call to be treated as a preemption for
the purpose of accomplishing this requirement.
2.2.5.8 Special Functions
The TCS-II shall accommodate the control and monitoring of the on/off status of a minimum of
four (4) special functions to be implemented by the intelligent local controller. The City will
define the scope and parameters of the special functions.
2.2.5.9 Remotely -Requested Download of Local Database
The maintenance technician shall have the ability, from the local controller, to effect a download
of the local controller database from the central database without the need for an operator to be
present at the TOC.
Specifications for an AIMS Page A-31
2.2.5.10 Timing Plan Compliance Monitoring.
The TCS-II software shall monitor the real-time phase returns from each intersection to ensure
that its operation is within proper constraints of the timing plan that is in affect. The TCS-II
software shall use the TCS-II database timing parameters to check against the real-time phase
returns. Operator -definable filters shall be utilized to define the window of time that a phase
must start or stop.
Through compliance monitoring, the error conditions, which shall be detected, includes but is not
limited to the following:
• The controller is not using the proper timing plan;
• The controller time clock is out of synchronization;
• The controller is not sequencing;
• The phase sequence is improper; and
• Phase time compliance.
The TCS-II software shall automatically inhibit monitoring if real-time feedback is not being
received from the controller.
2.2.6 Communications Failure Monitoring
Communications and controller hardware monitoring shall cause the system to fail individual
components when operator -definable error thresholds are exceeded. These components shall
include intersections, detectors, and communication channels. Upon failure, the TCS-II software
shall log the event and also display a visual alarm to the operator. The TCS-II software shall
continue to attempt communication with the failed component. If the failed component
communicates successfully for an operator -specified amount of time, the component shall be
considered operational. This event shall also be logged, along with the clearing of the alarm for
the failed component. The operator shall be able to disable any component in the system through
the user interface. When disabled, the software shall not communicate with the component.
The communications alarm shall also be able to be sent to a pager.
2.2.7 Event Scheduler
2.2.7.1 General
The operator shall be able to schedule any command for execution at any time. The system
administrator shall be able to inhibit commands from being entered into the event scheduler. The
entries in the event scheduler shall be automatically sequenced in ascending order by
TOD/DOW, regardless of the order in which the entries were made.
Specifications for an ATMS Page A-32
Operator commands shall have priority over scheduled entries in the event scheduler. The
operator shall be able to make entries into the event scheduler for up to a minimum of one year in
advance. The scheduler shall have the capability to load multiple commands for the same time
and to execute those commands at the same time. For events scheduled at the same time, the
execution shall be sequential.
The event scheduler dialog shall allow the user to configure the Server's internal scheduler to
perform specific actions based on time and date. Events can be scheduled to occur on any
combination of the day of the week, a particular date, or whether the day is a (user -definable)
holiday. The start time, and stop time shall be able to be specified. The target of the operation
shall be the complete traffic control network, a particular communications channel, a control
group, a specific Device, or an internal operation such as a system backup or time
synchronization. In spite of the flexibility offered in the scheduler, setting up events shall be
very easy and intuitive.
The Server shall support up to ten thousand (10,000) programmable time of year (TOY) events,
and up to ten thousand (10,000) programmable time of day/day of week (TOD/DOW) events.
Each event can be configured to implement a plan or execute a function.
The available externally oriented operations shall include:
1. Run a specific local controller coordination plan
2. Enable the local controller to run in "free" mode
3. Enable/disable responsive operation
4. Override the current responsive plan
5. Make a local controller active or inactive
6. Make a specific detector active or inactive
7. Make a specific comm. channel active or inactive
8. Place local controller in "flash" mode
9. Place local controller in "off-line" mode
10. Generate an alarm report
11. Clear a specific log
12. Enable/disable detector diagnostics
13. Broadcast real-time to a group of Devices or all Devices
All external events shall support an individual Device, a specific control group, or the entire
system.
The available internally oriented operations shall include:
1. Turn paging on or off
2. Synchronize the WorkStation and Device real-time clocks
3. Fetch the failure log from the Server or On -Street Masters
4. Auto log out an inactive user
Specifications for an ATMS Page A-33
5. Perform a database backup on the Server
6. Check to see if the system is running on UPS power
7. Close all the currently open database files and update.the disk archive
The user shall also be able to edit the holiday list and generate an event report from this dialog
box.
2.2.7.2 Temporary and Permanent Commands
Commands entered into the event scheduler shall be of two types, permanent and temporary.
Permanent commands shall be performed every time the matching of time parameters occurs.
Temporary commands shall be performed once and then be deleted from the scheduler database.
The operator shall be able to enter the following permanent and temporary command times as a
minimum.
• Permanent commands:
• Every day basis (i.e., every day of the year);
• Every week basis (i.e., on a given day or days of every week);
• Every time span basis (i.e., every hour);
• Every weekday (i.e., given weekday from Monday through Friday); and
• Every weekend (i.e., given weekend day such as Saturday or Sunday).
• Temporary commands:
• Specific date basis (e.g., December 25, 1997);
• Specific time basis (e.g., at 2:00 PM or 1400 hours)
• Specific date/time basis (e.g., on 4/15/98 at 11:00 AM)
Events are programmed with a start time, stop time and event action. They are also programmed
to be reoccurring (occurring every hour/day/year) or single shot (occurring only once unless
reprogrammed).
2.2.8 Traffic Data and Measures of Effectiveness
2.2.8.1 General
The TCS-II software shall be capable of using both system and local detectors for traffic
counting, traffic -responsive operation, and computation of measures of effectiveness (MOEs).
The TCS-II software shall be capable of handling the maximum number of detectors allowable
per intersection controller. The system shall process and maintain detector count data and
occupancy data on a continuous basis to be used for various traffic control strategies, reporting
tasks, and other functions. Detector feedback shall be obtained in an operator -selectable time
frame in minimum one minute increments.
Specifications for an ATMS Page A-34
2.2.8.2 Detector Data Types
At least the following detector data types shall be retrieved:
1) Volume - the number of vehicles (counted in an interval of time) where raw and
smoothed volume shall be displayable in operator -defined intervals;
2) Occupancy - the percentage of time the detector loop is occupied;
3) Speed;
4) Gap; and
5) Classification data.
2.2.83 Detector Data Collection and Retrieval
The TCS-II software. shall automatically record detector data in the TCS-II database, and
periodically archive the data onto removable optical media. Raw detector data shall be stored in
memory on a five-minute basis. Up to four weeks of five-minute detector data for each
intersection shall be stored in the TCS-II database by the database program. If bad data or no
data is received from the detector loops during any or all of the five-minute time frames, the data
will be tagged as questionable or not available in the TCS-II database. An operator -definable
filter shall be used to set the thresholds regarding the usability of data.
Each five-minute block shall be date/time tagged. In case of failure during a database write
process, the database program shall not leave a partially -written five-minute block. Any missing
five-minute blocks shall be tagged as unavailable for that five-minute period. The operator shall
have the ability to enable or disable the detector data collection function.
Every twenty-four hours, the five-minute detector data shall be automatically compressed and
written onto removable optical media. Each 24-hour history block shall be date/time tagged.
The data storage feature shall have the ability to append 24-hour detector data to the removable
optical media, enabling full usage of the media. When the removable optical media does not
have enough storage space left for a full 24-hour block, the system shall notify the operator that a
new storage disk is required. If this happens following a Friday or Saturday archival process, the
system shall set an alarm to notify an operator by pager. The operator shall have the ability to
enable or disable the detector data archival feature.
Detector data shall be retrievable from the removable optical media for use with the relational
database or traffic modeling packages. Upon retrieval, the detector data shall be automatically
expanded from the compressed format.
2.2.8.4 Detector Monitoring
The detector feedback from the field shall be continuously monitored for proper operation.
Detectors shall be classified as acceptable, marginal, disabled, and failed. Detector failures shall
be reported to the system log and operator alarm.
Specifications for an AIMS Page A-35
The TCS-II software shall have operator -selectable filters that define the thresholds that a
detector must exceed to be considered failed. The filter values shall be selectable on a TOD
basis. A minimum of three (3) TOD settings shall be available. As a minimum, the following
four failure types shall be diagnosed:
• Maximum Presence: if an active detector exhibits continuous detection for a
program entered period (0-255 minutes in one minute increments);
• No Activity: if an active detector does not exhibit an actuation during a program
period (0-255 minutes in one minute increments);
• Erratic Output: if an active detector exhibits excessive actuation (program entered
maximum counts per minute 0-255 in increments of one); and
• Failed Communication: failed detectors shall not be available for traffic control
strategies.
2.2.8.5 Intersection Measures of Effectiveness
The TCS-II software shall collect and store data on intersection measures of efficiency (MOEs).
The software shall process and maintain intersection MOE data on a continuous basis to be used
for various timing analysis and reporting tasks. Intersection feedback shall be stored on a per -
phase basis. The intersection MOEs which shall be stored include, but not be limited to, the
following:
• Percent of green time used versus split;
• Percent of detector calls (relative to a threshold value);
• Number of times the phase maxes out or is forced off prior to gap -out; and
• Number of pedestrian calls.
The system software shall automatically record intersection data in the TCS-II database, and
periodically archive the data onto removable optical media. Up to four weeks of intersection
data for each intersection shall be stored on the TCS-II database by the database program. If bad
data or no data are received from the intersection, the data will be tagged as questionable or not
available in the TCS-II database.
In case of failure during a database write process, the database program shall not leave a partially
written block. Any missing blocks shall be tagged as unavailable. The operator shall have the
capability to enable or disable data collection on an individual intersection basis.
The time increment between writing of data to the optical disk drive and start time shall be
operator -selectable with defaults of 24 hours and midnight, respectively. Data shall be
automatically compressed when written to the removable optical media. Each history file shall
be date and duration tagged via file naming convention. The data storage feature shall have the
ability to append intersection data to the removable optical media, enabling full usage of the
media. When the removable optical media does not have enough storage space left for a full
time interval of intersection data, the system shall notify the operator that a new storage disk is
Specifications for an ATMS Page A-36
required. The operator shall have the ability to enable and disable archiving on an individual
intersection basis.
Intersection data shall be retrievable from the removable optical media for use with the relational
database and traffic modeling packages. Upon retrieval, the intersection data from the optical
disk shall be automatically expanded from the compressed format.
The Contractor shall work with City staff to develop reports that uniquely meet the City needs.
2.2.9 TCS-II Database
2.2.9.1 Database Generation and Maintenance
The Contractor shall furnish and implement a City -approved, off -the -shelf database package.
The Contractor shall provide a database interface, which shall be integrated into the TCS-II
software to provide seamless operation for the operator. The resulting combination of TCS-II
software and database software shall provide for off-line and on-line database generation and
maintenance.
This shall include loading, modifying, examining, copying, and retrieving the data used to
operate the system. These data include traffic system configuration, timing plans, TOD/DOW
schedules, operator databases, and alarm databases. Traffic system configuration shall include
channel assignments, communication parameters, included intersections, etc. Any database
changes shall be achievable without having to restart the TCS-II software.
Data entry formats shall be designed for easy data preparation by the operators. All tables in the
database shall be printable in the proper format for use by the traffic engineers and maintenance
technicians in the field. For example, the timing plan sheets shall resemble the forms used by the
City for both data entry and in the printed form. In order to alleviate repetitive data entry, the
system shall allow the operator to copy data tables for use with other devices.
Database generation of traffic control operations shall include safeguards to preclude dangerous
or undesirable intersection operation. These safeguards shall, as a minimum, include range -
checking and timing plan verification.
The Server shall be responsible for maintaining all of the databases that implement the user
interface and system operations. The database format shall be Microsoft SQL Server, which
shall allow the database files and indexes to be accessed by third party utilities_ There shall be no
significant limitations on the size of the databases or database record fields.
2.2.9.2 Database Recovery
All database backup and recovery shall be through the TCS-II software user interface. The
operator shall be able to do the following:
Specifications for an ATMS Page A-37
Automatically compress and back-up the database on an operator -specified time -of -
day setting or upon operator command; and
Restore the back-up copy of the database to the TCS-II database.
The Server shall provide all the necessary utility operations for backing up, restoring, and
repairing the databases used by the program. The time of backup will be scheduled through the
event scheduler or by operator command.
As also mentioned above, there shall be only one operational set of the database files: this set
shall reside on the Server, and shall be shared rather than copied by the WorkStations. This
approach shall ensure database consistency and integrity among multiple users.
2.2.9.3 Database Reports
The operator shall be able to generate custom reports using the relational database custom report
utility supplied with the database package. The TCS-II shall provide a seamless interface to this
utility.
2.2.10 Reporting Capabilities
2.2.10.1 General
The reporting capability and monitor screen displays shall be obtainable from the same menu
options. The operator shall be able to click on a menu of report names and choose the display to
be shown on the monitor screen. The operator shall be able to print any of these screens to any
network printer or to a file at any time during the process by simply clicking a button on the
report screen. If sending to the printer, the text shall be reformatted as necessary in order to be
produce a legible printout. Unnecessary information shall not be printed. The City shall approve
all report formats.
Unless noted below, the displays/reports shall be available system -wide, by section, by channel,
or by single device.
A very flexible report generator is included in the WorkStation. All reports shall have the
capability to be directed to any combination of output devices such as the monitor, an ASCII text
file, or the printer. Where applicable, the report shall apply to the entire traffic control network,
or everything related to a Server, a particular Server channel, a control group, a local intersection,
a detector count station, or a configuration table archive set.
The Contractor shall work with City staff to develop reports that uniquely meet the City needs.
Specifications for an ATMS Page A-38
2.2.10.2 Types of Reports Required
As a minimum, the following displays/reports shall be available.
• System Status. This display shall be an overview of the present condition of all
devices in the traffic system. This shall include intersection controllers, detectors,
communication channels, and other categories of devices. The conditions shall
include all possible status conditions (e.g., on-line, failed, etc.) and modes (e.g.,
TOD/DOW, On Flash, etc.) as described in this specification.
By clicking on a particular category on the system status report, the operator shall
be able to initiate the display of an associated detailed report screen. For example,
by clicking on the field, which indicates the number of intersections failed, the
operator would initiate the display of a detailed screen listing the failed intersections
and other details (e.g., time of failure).
• Real -Time Monitor. This display/report will show the request and reply to and
from a single intersection. This monitor shall display the command being sent to an
intersection along with the feedback data received back from the intersection. The
display shall be continuous until stopped by the operator. The data shall be
displayed in an easily understood format. The data displayed shall not be displayed
in hex format. This display is required on an intersection basis only.
• Communication Statistics. This display/report shall show the communications
throughput. The display shall include number of communication attempts, number
of successes, number of failures, and percentage of successful communications per
intersection, per channel, and per system.
• Intersection Operation. This display/report shall show the detailed intersection
operation in real-time mode. This display shall be available on an intersection basis
only.
• Detailed Intersection Failure Status. This display/report shall display the failure
information for all failed intersections. This information shall include as a
minimum: intersection location, reason for failure, and time of failure.
• Detailed Detector Failure Status. This display/report shall. display the failure
information for all failed detectors. This information shall include as a minimum:
detector location, reason for failure, and time of failure.
• Camera Failure Status. To support a future closed-circuit television (CCTV)
surveillance system, this display/report shall include, as a minimum, camera
location, reason for failure, and time of failure. (Note: If and when CCTV is
Specifications for an ATMS Page A-39
installed, it is assumed that the cameras will be linked by means of communications
which are completely separate from the channels which connect the intersection
controllers.)
• Detailed Channel Failure Status. This display/report shall display the failure
information for all failed channels. This information shall include as a minimum:
channel address, associated intersections, reason for failure, and time of failure.
The Camera failure status report will be included in the video module of the software. The
Contractor will work with City staff to develop reports that uniquely meet the City needs.
2.2.10.3 Report Output Requirement
Reports and displays may be output to the TCS-II operator station monitors or any network
printer. Reports and displays may also be requested by remote computers, whether LAN -
connected or dial -in.
2.2.11 System Log Requirements
2.2.11.1 Traffic System Log
The traffic system log shall record, in order of occurrence, all traffic -related messages. As a
minimum, this shall include:
• Operational events (including occurrences of local preemption);
• Traffic device failures/repairs;
• Communication failures/repairs;
• Traffic data transfer messages;
• Manual override changes; and
• Operator log -on and log -off.
Unless the operator surppresed printing, log messages shall automatically output to a designated
printer. The operator shall be able to filter which messages are logged to the printer and shall be
able to suppress all log output to a printer. An on-line file of all log messages shall also be
maintained with all messages logged to the on-line file. This file shall be of fixed length and
circular format, overwriting at the beginning when reaching the end of the file.
2.2.11.2 Log of Current Operators
The TCS-II software shall maintain a continuous record of the operators who are currently
logged onto the system. The system shall add to this log any operator who logs onto the system
and, upon log -off, shall delete the name of that operator from this log.
Specifications for an ATMS Page A-40
2.2.11.3 Operating System Log
The operating system log shall log all central system related events that occur in order of
occurrence. As a minimum, it shall include the following:
• Internal system errors;
• System hardware failures;
• System network errors; and
• Software fatal errors.
Unless the operator has suppressed its printing, log messages shall be automatically output to a
designated printer. An on-line file of all log messages shall also be maintained. This file shall
be of fixed length and circular format, overwriting at the beginning when reaching the end of the
file.
2.2.12 Graphic Display Subsystem (GD5J.2.12
2.2.12.1 General
The Graphical Display System (GDS) shall follow the same graphical user interface guidelines
as the TCS-II software. The interface to the GDS shall be an integrated module of the TCS-II
software. All commands for manipulating the GDS shall be available directly from the TCS41
user interface. All graphic file generation shall occur within the TCS-II. Any remotely stored
graphic files shall be automatically updated by the system.
The graphic system shall have a base map that covers the entire extent of the City of Lubbock.
The base map will be a City -furnished CAD or GIS-generated graphic file serving as a static
background map. The Contractor shall incorporate the dynamic layers of the GDS onto the base
map. As a minimum, the base map will show the roadway centerlines of arterials and collector
streets, freeway centerlines, rail.lines, and major landmarks.
2.2.12.2 Pan/Zoom Requirements
As discussed in Subsection 2.3, it is desired that the dynamic mapping provided by the
Contractor incorporate full pan/zoom capability. In such case, the operator shall be able to set up
both dynamic and static informational layers that are displayed at different view scale levels by
defining the view scale levels in a zoom level set-up configuration database table. By setting up
the zoom scale range and appropriately enabled/disabled layers, the operator shall be able to
control which layers display at different zoom scales. For example, at the city-wide scale level
the operator might enable roadway centerlines (static information) as well as a communication
status indication (dynamic information) for each intersection controller across the city. When
zooming in to a group of intersections (i.e. changing the view scale), the roadway centerlines
would be disabled from view and the roadway curb lines would be enabled (become visible), and
perhaps all phases of all the intersections in the displayed group shall become visible.
Specifications for an ATMS Page A-41
An alternative, which would be considered as meeting the minimum required functionality (in
lieu of full zoom capability), would be to provide a minimum of three discrete levels of displays:
• System -wide display, which shall include the entire City of Lubbock. This level
shall include, as a minimum, centerlines of major roadways (including all which
include a signal), freeway centerlines, rail lines, and major landmarks. At this level,
signalized intersections, system detector stations, and other field devices shall be
depicted as dynamic symbols (e.g., circles, squares, etc.). The operator shall have
pan/zoom capability within the system -wide display.
• Area displays, which shall include portions of the system -wide display. (An
example would be an area display of the central business district.) At this level,
roadways may still be depicted as centerlines but all minor streets shall be included.
At this level, it shall be possible to view the green status of the coordinated phase
green. The operator shall have pan/zoom capability within each area display.
• Intersection displays, which shall depict roadway curb lines and lane lines and shall
include static displays of the following (as a minimum):
• Street names;
• Intersection number;
• Phase numbering;
• Special function definition; and
• North arrow.
The intersection display shall also include dynamic indicators as follows (as a
minimum):
• Controller operational mode (e.g., TOD/DOW, traffic responsive, manual, free,
or remote flash);
• Controller status (e.g., in transition, preempted, conflict flash, etc.);
• Communications status (e.g., on-line, bad communication, or no
communication);
• Timing parameters currently effect (e.g., control mode, transition status, control
section assignment, timing plan number, cycle length, offset, and split values);
• Color status of all vehicular phases and overlaps (including the circular red,
yellow and green indications and all arrows);
• Color status of all pedestrian phases (including walk, flashing don't walk, and
steady don't walk);
• Actuation status of all local detectors (vehicular and pedestrian) and all system
detectors associated with the intersection;
• Special function status;
• Count -up of cycle clock; and
Specifications for an AIMS Page A-42
• Count -down of the number of seconds remaining for the split of the phase in
service.
Common icons shall be used as much as possible for all display levels. All colors shall be
selectable by the operator. The same colors and icons shall also be used in display/report
screens. A legend shall be available within the display window, defining the meaning of each
icon and color.
If discrete display levels are used in lieu of full zoom capability, icons shall be provided on each
level's display to select the view of the other levels.
The Contractor -furnished software shall include a library of standard intersection drawings (e.g.,
standard four -legged intersection, standard ?tee intersection, etc.).
The Contractor will provide full zoom capability
2.2.12.3 Graphics Generation
As mentioned above, the system -wide base map will evolve from City-fu mished databases. The
Contractor shall provide a user-friendly utility for import and generation of these graphic images
for the GDS. Detailed intersection displays representative of the City's AutoCAD-based and
Microstation DGN design files shall also be able to be imported and generated for the GDS.
From this graphic generation utility, the operator shall be able to create and revise all the maps
and intersection drawings displayed by the GDS.
The actual creation of the graphic displays shall be a shared responsibility. As part of the
required training:
• The Contractor shall develop the system -wide display and demonstrate how it can
be edited in the future;
• The Contractor shall develop at least one area displays and oversee the creation, by
City staff, of other area displays; and
• The Contractor shall develop approximately ten (10) intersection displays
(encompassing a range of different intersection types) and shall oversee the
creation, by City staff, of approximately ten (10) other intersection displays.
The creation of the remaining area and intersection displays shall be the responsibility of the
City. The Contractor shall, however, provide telephonic guidance and support as needed by the
City.
All custom and commercially available software required for operation and modification of the
graphics generation utility package shall be supplied by the Contractor, who shall also supply
any additional hardware required for use of the graphics generation utility package.
Specifications for an ATMS Page A-43
2.2.12.4 Refresh Rates
All real-time dynamic data that are to be displayed on a graphic map shall be refreshed as
frequently as the feedback data are being returned from the field equipment. If feedback data are
not received from the field because of higher priority communication, a message shall be
displayed to the operator of the affected display.
All static graphic displays shall be designed and developed in such a way as to ensure
instantaneous redraw of the graphic display. This display includes the background map and the
real-time feedback data. For example, if the operator pans to the left, the entire screen needs to
be redrawn. All displays shall be drawn as quickly as possible. The draw time for the largest
map (system -wide) shall not take longer than two (2) seconds. All other displays shall not take
longer than one (1) second.
2.2.13 Scratch Pad Capability
The system shall have a method to leave messages electronically on the operator stations for
personal reminders or messages to other operators. The scratch pad facility shall be available in
a separate window integrated with the TCS-II interface.
2.2.14 System Installation and Failure Recovery
2.2.14.1 Software Installation
The installation of the TCS-II software from storage media shall be completely automated. From
the operating system command line, no more than two typed commands shall be required to fully
install all software required onto the computers. Once the software is installed, configuration
screens shall allow the system administrator to set distinct operating features of the system.
Regeneration of the software shall also be initiated from the event scheduler.
2.2.14.2 System Startup and Shutdown
The ability of the TCS-II components to interact with each other shall not be governed by a
structured start-up order. That is, if a component fails to operate or is powered down, the
remainder of the system shall not have to be shut down and restarted to re-establish a working
system. The unaffected components should simply wait for the missing component to be
returned to the system. When returned, all components should automatically revert to normal
operations.
The system shall be designed such that it will not need to be shut down. Hardware that is
removed from active duty by power -down or cable -disconnect shall be reported by other
components of the system to be non -responsive. When such equipment is powered up or
Specifications for an ATMS Page A-44
reconnected, the system should respond by recognizing the return to normalcy and resume
regular operations without operator interaction.
The Contractor -furnished documentation shall include published procedures for accomplishing,
in a logical fashion, a complete, system -wide power -down (such as for purposes of moving the
system).
2.2.14.3 System Failure and Recovery
The beginning and ending of the following system failures should be signified by paging
appropriate personnel in addition to other reporting requirements detailed below.
Power Failure. Each lifeline and non -essential component of the TCS-II and central
communications apparatus shall be configured with automatic shutdown software
which shall, upon switch -over to UPS, initially allow for up to one minute of
blackout before non -essential components begin an automatic shutdown procedure.
After 10 minutes of blackout, the lifeline communication and TCS-II components
shall initiate their shutdown procedures. When power is restored, the system shall
return to duty.
• Non -fatal Failure. If the TCS-II software detects a non -fatal error within one or
more of its processes, it shall alert the operator via an alarm and log a message to
the system log. The TCS-II shall continue to operate in a degraded state. The
operator shall have final determination on what is considered a non -fatal failure.
• Fatal Failure. If the TCS-II detects a fatal error within one or more of its processes,
it shall alert the operator via an alarm on and log a message to the system log. The
TCS-II shall then attempt an orderly shutdown of the system.
2.2.15 Software Documentation .2.15
2.2.15.1 General
The delivered TCS-II software shall be fully documented. This documentation shall consist of
pertinent technical documentation and operator documentation including the following:
• Proprietary source code escrow option (see Subsection 2.2.15.2);
• Database definitions and file structures;
• Variable descriptions, variable cross-references and subroutine calling sequences;
• Interface specifications;
• Requirements traceability matrix;
• Communication protocols including field device protocol;
• Security documentation;
• System backup and recovery procedures;
Specifications for an ATMS Page A-45
• System operational procedures and error handling;
• Hard copy user manual segregated into chapters (or volumes) which group topics
according to whether the software is used from TOC operator stations, from remote
computers, and from either of the above;
• On-line user manual or help facility;
• Warrantees on software; and
• Licenses and liens.
The Contractor may use different methods for documentation if it provides sufficient information
as determined by the City. All documentation shall be submitted to the City for final approval.
2.2.15.2 Source Code Escrow
Program source libraries, source code, flow charts of source code, database definitions, file
structures, communications protocols, variable descriptions, variable cross-references, subroutine
calling sequences, and other documentation are elements of the work product without which the
City would be at a severe loss should the Contractor be unable or unwilling to provide service for
the life of the software.
For this reason, the Contractor shall provide an independent escrow agent to handle such
proprietary work product documentation which shall be transferred from escrow agent to the City
in the event that the Contractor fails to provide service at a reasonable and justifiable price during
the life span of the TCS-II software.
2.2.16 Testing
2.2.16.1 System Software Acceptance Test
All software furnished shall be subject to monitoring and testing to determine conformance with
all applicable requirements and to ensure an orderly implementation of the system. The
Contractor shall provide a proposed acceptance test procedure to the City for approval at least
sixty (60) days before the acceptance test is to begin. The test procedures shall be structured to
exercise each element of the system and to verify the successful implementation of each required
feature and element of functionality.
Based on the approved procedures, the City shall perform an extensive test of the delivered
software. The Contractor shall correct any .problems, which may be encountered, and resolve
any omissions discovered during the software acceptance tests.
2.2.16.2 180-day Observation Period
A 180-day observation period shall be required. This observation period shall commence upon
successful completion of the system software acceptance test and all hardware components are
operational. The observation period shall be a minimum of 180 days in duration. Any major
Specifications for an AIMS Page A-46
software component deficiency will, at the City's option, (negotiable based upon type of failure)
reset the calendar to day number 1.
2.2.17 Final Acceptance and Warranty
Upon satisfactory completion of the 180-day observation period and successful operation of
other deliverables, the project will be accepted by the City. A warranty period shall then
commence. For five (5) years, the Contractor shall provide full warranty and support (remote and
on -site) for the TCS-II software and any other Contractor -furnished software. For two (2) years,
the Contractor shall provide full warranty and on -site support for Contractor -furnished
components of the central hardware.
2.2.18 Software and System Operational Training
The Contractor shall provide a minimum of forty (40) hours of training for City personnel on the
functional application and operation of the system software supplied. As a minimum this shall
include the following:
• Use of operator interface;
• Use of graphical map generation and animation;
• Database use and manipulation;
• System parameter and database entry;
• Error messages and troubleshooting techniques;
• Database custom report generation;
• Overview of system structure and interfacing;
• Priority scheme setup;
• Configuration setup;
• System maintenance;
• System startup and shutdown; and
• System backup and recovery procedures.
The training session shall consist of both formal classroom presentation and hands-on
workshops. The training shall be provided after full installation of the TCS-II and publication of
an approved user manual, but before the system software acceptance test procedure. Each
training program shall be scheduled at the mutual convenience of the Contractor and the City.
All training shall be conducted during the normal business hours of the city unless specifically
noted otherwise. The City shall reserve the right to videotape any and all training sessions. All
training courses, lectures, and demonstrations shall be presented in person by qualified
instructors. The training shall be conducted in Lubbock at a facility provided by the City. (Most
likely, portions of the training will be conducted in the TOC.) The Contractor shall assume for
budget purposes that the training will be conducted in blocks of not more than six (6) hours per
day and on not more than three (3) consecutive days in any one calendar week.
Specifications for an ATMS Page A-47
At the City's option, 24 hours of the training may be conducted in the Colorado Springs area.
Up to four City employees lodging and meals will be paid by Contractor. Travel expenses will
be the responsibility of the City of Lubbock. All materials and computers for the training session
shall be supplied by the Contractor.
2.3 Desired Features and Functionality
Subsection 2.3 defines features, which though not specifically required by Subsections 2.1.2 or
2.2, are desired by the City subject to their cost-effectiveness.
2.3.1 Preferred Computer Type
The TCS-II server shall be at least a Pentium II - 300 MHz machine, the workstations must be a
minimum of Pentium II - 166 MHz machines.
2.3.2 Automatic Detection of Changes in Field Databases
2.3.2.1 Monitoring of Controller Access
Because field technicians have access to the intersection controllers, there is the opportunity for
the local controller database to be changed without such change being commanded from the
TOC. The local intersection controller shall report four (4) feedback bits (door open, portable
computers connected, front panel accessed, and power out) that communicate to the TOC when
there is such activity at the controller. When the TCS-II detects any of these bits, it shall
automatically respond as follows.
• Power Out - Upon restoration of power, log that a power outage occurred and the
time at which power was restored.
• Door Open - Log that the door is open and when the door returns to a closed
position.
• Door Open and either the portable computer is connected or the front panel is
accessed - The TCS-II software shall log the event. After door closed signal is
received, the TCS-II software shall upload and compare the local controller's
database with the TCS-II's central database, which shall be considered to be the
master database.
2.3.2.2 Periodic Upload of Field Databases
The TCS-II shall perform periodic, automatic upload of all field databases and compare such
field databases with the TCS-II's central database, which shall be considered to be the master
database.
Specifications for an AIMS Page A-48
The upload and comparison of local databases shall be an operator scheduled event
2.3.2.3 Correction of Database Discrepancies
Whenever a discrepancy is discovered between a field database and the TCS-II's central database,
it is desired that the TCS-II software shall initiate one of two actions as defined by the operator:
Automatically download the TCS-II database, overwriting the local controller; or
Alert the operator of discrepancy.
When comparing field and central database parameters, the TCS-II software shall display the two
data sets side by side and highlight the discrepancies between the two data sets. Alternately, the
new TCS-II software shall highlight the discrepancies in the currently displayed database (central
or field) and enable the operator to toggle to the other database. The operator shall have the
option of saving the uploaded field database or downloading the central database to the field.
2.3.3 Automatic Identification of the Need for Timing Plan Updates_(not required, may
be added by change order if required at a later date)
The effectiveness of the new TCS-II will depend to a large degree on the appropriateness of the
timing plans. The software shall provide automatic method for identifying the need for updating
the timing plans. Such method may take into consideration traffic volume changes since the last
update and/or intersection and/or system MOEs as computed by the system.
2.3.4 Automatic Update of Linked Files not required, may be added by change order if
required at a later date)
When a change occurs to an associated graphic database file the operator shall be notified by an
icon, which shall be generated continuously to remind the operator that the database files are out
of date. Upon operator acknowledgment and termination of use of any graphic displays, the
system shall automatically update the files on the target operator station if necessary. If a
computer is not logged on at the time of the change, the computer's database shall be updated, if
necessary, when it connects to the TCS-II.
2.3.5 Generation and Display of Time -Space Diagrams
The new TCS-II software shall enable the operator to generate time -space diagrams based on the
timing stored in the central database and to display such time -space diagrams on -screen. The
operator shall then be able to perform on -screen fine-tuning, using click and drag methods to
adjust the offsets, with the resulting changes in the widths of the progression bands being
displayed. The operator shall then be able to save to the database the resulting changes in offset
for that timing plan.
Specifications for an AIMS Page A-49
To fine-tune crossing arterial progression, the operator shall be able to generate and display the
time -space diagram for each street in a separate window. The on -screen adjustment of the offset
of the common window shall result in changes in the widths of the progression bands in both
windows.
2.3.6 Automatic Generation of Timing Plans
The new TCS-II software shall provide automatic generation, editing, and downloading of timing
plans. This would include the following:
• An analysis package such as the Arterial Analysis Package (AAP) or the Windows -
based Synchro? 3.0 (or later version);
• The means by which system detector data can be interfaced with the analysis
package, thereby automating the process of inputting traffic volume data.
• The means by which the generated timing plans can be edited on -screen in a manner
similar to that described above in Subsection 2.3.5.
• The means by which an edited timing plan can be automatically downloaded to the
TCS-II database.
TCS-II will provide the ability to allow the user to automatically generate Passer -II or ACT's
No -Stop Transit down-loadable timing plans using system detectors and count station
information. This feature can be run as an automatic scheduled event, or as a manually
implemented, operator requested event.
2.3.7 Full Pan -Zoom of Graphical Displaces
The dynamic mapping provided by the Contractor shall incorporate full pantzoom capability. In
such case, the operator shall be able to set up both dynamic and static informational layers that
are displayed at different view scale levels by defining the view scale levels in a zoom level set-
up configuration database table. By setting up the zoom scale range and appropriately
enabled/disabled layers, the operator shall be able to control which layers display at different
zoom scales. For example, at the system -wide level, the operator might enable roadway
centerlines (static information) as well as a communication status indication (dynamic
information) for each intersection controller across the city. When zooming in to a group of
intersections (i.e. changing the view scale), the roadway centerlines would be disabled from view
and the roadway curb lines would be enabled (become visible), and perhaps all phases of all the
intersections in the displayed group shall become visible.
For purposes of zooming in on the map, the operator shall be able to select a smaller area of the
map to expand to the current window size, or expand to fill a new window, which can be resized.
The zoom capabilities shall also allow for returning to the entire graphic image, as well as
redisplaying the previous view's scaled image.
Specifications for an ATMS Page A-50
2.3.8 Graphical Reports
The new ATM software shall include graphical reports. For example, the following graphic
reports should be available:
1. Detector MOE Report. This graphic reports both real-time and archived measure of
efficiency (MOE) data. As a minimum, it shall include the following:
• Present volume versus historical volume;
• Present occupancy versus historical occupancy;
• Present speed versus historical speed; and
• Present delay versus historical delay.
Time frames for display shall be operator -selectable.
2. Intersection MOE Report. This graphic reports both real-time and archived MOE
data. As a minimum, it shall include the following:
• Percent of green time used;
• Percent of detector calls (relative to a threshold value);
• Number of max -outs (or force -offs); and
• Number of pedestrian calls.
2.3.9 Detailed Graphics Displays
The following detailed graphics displays shall be provided.
2.3.9.1 System -wide Display
The system -wide display shall be part of the static base map. At the top level, all intersections
shall be displayable within one window. The operator shall be able to configure the different
displayable layers along with the displayed map scale that these layers become visible. If real-
time information is not available for display at certain top level displays the default condition for
that layer shall be disabled.
The GDS software shall be capable of displaying system detector (or link) icons at the area wide
level. When the zoom level allows for the display of system detectors, the data shall be
displayed instead of the corresponding link data. Note that when traffic conditions are requested
for the area -wide display, decisions shall be based upon link parameters rather than detector
parameters. The operator shall be able to select the time interval to display the detector data.
These data shall be displayable in either raw or smoothed form (operator -selectable).
Specifications for an ATMS Page A-51
The operator shall be able to display all detector measures of efficiency (MOEs) available at the
area -wide map level. These include volume, occupancy, speed, and delay. A legend shall be
displayed showing which MOE is being displayed, the time interval and the thresholds that the
displayed colors are based on.
The operator shall specify which MOE is to be displayed and the time interval and thresholds
that shall be used for projected averages. A minimum of four conditions shall be defined as
unfavorable, intermediate, favorable, or unknown (i.e. detector failed). The condition shall be
determined by comparing the stored data against the default high and low thresholds set by
location and time -of -day.
The operator shall also be able to display detector status. The detector status classifications
which shall be depicted include the following:
• Not failed;
• No activity;
• Erratic output;
• Maximum presence;
• Failed communication; and
• Real-time feedback preempted.
2.3.9.2 Detailed Intersection Display
By double clicking on the intersection icon on the overview map at any zoom level, the operator
shall be able to display an individual detailed intersection in a window of the traffic display.
The window size shall default to one -quarter size of the available display screen size. The
operator shall be able to change this default. The intersection display shall depict the intersection
in an easy to understand display. Multiple intersection display windows shall be available for the
operator, without restriction to communications channels. The number of display windows shall
only be restricted to the number that can be feasibly displayed on the monitor. The operator shall
be able to minimize and maximize a detailed intersection display. This shall enable the operator
to have multiple displays available. The information available for intersection displays shall
include all information available for that intersection.
The MOE information displayed on a detailed intersection window shall be operator -selectable.
Thresholds shall be dynamically operator -changeable. A legend shall be displayed depicting
what MOE is being displayed, the threshold values, and the color definition. If real-time
feedback is not available because of higher priority communications, the graphic shall display an
appropriate color and/or a message notifying the operator.
Specifications for an ATMS Page A-52
2.3.10 Variable Message Sign Control
The new TCS-II shall have the capability to interface with the sign controllers of matrix -type
variable message signs (VMSs). This should allow the uploading and downloading of messages
from the central computer and the control of message displays through the TCS-II.
Skyline Signs of Colorado Springs software operating under Windows NT will be capable of
handling NTCIP and shall be integrated with TCS-II.
2.3.11 Closed -Circuit Television System Control and Monitoring
The TCS-II software shall have an integrated graphical interface to control, monitor, and record
events of the future CCTV system. This interface shall include camera selection, display
selection, configuration setup (presets, tours, etc.), selection and implementation of presets,
camera control (pan, zoom, focus, etc.), monitor switching, and VTR control. It shall be possible
through this graphical interface for the operator to detect camera failures.
2.3.11.1 Video Camera Control
The TCS-II shall be capable of providing RS-232 links for future CCTV controllers.
The camera control function of the TCS-II software shall be accessible by either clicking on a
camera icon located on a graphical map display, or by picking from a list of camera locations. A
camera control dialog box shall appear, enabling the operator to define and select presets, as well
as maneuver the tilt/pan/focus mechanisms from the comfort of the keyboard/mouse or CCTV
controller. The dialog box shall also indicate where the camera output is currently being routed
and allow change/selection of which monitors/VTRs are utilizing the camera's signal.
2.3.11.2 Video Monitor Switching and Control
The TCS-II shall be capable of providing an RS-232 link to a future video matrix switch.
The monitor control function of the TCS-II software shall be accessible by either clicking on a
monitor icon located on a schematic graphic of the TOC, or by picking from a list of CCTV
monitors. A CCTV monitor control dialog box shall appear, enabling the operator to power the
monitor(s) on/off. The dialog box shall also indicate the source of the CCTV monitor input and
allow change/selection of the input being displayed at that CCTV monitor. The software shall
also accommodate automatic sequencing through a number of video cameras/presets.
2.3.11.3 Video Tape Recorder Control..3.11.3
The TCS-II shall be capable of providing future RS-232 links to video tape recorders (VTR) and
shall enable the TCS-II software to remotely control VTRs.
Specifications for an AIMS Page A-53
The VTR control function of the TCS-II software shall be accessible by either clicking on a VTR
icon located on a schematic graphic of the TOC, or by picking from a list of VTRs. A VTR
control dialog box shall appear, enabling the operator to power the VTR on/off and control its
operation. The dialog box shall also indicate the source of the VTR input and allow
change/selection of such input. The software shall also accommodate automatic sequencing
through a number of video cameras/presets as the input to a VTR.
The VTRs shall have three methods of commencing recording via the TCS-II software, as
follows:
• Manually started by the operator ? the operator shall select a camera and route the
video signal to the VTR and manually initiate recording.
• Automatically by TOD ? the system shall select a camera and present and route the
video signal to the VTR and start recording based on the start time set up by the
operator. It shall automatically stop at the end time set up by the operator.
• Automatically by traffic -responsive ? the TCS-II software shall automatically select
a camera and preset and route the video signal to a VTR and start recording based
on selected speed and volume thresholds exceeded by detectors in the field. The
VTR shall record until the condition recedes.
The VTR present status (e.g., idle, recording, playing back) shall be reported to the TCS-II
software.
2.3.12 Other ITS Features
The following Intelligent Transportation Systems (ITS) features shall be provided by the
Contractor.
• Inter -agency Interoperability. Long term - Full interoperability with other
jurisdiction (e.g., TxDOT's) traffic management systems.
Short term - the City's system may need to share information with other
jurisdictions (e.g., TxDOT) through leased lines, dial -ins, and dial -outs.
This capability will be provided by the software. The software data base shall be
capable of being segmented, allowing multiple jurisdictions to monitor and control
their own signals without access to neighboring jurisdictions signals.
Specifications for an AIMS Page A-54
• Motorist Information Systems. Traffic data that is accumulated at the TOC can be
disseminated to the public by means of broadcast media (e.g., radio and television),
kiosks, dial -up service, and/or the Internet..
The TCS-II database format shall be Microsoft SQL Server, which shall allow the
database files and indexes to be accessed by third party utilities. There shall be no
significant limitations on the size of the databases or database record fields.
2.4 Optional Features and Functionality
The state-of-the-art in traffic system management is advancing rapidly and, while Lubbock wants
its new TCS-II to be up-to-date, there is equally great desire not to be the test bed for unproven
technology. Accordingly, this Subsection 2.4 defines certain features which may or may not be
appropriate for inclusion in the Project. The City's decision to include or not include a particular
optional feature or project element will be based on various factors which include (1) the
proposed technical approach, (2) the resulting benefit to the City, and (3) the cost. Those
features included in the contract price are followed with the following notation: (included);
those features that may be added by a future change order at a not to exceed cost are
followed with the notation: (by change order if required) and have the cost listed; those
features omitted from this contract completely are followed with the following notation:
(omitted).
2.4.1 Interface with Existing NEMA Controllers ft change order if required
The majority of Lubbock's existing non -Type 170 controllers are ten -plus years old and will not
be incorporated into the new TCS-II. Approximately sixteen (16) existing NEMA TS1
controllers are of one brand (Naztec) and are communications -compatible. (It should be noted
that these controllers make use of at least four different versions of Naztec firmware.)
ACT shall provide an Interface Unit at a cost of $750.00 per each controller to be connected and
software at a cost of $20,000.00 to replace the existing RIU. The unit will plug into the existing
RIU cable.
2.4.2 Implementation of NTCIP (included)
Because the final version of the NTCIP had not been adopted as of the writing of this
specification, an interim version will be used for the initial implementation of new TCS-II. An
option shall be provided for upgrade of the TCS-II to fully conform with the final version of the
NTCIP relative to actuated traffic signal controllers and in a manner that mill accommodate the
functionality required by these specifications.
TCS-II has its own protocol, which will be provided. In addition, CALTRANS AB3418 will be
provided. Both protocols as well as others can operate simultaneously on the TCS-II platform.
Specifications for an ATMS Page A-55
2.4.3 Automated Incident Detection (by change order if required,
Freeway management systems have traditionally incorporated algorithms to provide automated
detection of suspected traffic incidents. Traffic signal systems have traditionally not
incorporated this capability at least in part because it is more difficult to detect an incident in an
interrupted flow environment.
As part of the automated incident detection option, an automated incident detection algorithm
will be included. It specifically will include the capability to deal with the existing problem of
rear end accidents due to the limited sight distance at interchange overpasses. Additional
software cost of $60,000.00.
2.4.4 Additional Contractor -Provided Training (by change order if required)
The cost of additional days of Contractor -provided training shall be provided on the same terms
as that called for in Subsection 2.2.18 (i.e., in blocks of not more than six hours per day on not
more than three days in the same calendar week.) Cost of $1200.00/day/trainer.
2.4.5 Other Optional Features (by change order if required)
The City has the option to purchase the following
• Software for the integration of digital snapshot cameras into TCS-II can be provided. This
system uses the same communications line as the TCS-II data link. Pricing provided includes
one 470I PROM Module and one DYCAM color camera in a weather proof housing and the
necessary system software license. License is for unlimited use in city limits of Lubbock.
$20,000.00
• Software for tracking of citizen requests and complaints including automatic generation of
response letters. One seat license is free. Network version price to be negotiated
• A portable video system that is battery operated, includes a cell -phone controlled
pan/tilt/zoom, Sony color camera, IOX lens, Pelco housing and a 2.4 GHz microwave one
way video transmitter/receiver. $30,000
2.5 Submittal Data and As -Built Documentation
2.5.1 General
The Contractor shall provide two types of documentation for this project, submittal data and as -
built documentation. Any documentation which exceeds the size of I I" x 17" paper shall be
provided in the form of reproducibles 22" x 36" in size. No documentation shall be smaller than
8?" x 11". Reproducibles shall not be folded or creased.
Specifications for an ATMS Page A-56
All documentation shall be considered as an item of work and shall be completed before final
acceptance.
2.5.2 Project Implementation Schedule
Within two (2) weeks after notice -to -proceed, the Contractor shall develop and submit to the
City, a Project Implementation Schedule. As a minimum, this schedule shall address major
project activities and milestones including Contractor submittals, deliveries of Contractor -
furnished equipment, training, system software acceptance tests, 180-day observation period, and
final acceptance.
2.5.3 Submittal Data
Prior to the purchase or fabrication of any Contractor -furnished equipment, the Contractor shall
submit for review by the City catalog cut sheets and specifications for all standard, off -the -shelf
items and shop drawings for all non -catalog or custom items. All such documentation shall meet
the size requirements described in Subsection 2.6.1. Four (4) copies of 8?" x I V submittals shall
be provided. One (1) of these will be returned to the Contractor with appropriate notations. One
(1) copy of reproducible drawing shall be submitted. The reproducible drawing, with appropriate
notations, will be returned to the Contractor after necessary record prints have been made.
The purpose of the submittal data is to show specifically and in detail how the Contractor intends
to satisfy project requirements. If pre-printed literature is utilized to satisfy some or all of the
requirements; there shall be no statements on the literature which conflict with the final
specifications. Any such statements shall be crossed off and initialed by the Contractor and an
appropriate statement shall be attached clearly indicating how the requirements of the project
will be fulfilled. The Contractor shall clearly label each item of submittal data with the bid item
number or other description of the item(s) to which it applies.
Each formal submittal shall contain sufficient information and details to permit the City to fully
evaluate the situation. Submittals which are, in the judgment of the City, insufficient to permit
proper evaluation will be rejected. The Contractor shall not deviate from formal submittals
marked "Approved" or "Approved as Noted" without the written consent of the City.
The Contractor shall plan for submittal data to be in the hands of the City for fourteen (14)
calendar days. Following review of the submittal data, the City will return to the Contractor one
(1) copy or an agreed upon number of the submittal marked "Approved", "Approved as Noted"
or "Rejected". The City will also mark each item which must be resubmitted. The Contractor
may proceed with any items marked "Approved". The Contractor may also proceed with items
marked "Approved as Noted" if resubmission is not required. The Contractor shall not proceed
with any items which are marked "Rejected" or with items for which resubmission is required
but shall proceed immediately to correct said items and resubmit them for review. No time
extensions will be granted to the Contractor as a result of the need to resubmit various items for
Specifications for an ATMS Page A-57
review. Review by the City of various items shall not relieve the Contractor of his obligation to
furnish and install the work in accordance with project requirements.
The Contractor shall develop a submittal data transmittal form and submit same to the City for
approval as to format. The Contractor shall assign a submittal number to each submittal
package, which shall be transmitted under the cover of the approved form. The numbering
system shall be logical and ascending. The Contractor shall specifically list on the transmittal
sheet each item or element included. (An element is one part of several parts of information
related to the same bid item.) When drawings are submitted, each shall be listed separately. The
Contractor shall completely fill out all portions of the transmittal sheet except those reserved for
use by the City. The transmittal sheet will be used by the City to indicate the action taken on the
submittal package and a copy of the transmittal sheet showing these actions will be returned to
the Contractor. Only clearly related items shall be transmitted under the same transmittal sheet.
2.6 Documentation
2.6.1 General
Manuals shall be bound, and consist of minimum 8?" x 11" with 11" x 17" minimum schematics.
Operating instructions and maintenance manuals shall be provided for all Contractor -furnished
equipment. Four (4) sets of manuals shall be provided for each item of Contractor -furnished
equipment.
Four (4) copies of draft documentation shall be submitted to the City for written approval no
later than the delivery of the corresponding Contractor -furnished equipment. Upon written
approval by the City, final documentation for field hardware shall be submitted by the Contractor
prior to the end of the 180-day Observation Period.
2.6.2 Computer/Peripheral Hardware (Contractor -furnished)
The Contractor shall furnish four (4) copies of manuals detailing routine maintenance
requirements, troubleshooting procedures, interface drawings and parts lists for each piece of
Contractor -furnished equipment. This documentation material shall be submitted to the City for
review and approval a minimum of sixty (60) days prior to the beginning of the 180-day
Observation Period.
2.6.3 Computer/LAN/Peripheral Manufacturer Supplied Software
The Contractor shall submit four (4) copies of standard documentation for the operating system
and all Contractor -furnished computer/LAN/peripheral manufacturer -supplied software. This
documentation shall be submitted to the City a minimum of sixty (60) days prior to the start of
the 180-day Observation Period.
Specifications for an ATMS Page A-58
2.6.4 TCS-II Software
The Contractor shall provide and submit to the City for written approval, full and complete
documentation of the TCS-II Software that has been furnished and installed by the Contractor.
New flow charts and descriptive graphics shall be prepared and furnished as necessary,
indicating connection to and relationship to existing program modification, additions and
changes to the base software and their programs or routines.
The Contractor shall supply four (4) copies of the traffic control applications software
documentation to the City 60 days before the initial applications software test. Until acceptance
of the project, the Contractor shall be responsible for updating the City's software documentation
within two (2) weeks of performing any software changes. If the software documentation does
not reflect the current software operation, the City may stop all work on the project until the
software documentation is updated. Once initially delivered and installed, the Contractor shall
maintain on -site at all times, on disk or CD ROM, one (1) debugged and current backup version
of the software. Failure to maintain this documentation shall be grounds for the City to halt the
project until it is provided.
Prior to acceptance of the project, the Contractor shall provide four (4) final TCS-II software
documentation manuals, two (2) copies of the TCS-II software on CD-ROM, and two (2) copies
of program listings. The Contractor shall also demonstrate to the City that the backup version of
the program on disk or CD ROM is debugged and current. This backup version shall remain
after acceptance of the project.
2.6.5 Color Graphics Subsystem Software
The Contractor shall provide and submit to the City for written approval, full and complete
documentation of the color graphics subsystem software that has been furnished and installed by
the Contractor.
New flow charts and descriptive graphics shall be prepared and furnished as necessary,
indicating connection to and relationship to existing program modification, additions and
changes to the base software and their programs or routines.
The Contractor shall prepare and supply complete and fully debugged assembled listings of all
source coding provided with and used by the Contractor in the development of this system.
The Contractor shall supply two (2) copies of the current color graphics subsystem software
documentation to the City thirty (30) days before the central hardware is delivered on -site. From
the date of initial delivery until acceptance of the project, the Contractor shall be responsible for
updating the City's software documentation within two (2) weeks of performing any software
changes. If the software documentation does not reflect the current software operation, the City
may stop all work on the project until the software documentation is updated. The Contractor
Specifications for an ATMS Page A-59
shall maintain on -site at all times, one (1) debugged and current backup version on disk or CD
ROM. Failure to maintain this documentation shall be grounds for the City to halt the project
until it is provided.
Prior to acceptance of the project, the Contractor shall supply to the City three (3) final color
graphics subsystem software documentation manuals and two (2) copies of program listings.
The Contractor shall also demonstrate to the City that the backup version of the program on disk
or CD ROM is debugged and current. This backup version shall remain after project completion.
2.6.6 TCS-II User's Manual
The Contractor shall submit four (4) copies of the system user's manual for review and approval
by the City 60 days prior to the initial acceptance test.
These manuals shall consist of two (2) volumes:
1. Procedures for equipment setup, program loading, operating procedures, operational
options, program monitoring, recovery procedures, and error message definition and
corrections.
2. Procedures for preparing, updating, and troubleshooting the database and pattern
histories.
The operation of the LANs, file servers, microcomputers, workstations, and peripheral devices
shall be described in detail with respect to display of program information and parameters,
changing of input parameters, and operation of special keys and other equipment.
Sample output formats shall be provided. They shall be reproductions of laser printer, plotter,
and CRT display outputs. The computer information required to provide such a display shall be
illustrated with the appropriate output format.
A complete list of error messages associated with the software operation shall be provided for
both the system operation and the database and pattern history. Each error message that could
appear during system operation shall be defined as to the actual meaning, cause, and corrective
action to be taken. This information shall be in addition to the basic troubleshooting and
malfunction information that shall be provided.
Throughout the project, the system user's manual shall be continually updated on a monthly basis
to reflect the current applications software. Failure by the Contractor to perform this task shall
allow the City to halt work on the project until this task is corrected and demonstrated to the
satisfaction of the City.
Immediately prior to the acceptance of the project, the Contractor shall submit to the City four
(4) final copies of the system user's manuals. These manuals shall be updated to reflect the
Specifications for an ATMS Page A-60
current system operation and the City's comments. The City shall approve in writing these
manuals before final acceptance is complete.
2.6.7 Training Manuals
The Contractor shall prepare a set of training manuals individually ring -bound for use during the
training sessions. The manuals shall be developed for each of the training sessions and shall be
specifically directed at the subject matter required to be covered. Each training manual shall
specifically state the purpose of the manual. The manuals shall be revised following the training
sessions as required to correct any major errors or deficiencies noted in the training effort.
Two (2) copies of each manual shall be submitted to the City for review sixty (60) days prior to
the preliminary scheduled start of the appropriate training session. The appropriate training
session shall not start until two (2) weeks after approval by the City of the training manual and
the training dates. The number of manuals furnished for each training session shall be not less
than the maximum number of participants for that session up to a maximum of ten (10).
SECTION 3
FUNCTIONAL REQUIREMENTS OF THE ATMS CENTRAL HARDWARE
3.1 Hardware and Equipment
3.1.1 Furnishing of the Hardware and Equipment
As described in Section 4, for each element of hardware and equipment described in Subsections
3.1 and 3.2, the Contractor shall:
Recommend the brand, model number, and manufacturer's specifications and
catalog data (except for the console if it is to be custom-built); and
if the item is furnished by the Contractor, the unit ?furnish -only? prices (delivered
on -site in Lubbock).
For each individual item, the City, at its option, may elect to furnish the item taking advantage of
annual purchase contracts. If furnished by the City, a different brand or model number may be
supplied but the item will be an "equivalent" item (i.e., its specifications will meet or exceed the
published specifications of the brand and model number proposed by the Contractor). The major
reason for the City reserving the right to furnish items of hardware is to take advantage of
existing maintenance and support contracts and to minimize the number of brands of functionally
equivalent items that have to be supported and maintained.
Specifications for an ATMS Page A-61
3.1.2 Installation and Integration of the Required Hardware
Regardless of whether furnished by the Contractor or by the City, the Contractor shall install and
connect each item of the required hardware into the new ATMS and shall fully integrate the new
central software and hardware.
3.1.3 Hardware at the TOC
Section 4 describes the hardware that is required within the Traffic Operations Center (TOC) in
order for the new ATMS to provide the specified functionality. This shall include but shall not
necessarily be limited to the following:
Central processor one or more microcomputers (PCs);
File servers (primary and secondary);
10/10013aseT Ethernet Local Area Network (LAN) including an Ethernet switch;
Mass storage device(s);
Control console and other specified furniture;
Large -screen display device;
Brouter (bridge/router);
Intelligent multiplexer (IMUX) or Intelligent Serial Comm- 3M CLU;
V.34 modems;
Twisted -pair modems;
Equipment rack(s) to accommodate twisted -pair modems and future OTRs; and
RAID 5.
All equipment comprising the TOC LAN shall be compliant with IEEE Standard 802.3. All
TOC network equipment shall operate from 115 VAC 10 percent at 60 Hz, +5 to +50 degree
Celsius, and 20 to 80 percent relative humidity.
Specifications for an ATMS Page A-62
3.1.4 Hardware at the Signal Maintenance Shop
Section 4 describes the hardware required within the City's Signal Maintenance Shop in order for
the new ATMS to provide the specified functionality. All equipment required will be furnished
by the City.
3.2 Required Functionality of the Hardware and Equipment
3.2.1 Ethernet Switch
The Ethernet switch at the TOC (to be furnished by the City) shall be a modular platform
supporting each of the peripheral network devices (initial and future) defined in the
specifications. The switch shall provide a minimum of six (6) 100Base-TX ports and at least
twenty-four (24) 100Base-T ports. The file servers (primary and secondary) shall be connected
by means of 100Base-TX ports. Also, a connection to the City's existing LAN shall be made by
means of a 100Base-TX port. All other devices shall be connected by means of 100Base-T ports.
Initially, such devices shall include:
One (1) primary microcomputer workstation
One (1) brouter
Additional microcomputer workstations (City -furnished)
Laser printers and other common peripherals (City -furnished)
3.2.2 File Servers
At the TOC, there shall be two (2) identical file servers, each of which shall be connected to the
TOC LAN. One shall be primary and the other shall be secondary. RAID 5 shall be provided.
These file servers shall feature modular architecture, PC -based, and shall support Intel Pentium
II processors and their compatible operating systems. Each file server shall be connected to the
Ethernet switch by means of a 100Base-TX Ethernet channel Each file server shall include one
SVGA monitor port, two 3 1/2-inch 1.44 Megabyte floppy disk drives, and one (1) CD ROM
drive. Each file server shall have hard disk capacity to accommodate all of the following:
A minimum of fourteen (14) days of traffic monitoring data with the system
expanded to 250 intersections and 250 system detectors;
A specified central software including ATMS applications software, database
management software, and network management software; plus
A minimum of 2 Gigabytes of additional hard disk capacity.
Specifications for an AIMS Page A-63
Each file server shall be equipped with the same type monitor, keyboard, and mouse to be
supplied in conjunction with the primary microcomputer workstation as called for below.
Either integral to the primary file server or as a separate, connected device, the central hardware
shall automatically update the system's central clock to universal time. This may be
accomplished by means of the WWV radio broadcast.
3.2.3 Remote Dial -in
At the TOC, there shall be a minimum of three (3) ports which provide International
Telecommunications Union (ITU) Standard V.34 interface with auto -dial modems to provide
remote interface capability with the TOC LAN. Each such interface shall enable each of the
following:
Auto -dialing of telephone numbers assigned to pagers; and
Remote connection of the computers to the TOC LAN.
There shall be a minimum of two (2) ITU Standard V.34 modems, which shall be connected by
the Contractor to outside telephone lines. (These phone lines will be arranged for by the City and
their modular jacks will be installed by others.)
3.2.4 Primary Microcomputer Workstation
There shall be one (1) primary workstation, which shall be located on the new control console
specified below. This PC workstation shall be upgradable and shall meet the following
requirements:
Minimum clock running speed shall be 300 megahertz;
A minimum of 128 Megabytes of SDRAM shall be provided;
All software and hardware required for interface with the TOC LAN shall be
provided;
Pentium II processor;
Internal hard disk that can store at least eight (8) Gigabytes. This disk shall not be
compressed;
Sound card with speakers;
At least two (2) PCI expansion slots and at least six (6) ISA slots;
Ethernet 10/100 Base-T network interface card;
Internal 13X min./32X max. CD ROM drive, set-up as Drive D:;
Two internal diskette drives that will accept 1.44 Megabyte diskettes, one set-up as
Drive A: and the other set up as Drive B:; one of which shall be a SuperDisk LS-
120
A 101-style ASCII keyboard with separate numeric and cursor control keypads;
Specifications for an AIMS Page A-64
Latest version of the operating system required by the new ATMS applications
software;
Microsoft Windows 95 or NT 4.0 or later version (compatible with City's existing
system);
Two (2) RS-232C serial ports plus a mouse port;
One (1) parallel port;
One (1) external auto-dial/auto-answer modem, Hayes or approved equivalent. The
modem shall have at least the standard baud rates: 1,200, 2,400, 9,600, 19200 and
38400
Color display non -interlaced super VGA monitor; minimum screen size 21-inch
diagonal (19.7" viewable). The monitor shall be capable of displaying 1024 x 768
pixels in non -interlaced mode;
Super VGA video card in the microcomputer with 8 Mega -byte of SGRAM. The
video card shall be capable of displaying 1024 x 768 pixels in 256 colors;
Microsoft -compatible mouse with mouse drivers installed; and
Power strip, which shall be equipped with a circuit -breaker, surge suppressor, on -
off switch, indicator lamp, and a minimum of six grounded 120 VAC outlets.
3.2.5 Large -Screen Display System
To provide a display suitable for viewing by groups of visitors, there shall be a large -screen color
display system. This shall consist of a large -screen SVGA monitor. Section 4 includes the
recommended equipment and associated costs.
This monitor shall provide for the color display of ATMS system graphics suitable for viewing
by groups of visitors. In the case of the large -screen SVGA monitor, the screen shall have a
minimum diameter of 37 inches and shall be clearly readable in a fully -lighted room from any
viewing angle within 60 degrees of an axis perpendicular to the screen. Section 4 describes the
viewing characteristics.
3.2.6 Mass Storage Device
The equipment in the TOC shall include one (1) recordable CD system. In recording mode, the
CD system shall function as a double -speed recorder, recording data, audio, and video on a
standard, recordable 650 MB CD. In player mode, the CD system shall function as a double -
speed, multimedia compliant CD-ROM player, providing random access to all data on the CD.
Minimum data rate shall be 300 KB per second. Maximum seek time shall be 300 milliseconds.
Minimum buffer capacity shall be 1 MB. The recordable CD system shall operate at 115 ? 10%
VAC, 60 Hertz.
The Contractor shall interface the CD system with the TOC LAN. The CD system shall be
furnished with all cables necessary for connection to the network and to a multiple outlet power
strip.
Specifications for an ATMS Page A-65
3.2.7 Brouter (to be furnished by City)
At the TOC and at the SONET field hub, there shall be an Ethernet-to-DS-1 brouter (bridge -
router) which shall provide intelligent communications interconnection using Institute of
Electrical and Electronic Engineers (IEEE) 802.31 Ethernet standards facilitated by American
National Standards Institute (ANSI), North American Digital Hierarchy, DSX, Type DS-1
communications links. The functions of the brouter shall be to:
Provide physical and link layer protocol compatibility for bridging;
Provide protocol and signal compatibility at the network layer for routing;
Support virtual extension and integration of the TOC Ethernet local area network
(LAN) by means of the City's SONET metropolitan area network (MAN);
Combine brouted Ethernet messages into a common Ethernet at the physical, link,
and network level, and;
Simplify field addressing and communications.
The brouter will thereby provide an Ethernet LAN virtually extended through brouting via
multiple DS-1 s from the TOC to the field.
The Brouter shall include the "intelligence" to perform at least the following:
Bridge DS-1 interfaces (8 minimum) to a common Ethernet LAN;
Route data from its Ethernet bus to the appropriate DS-1 ports using TCP/IP
(IOBase-T) protocol;
Optimize bandwidths by using algorithms such as data compression and express
queuing, where a compatible capability exists on any attached equipment;
Simultaneous bridging and routing with latency not to exceed 1 msec from the time
of message receipt within the brouter;
Buffer data as required to accommodate input/output data rates without loss of data
and without causing transfer delays;
Transparently manage lower level protocols;
Accommodate full -duplex data transmissions on all attached DS-1 interfaces, and;
Conduit built-in test and report failures via alarms and indicators using SNMP
RMON reported via the network management interface integrated by the
Contractor.
All software required to operate, update network configuration/routing, and maintain the brouter
shall be provided with the brouter. Where the brouter requires loadable software for either
operations or maintenance, the software shall be provided on a magnetic media. Software shall
be provided on both a master and a working copy, along with a software users manual and any
required usage licenses. No equipment shall be installed nor operated without a software license,
if required.
Specifications for an ATMS Page A-66
3.2.8 Multiplexer furnished by the City)
Ultimately at each field hub, there shall be a modular -constructed, open architecture Intelligent
Multiplexer (IN=), the primary function of which is to provide an intelligent, time division
multiplexing device for accommodating attached, multi -dropped, RS-232, low speed devices.
The IMUX shall provide modular -expandable RS-232 channels in groups of at least six (6) per
module. Each RS-232 channel shall conform to Electronic Industries Association (EIA) RS-232
standards and shall have the capability of being field configurational to an EIA RS-485 or EIA
RS-422 interface. Each RS-232 channel shall be physically capable of supporting asynchronous
communications data rates of 1200, 2400, 4800, 9600, 19200 and 38400 baud while operating in
a full duplex or half duplex mode.
The IMUX, together with the connected brouter, shall physically groom the serially received data
from the communication devices attached to the IMUX's RS-232 interfaces into Ethernet format
and brouter those Ethernet messages to an addressed network controller device via the brouter's
DS-1 interface. Reversely, the brouter and the IN= shall receive individual Ethernet messages
from other network controller devices via the brouter's DS-1 link, brouting the DS-1 message
into Ethernet format, decomposing and routing of the Ethernet messages to the appropriate RS-
232 channel and conveying the message to the addressed, low -speed device. The IMUX, in
combination with the brouter, shall have the hardware and firmware to provide the following
basic functional capability:
a) Communications via a DS-1 link where applications software interfaces only over
an Ethernet communications interface (i.e., Ethernet-to-DS-1 brouting).
b) Real-time clock and programmable timers which are controlled by the operating
system.
c) Built -In -Test (BIT), both automatic and command -initiated, which are manageable
and reportable by the operating system.
d) Responsive interrupt integration of BIT functions preventing the propagation of
?corrupted? information through the system which might be caused by a failure of
the IMUX, brouter, or any of their printed circuit boards (PCBs) and associated
electronic components.
e) Serial, RS-232, input/output (I/O) ports supporting bi-directional, full duplex
communications with real-time linkage to the operating system, including the
appropriate buffering to accommodate a minimum of 1 second of communications
information at the maximum data rate of each of the RS-232 channels.
f) All basic, non -applications specific I/O driver and interrupt handling functions.
Specifications for an AIMS Page A-67
The IMUX, together with the brouter, shall be capable of polling and transferring information
with the addition of the protocol software/firmware. With the exception of applications oriented
functions, the IMUX, together with the brouter, shall include all basic hardware and firmware to
support communications, timing, and testing. The unit embedded system shall be capable of
supporting real-time, multi -tasking functions.
Each RS-232 channel shall be capable of independent operation and shall facilitate operation as
either a point-to-point or a multi -dropped low speed data link. The IMUX shall physically
accommodate any mix (i.e., master or slave) of polled and point-to-point low speed links, to the
extent that RS-232 input/output (UO) modules are incorporated. The IMUYs RS-232 modules
shall provide:
a) At least six (6), independent, full duplex capable, RS-232 ports with optical or wire
line modem interface compatibility.
b) Interface adaptability from EIA-RS-232 to EIA-RS-422 and EIA-RS-485. Interface
adaptability shall be via jumper wire or dip switch. An external adapter may be
utilized for RS-485. However, on -board adaptability to RS-485 is preferred.
c) Independent UART (Universal Asynchronous Receiver Transmitter) with
programmable baud rate generator (i.e., from 1,200 to 38,400 bps) for each channel.
d) Two Direct Memory Access (DMA) channels for each port; one for receive and one
for transmit.
e) At least 512 Kbytes of buffer memory per channel for each RS-232 port,
independently managed for both transmit and receive data.
3.2.8.1 3M I -Card
The contractor will supply 3M I -Cards to provide communications management and interface
with the intersections. The TCS-II system design differs from that shown in Figure 1.2.3.4 and
is shown on Figure 1.2.3.4A. In the Contractor's alternate system design, the workstations and
file servers are on the Ethernet with the communications routed through the 3M I -Cards. The I -
Card will perform the necessary communication tasks in place of the IMUX.
When the system is expanded on the Sonet Network, the Contractor will provide a
communications engineer for support on TCS-II to Sonet interface issues.
3.2.9 Power Strips
With each microcomputer, file server, and other device which must be plugged into electric
power, there shall be a multi -outlet power strip which includes an integral circuit breaker sized to
protect the connected equipment.
Specifications for an ATMS Page A-68
3.2.10 Central Control Console
In the TOC, there shall be a control console which shall be generally of the same size as the
existing control console. This console shall either be custom-built or shall be modular computer
room furniture. Either catalog cuts or shop drawing shall be submitted to the City.
The following apparatus shall be located on the desktop surface of the console: The primary PC
workstation's monitor, keyboard, and mouse. The file servers and the mass storage devices may
be located under the desktop.
The console shall also provide shelves under the counter for storage of software manuals and
diskettes. The central control console shall be supplied with three (3) high -back chairs with the
following features:
Castors (minimum of five)
Fully upholstered seat and back
Armrests
High -back
Pneumatic cylinder with lever for height adjustment while user is seated
Independent adjustment for tilt of chair back
3.3 City -Furnished Hardware and Equipment
3.3.1 SONET Communications Network
The City will install the SONET communications network depicted in Figures 1.2.3-1 through
1.2.3-3. At the TOC, at the Signal Maintenance Shop, and at the field hub, the brouter will be
connected by the City to the City -furnished SONET apparatus. Once the SONET network is in
place and operational, the Contractor shall provide technical support relative to the integration of
associated signal controllers into the new ATMS.
3.3.2 Fiber Optic Transceivers
The City will provide the fiber optic transceivers (OTRs) required to connect the traffic
controllers depicted in Figure 1.2.3.2-1.
Specifications for an ATMS Page A-69
3.3.3 Spread Spectrum Radio Apparatus
The City may procure and install a spread spectrum radio system to connect the intersections
depicted in Figure 1.2.3.3-1. Once such a system is in place and operational, the Contractor
shall provide technical support relative to the integration of associated signal controllers into the
new AIMS.
3.3.4 Controllers and Cabinets
For intersections which do not currently have them, the City will furnish and install the Type 170
controllers and cabinets. The City shall also provide and install the associated internal modems.
This shall include the intersections to be connected by means of the existing twisted -pair cable
network (as depicted in Figure 1.2.3.1-1).
3.3.5 Other Equipment
The City will furnish additional PC workstations, laser printers, and other common peripheral
devices and connect such devices to the Ethernet switch. The Contractor shall provide technical
support relative to the integration of these devices into the new ATMS.
The City will also furnish one or more laptop computers with internal modem. The Contractor
will assist with the loading of the Contractor -furnished ATMS software onto these computers.
SECTION 4
FUNCTIONAL REQUIREMENTS OF THE TCS-II AND OPTIONAL FEATURES
4.1 Contractor Provided Hardware
The Contractor agrees that the following Hardware meets the requirements of the Specifications
contained in this contract.
4.1.1 Price
The Contractor shall invoice at cost plus 20%. The Contractor will not exceed this price;
however, if a better price is found the Contractor will credit the City with the difference.
Specifications for an AIMS Page A-70
4.1.2 Hardware
Equipment
Manufacturer
Model Number
File Server & Central
Processor
Gateway
Compaq
(preferred)
NS 8000-2300
Primary Microcomputer
Workstation
Gateway
Compaq
(preferred)
E-3110 300
Data Archive Drive
10/1000Base T Ethernet LAN
Pinnacle Micro
RCD 4X4
Switch (by City)
3Com
SuperStack
Hub
3Com
Brouter (by City)
3Com
Intelligent Serial Comm
3M
I -Card
Board
Remote Dial in Modems
US Robotics
Sportster 56K
Large Screen Monitor
Misubishi
38" (sync)
Central Control Console
Evans
Series 200
Console Chairs
City choice
$600.00 ea. credit for purchase
Twisted Pair Modems
GDI
Model 400
Equipment Rack
Budd
502-70B 19" EISA
UPS
APC
Smart UPS 2200XL w/ battery pack
4.1.3 Accommodating the TCS-II Console
The City may choose either the alternative
accommodating the TCS-II console with a cab
video equipment as depicted in Figure 4.1.3-1.
the cost of the cabinet.
of keeping the existing control system or
[net that houses the 38 inch monitor and other
The Contractor's price for the console includes
Specifications for an ATMS Page A-71
LubbockTOC
TCS-II with edsfing equipment
F,3,rc 4.1,3-1
Page A-72