15058-CONTRACT - RHYTHM ENGINEERING LLC.DOCX

SERIAL 15058-RFP BELL RD ADAPTIVE SIGNAL CONTROL TECHNOLOGY (ASCT)
DEPLOYMENT
(Contract – Rhythm Engineering LLC.)
DATE OF LAST REVISION: September 07, 2016 CONTRACT END DATE: August 31, 2021
CONTRACT PERIOD THROUGH AUGUST 31, 2021
TO: All Departments
FROM: Office of Procurement Services
SUBJECT: Contract for BELL RD ADAPTIVE SIGNAL CONTROL TECHNOLOGY (ASCT)
DEPLOYMENT
Attached to this letter is published an effective purchasing contract for products and/or services to be supplied to
Maricopa County activities as awarded by Maricopa County on September 07, 2016.
All purchases of products and/or services listed on the attached pages of this letter are to be obtained from the
vendor holding the contract. Individuals are responsible to the vendor for purchases made outside of contracts. The
contract period is indicated above.
NP/at
Attach
Copy to: Office of Procurement Services
Sami Birchard, MCDOT
April Wire, MCDOT

CONTRACT PURSUANT TO RFP
SERIAL 15058-RFP
This Contract is entered into this 7th day of September, 2016 by and between Maricopa County (“County”), a
political subdivision of the State of Arizona, and Rhythm Engineering LLC, a Kansas corporation, (“Contractor”)
for the purchase of adaptive signal control technology services.
1.0 CONTRACT TERM:
1.1 This Contract is for a term of five (5) years, beginning on the 7th day of September, 2016 and
ending the 31st day of August, 2021.
1.2 The County may, at its option and with the agreement of the Contractor, renew the term of this
Contract for additional terms up to a maximum of five (5) years, (or at the County’s sole
discretion, extend the contract on a month-to-month bases for a maximum of six (6) months after
expiration). The County shall notify the Contractor in writing of its intent to extend the Contract
term at least sixty (60) calendar days prior to the expiration of the original contract term, or any
additional term thereafter.
2.0 FEE ADJUSTMENTS:
2.1 Any request for a fee adjustment must be submitted sixty (60) days prior to the current Contract
expiration. Requests for adjustment in cost of labor and/or materials must be supported by
appropriate documentation. If County agrees to the adjusted fee, County shall issue written
approval of the change. The reasonableness of the request shall be determined by comparing the
request with the lesser of 3% or Consumer Price Index – All Urban Consumers, Series ID
CUUR0400AA0, Not Seasonally Adjusted, West Urban Area, All items old base (12/77).
3.0 PAYMENTS:
3.1 As consideration for performance of the duties described herein, County shall pay Contractor the
sum(s) stated in Exhibit “A.”
3.2 Payment shall be made upon the County’s receipt of a properly completed invoice.
3.3 INVOICES:
3.3.1 The Contractor/Consultant shall be paid a fee as awarded by the County for complete and
satisfactory performance of work and/or materials delivered in accordance with the
detailed scope of work and any technical specifications. The County does not guarantee
any minimum or maximum fee during the period of this contract.
3.3.2 The County shall pay the Consultant/Contractor in full for each monthly payment
request, upon approval by the County and subject to the limitations set forth in the Scope
of Work under this contract. A Project Specific Consultant Payment Request form is
enclosed in Exhibit E. and must include back-up documentation with each invoiced
progress payment request. The backup documentation shall clearly indicate the hours
worked, date and employee’s name, including subconsultants. All backup documentation
shall include copies of any subconsultant or vendor invoices. The Small Business

SERIAL 15058-RFP
Enterprise Participation Reporting form, as shown in Exhibit E, is to be submitted with
each invoice/progress payment request. Any payment request submitted to the County
without this form may be rejected as an incomplete payment request, pursuant to the
terms of the contract.
Upon completion of all deliverables under the scope(s) of work and related technical
requirements in this contract, and final acceptance by Maricopa County Department of
Transportation, the Contractor/Consultant shall submit a Certificate of Performance and
Payment of ALL Claims form, as shown in Exhibit E.
3.3.3 Problems regarding billing or invoicing shall be directed to the using agency as listed on
the Purchase Order.
3.3.4 Payment shall be made to the Contractor by Accounts Payable through the Maricopa
County Vendor Express Payment Program. This is an Electronic Funds Transfer (EFT)
process. After Contract Award the Contractor shall complete the Vendor Registration
Form located on the County Department of Finance Vendor Registration Web Site
(http://www.maricopa.gov/Finance/Vendors.aspx).
3.3.5 Discounts offered in the contract shall be calculated based on the date a properly
completed invoice is received by the County (ROI).
3.3.6 EFT payments to the routing and account numbers designated by the Contractor shall
include the details on the specific invoices that the payment covers. The Contractor is
required to discuss remittance delivery capabilities with their designated financial
institution for access to those details.
3.4 PAYMENT RETENTION:
See Exhibit A System Verification & Acceptance, Milestone Payments
3.5 APPLICABLE TAXES:
3.5.1 Payment of Taxes: The Contractor shall pay all applicable taxes. With respect to any
installation labor on items that are not attached to real property performed by Contractor
under the terms of this Contract, the installation labor cost and the gross receipts for
materials provided shall be listed separately on the Contractor’s invoices.
3.5.2 State and Local Transaction Privilege Taxes: Maricopa County is subject to all
applicable state and local transaction privilege taxes. To the extent any state and local
transaction privilege taxes apply to sales made under the terms of this contract it is the
responsibility of the seller to collect and remit all applicable taxes to the proper taxing
jurisdiction of authority.
3.5.3 Tax Indemnification: Contractor and all subcontractors shall pay all Federal, state, and
local taxes applicable to its operation and any persons employed by the Contractor.
Contractor shall, and require all subcontractors to hold Maricopa County harmless from
any responsibility for taxes, damages and interest, if applicable, contributions required
under Federal, and/or state and local laws and regulations and any other costs including
transaction privilege taxes, unemployment compensation insurance, Social Security and
Worker’s Compensation.
3.6 TAX: (SERVICES)
No tax shall be levied against labor. It is the responsibility of the Contractor to determine any and
all taxes and include the same in proposal price.

SERIAL 15058-RFP
4.0 AVAILABILITY OF FUNDS:
4.1 The provisions of this Contract relating to payment for services shall become effective when funds
assigned for the purpose of compensating the Contractor as herein provided are actually available
to County for disbursement. The County shall be the sole judge and authority in determining the
availability of funds under this Contract. County shall keep the Contractor fully informed as to the
availability of funds.
4.2 If any action is taken by any state agency, Federal department or any other agency or
instrumentality to suspend, decrease, or terminate its fiscal obligations under, or in connection
with, this Contract, County may amend, suspend, decrease, or terminate its obligations under, or in
connection with, this Contract. In the event of termination, County shall be liable for payment
only for services rendered prior to the effective date of the termination, provided that such services
are performed in accordance with the provisions of this Contract. County shall give written notice
of the effective date of any suspension, amendment, or termination under this Section, at least ten
(10) days in advance.
5.0 DUTIES:
5.1 The Contractor shall perform all duties stated in Exhibit “B”, or as otherwise directed in writing
by the Procurement Officer.
5.2 During the Contract term, County may provide Contractor’s personnel with adequate workspace
for consultants and such other related facilities as may be required by Contractor to carry out its
contractual obligations.
6.0 TERMS and CONDITIONS:
6.1 INDEMNIFICATION:
To the fullest extent permitted by law, and to the extent that claims, damages, losses or expenses
are not covered and paid by insurance purchased by the Contractor, the Contractor shall defend
indemnify and hold harmless the County (as Owner), its agents, representatives, agents, officers,
directors, officials, and employees from and against all claims, damages, losses, and expenses
(including, but not limited to attorneys' fees, court costs, expert witness fees, and the costs and
attorneys' fees for appellate proceedings) arising out of, or alleged to have resulted from the
negligent acts, errors, omissions, or mistakes relating to the performance of this Contract.
Contractor's duty to defend, indemnify, and hold harmless the County, its agents, representatives,
agents, officers, directors, officials, and employees shall arise in connection with any claim,
damage, loss, or expense that is attributable to bodily injury, sickness, disease, death or injury to,
impairment of, or destruction of tangible property, including loss of use resulting there from,
caused by negligent acts, errors, omissions, or mistakes in the performance of this Contract, but
only to the extent caused by the negligent acts or omissions of the Contractor, a subcontractor, any
one directly or indirectly employed by them, or anyone for whose acts they may be liable, except
where such claim, damage, loss, or expense is caused in full or in part by the County or its agents
who are not the Contractor or its subcontractors .
The amount and type of insurance coverage requirements set forth herein shall in no way be
construed as limiting the scope of the indemnity in this paragraph.
The scope of this indemnification does not extend to the sole negligence of County.
6.2 INSURANCE.
6.2.1 Contractor, at Contractor’s own expense, shall purchase and maintain the herein
stipulated minimum insurance from a company or companies duly licensed by the State
of Arizona and possessing a current A.M. Best, Inc. rating of B++. In lieu of State of
Arizona licensing, the stipulated insurance may be purchased from a company or

SERIAL 15058-RFP
companies, which are authorized to do business in the State of Arizona, provided that
said insurance companies meet the approval of County. The form of any insurance
policies and forms must be acceptable to County.
6.2.2 All insurance required herein shall be maintained in full force and effect until all work or
service required to be performed under the terms of the Contract is satisfactorily
completed and formally accepted. Failure to do so may, at the sole discretion of County,
constitute a material breach of this Contract.
6.2.3 Contractor’s insurance shall be primary insurance as respects County, and any insurance
or self-insurance maintained by County shall not contribute to it.
6.2.4 Any failure to comply with the claim reporting provisions of the insurance policies or any
breach of an insurance policy warranty shall not affect the County’s right to coverage
afforded under the insurance policies.
6.2.5 The insurance policies may provide coverage that contains deductibles or self-insured
retentions. Such deductible and/or self-insured retentions shall not be applicable with
respect to the coverage provided to County under such policies. Contractor shall be solely
responsible for the deductible and/or self-insured retention and County, at its option, may
require Contractor to secure payment of such deductibles or self-insured retentions by a
surety bond or an irrevocable and unconditional letter of credit.
6.2.6 The insurance policies required by this Contract, except Workers’ Compensation and
Errors and Omissions, shall name County, its agents, representatives, officers, directors,
officials and employees as Additional Insureds.
6.2.7 The policies required hereunder, except Workers’ Compensation and Errors and
Omissions, shall contain a waiver of transfer of rights of recovery (subrogation) against
County, its agents, representatives, officers, directors, officials and employees for any
claims arising out of Contractor’s work or service.
6.2.8 Commercial General Liability.
Commercial General Liability insurance and, if necessary, Commercial Umbrella
insurance with a limit of not less than $2,000,000 for each occurrence, $4,000,000
Products/Completed Operations Aggregate, and $4,000,000 General Aggregate Limit.
The policy shall include coverage for premises liability, bodily injury, broad form
property damage, personal injury, products and completed operations and blanket
contractual coverage, and shall not contain any provisions which would serve to limit
third party action over claims. There shall be no endorsement or modifications of the
CGL limiting the scope of coverage for liability arising from explosion, collapse, or
underground property damage.
6.2.9 Automobile Liability.
Commercial/Business Automobile Liability insurance and, if necessary, Commercial
Umbrella insurance with a combined single limit for bodily injury and property damage
of not less than $1,000,000 each occurrence with respect to any of the Contractor’s
owned, hired, and non-owned vehicles assigned to or used in performance of the
Contractor’s work or services or use or maintenance of the Premises under this Contract.
6.2.10 Workers’ Compensation.
Workers’ Compensation insurance to cover obligations imposed by federal and state
statutes having jurisdiction of Contractor’s employees engaged in the performance of the
work or services under this Contract; and Employer’s Liability insurance of not less than
$1,000,000 for each accident, $1,000,000 disease for each employee, and $1,000,000
disease policy limit.

SERIAL 15058-RFP
Contractor, its contractors and its subcontractors waive all rights against Contract and its
agents, officers, directors and employees for recovery of damages to the extent these
damages are covered by the Workers’ Compensation and Employer’s Liability or
commercial umbrella liability insurance obtained by Contractor, its contractors and its
subcontractors pursuant to this Contract.
6.2.11 Errors and Omissions (Professional Liability) Insurance.
Errors and Omissions (Professional Liability) insurance and, if necessary, Commercial
Umbrella insurance, which shall insure and provide coverage for errors or omissions or
professional liability of the CONTRACTOR, with limits of no less than $2,000,000 for
each claim.
6.2.12 Professional Liability.
Contractor shall maintain Professional Liability insurance which shall provide coverage
for any and all acts arising out of the work or services performed by the Contractor under
the terms of this Contract, with a limit of not less than $1,000,000 for each claim, and
$3,000,000 aggregate claims.
6.2.13 Cyber –
Policy Limit:
6.2.13.1 The policy shall be issued with minimum limits of $100,000.
6.2.13.2 The policy shall include coverage for all directors, officers, agents and
employees of the Contractor.
6.2.13.3 The policy shall include coverage for third party fidelity.
6.2.13.4 The policy shall include coverage for theft.
6.2.13.5 The policy shall contain no requirement for arrest and conviction.
6.2.13.6 The policy shall cover loss outside the premises of the Named Insured.
6.2.13.7 The policy shall endorse (Blanket Endorsements are not acceptable) the
Department as Loss Payee as our interest may appear.
6.2.14 Certificates of Insurance.
6.2.14.1 Prior to Contract AWARD, Contractor shall furnish the County with valid and
complete certificates of insurance, or formal endorsements as required by the
Contract in the form provided by the County, issued by Contractor’s insurer(s),
as evidence that policies providing the required coverage, conditions and limits
required by this Contract are in full force and effect. Such certificates shall
identify this contract number and title.
6.2.14.2 In the event any insurance policy (ies) required by this contract is (are) written
on a “claims made” basis, coverage shall extend for two years past completion
and acceptance of Contractor’s work or services and as evidenced by annual
Certificates of Insurance.
6.2.14.3 If a policy does expire during the life of the Contract, a renewal certificate must
be sent to County fifteen (15) days prior to the expiration date.
6.2.15 Cancellation and Expiration Notice.
Contractor will endeavor to provide thirty (30) days prior written notice to the County in
the event that any required insurance shall expire, be canceled, or materially changed.

SERIAL 15058-RFP
6.3 WARRANTY OF SERVICES:
6.3.1 The Contractor warrants that all services provided hereunder shall conform to the
requirements of the Contract, including all descriptions, specifications and attachments
made a part of this Contract. County’s acceptance of services or goods provided by the
Contractor shall not relieve the Contractor from its obligations under this warranty.
6.3.2 In addition to its other remedies, County may, at the Contractor's expense, require prompt
correction of any services failing to meet the Contractor's warranty herein. Services
corrected by the Contractor shall be subject to all the provisions of this Contract in the
manner and to the same extent as services originally furnished hereunder.
6.4 INSPECTION OF SERVICES:
6.4.1 The Contractor shall provide and maintain an inspection system acceptable to County
covering the services under this Contract. Complete records of all inspection work
performed by the Contractor shall be maintained and made available to County during
contract performance and for as long afterwards as the Contract requires.
6.4.2 County has the right to inspect and test all services called for by the Contract, to the
extent practicable at all times and places during the term of the Contract. County shall
perform inspections and tests in a manner that shall not unduly delay the work.
6.4.3 If any of the services do not conform to Contract requirements, County may require the
Contractor to perform the services again in conformity with Contract requirements, at no
cost to the County. When the defects in services cannot be corrected by re-performance,
County may:
6.4.3.1 Require the Contractor to take necessary action to ensure that future
performance conforms to Contract requirements; and
6.4.3.2 Reduce the Contract price to reflect the reduced value of the services performed.
6.4.4 If the Contractor fails to promptly perform the services again or to take the necessary
action to ensure future performance in conformity with Contract requirements, County
may:
6.4.4.1 By Contract or otherwise, perform the services and charge to the Contractor,
through direct billing or through payment reduction, any cost incurred by
County that is directly related to the performance of such service; or
6.4.4.2 Terminate the Contract for default.
6.5 REQUIREMENTS CONTRACT:
6.5.1 Contractors signify their understanding and agreement by signing a bid submittal, that the
Contract resulting from the bid is a requirements contract. However, the Contract does
not guarantee any minimum or maximum number of purchases shall be made. It only
indicates that if purchases are made for the materials or services contained in the
Contract, they shall be purchased from the Contractor awarded that item if the Contractor
can meet all the delivery requirements of the County. Orders shall only be placed when
the County identifies a need and proper authorization and documentation have been
approved.
6.5.2 County reserves the right to cancel Purchase Orders within a reasonable period of time
after issuance. Should a Purchase Order be canceled, the County agrees to reimburse the
Contractor for actual and documentable costs incurred by the Contractor in response to
the Purchase Order. The County shall not reimburse the Contractor for any costs incurred
after receipt of County notice of cancellation, or for lost profits, shipment of product prior
to issuance of Purchase Order, etc.

SERIAL 15058-RFP
6.5.3 Contractors agree to accept verbal notification of cancellation of Purchase Orders from
the County Procurement Officer with written notification to follow. By submitting a bid
in response to this Invitation for Bids, the Contractor specifically acknowledges to be
bound by this cancellation policy.
6.6 SUSPENSION OF WORK
The Procurement Officer may order the Contractor, in writing, to suspend, delay, or interrupt all or
any part of the work of this contract for the period of time that the Procurement Officer determines
appropriate for the convenience of the County. No adjustment shall be made under this clause for
any suspension, delay, or interruption to the extent that performance would have been so
suspended, delayed, or interrupted by any other cause, including the fault or negligence of the
Contractor. No request for adjustment under this clause shall be granted unless the claim, in an
amount stated, is asserted in writing as soon as practicable after the termination of the suspension,
delay, or interruption, but not later than the date of final payment under the contract.
6.7 STOP WORK ORDER
The Procurement Officer may, at any time, by written order to the Contractor, require the
Contractor to stop all, or any part, of the work called for by this contract for a period of 90 days
after the order is delivered to the Contractor, and for any further period to which the parties may
agree. The order shall be specifically identified as a stop work order issued under this clause.
Upon receipt of the order, the Contractor shall immediately comply with its terms and take all
reasonable steps to minimize the incurrence of costs allocable to the work covered by the order
during the period of work stoppage. Within a period of 90 days after a stop-work is delivered to
the Contractor, or within any extension of that period to which the parties shall have agreed, the
Procurement Officer shall either—
6.7.1 Cancel the stop-work order; or
6.7.2 Terminate the work covered by the order as provided in the Default, or the Termination
for Convenience of the County, clause of this contract.
6.7.3 The Procurement Officer may make an equitable adjustment in the delivery schedule
and/or contract price, or otherwise, and the contract shall be modified, in writing,
accordingly, if the Contractor demonstrates that the stop work order resulted in an
increase in costs to the Contractor.
6.8 UNCONDITIONAL TERMINATION FOR CONVENIENCE:
Maricopa County may terminate the resultant Contract for convenience by providing sixty (60)
calendar days advance notice to the Contractor.
6.9 TERMINATION FOR DEFAULT:
The County may, by written notice of default to the Contractor, terminate this contract in whole or
in part if the Contractor fails to:
6.9.1 Deliver the supplies or to perform the services within the time specified in this contract or
any extension;
6.9.2 Make progress, so as to endanger performance of this contract; or
6.9.3 Perform any of the other provisions of this contract.
6.9.4 The County’s right to terminate this contract under these subparagraph may be exercised
if the Contractor does not cure such failure within 10 days (or more if authorized in

SERIAL 15058-RFP
writing by the County) after receipt of the notice from the Procurement Officer
specifying the failure.
6.10 STATUTORY RIGHT OF CANCELLATION FOR CONFLICT OF INTEREST:
Notice is given that pursuant to A.R.S. § 38-511 the County may cancel any Contract without
penalty or further obligation within three years after execution of the contract, if any person
significantly involved in initiating, negotiating, securing, drafting or creating the contract on
behalf of the County is at any time while the Contract or any extension of the Contract is in effect,
an employee or agent of any other party to the Contract in any capacity or consultant to any other
party of the Contract with respect to the subject matter of the Contract. Additionally, pursuant to
A.R.S § 38-511 the County may recoup any fee or commission paid or due to any person
significantly involved in initiating, negotiating, securing, drafting or creating the contract on
behalf of the County from any other party to the contract arising as the result of the Contract.
6.11 CONTRACTOR LICENSE REQUIREMENT:
6.11.1 The Contractor shall procure all permits, insurance, licenses and pay the charges and fees
necessary and incidental to the lawful conduct of his/her business, and as necessary
complete any required certification requirements, required by any and all governmental or
non-governmental entities as mandated to maintain compliance with and in good standing
for all permits and/or licenses. The Contractor shall keep fully informed of existing and
future trade or industry requirements, Federal, State and Local laws, ordinances, and
regulations which in any manner affect the fulfillment of a Contract and shall comply
with the same. Contractor shall immediately notify both Office of Procurement Services
and the using agency of any and all changes concerning permits, insurance or licenses.
6.11.2 Contractors furnishing finished products, materials or articles of merchandise that shall
require installation or attachment as part of the Contract, shall possess any licenses
required. A Respondent is not relieved of its obligation to posses the required licenses by
subcontracting of the labor portion of the Contract. Contractors are advised to contact the
Arizona Registrar of Contractors, Chief of Licensing, at (602) 542-1525 to ascertain
licensing requirements for a particular contract. Respondents shall identify which
license(s), if any, the Registrar of Contractors requires for performance of the Contract.
6.12 SUBCONTRACTING:
6.12.1 The Contractor may not assign to another Contractor or Subcontract to another party for
performance of the terms and conditions hereof without the written consent of the
County. All correspondence authorizing subcontracting must reference the Bid Serial
Number and identify the job project.
6.12.2 The Subcontractor’s rate for the job shall not exceed that of the Prime Contractor’s rate,
as bid in the pricing section, unless the Prime Contractor is willing to absorb any higher
rates or the County has approved the increase. The Subcontractor’s invoice shall be
invoiced directly to the Prime Contractor, who in turn shall pass-through the costs to the
County, without mark-up. A copy of the Subcontractor’s invoice must accompany the
Prime Contractor’s invoice.
6.13 AMENDMENTS:
All amendments to this Contract shall be in writing and approved/signed by both parties. Maricopa
County Office of Procurement Services shall be responsible for approving all amendments for
Maricopa County.
6.14 ADDITIONS/DELETIONS OF SERVICE:
6.14.1 The County reserves the right to add and/or delete materials and services to a Contract. If
a service requirement is deleted, payment to the Contractor shall be reduced

SERIAL 15058-RFP
proportionately, to the amount of service reduced in accordance with the bid price. If
additional materials or services are required from a Contract, prices for such additions
shall be negotiated between the Contractor and the County.
6.14.2 The County reserves the right of final approval on proposed staff for all Task Orders.
Also, upon request by the County, the Contractor shall be required to remove any
employees working on County projects and substitute personnel based on the discretion
of the County within two business days, unless previously approved by the County.
6.15 VALIDITY:
The invalidity, in whole or in part, of any provision of this Contract shall not void or affect the
validity of any other provision of the Contract.
6.16 SEVERABILITY:
The invalidity, in whole or in part, of any provision of this Contract shall not void or affect the
validity of any other provision of this Contract.
6.17 RIGHTS IN DATA:
The County shall have the use of data and reports resulting from a Contract without additional cost
or other restriction except as may be established by law or applicable regulation. Each party shall
supply to the other party, upon request, any available information that is relevant to a Contract and
to the performance thereunder.
6.18 NON-DISCRIMINATION:
CONTRACTOR agrees to comply with all provisions and requirements of Arizona Executive
Order 2009-09 including flow down of all provisions and requirements to any subcontractors.
Executive Order 2009-09 supersedes Executive order 99-4 and amends Executive order 75-5 and
may be viewed and downloaded at the Governor of the State of Arizona’s website
http://azmemory.azlibrary.gov/cdm/singleitem/collection/execorders/id/680/rec/1 which is hereby
incorporated into this contract as if set forth in full herein. During the performance of this contract,
CONTRACTOR shall not discriminate against any employee, client or any other individual in any
way because of that person’s age, race, creed, color, religion, sex, disability or national origin.
6.19 CERTIFICATION REGARDING DEBARMENT AND SUSPENSION
6.19.1 The undersigned (authorized official signing for the Contractor) certifies to the best of his
or her knowledge and belief, that the Contractor
6.19.1.1 is not presently debarred, suspended, proposed for debarment, declared
ineligible, or voluntarily excluded from covered transactions by any Federal
Department or agency;
6.19.1.2 have not within 3-year period preceding this Contract been convicted of or had a
civil judgment rendered against them for commission of fraud or a criminal
offense in connection with obtaining, attempting to obtain, or performing a
public (Federal, State or local) transaction or contract under a public transaction;
violation of Federal or State antitrust statues or commission of embezzlement,
theft, forgery, bribery, falsification or destruction of records, making false
statements, or receiving stolen property;
6.19.1.3 are not presently indicted or otherwise criminally or civilly charged by a
government entity (Federal, State or local) with commission of any of the
offenses enumerated in paragraph (2) of this certification; and

SERIAL 15058-RFP
6.19.1.4 have not within a 3-year period preceding this Contract had one or more public
transaction (Federal, State or local) terminated for cause of default.
6.19.1.5 The Contractor agrees to include, without modification, this clause in all lower
tier covered transactions (i.e. transactions with subcontractors) and in all
solicitations for lower tier covered transactions related to this Contract.
6.20 VERIFICATION REGARDING COMPLIANCE WITH ARIZONA REVISED STATUTES §41-
4401 AND FEDERAL IMMIGRATION LAWS AND REGULATIONS:
6.20.1 By entering into the Contract, the Contractor warrants compliance with the Immigration
and Nationality Act (INA using e-verify) and all other federal immigration laws and
regulations related to the immigration status of its employees and A.R.S. §23-214(A). The
contractor shall obtain statements from its subcontractors certifying compliance and shall
furnish the statements to the Procurement Officer upon request. These warranties shall
remain in effect through the term of the Contract. The Contractor and its subcontractors
shall also maintain Employment Eligibility Verification forms (I-9) as required by the
Immigration Reform and Control Act of 1986, as amended from time to time, for all
employees performing work under the Contract and verify employee compliance using the
E-verify system and shall keep a record of the verification for the duration of the
employee’s employment or at least three years, whichever is longer. I-9 forms are available
for download at USCIS.GOV.
6.20.2 The County retains the legal right to inspect contractor and subcontractor employee
documents performing work under this Contract to verify compliance with paragraph 6.20
of this Section. Contractor and subcontractor shall be given reasonable notice of the
County’s intent to inspect and shall make the documents available at the time and date
specified. Should the County suspect or find that the Contractor or any of its subcontractors
are not in compliance, the County shall consider this a material breach of the contract and
may pursue any and all remedies allowed by law, including, but not limited to: suspension
of work, termination of the Contract for default, and suspension and/or debarment of the
Contractor. All costs necessary to verify compliance are the responsibility of the Contractor.
6.21 INFLUENCE
As prescribed in MC1-1202 of the Maricopa County Procurement Code, any effort to influence an
employee or agent to breach the Maricopa County Ethical Code of Conduct or any ethical conduct
may be grounds for Disbarment or Suspension under MC1-902.
An attempt to influence includes, but is not limited to:
6.21.1 A Person offering or providing a gratuity, gift, tip, present, donation, money,
entertainment or educational passes or tickets, or any type valuable contribution or
subsidy,
6.21.2 That is offered or given with the intent to influence a decision, obtain a contract, garner
favorable treatment, or gain favorable consideration of any kind.
If a Person attempts to influence any employee or agent of Maricopa County, the Chief
Procurement Officer, or his designee, reserves the right to seek any remedy provided by the
Maricopa County Procurement Code, any remedy in equity or in the law, or any remedy provided
by this contract.
6.22 CONTRACTOR EMPLOYEE WHISTLEBLOWER RIGHTS AND REQUIREMENT TO
INFORM EMPLOYEES OF WHISTLERBLOWER RIGHTS.
6.22.1 The Parties agree that this Contract and employees working on this Contract shall be
subject to the whistleblower rights and remedies in the pilot program on contractor
employee whistleblower protections established at 41 U.S.C. § 4712 by section 828 of the

SERIAL 15058-RFP
National Defense Authorization Act for Fiscal Year 2013 (Pub. L. 112–239) and section
3.908 of the Federal Acquisition Regulation;
6.22.2 Contractor shall inform its employees in writing, in the predominant language of the
workforce, of employee whistleblower rights and protections under 41 U.S.C. § 4712, as
described in section 3.908 of the Federal Acquisition Regulation. Documentation of such
employee notification must be kept on file by Contractor and copies provided to County
upon request.
6.22.3 Contractor shall insert the substance of this clause, including this paragraph (c), in all
subcontracts over the simplified acquisition threshold ($150,000 as of September 2013).
6.23 FEDERAL CLAUSES
6.23.1 Title VI
The Maricopa County Department of Transportation, in accordance with the provisions
of Title VI of the Civil Rights Act of 1964 (78 Stat. 252.42 U.S.C. §§ 2000d-4) and the
Regulations, hereby notifies all bidders that it shall affirmatively ensure that any contract
entered into pursuant to this advertisement, disadvantaged business enterprises shall be
afforded full and fair opportunity to submit bids in response to this invitation and shall
not be discriminated against on the grounds of race, color, or national origin in
consideration for an award.
Additional Title VI Assurance language can be found in Exhibit E, Special Federal
Terms, Conditions and Documents. This Exhibit contains a commitment by the Maricopa
County Department of Transportation, as the recipient of the federal funding associated
with this Contract and related project. This commitment pertains to complying with all
referenced Acts and Regulations. Similar assurances are required of contractors and
consultants and must also be included in any subcontracts. Maricopa County Department
of Transportation’s Title VI Plan details can be found at:
http://www.mcdot.maricopa.gov/technical/TitleVI/home.htm.
6.23.2 Buy America
As applicable, the Contractor shall comply with CFR 23, § 635.410 Buy America
requirements and provide proof of compliance with delivery of the pertinent materials.
6.23.3 Small Business Enterprises
It is the County’s policy to facilitate and encourage participation by Small Business
Enterprise concerns (SBE) in County contracts. The County encourages the
Contractor/Consultant to take reasonable steps to eliminate obstacles to SBE participation
and to utilize SBEs in performing contracts.
The Contractor/Consultant shall comply with 49 CFR 26.7, and further defined pursuant
to Section 3 of the Small Business Act and Small Business Administration regulations
implementing it (13 CFR Part 21) where possible. For more details on the SBE program
and process requirements, reference the ADOT Business Engagement and Compliance
(BECO) guidelines for SBEs, which are registered in the Arizona Unified Transportation
Registration and Certification System (AZ UTRACS).
The Contractor/Consultant shall complete the SBE Participation Reporting Form
included in Exhibit E and submit with each invoice/payment request.

SERIAL 15058-RFP
6.23.4 Prompt Pay Legislation
In accordance with A.R.S. § 28-411 (Prompt Payment to Consultants and
Subconsultants), the County must issue payments to Prime Consultants within a certain
number of calendar days after receipt of an Payment Request/Invoice. The law also
requires the Consultants to pay their Subconsultants within a specific number of calendar
days after issuance of payment by the County, unless exceptions exist within the agreed-
upon Consultant/Subconsultant agreement.
Upon any resolution of unapproved invoices/Payment Requests, Prime Consultants shall
not withhold Subconsultants’ payments if the County has paid for the full value of
services rendered. Failure by the Prime Consultant to invoice the County in accordance
with the terms of the contract and/or pay Subconsultants in accordance with A.R.S. § 28-
411 shall be constituted as a material breach of contract, subjecting the Prime Consultant
to disqualification under this contract. The County reserves the right to request the Prime
Consultant provide proof of payment to Subconsultants at any time.
6.23.5 Disadvantaged Business Enterprises (DBE)
The Arizona Department of Transportation (hereinafter the Department or ADOT) has
established a DBE program in accordance with the regulations of the U.S. Department of
Transportation (USDOT), 49 CFR Part 26. This contract has no established contract goals
for DBE participation. Consultants/Contractors are still encouraged to employ reasonable
means to obtain DBE participation. Consultants/Contractors must retain records in
accordance with the DBE specifications included in Exhibit E.
Consultants/Contractors are hereby notified that this recordkeeping is important to the
ADOT, so that it can track DBE participation where only race neutral efforts are
employed.
6.23.6 Federal Aid Contracts
FHWA-1273 form is included in Exhibit E due to FHWA construction funding
(USDOT) being utilized for this contract and related project activities and/or
procurement. As applicable, all clauses in this form are to be complied with under
this contract, and this form shall be inserted in any Contractor/Consultant’s
subcontracts.
6.24 ACCESS TO AND RETENTION OF RECORDS FOR THE PURPOSE OF AUDIT AND/OR
OTHER REVIEW:
6.24.1 In accordance with section MCI 371 of the Maricopa County Procurement Code the
Contractor agrees to retain all books, records, accounts, statements, reports, files, and
other records and back-up documentation relevant to this Contract for six (6) years after
final payment or until after the resolution of any audit questions which could be more
than six (6) years, whichever is latest. The County, Federal or State auditors and any
other persons duly authorized by the Department shall have full access to, and the right to
examine, copy and make use of, any and all said materials.
6.24.2 If the Contractor’s books, records , accounts, statements, reports, files, and other records
and back-up documentation relevant to this Contract are not sufficient to support and
document that requested services were provided, the Contractor shall reimburse Maricopa
County for the services not so adequately supported and documented.
6.24.3 If at any time it is determined by the County that a cost for which payment has been made
is a disallowed cost, the County shall notify the Contractor in writing of the disallowance.
The course of action to address the disallowance shall be at sole discretion of the County,
and may include either an adjustment to future invoices, request for credit, request for a
check or deduction from current billings Submitted by the Contractor by the amount of

SERIAL 15058-RFP
the disallowance, or to require reimbursement forthwith of the disallowed amount by the
Contractor by issuing a check payable to Maricopa County.
6.25 AUDIT DISALLOWANCES:
If at any time, County determines that a cost for which payment has been made is a disallowed
cost, such as overpayment, County shall notify the Contractor in writing of the disallowance.
County shall also state the means of correction, which may be but shall not be limited to
adjustment of any future claim submitted by the Contractor by the amount of the disallowance, or
to require repayment of the disallowed amount by the Contractor.
6.26 OFFSET FOR DAMAGES;
In addition to all other remedies at Law or Equity, the County may offset from any money due to
the Contractor any amounts Contractor owes to the County for damages resulting from breach or
deficiencies in performance of the contract.
6.27 PUBLIC RECORDS:
Under Arizona law, all Offers submitted and opened are public records and must be retained by
the Records Manager at the Office of Procurement Services. Offers shall be open to public
inspection and copying after Contract award and execution, except for such Offers or sections
thereof determined to contain proprietary or confidential information. by the Office of
Procurement Services. If an Offeror believes that information in its Offer or any resulting Contract
should not be released in response to a public record request under Arizona law, the Offeror shall
indicate the specific information deemed confidential or proprietary and submit a statement with
its offer detailing the reasons that the information should not be disclosed. Such reasons shall
include the specific harm or prejudice which may arise from disclosure. The Records Manager of
the Office of Procurement Services shall determine whether the identified information is
confidential pursuant to the Maricopa County Procurement Code.
6.28 PRICES:
Contractor warrants that prices extended to County under this Contract are no higher than those
paid by any other customer for these or similar services.
6.29 INTEGRATION:
This Contract represents the entire and integrated agreement between the parties and supersedes
all prior negotiations, proposals, communications, understandings, representations, or agreements,
whether oral or written, express or implied.
6.30 RELATIONSHIPS:
In the performance of the services described herein, the Contractor shall act solely as an
independent contractor, and nothing herein or implied herein shall at any time be construed as to
create the relationship of employer and employee, co-employee, partnership, principal and agent,
or joint venture between the County and the Contractor.

SERIAL 15058-RFP
6.31 GOVERNING LAW:
This Contract shall be governed by the laws of the state of Arizona. Venue for any actions or
lawsuits involving this Contract shall be in Maricopa County Superior Court or in the United
States District Court for the District of Arizona, sitting in Phoenix, Arizona
6.32 ORDER OF PRECEDENCE:
In the event of a conflict in the provisions of this Contract and Contractor’s license agreement, if
applicable, the terms of this Contract shall prevail.
6.33 INCORPORATION OF DOCUMENTS:
The following are to be attached to and made part of this Contract:
6.33.1 Exhibit A, Pricing;
6.33.2 Exhibit B, Scope of Work;
6.33.3 Exhibit C, ”Click Through” Software Agreement;
6.33.4 Exhibit D, Office of Procurement Services Contractor Travel and Per Diem Policy;
6.33.5 Exhibit E, Special Federal Terms, Conditions and Documents
NOTICES:
All notices given pursuant to the terms of this Contract shall be addressed to:
For County:
Maricopa County
Office of Procurement Services
ATTN: Contract Administration
320 West Lincoln Street
Phoenix, Arizona 85003-2494
For Contractor:
Rhythm Engineering
ATTN: Accounting
11228 Thompson Avenue
Lenexa, KS. 66219

SERIAL 15058-RFP
MARICOPA COUNTY
CHAIRMAN, BOARD OF SUPERVISORS DATE
ATTESTED:
CLERK OF THE BOARD DATE
APPROVED AS TO FORM:
DEPUTY COUNTY ATTORNEY DATE

SERIAL 15058-RFP
EXHIBIT A
PRICING
SERIAL 15058-RFP
NIGP CODE: 918-42
RESPONDENT'S NAME: Rhythm Engineering
COUNTY VENDOR NUMBER :
ADDRESS: 11228 Thompson Avenue
Lenexa, KS 66219
P.O. ADDRESS: N/A
TELEPHONE NUMBER: 913.227.0603
FACSIMILE NUMBER: 913.227.0674
WEB SITE: www.rhythmtraffic.com
CONTACT (REPRESENTATIVE): Steve Laner
REPRESENTATIVE'S E-MAIL ADDRESS: Steve.laner@rhythmtraffic.com
YES NO REBATE
WILL ALLOW OTHER GOVERNMENTAL ENTITIES TO PURCHASE
FROM THIS CONTRACT [ ] [X]
WILL ACCEPT PROCUREMENT CARD FOR
PAYMENT: [ ] [X]
WILL OFFER REBATE (CASH OR CREDIT) FOR UTILIZING
PROCUREMENT CARD: [ ] [X] %
(Payment shall be made within 48 hours of utilizing the
Purchasing Card)
[X] NET 30 DAYS
EARLY TERMINATION OF MAINTENANCE
MCDOT shall have the option to discontinue maintenance and support on a yearly basis and receive a rebate of
funds paid up front for the four-year subscription for unused years of maintenance, per the sliding scale shown
below. Partial years of maintenance will not be refunded. The following schedule of rebates applies:
Termination of M&S after year 1: $29,250 refund
Termination of M&S after year 2: $29,250 refund
Termination of M&S after year 3: $19,500 refund
Termination of M&S after year 4: $ 9,750 refund
Exhibit A Detail
Project: AZ, Phoenix - Bell Rd ASCT - Area#2
Description Units Unit Cost Total Cost
In|Sync software with optimized hardware/detection to 13 $25,000 $325,000
manage single intersection
In|Sync standard two-year warranty 13 Included $0.00
In|Sync warranty – year 3 13 $750 $9,750
In|Sync warranty – year 4 13 $750 $9,750

SERIAL 15058-RFP
In|Sync warranty – year 5 13 $750 $9,750
Pedestrian Module (any ped actuation buttons) 13 $5,000.00 $65,000.00
Additional In|Sync Processors 0 $4,500.00 $0.00
Additional In|Sync Cameras 0 $1,750.00 $0.00
10” LCD monitor, integrated USB mouse/keyboard 13 $700.00 $9,100.00
Ethernet repeaters (req’d for cable runs > 320 ft) 13 $500.00 $6,500.00
Project Management Included $13,850.00
Installation Training (onsite) Included $0.00
Configuration of In|Sync Included $0.00
Shipping and Handling per intersection (from Lenexa, 13 $150.00 $1,950.00
KS)
Standard camera mounting hardware 52 $225.00 $11,700.00
TOTAL EQUIPMENT COST $462,350.00
Area #2
Unit Total
Item Description Quantity Unit Price Price
Mobilization, General Conditions per Move In/Move Out 1 EACH $5,600 $5,600
4 Man Crew Lodging & Per Diem 17 DAY $600 $10,200
Traffic Control / Lane Closures 34 EACH $1,500 $51,000
Install Detection Camera (Install Only) w/Video & Power
Cabling (F & I) 52 EACH $1,700 $88,400
Install ASCT Device In Controller Cabinet (Install Only) 13 EACH $1,000 $13,000
TOTAL INSTALLATION COST $168,200
The In|Sync algorithm works with the included video detection, as well as Rhythm-provided and certified thermal
detection. Rhythm’s product development arm continues to research and integrate additional detection types;
however, at the time of this contract, Rhythm’s recommended video or thermal detection are the only two options
fully compatible with the In|Sync system.
In\Sync is unique in that it measures live queues and REQUIRES either Rhythm-integrated video or thermal
detection. In\Sync Fusion integrates an agency’s other detectors with our video detection, but cannot operate only
on agency’s detection
Agency must use Vendor-provided ASCT hardware and software (including integrated detection) as specified and
priced.
System Verification & Acceptance
This section identifies required, but not limited to, verification activities that will lead to project Final
Acceptance. System verification testing shall be conducted by the contracted system provider to verify that
the ASCT complies with the functional requirements as listed in the Technical Requirements shown in
Attachment C of "Serial 15058 - RFP Request for Proposal for Bell Road Adaptive Signal Control
Technology (ASCT) Deployment".
The contracted system provider shall provide any and all necessary on-site and off-site support, labor and
equipment as appropriate during the system implementation, integration and verification testing. A
proposed System Verification Plan shall be provided by the contracted system provider within 15 working
days after Notice to Proceed. The Proposed Verification Plan shall be submitted to and reviewed by
MCDOT. Any deficiencies in the proposed plan will be identified by MCDOT. All deficiencies identified
shall be addressed by he contracted system provider.

SERIAL 15058-RFP
All system requirements listed in the Technical Requirements & Responses table identified by the
contracted system provider as “Provided”, and accounting for stated and MCDOT accepted concessions
regarding to what extent they are met, shall be verified using one of the following verification methods:
 Demonstration is used for a requirement that the system can demonstrate without external test
equipment.
 Test is used for a requirement that requires some external piece of test equipment.
 Analyze is used for a requirement that is met indirectly through a logical conclusion or
mathematical analysis of a result. For example, algorithms for congestion: the contracted system
provider may need to show that the requirement is met through the analysis of count and
occupancy calculations in software or firmware.
 Inspection is used for verification through a visual comparison.
The proposed System Verification Plan submitted by the contracted system provider shall identify the
specific verification method, location, stage at which the project verification is anticipated to occur, and
verification procedure for each system requirement shown in the system Technical Requirements &
Responses table. Additional details may be provided to or requested by MCDOT, in addition to identifying
the verification method, as necessary to clarify the proposed verification procedure.
The proposed System Verification Plan shall contain as a minimum, but not limited to, a schedule showing
all activities, testing procedures relative to other project schedule components, equipment needed,
personnel and roles. The proposed System Verification Plan shall include examples of forms to be used
during testing for documentation purposes, acceptance criteria, duration(s) of each test, compliance criteria,
retesting timeframes and shall provide a place on the form to record results.
The proposed System Verification Plan responses to each system requirement will be subject to approval
by MCDOT. Each system requirement, accounting for stated and MCDOT accepted concessions regarding
to what extent they are met, shall be associated with a verification procedure.
The contracted system provider shall identify how the veracity of the items listed in System Requirements
Reference Number 6.0-5 can be verified by the agency. The contracted system provider shall detail the
method/source of data acquisition and calculation algorithm(s) (methodology) to the agency resulting in
validating the veracity of providing accurate data back to the ASCT and producing accurate performance
measures listed in the System Requirements Reference Number 6.0-5.
All deliverables included as part of the System Verification shall be listed as part of the proposed System
Verification Plan submittal to MCDOT. MCDOT may request the proposed forms be revised. All forms
shall be approved by MCDOT before use.
MCDOT will respond to a submitted proposed System Verification Plan within 20 working days, noting
any specific requirement procedures that may require clarification, further detail or revision. The
contracted system provider shall revise the Proposed Verification Plan as directed, until acceptance of the
System Verification Plan is granted by MCDOT.
All requirements listed in the Technical Requirements & Responses table shall be met. Requirements
found to be deficient to any level other than full compliance shall be deemed not accepted and final
acceptance shall not be granted until all items are resolved. No additional compensation will be given to
bring the system into compliance if found to be non-compliant during the System Verification procedures
for requirements noted as compliant by the contracted system provider in the Technical Requirements &
Responses table as part of this agreement. .
MCDOT shall identify a Verification Monitor, responsible for observing and documenting the results of
each verification procedure. Any verification failure or lack of performance to meet the stated system
requirements shall be recorded by the Verification Monitor and the contracted system provider shall
prepare a report stating why a system requirement was not met. The report shall include a proposed
solution to resolve the deficiency and shall be submitted to MCDOT within 10 working days after the

SERIAL 15058-RFP
failure is discovered. If the proposed solution includes a software revision or hardware replacement,
upgrade, or repair, such mitigation shall be executed and retested. No additional payment shall be made for
such solution.
If there is a system requirement that the contracted system provider is not able to meet, the contracted
system provider shall document in a report, and develop a proposed plan to provide similar performance or
operation to meet the requirement. The proposed revised approach to meet the system requirement shall be
subject to review and approval by MCDOT, and new testing of the revised requirement shall be initiated
within 10 working days of any approved approach.
Upon completion of all required verification testing, the contracted system provider shall prepare a final
System Verification Report which will document:
 Verification procedures
 Verification Results
 Necessary mitigations/revisions
 Retesting procedures and results
 Final disposition of each system requirement listed in the Technical Requirements & Responses
table
 Failures and detailed resolution to each of the failures
The Final System Verification Report shall be submitted to MCDOT for review. Any comments resulting
from the review shall be transmitted to the contracted system provider. The report shall be revised as
directed, and resubmitted to MCDOT. An Approved Final Verification Report is necessary for final project
acceptance.
Milestone Payments
The parties acknowledge that payment for the Milestones hereunder be payable only upon the County’s
acceptance of such Milestone, acceptance of which shall not be unreasonably withheld, delayed or
conditioned. The Schedule of Milestones, as defined below, is inclusive of the terms and conditions within
the Master Agreement.
Milestone 1 - Product Delivery
System provider will ship all necessary and agreed upon equipment within 30 days of expected installation
date. An invoice for 75% of equipment costs will issued upon Shipment with terms of Net 30.
Milestone Value - 75% of Total Equipment Cost $ 346,762.50
Milestone 2 - Intersection Detection Identification
The system provider shall work cooperatively with MCDOT and MCDOT’s design consultant to identify
specific detection to be provided on each approach, for each movement, resulting from the ASCT system
configuration mutually agreed to by MCDOT and the system provider for this project. Such detection will
be provided by MCDOT under separate contract, unless specifically made a part of the system provider's
contract herein. System provider shall specify, detection distances, zone(s), output configuration
(channels) and method of verification of suitable detection implementation resulting in the optimum
conditions for the system provider's ASCT system to operate successfully. MCDOT shall review and
approve system provider’s recommendations for detection implementation. Final plans shall be the
responsibility of MCDOT. System provider shall note that 15 specific locations are available for intrusive
detection (loops). All others shall use non-intrusive detection methods that do not result in any ground
disturbance.
Vendor shall also supply specifications for detection technologies and systems that are compatible with
their system resulting in maximum system effectiveness. Vendor shall identify any detection technologies
or systems that are incompatible with or unsuitable for use with their proposed system.
Milestone Value - 25% of Installation Cost $ 42,050.00
Milestone 3 - System Installation and Training
The system provider shall deliver, install, configure and set up all hardware and software associated with
the ASCT system, and conduct agency staff training per the terms and conditions of this agreement.
System provider shall acknowledge that the field detection elements, installed by separate contract, unless

SERIAL 15058-RFP
specifically made a part of the system provider's contract herein, shall be in-place and functional prior to
full ASCT implementation and agency staff training.
Milestone Value - 25% of Installation Cost $ 42,050.00
Milestone 4 - Final Acceptance
The system provider shall attain Final Acceptance from MCDOT based on successfully passing the testing
requirements of the MCDOT approved Verification Plan, which test functionality and compliance to the
System Technical Requirements agreed to by the system provider under the terms and conditions of this
agreement.
Milestone Value -Remainder of Project Cost (25% of Equipment cost + 50% of Installation Cost)
$ 199,687.50

SERIAL 15058-RFP
Exhibit B
Scope of Work
Project Approach/Methodology
Detection: Presence & Queue Lengths
The In|Sync system includes four Samsung® IP detection cameras per intersection. Unique to In|Sync, cameras are
connected directly to the processor to constantly view each approach and measure the length of each queue. Where
other traffic control systems estimate movement demand based on past history, In|Sync measures demand in real
time. This allows In|Sync to schedule the right amount of time to clear the actual queue at that moment, and then
change quickly to another phase pair with active demand.
In|Sync cameras are connected directly to the In|Sync processor via Ethernet cable. As shown in the following
image, many detection zones are drawn on each camera image, allowing the In|Sync processor to measure how
many vehicles are in queue for each movement at every moment in time.
Detection Zones in the In|Sync Camera View
The blue boxes in the image are detection zones set in the In|Sync processor. Multiple times per second, the
processor analyzes the video image and determines whether each zone is occupied or empty. Each time a vehicle
arrives at the end of a queue, In|Sync shall see another detection zone become active, allowing In|Sync to know the
queue length for that approach at that exact moment.
This ability to actively measure queue length in real time is a unique capability of In|Sync, separating it from other
adaptive systems, which use past data to estimate current queue.
Based on the length of queue for a given movement, In|Sync shall allocate the appropriate amount of time to serve
that queue, adjusting phase order as appropriate dynamically, to best serve all vehicles. For examples of In|Sync’s
proven benefits in near-saturated conditions, refer to the In|Sync Demonstrated Benefits section of this report.

SERIAL 15058-RFP
Dynamic Sequencing
In|Sync is not constrained by the limitations of ring-and-barrier operations and can dynamically choose to serve
phases in the order that works best. In|Sync can also skip phases when no demand is present. These unique
capabilities allow In|Sync to allocate green time much more effectively than other systems, and the result is more
green time becoming available for movements with heavy demand.
The In|Sync algorithm allocates green time according to a “greedy” mechanism. This algorithm calculates which
movement is most in need of service, and shall schedule that movement as soon as it can (while obeying the
sequence library programmed in its configuration file). The results of this unique capability are twofold:
I) Heavy movements with large current demand get service sooner. This results in generally lower queues
network-wide.
II) Platoons traveling in either direction along the corridor more often arrive on green, and stops are dramatically
reduced.
In|Sync’s global optimizer synchronizes a series of traffic signals, creating progression along an entire corridor. To
do this, In|Sync schedules green tunnels based on demand. These tunnels are essentially speed lines allowing
platoons of vehicles to get several green lights in a row. Communications between signals allows In|Sync to
anticipate platoon arrival, serve the coordinated movement a green signal and avoid slowing or stopping
progression.
Green Tunnels Facilitate Bi-Directional Progression
The In|Sync global optimization allows for the dynamic adjustment of the period length depending on real-time
traffic demand. It can also dynamically adjust the size of the green tunnel at each intersection.
Bidirectional Progression
Traditional traffic signal control systems are effective in coordinating movements in a single direction; however,
they struggle to provide coordination simultaneously in the opposing direction. This is due to the ring and barrier
operation of traffic signal controllers and the often unevenly spaced intersections along the corridor. In|Sync does
not have the ring-and-barrier limitation, and can choose any phase sequence allowed in its library. At one
intersection, for example, eastbound and westbound green tunnels may run at the same time, and at the next
intersection to the west, the westbound tunnel may run first, followed by a gap, followed by the eastbound tunnel,
followed by another gap. The genius of the In|Sync adaptive algorithm is that any phase may be served during either
gap, resulting in better green-time allocation and reduced delay.
Eliminating Transition
With conventional controllers, transition is caused any time a controller is switching from one timing plan to
another. Transition is also caused by Emergency Vehicle Preemption and pedestrian calls. Because In|Sync does not

SERIAL 15058-RFP
operate using ring-and-barrier functionality, In|Sync does not have transition. In|Sync processors at each intersection
know when their next scheduled coordinated movement needs to occur. The processor serves all minor movements
during the available time, in the order that optimizes operations, then shows green for the coordinated movement
right on time. Any disrupting event (e.g., an emergency preempt) that would cause transition in a conventional
system is seamlessly handled by In|Sync. The moment the disruption ends, In|Sync determines when its next
coordinated movement is scheduled to occur. It shall use the available time to serve the currently queued vehicles
for all minor movements, then guarantee green for the coordinate movement, right on time. As soon as that
coordinate movement (green tunnel) ends, In|Sync shall go back to serving all minor movements, in the best
sequence to minimize delay to all traffic. Through this improved mechanism, transition is eliminated with In|Sync.
Customized Plans for Special Events
In|Sync’s configuration parameters, developed by a Rhythm project engineer, govern the real-time adjustments that
the system makes to handle standard variations in traffic demand. This continuous monitoring and adjustment
ensures the most-efficient servicing possible, reducing wasted green time and unnecessary delay. Special events that
drastically change traffic demand volumes, however, can be handled one of three ways within In|Sync:
 Utilizing standard configuration parameters, In|Sync’s adaptive
qualities shall increase period length and, if necessary, green tunnel
duration to accommodate volume changes.
 For planned events where traffic volumes exceed even the maximum
adaptive parameters in a standard configuration, special configurations
can be created and scheduled. For example, if a venue releases a great
deal of traffic at a specific time of day on the same day each week, a
special configuration can be created and scheduled to accommodate the
extreme variation in the traffic pattern. These special configurations could include higher period lengths,
different upper and lower bounds for period lengths, or even completely different coordinated route through
the corridor. This is a great option for a demand surge entering the corridor from the side street—a route
can be created that begins with a left-turn off the side street and continues through the corridor, clearing the
surge of traffic generated by the planned event or venue.
 In|Sync’s 1.6 operating software includes variable-driven event triggers that switch configuration
parameters for unplanned events based on user-defined considerations. In|Sync shall receive a binary
(on/off) signal from a device or controller, which shall trigger the alternate configuration.
In all cases, the In|Sync system is able to increase period length and change configurations without transition. This
ability is unique to the In|Sync system, which is not confined by conventional traffic controller logic (i.e., ring-and-
barrier operations and using a reference point to create coordination).
Reducing Wasted Green Time
When vehicles are flowing through the intersection (i.e. the phase being measured is currently showing green),
In|Sync uses the camera feed to evaluate which detection zones are currently occupied. This gives In|Sync the
unique ability to determine an occupancy percentage for each lane. As shown in the following image, many
detection zones are drawn in each lane. In|Sync shall measure the outside through lane, for example, and detect that
20% of the zones are currently occupied. As time passes and vehicles are served, the occupancy of that lane may
drop to 10% of the detection zones currently being occupied, then 8%.

SERIAL 15058-RFP
Detection Zones in the In|Sync Camera View
In its configuration file, In|Sync is given rules for when it should gap out a phase with current demand. For example,
if 70% of the scheduled green time has passed, and fewer that 10% of the detection zones are occupied, In|Sync is
permitted to gap out. These parameters are adjustable via CentralSync for each approach at each intersection during
each time of the day.
This improved functionally allows In|Sync to gap out earlier than conventional systems, which waste time counting
down passage timers when all traffic is through the intersection. By utilizing occupancy gap out, vehicles are cleared
through the intersection on yellow, as intended, and less time is wasted showing green to an empty approach. (Note,
if traditional gap-out behavior is desired instead of occupancy gap-out, this is an available option in In|Sync as well.)
Setting Corridor Goals & Objectives
In|Sync does not have time-of-day plans made up of splits and offsets. Instead, configuration files are created which
give In|Sync high-level parameters to govern its behavior. Some of these parameters include green tunnel width,
lower and upper bounds of period length, and allowable sequences. In|Sync shall operate within these parameters,
assigning green time and sequences dynamically, moment by moment, in response to the current demand. The
conventional method of summing 15-minute volumes and calculating peak hour factors to build a generic timing
plan is replaced with real-time measurements and dynamic green time allocation by the In|Sync algorithm. As
demand changes, In|Sync responds automatically, with no need to update timing plans.
Limited calibration is needed to maintain operations with the In|Sync system because the system chooses its own
sequencing and equitable distribution of green time. This process can be thought of as having a new micro “timing
plans” generated every “cycle” at every intersection independently based on live measurements without transition.
The system’s adaptive capabilities shall greatly minimize the operational load for cities and county staff.
Achieving Agency Goals & Objectives
In|Sync’s effectiveness can be measured through a number of different metrics, including corridor travel time,
number of stops, individual movement delay, and system-wide delay. Unlike conventional methods of traffic signal
control, which estimate demand based on daily averages or measured volumes from a previous cycle, In|Sync makes
green allocation decisions based on its measurements of queues at that very moment.

SERIAL 15058-RFP
This superior methodology gives In|Sync the ability to discern traffic conditions at each intersection and make the
best decisions about how to allocate green time to serve traffic. Additionally, because each In|Sync intersection is in
communication with other intersections in the network, platoons of vehicles are served with fewer stops. In|Sync
makes real-time decisions based on real-time measurements, and the global optimizer helps ensure the efficient use
of green time in and throughout the entire corridor.
In|Sync is not restricted by the traditional ring-and-barrier methodology. This means that there are no cycles or
offsets in the way we conventionally think of it. Controllers need to be re-timed frequently because cycle lengths
need to be common amongst all intersections in a corridor. With In|Sync, many of these limitations are eliminated.
In|Sync does not have a cycle; rather, from one period to the next, In|Sync chooses which sequence of phases best
serve the current demand. Imagine how a person would make decisions if he were standing at the intersection,
viewing all approaches simultaneously; this is the type of operation that In|Sync’s artificial intelligence replicates.
Adaptive control functionality is quite different from off-line optimization methods. For instance, the In|Sync
adaptive traffic control system constantly gathers traffic condition data then analyzes, optimizes and adapts the
signal timings in real-time, every second, to serve changing traffic demands. This method contrasts with traditional,
off-line optimization techniques wherein data collection and signal re-timings are performed once every few years.
Traditional optimization techniques develop predetermined system timing plans that are stored and downloaded
based upon time of day or responsive control thresholds. Unless there is a stored plan that matches actual traffic
conditions, they do not precisely accommodate variable or unpredictable traffic demand.
The Long-Term Solution
In|Sync processors communicate via a distributed network, so there is truly no limit to the number of processors that
can be linked together. This capability allows Maricopa County to select the very best in adaptive traffic control for
use in the signals identified for this project, and later expand the system on other corridors in the vicinity with
seamless integration. The system requirements specify 50 intersections being controlled with adaptive operations,
and In|Sync significantly exceeds this requirement.
An In|Sync processor resides at each intersection, and communicates to all other In|Sync processors in the network.
Intersections can be split into groups, and this is done in instances where doing so provides benefit. Some In|Sync
corridors include more than 20 intersections along a single corridor, all operating together in one group. In other
instances, geometric considerations make it preferable to split the corridor into two or more groups. No limits exist
on the number of intersections or the number of groupings. Rather, Rhythm engineers work with agency staff to
create the best possible configuration, allowing In|Sync to best optimize traffic operations in real time.
Remote Configuring, Setup, and Troubleshooting
In|Sync processors can be accessed by authorized users from any device connected to the internet. A Virtual Private
Network (VPN) connection is used to access an In|Sync device residing at the intersection. That device essentially
hosts a web page that users access and interact with to adjust configuration files. This allows engineers and
technicians from Rhythm and the traffic agency to determine camera status, see light states, and monitor queues
from anywhere. Imagine being able to observe, diagnose, and fix a traffic signal problem from your tablet or
computer in your living room at home—this is the technology and capability the In|Sync system provides today.
No Dependency on a Central Server
In|Sync does not rely on a central server. Rather, each In|Sync processor optimizes phase sequence and green time
allocation based live demand. This distributed network infrastructure provides the highest failure mitigation and best
operations during a communication outage. Each processor shares the same configuration file with all processors in
its group. When communication between intersections goes down, all processors know it, and respond accordingly.
Each processor knows what the other processors should be doing when, and shall continue to run the scheduled
configuration file during the various times of day.
While communications are down, In|Sync shall lose the dynamic period length functionality. All processors shall
recognize the loss of communication between intersections and shall run the default period length for the given time
of day. Once communications are restored, dynamic period length functionality shall resume.
The local optimizer is unaffected by communications loss. The local cameras continue to view each approach, send
video feeds to the In|Sync processor, which measures queues and schedules phases appropriately. Coordinated

SERIAL 15058-RFP
movements are served on time, and adaptive operations continue without disruption. Because of the distributed
network architecture, there is not a central point of failure.
Maximizing Throughput
In|Sync’s adaptive configurations feature the ability to adjust service times based on real-time traffic conditions,
utilizing a set of baseline parameters, extending or truncating coordinated movements and period lengths based on
demand and delay. In|Sync's computes split times, second by second, according to real-time queues. In|Sync shall
serve a phase as long as demand exists for that phase, until the time available until the next coordinated phase equals
the time required to serve all queued traffic that has not yet been served in the current period. This superior
methodology allows In|Sync to handle unusual spikes in demand and unpredictable traffic conditions optimally.
In|Sync's configuration files, while similar in concept to a Time-of-Day plan, work in a completely different way.
While other systems rely on ring-and-barrier functionality, cycles, and splits, In|Sync has only "green tunnels" and
"white space." During a green tunnel, a user-specified phase shall be guaranteed green. As soon as the green tunnel
ends, In|Sync enters the "white space," (i.e, the local optimizer takes control of operations). The local optimizer
dynamically assigns green time based on current live demand. In|Sync measures queues constantly, so it shall know
that the phase has high demand at this moment, and shall assign the amount of time needed to clear this queue.
In|Sync is the only adaptive solution capable of this optimal methodology.
In|Sync uses a dynamic period length to maintain side street service. The period length (i.e., the time between the
start of a coordinated movement and the next start of that same coordinated movement) shifts according to the
overall demand along the corridor and minor movement demand. When an In|Sync processor at a local
intersections detects that the “white space” available was not long enough for all minor movements to be served, it
sends a signal to all other In|Sync processors in the group, and each one increases the length of time of its white
space before the next green tunnel (i.e., coordinated movement). This is how In|Sync distributes green time to best
facilitate progression, without inducing transition events seen with ring-based controllers. With In|Sync, the user
does not have to define all possible timing plans to implement adaptive operations. This significantly reduces staff
workload and the time commitment needed to operate the system.
Phase Order and Safe Operations
In|Sync dynamically and in real-time, determines the order of phases based on actual traffic demand. The agency
has full control of what phase sequences are in In|Sync’s allowed library. No phase sequence shall ever be allowed
that creates a yellow trap. In|Sync is coded never to allow a yellow trap to occur. By referring to its library of
available phase sequences, In|Sync measures all queues in real time and selects the phase sequence that is best for
that particular moment. A few seconds later, In|Sync again evaluates all allowed sequences, and again determines
the best one. This iterative process occurs again, in the moment in real time. Through this mechanism, In|Sync
constantly determines the best phase sequence for the live traffic, while ensuring safe operations at all times.
Pedestrian Service
In|Sync serves pedestrian demand along with vehicular demand using its pedestrian module. This functionality
ensures progression is maintained and pedestrians crossing the mainline do not trigger transition. All of the walk and
flashing don’t walk times shall be adhered to. The project engineers shall balance pedestrian traffic with mainline
vehicular traffic.
Improving pedestrian safety is a key objective of the pedestrian module. This is accomplished by In|Sync creating
very structured platoons and more predictable gaps between platoons where pedestrians may safely cross. Through
this mechanism, pedestrians are served without ever causing transition, which results in the best experience for all
roadway users.

SERIAL 15058-RFP
Work Plan
Include all project requirements and the proposed tasks, services, activities, etc. necessary to accomplish the scope
of the project defined in this solicitation. This section of the proposal shall contain sufficient detail to convey to
evaluation team the proposer’s knowledge of the subjects and skills necessary to successfully complete the project.
Include any required involvement of agency staff. The proposer may also present any creative approaches that
might be appropriate and may provide any pertinent supporting documentation. Proposers shall include any and all
additions and/or deletions that may pertain to the proposed system.
Task 1. Training Installers & Agency Staff
Installation Training
Rhythm Engineering shall provide the turn-key installation services per the RFP. However, Rhythm Engineering
would like to offer Maricopa County and associated agencies on-site training on how to use the In|Sync System.
Rhythm Engineering has conducted over 430 classroom training sessions and 430 field training sessions to date.
Rhythm Engineering’s technicians shall arrive at the project location on a Monday and prepare for the In|Sync
deployment class Tuesday morning at 9 a.m. County and city staff are invited to attend a training session made up of
a morning classroom session and an afternoon field session. Use of a bucket truck (to be provided by the one of the
cities) is needed for the afternoon session.
Classroom-style training shall be held the first morning of deployment training. It shall cover:
 In|Sync Equipment, Hardware Components and Integration.
 Camera Setup, Laptop Configuration, and Settings
 In|Sync’s WebUI

During the afternoon of the first day, there shall be a field demonstration at the intersection. Rhythm Engineering’s
technician shall provide installation training and install In|Sync in-cabinet equipment at the first intersection.
Rhythm Engineering’s technician shall work onsite for several days to advise and guide the installation team to
install the in-cabinet In|Sync equipment. The installation team shall be trained to install systems independently and
bring them into “Detector Mode”.
All intersections that were not installed during training shall be installed with remote assistance from Rhythm
Engineering. The in-cabinet installation work shall not cause any outages and can be conducted during normal
business hours. In-cabinet In|Sync installation, adaptive turn-on, and configuration work actually requires the
presence of traffic so Rhythm’s technician or engineer can verify the parameter changes of the In|Sync system.
Training Documents
In|Sync users are provided with electronic user manuals, a free video training library, web-based content, and access
to support staff via the phone 24/7. Rhythm Engineering’s project engineers and technicians provide ongoing
operational support around the clock, enabling users to develop a robust understanding of how In|Sync works and
the best methods for optimizing performance.
City staff shall receive printed and electronic copies
of all system documentation. These user guides are
written in an easy-to-read format with photos,
screenshots and other graphics to help communicate
instructions. In|Sync documentation includes:
 In|Sync Installation and Maintenance Guide
 In|Sync:Tesla® WebUI Guide
 CentralSync Software Guide

SERIAL 15058-RFP
Task 2. System Hardware
In|Sync Hardware
Four cameras are included with the In|Sync system (one for each approach). These cameras can be mast-arm
mounted or pole mounted, and shall be connected to the In|Sync processor via Ethernet cable. The first step to install
In|Sync is to mount the detection cameras and pull cable (both Ethernet and power cable) from the traffic cabinet to
each camera. With the remote assistance of Rhythm staff, cameras shall be positioned, aimed, and zoomed properly
as they are installed.
The second step is to install all cabinet hardware, including the In|Sync processor, DIN relay, equipment panel,
SDLC intercept module, and the cabling connecting these devices (to each other, to the detector card rack, and to the
controller).

SERIAL 15058-RFP
The In|Sync processor is installed inline between existing detectors and the controller. In|Sync decides which two
phases should be served in a given moment, and sends calls to the controller for those two phases only.
The following hardware shall be provided by Rhythm Engineering for each In|Sync intersection.
 Up to four digital cameras (one per approach) and camera enclosures
 The camera bracket is also included and is mounted directly on the bottom of the enclosure.
 Pelco camera mounting hardware
 One In|Sync processor
 SDLC Intercept Module (includes necessary cabling)
 Equipment panel
 Includes:
 Ethernet switch (communications hub for Ethernet connections)
 Lightning arrestors for Ethernet cables (placed between camera and switch)
 24 VDC power supply (110V/AC direct input, Ethernet switch, power out to processors, DIN
Relay, and cameras)
 Termination points for camera power
 ICAT5E cable for connecting cameras to the In|Sync processor (optional to be provided by Rhythm or
obtained from another vendor)
 Camera power cable (optional to be provided by Rhythm or obtained from another vendor)
The following figure is an example of detector inputs being sent to a NEMA TS2, Type 1 Controller with a SDLC
connection after installing In|Sync and the SDLC Intercept Module.

SERIAL 15058-RFP
The following graphic depicts an example In|Sync installation cabinet layout using a SDLC connection.

SERIAL 15058-RFP
Standards Compliance
In|Sync complies with all necessary industry standards. In|Sync is deployed systems in 29 different states, is NEMA
TS1 tested and certified, and is listed on the Approval Product List (APL) for multiple states, including Florida,
Virginia, and Pennsylvania. In|Sync integrates and operates with all models and brands of traffic controllers, making
the adaptive installation process straightforward.
In|Sync integrates and operates with any modern traffic controller. Rhythm Engineering’s patented method works
with all forms of pin assignments into the controller. This capability means that the city shall avoid being tied down
to one specific type of traffic controller. A corridor with different controller or even cabinet types intersection-to-
intersection can be coordinated seamlessly with In|Sync.
Since In|Sync works with the existing controllers and detection devices, the processors can immediately begin
receiving data after installation, allowing Rhythm’s engineering and operational staff to monitor and optimize
adaptive configurations based on variations in regular traffic flows.
Cabling, Devices, & Equipment
The following cable type is required for powering the In|Sync cameras and connecting them to the In|Sync
processor. This cabling can be either provided by Rhythm at the price listed in the quote section of this report, or
purchased by the County/City from another qualified vendor.
Shielded ICAT5E Cable
Commscope P/N: 8841405/10 2003 Black ICAT5E cable (or Rhythm Engineering-approved equivalent shielded
ICAT5E outdoor UV-resistant aerial/duct Ethernet cable). Recommended cables are available from an electrical
supply house (such as Anixter, Accutech, or Graybar) and pulled from the traffic cabinet to the specified camera
location. We recommend 10 ft. of slack left at the cabinet and 5 ft. of slack at each camera.
If you are installing the camera in temperatures under 0° C/32° F, we recommend using the Belden 7937A Multi-
Conductor - DataTuff® Waterblocked Cate 5e Cable because it remains flexible in temperatures up to -25°C/-13°F
Power Cable
IMSA 20-1 Traffic Control Cable, is used to supply power to the cameras and camera enclosures. (14-3 AWG
Stranded Copper - For use in signal systems in underground conduit/duct or as aerial cable supported by a
messenger.)

SERIAL 15058-RFP
Adaptive System Equipment Cut Sheets

SERIAL 15058-RFP

SERIAL 15058-RFP

SERIAL 15058-RFP

SERIAL 15058-RFP

SERIAL 15058-RFP

SERIAL 15058-RFP

SERIAL 15058-RFP

SERIAL 15058-RFP
Task 3. Communications
The In|Sync system involves individual intersections that talk to each other to facilitate progression of traffic along a
corridor. This “talk” happens via Internet Protocol (IP) communications. IP communication is a robust and proven
technology that has allowed the Internet as we know it to evolve. As long as there is some route between two points,
no matter how indirect, they can communicate.
Note: The word “Internet” in Internet protocol can be a little misleading – it is not necessary for the network to be
open to the rest of the world. Typically the network used by In|Sync is either sequestered behind firewalls or totally
isolated. Municipalities with an existing networking plan can often just incorporate the traffic network into their
broader networking scheme.
Various types of communication have been utilized along In|Sync project corridors, including copper interconnect,
fiber and wireless radio. In|Sync does not require specialized forms of communications and can accommodate all
proposed communications. Moreover, In|Sync’s design as a distributed network is the most practical approach to
maintain traffic operations in the event of communications outage. Even if the network communications fail,
coordination between signals continues.
Interconnect Communication
In order for In|Sync to coordinate traffic between intersections, some route for Internet protocol (IP)
communications must exist between the intersections. IP communication can occur over many types of physical
infrastructure, including fiber optic cable, Ethernet cabling, twisted-pair cabling, or wireless radio technologies.
These physical connection technologies can be mixed and matched as appropriate, even within the same corridor.
In|Sync’s design as a distributed network is the most practical approach to maintain traffic operations in the event of
communications outage. Even if the network communications fail, coordination between signals continues.
An example In|Sync Network Communications Schema is shown in the following graphic. This depicts the cameras,
processors, din relay, controller, unmanaged Ethernet switch, and managed Ethernet switch at each intersection. It

SERIAL 15058-RFP
also depicts one option of connection of the intersection-level network to the county / city’s network, via a DSL
modem. In practice, any connection method is acceptable to Rhythm Engineering, so long as our operations team
has access to access the intersection devices via Virtual Private Network (VPN).
The following figure shown an example depiction of how In|Sync processors communicate over a mixed network. In
this example, a DSL drop is located at the intersection that is closest to the phone company’s central office. This
provides the best DSL line speed.

SERIAL 15058-RFP
Note: The top two intersections are not directly connected to each other. Any IP traffic between them is
automatically routed through the third intersection. How intersections communicate to each other is the backbone of
signal coordination. Interruptions in the network can be tolerated quite well, as each intersection shall continue to
run coordination based on the configuration files that were in use by all processors the last time full connectivity was
available as well as having the ability to continue to view real-time data from the cameras at each local intersection,
giving In|Sync full local adaptivity even when communication is lost.

SERIAL 15058-RFP
IP Addresses
Ten IP addresses are required for each intersection in an In|Sync corridor. This ensures that there is one static IP
address per In|Sync network device (cameras, processor, DIN Relay), plus three to five designated open static IP
addresses for technicians to use when on-site.
Failure Mitigation
Should power to the In|Sync processor be lost, detector calls are passed directly through to the controller. As soon as
power is restored, the In|Sync processor shall automatically turn back on and shall boot up within one minute. All
configuration files are stored in the In|Sync processor itself, so once the processor has booted up, it shall begin
running the appropriate configuration and shall be fully adaptive and coordinated.
Because In|Sync uses a distributed network between the intersections on the corridor, there is no single point of
failure across the network of intersections. During a communication outage, In|Sync processors shall continue
operating in coordination with each other and executing adaptive operations using real-time camera views. As a
result, the vulnerabilities experienced in centralized networks and/or server-based solutions are mitigated. Exposure
to the risk of communication loss is also much lower when conducting adaptive configuration changes and adaptive
hardware maintenance.
In a real-life example of its failure mitigation capabilities, In|Sync processors continued uninterrupted adaptive
operation with coordination between signals, on a 64,000 ADT arterial with broken communications for six months
in San Ramon, CA.
In the rare event of an In|Sync processor failure, detector calls are passed directly through to the controller. The
controller shall see all detector calls and allocate time using the plan it has stored. The In|Sync processor would need
to be repaired or replaced in order for the intersection to reenter adaptive operation. This would be addressed by the
In|Sync warranty.
Included with each In|Sync system is a DIN relay, which is housed in the traffic cabinet and routes power to the
Rhythm devices. The DIN relay is an IP-addressable device which is used to route power to the cameras and the
In|Sync processor. This connection method prevents overloads, brown-outs, blown breakers and other power
problems before they occur. If any camera loses connection to the network port or experiences an instance of
“locking up” for any reason, it can be power cycled remotely by the DIN relay using the WebUI software. The DIN
relay can be accessed through the WebUI by any credentialed user on any internet-ready device, even a tablet or
smartphone. No longer shall technicians have to drive out to a traffic cabinet to power cycle a camera. This
capability makes troubleshooting and failure mitigation much simpler, as many potentially aggravating problems
can be fixed in minutes without staff ever having to leave their office.

SERIAL 15058-RFP
Task 4. System Installation
Pre-Installation Review
Before installing the In|Sync system, a thorough pre-installation review shall be completed by the project team
(made up of County/City and Rhythm Engineering staff). The Rhythm Engineering operations team shall work with
the county/city to ensure appropriate communication, detection, cabinet preparations and installation have been
completed. All onsite work mounting of the In|Sync cameras, pulling the camera’s Ethernet and power cabling, as
well as establishing intersection-to-intersection network communications shall be completed by a Rhythm
Engineering certified installer. Rhythm Engineering shall remotely attend all pre-installation meetings and work
with county/city staff to fully comply with submitting all pre-installation submittals to achieve adaptive turn-on by
the proper date.
The process of deploying In|Sync is made up of two phases:
 installing the hardware and turning on “detector mode”
 implementing In|Sync’s “adaptive turn-on”.
Pre-Installation Checklist
1 As-built signal plans, hourly traffic volumes, and signal controller pin input information is sent to Rhythm
Engineering in advance.
2 If the intersection is new, verify that stop bars and lane lines/striping are painted or are clearly identified
with markers or cones.
3 Power is provided at the traffic cabinet (a generator is acceptable in new construction situations).
4 A controller is installed and functional.
5 Camera mounting hardware is assembled and in place at the Panamorphic camera location.
6 In|Sync‘s monitoring cameras are installed per Rhythm Engineering specifications.
7 Specified camera power and shielded ICAT5e Ethernet cables are pulled to each camera location from the
traffic cabinet.
8 Each camera power and shielded ICAT5e Ethernet cable is clearly marked identifying its use at the cabinet.
9 Communications are in place and have been tested:
9.2 Between each signal/system (via copper, fiber, or wireless)
9.3 Remotely to Rhythm’s tech team via VPN or other external network access
10 All In|Sync system components are onsite and inventoried.
10.2 Processor
10.3 Equipment panel
10.4 DIN Relay
11 In|Sync connection hardware is onsite and inventoried:
11.2 ABC Y-cable, SDLC Module, or C1 Y-Cable (Depending on the controller solution)

SERIAL 15058-RFP
Preparing the Controller for Adaptive Mode
Prior to In|Sync adaptive operation, the existing controller shall be set into free mode. This shall allow In|Sync to
place calls only to the phase pair scheduled to be green (see explanation in Table A below). In|Sync shall never call
conflicting phases while in adaptive mode.
Settings for preparing the controller for adaptive mode
Setting Action Explanation
Coordination Selection varies by Coordination based parameters shall prevent the
controller; Is called controller from operating the intersection based on the
Disabled, Free, or calls it receives from In|Sync.
Uncoordinated
Minimum Green Time 10 sec. on mainline In Adaptive mode, the local optimizer
through movements schedules the appropriate amount of green time for a
standing queue. In|Sync cannot serve any phase for less
5 sec. on all other than the Min Green programmed in the controller. These
movements Min Green settings must also be programmed in In|Sync.
Maximum Leave as Because Max Green times are only used when conflicting calls are present, they are
Green Times currently irrelevant during normal adaptive operation.
set

SERIAL 15058-RFP
Setting Action Explanation
Gap/Passage 1 sec. When In|Sync moves calls to the next scheduled phase pair, there
Time may be a fraction of a second where the controller has no calls due
to system latency. In order to remove the possibility of soft recall,
we require setting the Gap or Passage time to 1 second.
All Recalls Disabled Recalls should be configured in In|Sync rather than the controller.
(Max., Min, etc.)
Soft Recall Enabled on mainline While in adaptive mode In|Sync shall always place two concurrent
through phases calls to the controller thus making the use of soft recall allowable
but unnecessary.
Non-locking Enabled on all phases This prevents the controller from locking calls caused by In|Sync’s
Memory detector heartbeat (see Detector Diagnostic Failure Mode).
Detector Delays Remove all Detector delays should be configured in the In|Sync detector setup
instead of in the controller.
Protected/permit Omit the left turn call This is a precaution to prevent a yellow trap if the controller receives
ted left turns when opposing calls on permitted left turn phases when the opposing through is
through movements green.
are green
Protected Only, Allow lagging left This enables more adaptive functions of In|Sync.
Flashing Yellow turns
and Dallas
Display Left
Turns
Detector Enabled In|Sync’s detector heartbeat pulses calls on all phases to the
Diagnostics controller periodically to prevent detector diagnostics off failure
Failure Mode Off Failure set to 5 from occurring. This heartbeat functionality is also a reason why
minutes Non-locking Memory must be enabled.
To ensure that making the switch to In|Sync adaptive traffic control is a positive experience for agency personnel
and motorists, a Rhythm Engineering project engineer shall be onsite at the deploying agency’s office and at
individual project intersections. The engineer shall stay onsite for several days, driving the In|Sync intersections
multiple times with agency representatives, fine-tuning the system as needed and providing training on In|Sync user
software. Unlimited remote technical support during verification and validation testing is also included.
Detector Mode & Adaptive Turn-On
In detector mode, the system functions like a standard detection system and submits calls to the controller. The
adaptive turn-on is an onsite and offsite support process that involves configuring the system to adapt to real-time

SERIAL 15058-RFP
traffic demand. Rhythm Engineering’s personnel shall be onsite at least two times during the deployment process -
once for installation and training and once for adaptive turn-on and a three (3) day in-depth engineering training
after the adaptive turn-on. An additional training session shall also be scheduled after the initial adaptive operation
but shall be conducted remotely via webinar.
In|Sync Detector Mode
The first step in developing a configuration plan is quantifying the existing traffic demand. This is accomplished by
setting In|Sync into detector mode. While in detector mode, In|Sync shall pass all detector calls directly through into
the controller. The controller operates normally, using its existing time-of-day plan. During the period that In|Sync is
operating in detector mode, it collects traffic demand and queue data for each movement at each approach. This data
shall be used to configure In|Sync’s adaptive parameters.
Immediately prior to In|Sync adaptive operation, each controller needs to be
set into free mode. Once the controller is set to free mode, In|Sync controls
the signal by submitting detector calls for only the two phases it wants to be
green at that given moment. The controller shall respond by turning those
movements green, and shall stay in that state until In|Sync decides to change
state and sends a different set of detector calls to the controller. In|Sync shall
never call conflicting phases while in adaptive mode.
Adaptive Turn-On
Rhythm Engineering shall work with county/city staff to develop a clear
sense of goals and priorities for the overall adaptive system and for individual intersections. These discussions shall
be a significant focus of the external kickoff meeting and during the implementation process. Key parameters shall
be identified and explored prior to the development of the adaptive control configuration plan.
After fully understanding the project objectives, Rhythm Engineering’s
project engineers shall begin building an In|Sync configuration customized to
the specific characteristics of the corridor. A configuration is a set of
parameters that calibrate In|Sync to best achieve project goals and objectives.
Rhythm’s project engineers shall develop and test the In|Sync configuration
before it is deployed. Once testing is completed, the configuration file shall be
sent to the In|Sync processor using CentralSync, the complimentary
configuration software included with In|Sync.
Rhythm Project Engineer On-Site
To ensure that making the switch to In|Sync adaptive traffic control is a positive experience for agency personnel
and motorists, a Rhythm Engineering project engineer shall be onsite at the deploying agency’s office and at project
intersections during the adaptive turn-on. The engineer shall stay onsite for several days, driving the In|Sync
intersections multiple times with agency representatives, fine-tuning the system as needed and providing training on
In|Sync user software.

SERIAL 15058-RFP
Task 5. Software Delivery
Software Licensing
In|Sync user software is included at no charge with the purchase of the In|Sync system. This software may be loaded
on to unlimited work stations, and there are no software costs or fees for doing this. In|Sync user software has two
components:
(1) The In|Sync WebUI is a web browser-based tool for monitoring and adjustments, accessible on any
device. The WebUI provides camera views of the corridor, access to the individual In|Sync Processors
(i.e. each intersection) and detailed traffic data. In addition, county/city staff shall be trained to perform
status checks of adaptive operations, see In|Sync’s adaptive sequencing, check communications status,
and place manual calls to override the adaptive traffic control. Data are automatically stored in each
processor for the previous 30 days, including traffic counts, delay, and queue length. Data can also be
archived for future use using a simple FTP archival tool.
(2) CentralSync is a Windows-based program used for creating In|Sync adaptive configurations.
Training shall be conducted outlining CentralSync’s features, including time-space diagram views,
editing of progression protocols, geographic mapping of intersections, adjustments to phasing, and
viewing and editing of other configuration settings. Adaptive configuration modifications can be
uploaded to and downloaded from the corridor remotely throughout the day.
WebUI
In|Sync WebUI is a web browser-based tool for monitoring and adjustments. The WebUI provides camera views of
the corridor, access to the individual In|Sync Processors (i.e. each intersection) and detailed traffic data. In addition,
county/city staff shall be trained to perform status checks of adaptive operations, see In|Sync’s adaptive sequencing,
check communications status, and place manual calls to override the adaptive traffic control. Data are automatically
stored in each processor for the previous 30 days, including traffic counts, delay, and queue length. Data can also be
archived for future use using a simple FTP archival tool.
CentralSync
CentralSync is a Windows-based program used for creating In|Sync adaptive configurations. Training shall be
conducted outlining CentralSync’s features, including time-space diagram views, editing of progression protocols,
geographic mapping of intersections, adjustments to phasing, and viewing and editing of other configuration
settings. Adaptive configuration modifications can be uploaded to and downloaded from the corridor remotely
throughout the day.

SERIAL 15058-RFP
Screenshots of the CentralSync interface are shown on the following page.
CentralSync enables engineers to easily and quickly create, modify and deploy traffic management variables and
strategies using a map-based interface. Modifications can be uploaded and downloaded remotely by the operator.
CentralSync features include
 time-space diagram views
 editing of progression protocols
 geographic mapping of intersections
 adjustments to phasing
 viewing and editing of configuration settings.

SERIAL 15058-RFP
CentralSync System Requirements
1. Operating System: Windows XP or later
2. Web Browser: Internet Explorer 7 or later
3. Hard Disk Space: 12MB
4. Device: Any PC device running Windows XP
5. (256MB for XP, 1GB for Windows 7 32bit, 2GB for Windows 64bit)
6. Display: 1024x768 or larger required, 1280x1024 or larger recommended
Database Development and Archival
In|Sync automatically records and logs turning counts and delay data. Each In|Sync processor at each intersection
keeps a running total of all movements for the past 30 days. This data is displayed in the WebUI, and is also
available for one-time or recurring download in the form of csv files.
A sample .csv history file is shown in the image below. Each row indicates a change from one phase pair to another,
and the queue and first-vehicle delay for each movement are shown across the columns.

SERIAL 15058-RFP
Task 6. Support
Project Moves into Support Mode
After the In|Sync system is fully implemented and accepted by the county/city, the corridor moves into Support
Mode. Rhythm Engineering’s project engineers and technicians provide continual ongoing operational support
around the clock. Day-to-day operation of the system requires minimal staff involvement. Detailed information on
warranty and maintenance support, both provided for five years, can be found in the following sections of this
report.
Limited calibration is needed to maintain operations with the In|Sync system because the system chooses its own
sequencing and equitable distribution of green time. This process can be thought of as having a new micro “timing
plans” generated every “cycle” at every intersection independently based on live measurements without transition.
The system’s adaptive capabilities shall minimize the operational load for agency staff.
Testing Plan & System Acceptance
Rhythm Engineering has worked with many different agencies to develop test plans for testing and evaluating the
In|Sync system. Following are a specific examples where robust system testing plans were created and put to use.
 Florida Department of Transportation District 4, Palm Bch Co, FL, Okeechobee Blvd Corridor
 City of Chattanooga, TN, Route 153 Corridor
Upon receiving notice to proceed, Rhythm engineers shall coordinate with agency staff to craft a customized test
plan document, using the previously completed test plan documents cited above as a template. The test plan
document shall ensure the testing of the In|Sync system and verification that project objectives, as defined by agency
staff, are met or exceeded. The test plan shall also help demonstrate that the features and functionality described in
this proposal are present and working properly at all project intersections.
A few example pages of test plan items are shown on the following pages to showcase what a test plan would look
like. Agency staff feedback is critical to allow Rhythm to construct the best possible test plan for achieving the most
important project objectives.
Example Test Plans
1. Connecting & Testing In|Sync:
In|Sync is an overlay system in which the In|Sync processor submits detector calls into the controller while the
controller is running in its’ free mode configuration. The controller shall receive standard detector calls from In|Sync
through the In|Sync ABC-Y or SDLC cable which connects the existing cabinet’s detector inputs. The interface shall
be tested by submitting detector calls from In|Sync into the controller and testing calls to the traffic controller. The
controller shall confirm calls from In|Sync via the Naztec’s detector call status window.
1. Click on Manual Call to send call to the controller
2. Verify In|Sync call from the controller window

SERIAL 15058-RFP
Connecting In|Sync and Testing In|Sync (if controller uses C1 cabling):
In|Sync is an overlay system in which the In|Sync processor submits detector calls into the controller while the
controller is running in its’ free mode configuration. The controller shall receive standard detector calls from In|Sync
through the In|Sync C1-Y cable which connects the existing cabinet’s C1 cable. The interface shall be tested by
submitting detector calls from In|Sync into the controller and testing calls to the traffic controller. The controller

SERIAL 15058-RFP
shall confirm calls from In|Sync via the detector call status window.
Test Case ID: 1
Test Case Name: Connecting In|Sync and Testing In|Sync Checklist & Acceptance
Test Objective: To confirm In|Sync shall interface with Naztec ATC or 2070 controllers.
Requirements:  All parties are present,  Naztec controller is in “free mode”,  In|Sync is fully installed
Tested By: ____________________________________________________
Test Date: _____________________________________________________
Step Action Expected Result(s) Pass Problem/Issue Log
1 Log on to Web UI Web UI webpage loads
2 Enable manual controls Phase controls opens
3 Select phase to actuate Controller responds to call
4 Disable manual controls Phase controls close

SERIAL 15058-RFP
2. Testing In|Sync’s security functionalities:
In|Sync has a built in security model that can be customized by intersection. The user can create credentials with
configured permissions. For example, a certain credential may have view only rights; another may have full Web UI
access, and one may have full Web UI and CentralSync access.
In|Sync also reports invalid login attempts to detect if malicious login attempts are occurring.
Test Case ID: 2
Test Case Name: Testing In|Sync’s Security Functionalities
Test Objective: To demonstrate In|Sync’s security functionalities
Requirements:  All parties are present,  Intersection is fully installed  Test shall occur at TMC, Intersection, or
test intersection,  Web browser with network access to intersection
Tested By: ____________________________________________________
Test Date: _____________________________________________________

SERIAL 15058-RFP
Step Action Expected Result(s) Pass Problem/Issue Log
Browse to an intersection using a
web browser by typing in the IP In|Sync Web UI login screen shall
1
address of the intersection preceded display
by http://
In|Sync Web UI shall log in the user
2 Enter in the user credentials supplied
as inputted
Navigate to the “Account” pull-out The Web UI shall display the current
3
menu and select “Edit Users” configured user credentials
Click the pencil icon to edit a user or
In|Sync shall bring up the Edit/New
4 click “New User” to create a new
User Window
user
Click Add/Save to finish the user In|Sync saves the user for the
5
credential setup. currently logged on to intersection
Click “Propagate Users” to propagate
In|Sync shall propagate the changes
6 the configured users to all
made to all intersections
intersections on the corridor

SERIAL 15058-RFP
3. Testing adaptive operations when detectors fail:
In|Sync handles detector failure by using historical green split information and serving the proper phases until the
detector is operational. This operation is called historical mode and is indicated by displaying a “Fog Mode” or
“Unresponsive Camera” icon (see below) for the respective approach on the Web UI. The occurrence of fog mode
triggers the respective processor to send an email or text message alert to the user indicating a video detection
camera is compromised based on analysis of the fog zones. If there is no response from the IP address associated
with the video detection camera then an “Unresponsive Camera” icon (see below) shall display on the Web UI.
During historical mode, In|Sync shall schedule green time based on the historical green splits for that particular 15
minute period and day of week over the last 4 weeks. When the camera view is no longer compromised or the
camera becomes responsive, In|Sync shall automatically come out of historical mode. There is no need to jump in
and out of adaptive and non-adaptive operation when a detector fails.
Test Case ID: 3 Fog Mode Icon Unresponsive Camera Icon
Test Case Name: Testing adaptive operations test when detectors fail
Test Objective: To confirm that In|Sync goes into historical mode when a detector has failed.
Requirements:  All parties are present,  In|Sync is fully installed with network communications established, 
DIN (Power) Relay fully installed at all intersections,  Test shall occur at intersection location or at TMC.
Tested By: ____________________________________________________
Test Date: _____________________________________________________
Step Action Expected Result(s) Pass Problem/Issue Log
Ensure In|Sync adaptive Traffic is being served
1 operations are functioning according to In|Sync’s Web UI
normally scheduler.
2 Log in to the In|Sync WebUI WebUI page loads
Log in to the DIN Relay
3 DIN Relay WebUI page loads
WebUI
Remove power from a
In|Sync WebUI shall display a
camera remotely using the
4 stale image on the respective
DIN Relay to replicate a
camera image
failed detector
Observe WebUI video to Phases associated with the
5 verify service of approach failed detector shall still be
with failed detector serviced
Supply power back to the In|Sync WebUI begins
6 camera using the DIN Relay processing video after camera
interface goes through boot up process

SERIAL 15058-RFP
4. Testing alarms to user-specified recipients
Failure can be managed by several means. Notifying the user-defined recipients can be done through In|Sync
 Enable Notifications
1) Add & Enter Recipient
4) Send Test Email
2) Set Notification Times
for Recipients
3) Configure Alarms to be Sent
generated alarms as shown below:

SERIAL 15058-RFP
In|Sync Kiosk Advanced Tab
In|Sync Application Email Notifications Window

SERIAL 15058-RFP
Test Case ID: 4
Test Case Name: Testing alarms to user-specified recipients
Test Objective: To confirm In|Sync’s to alarms to user-specified recipients
Requirements:  All parties are present,  All In|Sync intersections in group are fully installed with network
communications established,  Test shall occur at intersection locations or at TMC,  Use current CentralSync
configuration,  Separate PC or laptop (if test is conducted at the intersection).
Tested By: ____________________________________________________
Test Date: _____________________________________________________
Step Action Expected Result(s) Pass Problem/Issue Log
Load project’s respective CentralSync
CentralSync loads project’s
1 configuration on the separate PC or
configuration
laptop
The email notifications windows
Open the Email Notifications window
2 as displayed on the previous
in CentralSync
page shall display
Recipient information should
3 Setup email settings for recipient
show up in subscriber’s window
All intersections along the
Send CentralSync configuration to the
4 corridor shall update the email
field
notification settings
Log in to the intersection Kiosk by
5 logging in to the IP address through Test email shall be received
RDP
Navigate to In|Sync by clicking the
6 “Advanced” tab and selecting In|Sync application shall display
“In|Sync”
Click “Notifications” to bring up the In|Sync notification windows
7
notifications windows shall display
Verify or enter the email server
Test email received in the
8 settings in the “SMTP Settings” tab
accounts inbox
and send a test email
System Upgradability & Maintainability
In|Sync is easy to deploy, operate and maintain. It is compatible with existing systems. When the agency desires to
expand the system to include additional intersections, additional In|Sync systems can be added one-by-one, in
groups, or any combination of intersections and corridors. Adjustments to the configuration files are included at no
charge as part of the ongoing support that comes with the In|Sync system. Additionally, warrantied systems receive
the latest software releases.
Rhythm Engineering is positioned at the forefront of the adaptive technology. We reinvest over 20 percent of our
resources into Research and Development (R&D). R&D expense has averaged $1,250,000/ year in development
costs over previous three years. For 2015, we’re budgeting just over $3 million in development costs, which is
roughly 30% of our budgeted expense for 2015. At our core, Rhythm Engineering is a company that fuses the latest
technology with traffic infrastructure. As technology evolves, we continue to improve and modify our system.
Training personnel on how to effectively use In|Sync is simple and straightforward. This helps makes the system
efficient to use among personnel within your agency, even as things change and expand. In addition to on-site and
on-call training and support, Rhythm continues to expanding its website and video training library to support partner
agencies.

SERIAL 15058-RFP
Project Schedule
Include a project schedule indicating when the elements of the work shall be completed and when deliverables, if
any, shall be provided.
Rhythm Engineering shall completely deploy the In|Sync® adaptive system within the agreed-upon time from the
receipt of a project purchase order. It is assumed that all the signals to be outfitted with In|Sync® shall be
operational and ready for equipment installation, including Ethernet connectivity and wiring completion.
The Operations team at Rhythm engineering employees a staff 18 technicians, engineers, and project managers.
Project managers utilize the latest in project management tools and technology to schedule and deploy In|Sync
systems effectively and on schedule. Once a purchase order is received, project timelines are built out by the project
manager and communicated to all parties including agency contacts, installers, and other contractors. As of
September, 2015, the deployment schedule for current deployments is shown below.
More U.S. traffic agencies trust In|Sync than any other adaptive traffic control system. More than 4 million vehicles
drive through In|Sync intersections each day, allowing millions of motorists to enjoy the benefits of better, smarter
traffic flow.
Deployment Process
Rhythm Engineering shall completely deploy this In|Sync adaptive system within a mutually-agreed upon period of
time that per the county/city’s requirements. It is assumed that all the signals to be outfitted with In|Sync shall be
operational and ready for equipment installation, including Ethernet connectivity and wiring completion. Any delays
in implementation outside of Rhythm Engineering’s control are excluded from this timeframe.

SERIAL 15058-RFP
The following image and table describe Rhythm Engineering’s typical process from taking a project from kick-off
through activation and finally into support mode.
Data Procurement Equipment Detector Adaptive Support
Gathering & & Shipping Installation Mode Turn-on & Mode
Kickoff Configuration
RAM – Regional Account Manager RPM – Rhythm Project Manager
RQA – Rhythm Quality Assurance SOWQ – Statement of Work/Quote
PPM – Partner (Client) Project Manager PNA – Partner (Client) Network Admin
Step Description
1 Data Gathering / Kickoff
2 PPM sends Purchase Order to RAM
3 RAM hosts Internal Kickoff Meeting
4 RAM reports project boundaries & project goals
5 RPM creates project schedule
6 RAM reviews significant project details
7 RAM reports location of relevant documentation
8 RAM introduces RPM to external parties
9 RPM confirms with PPM the accuracy of SOWQ
10 RPM requests IP addresses from PNA
11 External Kickoff Meeting
12 Contractor reviews cabinet hardware on site, determines size and application compatibility
13 RPM informs PPM of projected Ship Date
14 RPM creates detailed list of equipment Rhythm shall provide (intersection by intersection)
15 RPM (or Contractor) requests networking details from PPM
16 RPM sends RQA manager equipment list to order
17 RQA places order with Rhythm equipment manufacturer
18 Procurement & Shipping
19 Rhythm Supply & Operations personnel configure and test equipment
20 RQA personnel box and ship equipment
21 Rhythm Admin sends equipment invoice to client
22 Rhythm Technician pings network devices to confirm coms up
23 RPM confirms Technician travel date with client and contractor
24 Equipment Installation
25 [presuming contractor has prior experience] Contractor pulls camera cable, mounts cameras
26 Rhythm Technician arrives on site, trains contractor and client on installation
27 Contractor installs and connects all cabinet equipment
28 RPM confirms all communications (local & global) are functioning properly
29 Detector Mode
30 Rhythm Technician and Contractor set camera views and draws detection zones
31 All Rhythm equipment is installed, connected and configured, processor is in “Detector Mode”
32 The existing controller is controlling the intersection while In|Sync collects turning movement
data
33 Count data is collected by the In|Sync processor for 2-3 weeks
34 Adaptive Turn-on & Configuration
35 Rhythm Engineer builds configuration file
36 Rhythm Engineer travels to site, switches system from “Detector Mode” to “Adaptive Mode”
37 Rhythm Engineer returns to home office, reviews and adjusts system remotely
38 Rhythm Engineer requests RIDOT's confirmation that project objectives have been achieved
39 Support Mode

SERIAL 15058-RFP
Deliverables
Fully describe deliverables to be submitted under the proposed contract.
As described in the Work Plan section of this report, Rhythm Engineering shall provide key deliverables in support
of this adaptive traffic singal system deployment, including:
 Training documents (Task 1)
 On-site training classes (Task 1)
 Hardware and cabling (Task 2)
 Access to software, including WebUI & CentralSync (Task 5)
 Test plan and system acceptance documents (Task 6)
 Warranty documentation (Task 6)
 Project Schedule & Project Management documentation
Area#2
Map of the Corridor
Project Intersection Detail
Proposed Project Intersection(s) are as follows: Camera Mounting
Images
10- Bell Road & Del Webb/99th Ave
Existing and client supplied equipment (please notify if incorrect):
 TS2-Type 2 in a TS2-Type 2
 Approach(es): 4
 Existing Detection:
 Interconnect Communication Type: Fiber
 Interconnect Communication Deployed: Yes
Rhythm Engineering - Supplied Equipment
 System Type: 1 In|Sync processor(s) NB Camera: Mast Arm Mount
 Connection Type: SDLC SB Camera: Mast Arm Mount
WB Camera: Mast Arm Mount
 Quantity of Cameras: 4 EB Camera: Mast Arm Mount
 Pedestrian Module:
 Ethernet Repeaters Needed: TBD
 Controller Mode/Pin Configuration:
 Monitor(s)/Keyboard(s): Yes
Intersection Notes Pertinent to In|Sync Development:
 Camera Mounting Hardware Responsibility: Rhythm Engineering
 Intersection Notes:

SERIAL 15058-RFP
20- Bell Road & 98th Ave
Existing and client supplied equipment (please notify if incorrect):
 TS2-Type 2 in a TS2-Type 2
 Approach(es): 4
 Existing Detection:
 Interconnect Communication Type: Fiber
 Interconnect Communication Deployed: Yes
Rhythm Engineering - Supplied Equipment
 System Type: 1 In|Sync processor(s) NB Camera: Mast Arm Mount
SB Camera: Mast Arm Mount
 Connection Type: SDLC WB Camera: Mast Arm Mount
 Quantity of Cameras: 4 EB Camera: Mast Arm Mount
 Pedestrian Module:
 Ethernet Repeaters Needed: TBD
 Controller Mode/Pin Configuration:
 Monitor(s)/Keyboard(s): Yes
Intersection Notes Pertinent to In|Sync Development:
 Camera Mounting Hardware Responsibility: Rhythm Engineering
 Intersection Notes:
30- Bell Road & Lindgren Ave
Existing and client supplied equipment (please notify if incorrect):
 TS2-Type 2 in a TS2-Type 2
 Approach(es): 4
 Existing Detection:
 Interconnect Communication Type: Fiber
 Interconnect Communication Deployed: Yes
Rhythm Engineering - Supplied Equipment
 System Type: 1 In|Sync processor(s) NB Camera: Mast Arm Mount
SB Camera: Mast Arm Mount
 Connection Type: SDLC WB Camera: Mast Arm Mount
 Quantity of Cameras: 4 EB Camera: Mast Arm Mount
 Pedestrian Module:
 Ethernet Repeaters Needed: TBD
 Controller Mode/Pin Configuration:
 Monitor(s)/Keyboard(s): Yes
Intersection Notes Pertinent to In|Sync Development:
 Camera Mounting Hardware Responsibility: Rhythm Engineering
 Intersection Notes:
40- Bell Road & 92nd Ave
Existing and client supplied equipment (please notify if incorrect):
 TS2-Type 2 in a TS2-Type 2
 Approach(es): 3
 Existing Detection:
 Interconnect Communication Type: Fiber
 Interconnect Communication Deployed: Yes
Rhythm Engineering - Supplied Equipment
 System Type: 1 In|Sync processor(s) NB Camera:
SB Camera: Mast Arm Mount
 Connection Type: SDLC WB Camera: Mast Arm Mount
 Quantity of Cameras: 3 EB Camera: Mast Arm Mount
 Pedestrian Module:
 Ethernet Repeaters Needed: TBD
 Controller Mode/Pin Configuration:
 Monitor(s)/Keyboard(s): Yes
Intersection Notes Pertinent to In|Sync Development:
 Camera Mounting Hardware Responsibility: Rhythm Engineering
 Intersection Notes:

SERIAL 15058-RFP
50- Bell Road & 91st Ave
Existing and client supplied equipment (please notify if incorrect):
 TS2-Type 2 in a TS2-Type 2
 Approach(es): 4
 Existing Detection:
 Interconnect Communication Type: Fiber
 Interconnect Communication Deployed: Yes
Rhythm Engineering - Supplied Equipment
 System Type: 1 In|Sync processor(s) NB Camera: Mast Arm Mount
SB Camera: Mast Arm Mount
 Connection Type: SDLC WB Camera: Mast Arm Mount
 Quantity of Cameras: 4 EB Camera: Mast Arm Mount
 Pedestrian Module:
 Ethernet Repeaters Needed: TBD
 Controller Mode/Pin Configuration:
 Monitor(s)/Keyboard(s): Yes
Intersection Notes Pertinent to In|Sync Development:
 Camera Mounting Hardware Responsibility: Rhythm Engineering
 Intersection Notes:
60- Bell Road & 87th Ave
Existing and client supplied equipment (please notify if incorrect):
 TS2-Type 2 in a TS2-Type 2
 Approach(es): 4
 Existing Detection:
 Interconnect Communication Type: Fiber
 Interconnect Communication Deployed: Yes
Rhythm Engineering - Supplied Equipment
 System Type: 1 In|Sync processor(s) NB Camera: Mast Arm Mount
SB Camera: Mast Arm Mount
 Connection Type: SDLC WB Camera: Mast Arm Mount
 Quantity of Cameras: 4 EB Camera: Mast Arm Mount
 Pedestrian Module:
 Ethernet Repeaters Needed: TBD
 Controller Mode/Pin Configuration:
 Monitor(s)/Keyboard(s): Yes
Intersection Notes Pertinent to In|Sync Development:
 Camera Mounting Hardware Responsibility: Rhythm Engineering
 Intersection Notes:
70- Bell Road & 84th Ave
Existing and client supplied equipment (please notify if incorrect):
 TS2-Type 2 in a TS2-Type 2
 Approach(es): 4
 Existing Detection:
 Interconnect Communication Type: Fiber
 Interconnect Communication Deployed: Yes
Rhythm Engineering - Supplied Equipment
 System Type: 1 In|Sync processor(s) NB Camera: Mast Arm Mount
SB Camera: Mast Arm Mount
 Connection Type: SDLC WB Camera: Mast Arm Mount
 Quantity of Cameras: 4 EB Camera: Mast Arm Mount
 Pedestrian Module:
 Ethernet Repeaters Needed: TBD
 Controller Mode/Pin Configuration:
 Monitor(s)/Keyboard(s): Yes
Intersection Notes Pertinent to In|Sync Development:
 Camera Mounting Hardware Responsibility: Rhythm Engineering
 Intersection Notes:

SERIAL 15058-RFP
80- Bell Road & L-101
Existing and client supplied equipment (please notify if incorrect):
 TS2-Type 2 in a TS2-Type 2
 Approach(es): 6
 Existing Detection:
 Interconnect Communication Type: Fiber
 Interconnect Communication Deployed: Yes
Rhythm Engineering - Supplied Equipment
 System Type: 2 In|Sync processor(s) NB Camera: Mast Arm Mount
SB Camera: Mast Arm Mount
 Connection Type: SDLC WB Camera: Mast Arm Mount
 Quantity of Cameras: 6 EB Camera: Mast Arm Mount
 Pedestrian Module: NB ADV Camera: Mast Arm Mount
 Ethernet Repeaters Needed: TBD SB ADV Camera: Mast Arm Mount
 Controller Mode/Pin Configuration:
 Monitor(s)/Keyboard(s): Yes
Intersection Notes Pertinent to In|Sync Development:
 Camera Mounting Hardware Responsibility: Rhythm Engineering
 Intersection Notes:
90- Bell Road & 83rd Ave
Existing and client supplied equipment (please notify if incorrect):
 TS2-Type 2 in a TS2-Type 2
 Approach(es): 4
 Existing Detection:
 Interconnect Communication Type: Fiber
 Interconnect Communication Deployed: Yes
Rhythm Engineering - Supplied Equipment
 System Type: 1 In|Sync processor(s) NB Camera: Mast Arm Mount
SB Camera: Mast Arm Mount
 Connection Type: SDLC WB Camera: Mast Arm Mount
 Quantity of Cameras: 4 EB Camera: Mast Arm Mount
 Pedestrian Module:
 Ethernet Repeaters Needed: TBD
 Controller Mode/Pin Configuration:
 Monitor(s)/Keyboard(s): TBD
Intersection Notes Pertinent to In|Sync Development:
 Camera Mounting Hardware Responsibility: Rhythm Engineering
 Intersection Notes:
100- Bell Road & 79th Ave
Existing and client supplied equipment (please notify if incorrect):
 TS2-Type 2 in a TS2-Type 2
 Approach(es): 4
 Existing Detection:
 Interconnect Communication Type: Fiber
 Interconnect Communication Deployed: Yes
Rhythm Engineering - Supplied Equipment
 System Type: 1 In|Sync processor(s) NB Camera: Mast Arm Mount
SB Camera: Mast Arm Mount
 Connection Type: SDLC WB Camera: Mast Arm Mount
 Quantity of Cameras: 4 EB Camera: Mast Arm Mount
 Pedestrian Module:
 Ethernet Repeaters Needed: TBD
 Controller Mode/Pin Configuration:
 Monitor(s)/Keyboard(s): Yes
Intersection Notes Pertinent to In|Sync Development:
 Camera Mounting Hardware Responsibility: Rhythm Engineering
 Intersection Notes:

SERIAL 15058-RFP
110- Bell Road & 77th Ave
Existing and client supplied equipment (please notify if incorrect):
 TS2-Type 2 in a TS2-Type 2
 Approach(es): 4
 Existing Detection:
 Interconnect Communication Type: Fiber
 Interconnect Communication Deployed: Yes
Rhythm Engineering - Supplied Equipment
 System Type: 1 In|Sync processor(s) NB Camera: Mast Arm Mount
SB Camera: Mast Arm Mount
 Connection Type: SDLC WB Camera: Mast Arm Mount
 Quantity of Cameras: 4 EB Camera: Mast Arm Mount
 Pedestrian Module:
 Ethernet Repeaters Needed: TBD
 Controller Mode/Pin Configuration:
 Monitor(s)/Keyboard(s): Yes
Intersection Notes Pertinent to In|Sync Development:
 Camera Mounting Hardware Responsibility: Rhythm Engineering
 Intersection Notes:
120- Bell Road & 75th Ave
Existing and client supplied equipment (please notify if incorrect):
 TS2-Type 2 in a TS2-Type 2
 Approach(es): 4
 Existing Detection:
 Interconnect Communication Type: Fiber
 Interconnect Communication Deployed: Yes
Rhythm Engineering - Supplied Equipment
 System Type: 1 In|Sync processor(s) NB Camera: Mast Arm Mount
SB Camera: Mast Arm Mount
 Connection Type: SDLC WB Camera: Mast Arm Mount
 Quantity of Cameras: 4 EB Camera: Mast Arm Mount
 Pedestrian Module:
 Ethernet Repeaters Needed: TBD
 Controller Mode/Pin Configuration:
 Monitor(s)/Keyboard(s): Yes
Intersection Notes Pertinent to In|Sync Development:
 Camera Mounting Hardware Responsibility: Rhythm Engineering
 Intersection Notes:
130- Bell Road & 73rd Ave
Existing and client supplied equipment (please notify if incorrect):
 TS2-Type 2 in a TS2-Type 2
 Approach(es): 4
 Existing Detection:
 Interconnect Communication Type: Fiber
 Interconnect Communication Deployed: Yes
Rhythm Engineering - Supplied Equipment
 System Type: 1 In|Sync processor(s) NB Camera: Mast Arm Mount
SB Camera: Mast Arm Mount
 Connection Type: SDLC WB Camera: Mast Arm Mount
 Quantity of Cameras: 4 EB Camera: Mast Arm Mount
 Pedestrian Module:
 Ethernet Repeaters Needed: TBD
 Controller Mode/Pin Configuration:
 Monitor(s)/Keyboard(s): Yes
Intersection Notes Pertinent to In|Sync Development:
 Camera Mounting Hardware Responsibility: Rhythm Engineering
 Intersection Notes:

SERIAL 15058-RFP
ATTACHMENT C-2
TECHNICAL REQUIREMENTS & RESPONSES
PROJECT AREA 2
Versio Project Area #2: Bell Proposer Response
n 2.1 Road and Loop 101
from 99th Avenue
through 73rd Avenue
Sys Level System Concept of Operations Meet Proposer Written Description of How Verification
Reqs of Requirements Need Statements from Requ Proposed System Fulfills Method
Refere Impor Final FHWA Model ireme Requirement
nce tance Documents, FHWA- nts
Numb HOP-11-027, Appendix (Yes
er B or
No)
1 1 Network
Characteristic
s
1.0-1 5 The ASCT 4.2.0-1 Yes In|Sync processors communicate via a Demonstrated
shall control a distributed network. When a by Numerous
minimum of 13 configuration is updated on one installations
signals processor, all other processors receive consisting of
concurrently the update. In|Sync can control 13+ signals in
significantly more than 50 signals operation.
concurrently.

SERIAL 15058-RFP
The system operators
needs to eventually
adaptively control up to
13 signals from one or
more of the participating
agency's TMCs. The
adaptive capability shall
be provided for signals
operated by MCDOT,
Peoria, ADOT, and
Glendale. The Peoria
TMC is also an ADOT
alternate traffic operations
center and is located at
9875 N. 85th Avenue,
Peoria, AZ. The MCDOT
TMC is located at 2919
W. Durango Street,
Phoenix, AZ. The ADOT
TOC is located at 2302
West Durango Street,
Phoenix, AZ 85009. The
Glendale TMC is located
at 9645 N. 59th Avenue,
Glendale, AZ.
1.0-2 5 The ASCT 4.2.0-2 Yes Signals are grouped together in the Demonstrated
shall support In|Sync system.
groups of The system operator needs
signals. to be able to adaptively
control up to 4
independent groups of
signals. While the signals
are relatively close, the

SERIAL 15058-RFP
traffic conditions are such
that they shall normally be
coordinated as two (or
more) separate and
independent groups.
4.2.0-3
The system operator needs Yes Intersection groupings may be edited at Demonstrated
to vary the number of any time by a user with network access
signals in an adaptively and proper administrative credentials.
controlled group to
accommodate the
prevailing traffic
conditions.
1.0- 5 The boundaries 4.2.0-2 Yes The agency has full credentials to make Demonstrated
2.0-1 surrounding changes to In|Sync and customize signal
signal controller parameters.
controllers that The system operator needs
operate in a to be able to adaptively
coordinated control up to 4
fashion shall independent groups of
be defined by signals. While the signals
the user. are relatively close, the
1.0- 5 The ASCT traffic conditions are such Yes In|Sync can control any number of Demonstrated
2.0-2 shall control a that they shall normally be signal groups.
minimum of 4 coordinated as two (or
groups of more) separate and
signals independent groups.
1.0- 5 The size of a 4.2.0-3 Yes In|Sync can control any number of Demonstrated
2.0-3 group shall signals within a group.
range from 1 to The system operator needs
13 signals. to vary the number of
signals in an adaptively
controlled group to

SERIAL 15058-RFP
accommodate the
prevailing traffic
conditions.
1.0- 5 Each group 4.2.0-2 Yes A group of In|Sync signals can be set to Demonstrated
2.0-4 shall operate operate independently of all other
independently groups.
The system operator needs
to be able to adaptively
control up to 4
independent groups of
signals. While the signals
are relatively close, the
traffic conditions are such
that they shall normally be
coordinated as two (or
more) separate and
independent groups.
1.0- 4 The boundaries 4.2.0-3 Yes In|Sync signals are organized into Demonstrated
2.0- surrounding groups. Each group of signals is
5.0-1 signal governed by a configuration file which
controllers that is copied to every processor in that
operate in a group. The configuration running at a
coordinated given time of the day is defined by the
fashion shall time of day schedule defined within that
be altered by configuration file.
the system The system operator needs
according to a to vary the number of
time of day signals in an adaptively
schedule. (For controlled group to
example: this accommodate the
may be prevailing traffic
achieved by conditions.
assigning

SERIAL 15058-RFP
signals to
different
groups or by
combining
groups.)
1.0- 4 The boundaries Yes Automatically switching into alternate Demonstrated
2.0- surrounding operations (i.e., event triggering) is an
5.0-2 signal important feature that is available with
controllers that In|Sync. In|Sync shall receive a binary
operate in a (on/off) signal from a device or
coordinated controller, which shall trigger the
fashion shall alternate configuration.
be altered by
the system
according to
traffic
conditions.
(For example:
this may be
achieved by
assigning
signals to
different
groups or by
combining
groups.)
1.0- 5 The boundaries Yes System users with network access and Demonstrated
2.0- surrounding proper credentials may manually change
5.0-3 signal configurations remotely at any time.
controllers that
operate in a
coordinated
fashion shall

SERIAL 15058-RFP
be altered by
the system
when
commanded by
the user.
2 2 Type of
Operation
2.1 2.1 General
2.1.1 2.1.1 Mode of
Operation
2.1.1.0 5 The ASCT 4.14.0-1 Yes In the rare case that an In|Sync Demonstrated
-2 shall operate processor should fail, all detector calls
non-adaptively are passed directly through to the
when the controller, which shall control the signal
adaptive non-adaptively.
control The system operator needs
equipment to have a fallback state
fails. that allows coordination
2.1.1.0 5 The ASCT using a common cycle Yes During detector failure, In|Sync accesses Demonstrated
-2.0-1 shall operate length for all signals historical data collected from previous
non-adaptively within a coordinated four weeks of operation. In|Sync
when a user- group, without causing estimates the traffic demand for the day-
specified disruption to traffic flow, of-week and time-of-day (15-minute
detector fails. in the event of equipment, interval) and serves traffic optimally.
communications and Non-adaptive operations can also be
software failure. For accomplished remotely.
example, if the

SERIAL 15058-RFP
2.1.1.0 5 The ASCT communications link to Yes During detector failure, In|Sync accesses Demonstrated
-2.0-2 shall operate the Peoria TMC fails, a historical data collected from previous
non-adaptively defined boundary of the four weeks of operation. In|Sync
when the ASCT could continue to estimates the traffic demand for the day-
number of operate adaptively. of-week and time-of-day (15-minute
failed detectors Alternatively, if the interval) and serves traffic optimally.
connected to a communications link to Non-adaptive operations can also be
signal the Glendale TMC fails, a accomplished remotely.
controller defined boundary of the
exceeds a user- ASCT could operate non-
defined value. adaptively based on
2.1.1.0 5 The ASCT system operator Yes During detector failure, In|Sync accesses Demonstrated
-2.0-3 shall operate preference. historical data collected from previous
non-adaptively four weeks of operation. In|Sync
when the estimates the traffic demand for the day-
number of of-week and time-of-day (15-minute
failed detectors interval) and serves traffic optimally.
in a group Non-adaptive operations can also be
exceeds a user- accomplished remotely.
defined value.
2.1.1.0 5 The ASCT Yes The In|Sync architecture is distributed Demonstrated
-2.0-4 shall operate and therefore, the intelligence resides
non-adaptively locally at the intersection. The global
when a user- optimization (signal synchronization)
defined reverts to historical data while the local
communication optimizer is not affected by the loss of
s link fails. communication.
2.1.1.0 5 The ASCT 4.7.0-3 Yes Users can command In|Sync to fall back Demonstrated
-3 shall operate to fully actuated mode or controller
non-adaptively based operations.

SERIAL 15058-RFP
when a user The system operator needs
manually to over-ride adaptive
commands the operation for a user-
ASCT to cease defined group which may
adaptively or may not be completely
controlling a contained within an
group of agency's jurisdiction.
signals. When operator is advised
of an incident that shall
increase demand, the
operator may select an
appropriate flush plan.
The operator shall
schedule an ending time
for the event. The flush
plan shall remain in place
until either the scheduled
end time passes or the
operator cancels the plan.
2.1.1.0 5 The ASCT 4.7.0-3 Yes A user can command In|Sync to Demonstrated
-4 shall operate “Detector Mode” remotely or on site. In
non-adaptively Detector Mode, In|Sync shall pass all
when a user detector calls to the controller, which
manually shall operate the signal non-adaptively.
commands the The system operator needs
ASCT to cease to over-ride adaptive
adaptive operation. When operator
operation. is advised of an incident
that shall increase
demand, the operator may
select an appropriate flush
plan. The operator shall
schedule an ending time

SERIAL 15058-RFP
for the event. The flush
plan shall remain in place
until either the scheduled
end time passes or the
operator cancels the plan.
2.1.1.0 5 The ASCT 4.7.0-2 Yes Non-adaptive configuration files can be Demonstrated
-5 shall operate created and set to run when desired via
non-adaptively the time of day schedule.
in accordance The system operator needs
with a user- to schedule pre-
defined time- determined operation by
of-day time of day. The Peoria
schedule. Sports Complex is located
south of Bell Road with
access from 83rd Avenue
or 75th Avenue. When an
event occurs (e.g.,
baseball game), its start
time is scheduled and the
end time is not predictable
(e.g., a baseball game that
may run from two to four
hours). The agency shall
program the system so
that at a scheduled time it
begins operation in a
mode that accommodates
the arrival of patrons to
the event. The schedule
shall allow normal
operation while the event
is in progress and there is
little associated traffic.

SERIAL 15058-RFP
The schedule shall also
place the system in an
appropriate mode of
operation to accommodate
patrons leaving the event.
An operator shall be able
to manually implement
the appropriate signal
operation when the event
ends.
4.7.0-3
The system operator needs Yes A user with appropriate administrative Demonstrated
to over-ride adaptive credentials may manually call any
operation. When operator adaptive or non-adaptive configuration
is advised of an incident to run at any time for any duration.
that shall increase
demand, the operator may
select an appropriate flush
plan. The operator shall
schedule an ending time
for the event. The flush
plan shall remain in place
until either the scheduled
end time passes or the
operator cancels the plan.
2.1.1.0 5 The ASCT 4.17.0-2 Yes Automatically switching into alternate Demonstrated
-6 shall operate operations (i.e., event triggering) is an
non-adaptively important feature that is available in
when In|Sync. In|Sync shall receive a binary
commanded by (on/off) signal from a device or
an external controller, which shall trigger the
system alternate configuration. This alternate
process. configuration can be an adaptive or non-

SERIAL 15058-RFP
adaptive configuration.
The system needs to react
to commands issued by an
external decision support
system or an Integrated
Corridor Management
system, commanding the
ASCT to initiate a flush
plan. This flush plan shall
remain in operation until
the command from the
external source is
removed.

SERIAL 15058-RFP
2.1.1.0 5 The ASCT 4.1.0-1.0-1 Yes If applicable, the user defines a dynamic Demonstrated
-7 shall alter the period length used to maintain side
adaptive street service. The period length shifts
operation to according to the overall demand along
achieve the corridor and the local intersection
required adaptively selects how to distribute
objectives in green time to best facilitate progression
user-specified without inducing transition events seen
conditions. with cycle, split, and offset based
systems. With In|Sync, the user does not
have to define all possible timing plans
to implement adaptive operations,
significantly reducing the work load.
The state of the signal controller is
altered by In|Sync submitting holds and
force-offs. The user can still manipulate
the controller’s operation through the
use of their central system software if
desired.
The objective of the
coordination shall be to
maximize the throughput
along the coordinated
route. This may involve a
tradeoff that increases
delay to cross streets and
turning movements in
order to maximize the
green time provided to
coordinated traffic flows.
4.1.0-1.0-3

SERIAL 15058-RFP
The operator shall be able Yes The agency and Rhythm Engineering Demonstrated
to define for each group of define a dynamic period range used to
intersections the maintain side-street service. The period
appropriate operational length shifts according to the overall
objective. For example, demand along the corridor and the local
near the freeway intersection adaptively selects how to
interchange or in a distribute green time to best facilitate
location with heavy progression without inducing transition
turning movements, the events seen with cycle, split, and offset
queue management based systems. With In|Sync, the user
strategy may be specified, does not have to define all possible
while on an arterial with timing plans to implement adaptive
long signal spacing the operations, significantly reducing the
smooth flow objective work load. The state of the signal
may be specified. controller is altered by In|Sync
submitting holds and force-offs. The
user can still manipulate the controller’s
operation through the use of their central
system software if desired.
4.1.0-3
The system operator needs Yes In|Sync’s adaptive configurations Demonstrated
to change the operational feature the ability to adjust service times
strategy (for example, based on real-time traffic conditions,
from smooth flow to utilizing a set of baseline parameters,
maximizing throughput or extending or truncating coordinated
managing queues) based movements and period lengths based on
on changing traffic demand and delay.
conditions. For example,
an incident is blocking the
freeway and traffic is
diverting onto the arterial.
The system shall
adaptively respond and

SERIAL 15058-RFP
the off-ramp shall become
the coordinated phase.
2.1.1.0 5 When current 4.1.0-1.0-1 Yes In|Sync’s adaptive configurations Demonstrated
-7.0-1 measured feature the ability to adjust service times
traffic based on real-time traffic conditions,
conditions utilizing a set of baseline parameters,
meet user- extending or truncating coordinated
specified movements and period lengths based on
criteria, the demand and delay.
ASCT shall The objective of the
alter the state coordination shall be to
of the signal maximize the throughput
controllers, along the coordinated
maximizing route. This may involve a
the throughput tradeoff that increases
of the delay to cross streets and
coordinated turning movements in
route. order to maximize the
green time provided to
coordinated traffic flows.
4.1.0-3
The system operator needs Yes In|Sync adjusts its sequencing based on Demonstrated
to change the operational real-time information based on user-
strategy (for example, defined parameters before the arrival of
from smooth flow to the coordinated movement at each
maximizing throughput or intersection. This bidirectionally
managing queues) based maximizes throughput of the
on changing traffic coordinated route.
conditions. For example,
an incident is blocking the
freeway and traffic is
diverting onto the arterial.

SERIAL 15058-RFP
The system shall
adaptively respond and
the off-ramp shall become
the coordinated phase.
2.1.1.0 3 When current 4.1.0-1.0-4 Yes Real-time analysis of demand and delay Demonstrated
-7.0-2 measured addresses most storage issues, and in
traffic instances where a period length does not
conditions leave enough time to service total
meet user- demand, In|Sync raises the period
specified length. (see response 2.1.1.0-7.0-1)
criteria, the The objective of the
ASCT shall coordination shall be to
alter the state manage the lengths of
of signal queues stored at critical
controllers, locations within the
preventing coordinated group so that
queues from long queues do not block
exceeding the upstream intersections or
storage otherwise reduce the
capacity at capacity available during
user-specified the green phases. This
locations. shall involve controlling
phase lengths so that the
size of platoons entering a
downstream block do not
exceed the storage length
if the platoon shall be
stopped. It shall also
involve control of offsets
and phase lengths so that
queues may be stored in
locations where they shall
not adversely affect

SERIAL 15058-RFP
capacity of the system.
Queues often overflow
from the westbound left
turn bay at 84th Avenue
and Bell and at the
eastbound left turn bay at
83rd Avenue and Bell
during the PM peak.
2.1.1.0 3 When current 4.1.0-1.0-3 Yes Real-time analysis of both demand and Demonstrated
-7.0-3 measured delay, In|Sync provides the exact
traffic amount of green time necessary to fully
conditions service a movement without wasting
meet user- green time on a movement with no
specified demand.
criteria, the The operator shall be able
ASCT shall to define for each group of
alter the state intersections the
of signal appropriate operational
controllers objective. For example,
providing near the freeway
equitable interchange or in a
distribution of location with heavy
green times. turning movements, the
queue management
strategy may be specified,
while on an arterial with
long signal spacing the
smooth flow objective
may be specified.
4.1.0-3
The system operator needs Yes In|Sync’s adaptive configurations Demonstrated
to change the operational feature the ability to adjust service times
strategy (for example, based on real-time traffic conditions,

SERIAL 15058-RFP
from smooth flow to utilizing a set of baseline parameters.
maximizing throughput or Users can also manually call alternate
managing queues) based configurations at any time, with proper
on changing traffic credentials from any internet-connected
conditions. For example, device.
an incident is blocking the
freeway and traffic is
diverting onto the arterial.
The system shall
adaptively respond and
the off-ramp shall become
the coordinated phase.
2.1.1.0 4 When current 4.1.0-1.0-2 Yes In|Sync adjusts its sequencing based on Demonstrated
-7.0-4 measured real-time information based on user-
traffic defined parameters before the arrival of
conditions the coordinated movement at each
meet user- intersection. This bidirectionally
defined maximizes throughput of the
criteria, the coordinated route.
ASCT shall Providing coordinated
alter the state bands along arterial roads
of signal to smooth the flow of
controllers traffic.
providing two- 4.1.0-3
way The system operator needs Yes In|Sync’s adaptive configurations Demonstrated
progression on to change the operational feature the ability to adjust service times
a coordinated strategy (for example, based on real-time traffic conditions,
route. from smooth flow to utilizing a set of baseline parameters.
maximizing throughput or Users can also manually call alternate
managing queues) based configurations at any time, with proper
on changing traffic credentials from any internet-connected
conditions. For example, device.
an incident is blocking the

SERIAL 15058-RFP
freeway and traffic is
diverting onto the arterial.
The system shall
adaptively respond and
the off-ramp shall become
the coordinated phase.
2.1.1.0 5 The ASCT 4.1.0-1.0-3 Yes In|Sync adjusts local and global Demonstrated
-8 shall provide optimization based on phase failures
maximum and using minimum phase times from the
minimum controller. Maximums (green
phase timing restrictions) can also be used, though
and cycle they often limit optimal service of the
lengths. intersection.
The operator shall be able
to define for each group of
intersections the
appropriate operational
objective. For example,
near the freeway
interchange or in a
location with heavy
turning movements, the
queue management
strategy may be specified,
while on an arterial with
long signal spacing the
smooth flow objective
may be specified.
4.10-1.0-6

SERIAL 15058-RFP
The system shall identify Yes In|Sync’s adaptive configurations Demonstrated
the critical intersection in feature the ability to adjust service times
the group (or the user based on real-time traffic conditions,
shall specify the critical utilizing a set of baseline parameters.
intersection), and Users can also manually call alternate
determine the appropriate configurations at any time, with proper
signal timing parameters credentials from any internet-connected
for that intersection (such device.
2.1.1.0 5 The ASCT as cycle length, phase Yes The maximum green time In|Sync shall Demonstrated
-8.0-1 shall provide a sequence, phase times). allocate to a phase is dependent on how
user-specified The primary determinant much demand exists on all other phases.
maximum of the cycle length shall In|Sync shall end a phase when the time
value for each be to accommodate traffic available before the next coordinated
phase and without phase failures on movement equals In|Sync’s estimate of
cycle length at critical movements that the time needed to serve all movements
each signal would adversely affect the with current demand.
controller. operation of other
2.1.1.0 5 The ASCT intersections or the Yes In|Sync does not use cycles. If demand Demonstrated
-8.0- shall not progress in the peak exists for one phase but no others,
1.0-1 provide a direction. If this cycle In|Sync shall keep that phase green until
phase length length is close to but demand exists on another phase. This is
longer that the lower than a "natural" a superior behavior than setting
maximum cycle length for the maximum phase lengths—which are
value. coordinated group, it shall only necessary because of ring-and-
select that cycle length. If barrier operations.
2.1.1.0 5 The ASCT a higher cycle length is Yes In|Sync is configured to provide user- Demonstrated
-8.0-2 shall provide a required for the critical specified minimum phase values at each
user-specified intersection, that cycle signal controller for safe operation.
minimum length shall be selected,
value for each within a user-specified
phase and range.
cycle length at
each signal

SERIAL 15058-RFP
controller.
2.1.1.0 5 The ASCT Yes In|Sync shall always serve a phase for at Demonstrated
-8.0- shall not least its minimum green time.
2.0-1 provide a
phase length
shorter than the
minimum
value.
2.1.1.0 5 The ASCT 4.1.0-4 Yes In|Sync automatically and adaptively Demonstrated
-9 shall detect adjusts local and global optimization
repeated based on phase failures within the
phases that do boundaries of the configuration.
not serve all The system shall
waiting determine the optimal
vehicles. order of phases to provide
(These phase the best coordination. If
failures may be the green time required for
inferred, such a left turn phase is longer
as by detecting the time required to
repeated max- service a queue fully
out.) occupying the left turn
2.1.1.0 5 The ASCT bay, and the queue would Yes In|Sync automatically and adaptively The data can
-9.0-1 shall alter overflow and block the adjusts local and global optimization be extracted
operations, to adjacent lane, the operator based on phase failures within the from the
minimize shall be able to specify the boundaries of the configuration. history logs.
repeated phase phase to operate twice for
failures. each occurrence of the
opposing through
movement, in order to
avoid queue overflow.
The user shall specify a

SERIAL 15058-RFP
maximum elapsed time
between successive
occurrences of a phase
when the phase is called.
The entire corridor may be
set by the operator to
operate as one coordinated
group. If the corridor is
divided into more than
one group, the system
may have the freedom to
operate it as one group
subject to user-specified
criteria, such as the
volume of traffic in the
peak direction exceeds a
threshold.
2.1.2 2.1.2
Allowable
Phases
2.1.2.0 5 The ASCT 4.9.0-1.0-6 Yes In|Sync may only skip a phase in the Demonstrated
-3 shall prevent current sequence when there is no
skipping a demand.
user-specified The ability to maintain
phase when the coordination with external
user-specified movements by preventing
phase sequence one or more phases being
is operating. skipped under certain
traffic conditions or signal
states.
2.1.2.0 5 The ASCT 4.9.0-1.0-6 Yes In|Sync shall always serve every phase Demonstrated
-4 shall prevent that has demand at least once per period
skipping a (i.e., once per cycle). No phase with

SERIAL 15058-RFP
user-specified demand shall be skipped.
phase based on
the state of a
user-specified The ability to maintain Yes In|Sync shall always serve every phase Demonstrated
external input. coordination with external that has demand at least once per period
movements by preventing (i.e., once per cycle). No phase with
one or more phases being demand shall be skipped.
skipped under certain
traffic conditions or signal
states.
4.17.0-2
The system needs to react Yes In|Sync’s adaptive configurations Demonstrated
to commands issued by an feature the ability to adjust service times
external decision support based on real-time traffic conditions,
system or an Integrated utilizing a set of baseline parameters.
Corridor Management Users can also manually call alternate
system, commanding the configurations at any time, with proper
ASCT to initiate a flush credentials from any internet-connected
plan. This flush plan shall device.
remain in operation until
the command from the
external source is
removed.
2.1.2.0 3 The ASCT 4.9.0-1.0-6 Yes In|Sync prevents skipping user-specified Demonstrated
-5 shall prevent phases by allowing and disallowing
skipping a certain sequences.
user-specified The ability to maintain
phase coordination with external
according to a movements by preventing
time of day one or more phases being
schedule. skipped under certain
traffic conditions or signal
states.

SERIAL 15058-RFP
2.1.2.0 2 The ASCT 4.9.0-1.0-5 Yes Users may define allowed or omitted Demonstrated
-6 shall omit a phases.
user-specified The ability to maintain
phase when the coordination with external
cycle length is movements by allowing
below a user- one or more phases to be
specified omitted (disabled) under
value. certain traffic conditions
or signal states.
2.1.2.0 3 The ASCT 4.9.0-1.0-5 Yes In|Sync can be configured to omit a Demonstrated
-7 shall omit a user-specified phase during a particular
user-specified time of day or event.
phase based on The ability to maintain
measured coordination with external
traffic movements by allowing
conditions. one or more phases to be
omitted (disabled) under
certain traffic conditions
or signal states.
2.1.2.0 2 The ASCT 4.9.0-1.0-5 Yes In|Sync can be configured to omit a Demonstrated
-8 shall omit a user-specified phase during a specific
user-specified event. A binary signal from the external
phase based on device must be routed into the In|Sync
the state of a processor to inform it to switch into
user-specified alternate operations.
external input. The ability to maintain
coordination with external
movements by allowing
one or more phases to be
omitted (disabled) under
certain traffic conditions
or signal states.
4.17.0-2

SERIAL 15058-RFP
The system needs to react Yes In|Sync’s adaptive configurations Demonstrated
to commands issued by an feature the ability to adjust service times
external decision support based on real-time traffic conditions,
system or an Integrated utilizing a set of baseline parameters.
Corridor Management Users can also manually call alternate
system, commanding the configurations at any time, with proper
ASCT to initiate a flush credentials from any internet-connected
plan. This flush plan shall device.
remain in operation until
the command from the
external source is
removed.
2.1.2.0 4 The ASCT 4.9.0-1.0-5 Yes The user may determine which phases Demonstrated
-9 shall omit a can be omitted based on the time of day.
user-specified The ability to maintain
phase coordination with external
according to a movements by allowing
time of day one or more phases to be
schedule omitted (disabled) under
certain traffic conditions
or signal states.
2.1.2.0 4 The ASCT 4.9.0-1.0-10 Yes In|Sync's algorithm automatically Demonstrated
-10 shall assign assigns unused time to promote optimal
unused time service at the intersection. The allowed
from a phases can be restricted to user-
preceding specified phases only.
phase that
terminates
early to a user-
specified phase
as follows:
* Next phase; Allow the operator to
* Next specify which phase

SERIAL 15058-RFP
coordinated receives unused time from
phase; a preceding phase
* User-
specified
phase.
2.1.2.0 4 The ASCT 4.9.0-1.0-10 Yes In|Sync's algorithm automatically Demonstrated
-11 shall assign assigns unused time to promote optimal
unused time service at the intersection. The allowed
from a phases can be restricted to user-
preceding specified phases only.
phase that is
skipped to a
user-specified
phase as
follows:
* Previous Allow the operator to
phase; specify which phase
* Next phase; receives unused time from
* Next a preceding phase
coordinated
phase;
* User-
specified
phase.
2.1.3 2.1.3
Oversaturatio
n

SERIAL 15058-RFP
2.1.3.0 4 The ASCT 4.1.0-1.0-4 Yes In|Sync detects and measures queues in Demonstrated
-1 shall detect the each and every lane for all approaches
presence of multiple times per minute. The agency
queues at pre- and Rhythm Engineering define a
configured dynamic period range used to minimize
locations. and manage queues throughout the
network. The period length shifts
according to the overall demand along
the corridor and the local intersection
adaptively selects how to distribute
green time to best facilitate progression
without inducing transition events seen
with cycle, split, and offset based
systems. With In|Sync, the user does not
have to define all possible timing plans
to implement adaptive operations,
significantly reducing the work load.
The state of the signal controller is
altered by In|Sync submitting holds and
force-offs. The user can still manipulate
the controller’s operation through the
use of their central system software if
desired.
The objective of the
coordination shall be to
manage the lengths of
queues stored at critical
locations within the
coordinated group so that
long queues do not block
upstream intersections or
otherwise reduce the
capacity available during

SERIAL 15058-RFP
the green phases. This
shall involve controlling
phase lengths so that the
size of platoons entering a
downstream block do not
exceed the storage length
if the platoon shall be
stopped. It shall also
involve control of offsets
and phase lengths so that
queues may be stored in
locations where they shall
not adversely affect
capacity of the system.
Queues often overflow
from the westbound left
turn bay at 84th Avenue
and Bell and at the
eastbound left turn bay at
83rd Avenue and Bell
during the PM peak.

SERIAL 15058-RFP
4.1.0-1.0-5 Yes In|Sync detects and measures queues in Demonstrated
each and every lane for all approaches
multiple times per minute. The agency
and Rhythm Engineering define a
dynamic period range used to minimize
and manage queues throughout the
network. The period length shifts
according to the overall demand along
the corridor and the local intersection
adaptively selects how to distribute
green time to best facilitate progression
without inducing transition events seen
with cycle, split, and offset based
systems. With In|Sync, the user does not
have to define all possible timing plans
to implement adaptive operations,
significantly reducing the work load.
The state of the signal controller is
altered by In|Sync submitting holds and
force-offs. The user can still manipulate
the controller’s operation through the
use of their central system software if
desired.
Manage the locations of
queues within the network
4.1.0-4
The system operator needs Yes In|Sync automatically and adaptively Demonstrated
to detect repeated phase adjusts local and global optimization
failures and control signal based on phase failures within the
timing to prevent phase boundaries of the configuration.
failures building up
queues. The operator in
this case is trying to

SERIAL 15058-RFP
prevent a routine queue
from forming where it
shall block another
movement in the cycle
unnecessarily. For
example, the operator may
need to prevent a queue
resulting from the trailing
end of the through green
from blocking the storage
needed by an entering
side-street left turn in the
subsequent phase. An
overall queue
management strategy,
particularly when
congestion is present, is
covered under 4.1.0-1.0-5.
4.5.0-1
The system operator needs Yes In|Sync detects and measures queues in Demonstrated
to detect queues from each and every lane for all approaches
outside the system and multiple times per minute. In|Sync then
modify the ASCT uses this information to assign green
operation to accommodate time to movements with the greatest
the queuing. demand.
4.5.0-2
The system operator needs Yes In|Sync detects and measures queues in Demonstrated
to detect queues within the each and every lane for all approaches
system's boundaries and multiple times per minute. In|Sync then
modify the ASCT uses this information to assign green
operation to accommodate time to movements with the greatest
the queuing. demand.
4.5.0-3

SERIAL 15058-RFP
The system operator needs Yes Automatically switching into alternate Demonstrated
to detect queues operations (i.e., event triggering) is an
propagating outside its important feature that is available in
boundaries from within In|Sync. In|Sync shall receive a binary
the ASCT boundaries, and (on/off) signal from a device or
modify its operation to controller, which shall trigger the
accommodate the alternate configuration. This can
queuing. alternate configuration be an adaptive or
non-adaptive configuration.
4.5.0-4
The system operator needs Yes Configuration files that govern Demonstrated
to store queues in In|Sync’s behavior are created which
locations where they can define coordinated routes and movement
be accommodated without prioritios through a group of signals.
adversely affecting
adaptive operation.
4.5.0-5
The system operator needs Yes Configuration files that govern Demonstrated
to prevent queues forming In|Sync’s behavior are created which
at user-specified locations. define coordinated routes and movement
prioritios through a group of signals.
2.1.3.0 5 When queues 4.1.0-1.0-4 Yes Intersection phasing is continuously Demonstrated
-2 are detected at dynamic with respect to each
user-specified intersection’s tunnel (coordinated
locations, the movement) this prevents queues from
ASCT shall exceeding the storage capacity at
execute user- specified locations without the user
specified having to define every plausible
timing condition.

SERIAL 15058-RFP
plan/operationa The objective of the
l mode. coordination shall be to
manage the lengths of
queues stored at critical
locations within the
coordinated group so that
long queues do not block
upstream intersections or
otherwise reduce the
capacity available during
the green phases. This
shall involve controlling
phase lengths so that the
size of platoons entering a
downstream block do not
exceed the storage length
if the platoon shall be
stopped. It shall also
involve control of offsets
and phase lengths so that
queues may be stored in
locations where they shall
not adversely affect
capacity of the system.
Queues often overflow
from the westbound left
turn bay at 84th Avenue
and Bell and at the
eastbound left turn bay at
83rd Avenue and Bell
during the PM peak.
4.1.0-1.0-5

SERIAL 15058-RFP
Manage the locations of Yes Configuration files that govern Demonstrated
queues within the network In|Sync’s behavior are created which
define coordinated routes and movement
prioritios through a group of signals.
4.1.0-4
The system operator needs Yes In|Sync automatically and adaptively Demonstrated
to detect repeated phase adjusts local and global optimization
failures and control signal based on phase failures within the
timing to prevent phase boundaries of the configuration.
failures building up
queues. The operator in
this case is trying to
prevent a routine queue
from forming where it
shall block another
movement in the cycle
unnecessarily. For
example, the operator may
need to prevent a queue
resulting from the trailing
end of the through green
from blocking the storage
needed by an entering
side-street left turn in the
subsequent phase. An
overall queue
management strategy,
particularly when
congestion is present, is
covered under 4.1.0-1.0-5.
4.5.0-1

SERIAL 15058-RFP
The system operator needs Yes In|Sync detects and measures queues in Demonstrated
to detect queues from each and every lane for all approaches
outside the system and multiple times per minute. In|Sync then
modify the ASCT uses this information to assign green
operation to accommodate time to movements with the greatest
the queuing. demand.
4.5.0-2
The system operator needs Yes In|Sync detects and measures queues in Demonstrated
to detect queues within the each and every lane for all approaches
system's boundaries and multiple times per minute. In|Sync then
modify the ASCT uses this information to assign green
operation to accommodate time to movements with the greatest
the queuing. demand.
4.5.0-3
The system operator needs Yes In|Sync detects and measures queues in Demonstrated
to detect queues each and every lane for all approaches
propagating outside its multiple times per minute. In|Sync then
boundaries from within uses this information to assign green
the ASCT boundaries, and time to movements with the greatest
modify its operation to demand.
accommodate the
queuing.
4.5.0-4
The system operator needs Yes Configuration files that govern Demonstrated
to store queues in In|Sync’s behavior are created which
locations where they can define coordinated routes and movement
be accommodated without prioritios through a group of signals.
adversely affecting
adaptive operation.
4.5.0-5

SERIAL 15058-RFP
The system operator needs Yes Configuration files that govern Demonstrated
to prevent queues forming In|Sync’s behavior are created which
at user-specified locations. define coordinated routes and movement
prioritios through a group of signals.
2.1.3.0 5 When queues 4.1.0-1.0-4 Yes In|Sync's algorithm shall compute split Demonstrated
-3 are detected at times, second by second, according to
user-specified real-time queues. In|Sync shall serve a
locations, the phase as long as demand exists for that
ASCT shall phase, until the time available until the
execute user- next coordinated phase equals the time
specified required to serve all queued traffic that
adaptive has not yet been served in the current
strategy in period. This superior methodology
accordance allows In|Sync to handle unusual spikes
with in demand without switching to some
requirements generic "other" timing plan.
2.1.1.0-2 (The The objective of the
ASCT shall coordination shall be to
operate non- manage the lengths of
adaptively queues stored at critical
when adaptive locations within the
control coordinated group so that
equipment long queues do not block
fails.). upstream intersections or
otherwise reduce the
capacity available during
the green phases. This
shall involve controlling
phase lengths so that the
size of platoons entering a
downstream block do not
exceed the storage length
if the platoon shall be

SERIAL 15058-RFP
stopped. It shall also
involve control of offsets
and phase lengths so that
queues may be stored in
locations where they shall
not adversely affect
capacity of the system.
Queues often overflow
from the westbound left
turn bay at 84th Avenue
and Bell and at the
eastbound left turn bay at
83rd Avenue and Bell
during the PM peak.
4.1.0-1.0-5 Yes Configuration files that govern Demonstrated
In|Sync’s behavior are created which
define coordinated routes and movement
prioritios through a group of signals.
Manage the locations of
queues within the network
4.1.0-4
The system operator needs Yes In|Sync automatically and adaptively Demonstrated
to detect repeated phase adjusts local and global optimization
failures and control signal based on phase failures within the
timing to prevent phase boundaries of the configuration.
failures building up
queues. The operator in
this case is trying to
prevent a routine queue
from forming where it
shall block another
movement in the cycle
unnecessarily. For

SERIAL 15058-RFP
example, the operator may
need to prevent a queue
resulting from the trailing
end of the through green
from blocking the storage
needed by an entering
side-street left turn in the
subsequent phase. An
overall queue
management strategy,
particularly when
congestion is present, is
covered under 4.1.0-1.0-5.
4.5.0-1
The system operator needs Yes Configuration files that govern Demonstrated
to detect queues from In|Sync’s behavior are created which
outside the system and define coordinated routes and movement
modify the ASCT prioritios through a group of signals.
operation to accommodate
the queuing.
4.5.0-2
The system operator needs Yes Configuration files that govern Demonstrated
to detect queues within the In|Sync’s behavior are created which
system's boundaries and define coordinated routes and movement
modify the ASCT prioritios through a group of signals.
operation to accommodate
the queuing.
4.5.0-3

SERIAL 15058-RFP
The system operator needs Yes Automatically switching into alternate Demonstrated
to detect queues operations (i.e., event triggering) is an
propagating outside its important feature that is available in
boundaries from within In|Sync. In|Sync shall receive a binary
the ASCT boundaries, and (on/off) signal from a device or
modify its operation to controller, which shall trigger the
accommodate the alternate configuration. This can
queuing. alternate configuration be an adaptive or
non-adaptive configuration.
4.5.0-4
The system operator needs Yes Configuration files that govern Demonstrated
to store queues in In|Sync’s behavior are created which
locations where they can define coordinated routes and movement
be accommodated without prioritios through a group of signals.
adversely affecting
adaptive operation.
4.5.0-5
The system operator needs Yes Configuration files that govern Demonstrated
to prevent queues forming In|Sync’s behavior are created which
at user-specified locations. define coordinated routes and movement
prioritios through a group of signals.
2.1.3.0 4 When queues 4.1.0-1.0-4 Yes In|Sync uses real-time analysis to omit Demonstrated
-4 are detected at phases as it determines are necessary
user-specified with respect to the coordinated
locations, the movement.
ASCT shall The objective of the
omit a user- coordination shall be to
specified phase manage the lengths of
at a user- queues stored at critical
specified locations within the
signal coordinated group so that
controller. long queues do not block
upstream intersections or

SERIAL 15058-RFP
otherwise reduce the
capacity available during
the green phases. This
shall involve controlling
phase lengths so that the
size of platoons entering a
downstream block do not
exceed the storage length
if the platoon shall be
stopped. It shall also
involve control of offsets
and phase lengths so that
queues may be stored in
locations where they shall
not adversely affect
capacity of the system.
Queues often overflow
from the westbound left
turn bay at 84th Avenue
and Bell and at the
eastbound left turn bay at
83rd Avenue and Bell
during the PM peak.
4.1.0-1.0-5
Manage the locations of Yes Configuration files that govern Demonstrated
queues within the network In|Sync’s behavior are created which
define coordinated routes and movement
prioritios through a group of signals.
4.1.0-4

SERIAL 15058-RFP
The system operator needs Yes Configuration files that govern Demonstrated
to detect repeated phase In|Sync’s behavior are created which
failures and control signal define coordinated routes and movement
timing to prevent phase prioritios through a group of signals.
failures building up
queues. The operator in
this case is trying to
prevent a routine queue
from forming where it
shall block another
movement in the cycle
unnecessarily. For
example, the operator may
need to prevent a queue
resulting from the trailing
end of the through green
from blocking the storage
needed by an entering
side-street left turn in the
subsequent phase. An
overall queue
management strategy,
particularly when
congestion is present, is
covered under 4.1.0-1.0-5.
4.5.0-4
The system operator needs Yes Configuration files that govern Demonstrated
to store queues in In|Sync’s behavior are created which
locations where they can define coordinated routes and movement
be accommodated without prioritios through a group of signals.
adversely affecting
adaptive operation.
4.5.0-5

SERIAL 15058-RFP
The system operator needs Yes Configuration files that govern Demonstrated
to prevent queues forming In|Sync’s behavior are created which
at user-specified locations. define coordinated routes and movement
prioritios through a group of signals.
2.2 2.2 Sequence-
based
Adaptive
Coordination
2.2.0-2 3 The ASCT 4.1.0-1.0-1
shall select
cycle length Maximize the throughput Yes In|Sync detects and measures queues in Demonstrated
based on a on coordinated routes each and every lane for all approaches
time of day multiple times per minute. The agency
schedule. and Rhythm Engineering define a
dynamic period range used to minimize
and manage queues throughout the
network. The period length shifts
according to the overall demand along
the corridor and the local intersection
adaptively selects how to distribute
green time to best facilitate progression
without inducing transition events seen
with cycle, split, and offset based
systems. With In|Sync, the user does not
have to define all possible timing plans
to implement adaptive operations,
significantly reducing the work load.
The state of the signal controller is
altered by In|Sync submitting holds and
force-offs. The user can still manipulate
the controller’s operation through the
use of their central system software if
desired.

SERIAL 15058-RFP
4.1.0-1.0-2
Provide smooth flow Yes Intersection phasing is continuously Demonstrated
along coordinated routes dynamic with respect to each
intersection’s tunnel (coordinated
movement) to provide smooth flow
along coordinated routes,.
4.1.0-1.0-3
Distribute phase times in Yes Intersection phasing is continuously Demonstrated
an equitable fashion dynamic with respect to each
intersection’s tunnel (coordinated
movement) to distribute time in an
equitable fashion.
4.1.0-1.0-4
The objective of the Yes Intersection phasing is continuously Demonstrated
coordination shall be to dynamic with respect to each
manage the lengths of intersection’s tunnel (coordinated
queues stored at critical movement) this prevents queues from
locations within the exceeding the storage capacity at
coordinated group so that specified locations without the user
long queues do not block having to define every plausible
upstream intersections or condition.
otherwise reduce the
capacity available during
the green phases. This
shall involve controlling
phase lengths so that the
size of platoons entering a
downstream block do not
exceed the storage length
if the platoon shall be
stopped. It shall also
involve control of offsets
and phase lengths so that

SERIAL 15058-RFP
queues may be stored in
locations where they shall
not adversely affect
capacity of the system.
Queues often overflow
from the westbound left
turn bay at 84th Avenue
and Bell and at the
eastbound left turn bay at
83rd Avenue and Bell
during the PM peak.
2.2.0-3 4 The ASCT 4.1.0-1.0-3
shall calculate Distribute phase times in Yes In|Sync does not preschedule time; Demonstrated
phase lengths an equitable fashion rather, it continuously analyzes how
for all phases much time is left before the subsequent
at each signal coordinated movement and calculates
controller to sequences and phases on that basis.
suit the current 4.1.0-1.0-5
coordination Manage the locations of Yes Intersection phasing is continuously Demonstrated
strategy. queues within the network dynamic with respect to each
intersection’s tunnel (coordinated
movement) this prevents queues from
exceeding the storage capacity at
specified locations without the user
having to define every plausible
condition.
4.1.0-4

SERIAL 15058-RFP
The system operator needs Yes In|Sync automatically and adaptively Demonstrated
to detect repeated phase adjusts local and global optimization
failures and control signal based on phase failures within the
timing to prevent phase boundaries of the configuration.
failures building up
queues. The operator in
this case is trying to
prevent a routine queue
from forming where it
shall block another
movement in the cycle
unnecessarily. For
example, the operator may
need to prevent a queue
resulting from the trailing
end of the through green
from blocking the storage
needed by an entering
side-street left turn in the
subsequent phase. An
overall queue
management strategy,
particularly when
congestion is present, is
covered under 4.1.0-1.0-5.
2.2.0-4 3 The ASCT 4.1.0-1.0-1 Yes In|Sync's configuration engineers Demonstrated
shall calculate determine the parameters of the offsets;
offsets to suit however, the adaptive algorithm can
the current make real-time adjustments to the
coordination service of the movements.
strategy for the Maximize the throughput
user-specified on coordinate routes
reference point 4.1.0-1.0-2

SERIAL 15058-RFP
for each signal Provide smooth flow Yes Intersection phasing is continuously Demonstrated
controller along coordinated routes dynamic with respect to each
along a intersection’s tunnel (coordinated
coordinated movement) to provide smooth flow
route within a along coordinated routes,.
group. 4.1.0-1.0-4
The objective of the Yes Intersection phasing is continuously Demonstrated
coordination shall be to dynamic with respect to each
manage the lengths of intersection’s tunnel (coordinated
queues stored at critical movement) this prevents queues from
locations within the exceeding the storage capacity at
coordinated group so that specified locations without the user
long queues do not block having to define every plausible
upstream intersections or condition.
otherwise reduce the
capacity available during
the green phases. This
shall involve controlling
phase lengths so that the
size of platoons entering a
downstream block do not
exceed the storage length
if the platoon shall be
stopped. It shall also
involve control of offsets
and phase lengths so that
queues may be stored in
locations where they shall
not adversely affect
capacity of the system.
Queues often overflow
from the westbound left
turn bay at 84th Avenue

SERIAL 15058-RFP
and Bell and at the
eastbound left turn bay at
83rd Avenue and Bell
during the PM peak.
2.2.0- 3 The ASCT 4.1.0-1.0-1 Yes In|Sync parameters including offsets are Demonstrated
4.0-1 shall apply configured in the included CentralSync
offsets for the software.
user-specified Maximize the throughput
reference point on coordinate routes
of each signal 4.1.0-1.0-2
controller Provide smooth flow Yes Intersection phasing is continuously Demonstrated
along a along coordinated routes dynamic with respect to each
coordinated intersection’s tunnel (coordinated
route. movement) to provide smooth flow
along coordinated routes,.
4.1.0-1.0-4
The objective of the Yes Intersection phasing is continuously Demonstrated
coordination shall be to dynamic with respect to each
manage the lengths of intersection’s tunnel (coordinated
queues stored at critical movement) this prevents queues from
locations within the exceeding the storage capacity at
coordinated group so that specified locations without the user
long queues do not block having to define every plausible
upstream intersections or condition.
2.2.0-5 4 The ASCT otherwise reduce the Yes In|Sync can implement a dynamic Demonstrated
shall calculate capacity available during period length based on optimization
a cycle length the green phases. This objectives. The dynamic period
for each cycle shall involve controlling facilitates progression, queue
based on its phase lengths so that the management, and equitable distribution

SERIAL 15058-RFP
optimization size of platoons entering a of green parameters for each
objectives (as downstream block do not intersection and makes changes to the
required exceed the storage length period length to ensure optimal
elsewhere, e.g., if the platoon shall be progression along the corridor.
progression, stopped. It shall also
queue involve control of offsets
management, and phase lengths so that
equitable queues may be stored in
distribution of locations where they shall
green). not adversely affect
2.2.0- 4 The ASCT capacity of the system. Yes Upper and lower bounds of the period Demonstrated
5.0-1 shall limit Queues often overflow (In|Sync’s adaptive “cycle length”
cycle lengths from the westbound left equivalent) can be assigned. In|Sync
to user- turn bay at 84th Avenue calculates period length in real-time
specified and Bell and at the based on traffic conditions.
values. eastbound left turn bay at
83rd Avenue and Bell
during the PM peak.

SERIAL 15058-RFP
2.2.0- 5 The ASCT 4.1.0-1.0-1 Yes In|Sync detects and measures queues in Demonstrated
5.0-2 shall limit each and every lane for all approaches
cycle lengths multiple times per minute. The agency
to a user- and Rhythm Engineering define a
specified dynamic period range used to minimize
range. and manage queues throughout the
network. The period length shifts
according to the overall demand along
the corridor and the local intersection
adaptively selects how to distribute
green time to best facilitate progression
without inducing transition events seen
with cycle, split, and offset based
systems. With In|Sync, the user does not
have to define all possible timing plans
to implement adaptive operations,
significantly reducing the work load.
The state of the signal controller is
altered by In|Sync submitting holds and
force-offs. The user can still manipulate
the controller’s operation through the
use of their central system software if
desired.
Maximize the throughput Yes See response 2.2.0-5.0-2 Demonstrated
on coordinate routes
4.1.0-1.0-2
Provide smooth flow Yes See response 2.2.0-5.0-2 Demonstrated
along coordinated routes
4.1.0-1.0-3
Distribute phase times in Yes See response 2.2.0-5.0-2 Demonstrated
an equitable fashion
4.1.0-1.0-4

SERIAL 15058-RFP
The objective of the Yes Intersection phasing is continuously Demonstrated
coordination shall be to dynamic with respect to each
manage the lengths of intersection’s tunnel (coordinated
queues stored at critical movement) this prevents queues from
locations within the exceeding the storage capacity at
coordinated group so that specified locations without the user
long queues do not block having to define every plausible
upstream intersections or condition.
2.2.0- 4 The ASCT otherwise reduce the Yes This is a configurable parameter in Demonstrated
5.0-3 shall calculate capacity available during In|Sync.
optimum cycle the green phases. This
lengths shall involve controlling
according to phase lengths so that the
the user- size of platoons entering a
specified downstream block do not
coordination exceed the storage length
strategy. if the platoon shall be
2.2.0- 4 The ASCT stopped. It shall also Yes In|Sync dynamically adjusts the period Demonstrated
5.0-4 shall limit involve control of offsets length (similar to cycle length) within
changes in and phase lengths so that user-defined thresholds for a group of
cycle length to queues may be stored in intersections simultaneously. As traffic
a user- locations where they shall demand increases, In|Sync shall increase
specified not adversely affect (or decrease) period length by user-
value. capacity of the system. specified increments within the user-
Queues often overflow specified range.
2.2.0- 5 The ASCT from the westbound left Yes In|Sync dynamically adjusts the period Demonstrated
5.0- shall increase turn bay at 84th Avenue length (similar to cycle length) within
4.0-1 the limit for a and Bell and at the user-defined thresholds for a group of
user-specified eastbound left turn bay at intersections simultaneously. As traffic
number of 83rd Avenue and Bell demand increases, In|Sync shall increase
cycles based during the PM peak. (or decrease) period length by user-
on a change in specified increments within the user-
conditions specified range.

SERIAL 15058-RFP
2.2.0- 5 The change in Yes In|Sync dynamically adjusts the period Demonstrated
5.0- conditions length (similar to cycle length) within
4.0- shall be user-defined thresholds for a group of
1.0-1 defined by a intersections simultaneously. As traffic
user-specified demand increases, In|Sync shall increase
number of (or decrease) period length by user-
successive specified increments within the user-
adaptive specified range.
increases in
cycle length at
the maximum
rate.
2.2.0- 5 The increase Yes The range of allowed period length is Demonstrated
5.0- shall be user- user-specified for each configuration file
4.0- defined. individually. A time-of-day schedule
1.0-2 specifies which configuration file is
running for each day and hour of the
week.
2.2.0- The ASCT 4.1.0-5 Yes In|Sync’s offsets are based on the Demonstrated
5.0-5 shall adjust volumetric profile of traffic from one
offsets to intersection to the next. Offsets may
minimize the adjust to local demand and can
chance of dynamically shift when using dynamic
stopping period lengths. In|Sync ensures their
vehicles structure does not cause transition
approaching a effects and accommodates upstream
signal that traffic, which impacts opposing traffic
have been flow downstream. In|Sync achieves this
served by a level of operation without the need for
user-specified costly and time consuming installation
phase at an of advanced detection.
5 upstream The system operator needs
signal. to minimize the chance

SERIAL 15058-RFP
that a queue forms at a
specified location.
2.3 2.3 Non- Not Used
sequence-
based
adaptive
coordination
2.4 2.4 Single
intersection
adaptive
operation
5 The ASCT The objective of the single Yes Configuration files that govern Demonstrated
shall execute intersection adaptive In|Sync’s behavior are created which
Single strategy is to allow for define coordinated routes and movement
intersection adaptive operation during prioritios through a group of signals.
adaptive the off peak hours during Configurations are set by time of day.
strategy at night time operations.
user-specified Each intersection shall
locations operate in an adaptive
according to a mode solely based on each
time of day specific intersections
schedule. volumes. This shall allow
the intersection to operate
in a adaptive mode and
operate in a more efficient
mannar to respond quickly
to the traffic at each
intersection.
2.5 2.5 Phase- Not Used
based
adaptive
coordination
2.6 2.6

SERIAL 15058-RFP
Responsivenes
s
2.6.0-3 3 The ASCT 4.8.0-1 Yes In|Sync achieves bidirectional Demonstrated
shall limit the progression through its patented
changes in the optimization techniques. Users may
direction of define a primary direction in the
primary adaptive configuration by time of day,
coordination to or maintain In|Sync’s default optimal
a user- bidirectional capability.
specified The system operator needs
frequency. to modify the ASCT
operation to closely
follow changes in traffic
conditions.
4.8.0-2
The system operator needs Yes In|Sync dynamically adjusts the period Demonstrated
to constrain the selection length (similar to cycle length) within
of cycle lengths to those user-defined thresholds for a group of
that provide acceptable intersections simultaneously. As traffic
operations, such as when demand increases, In|Sync shall increase
resonant progression (or decrease) period length by user-
solutions are desired. specified increments within the user-
specified range.
2.6.0-4 3 When a large 4.8.0-3 Yes In|Sync maintains progression while Demonstrated
change in locally accounting for large changes in
traffic demand traffic demand. At the global level,
is detected, the In|Sync creates dynamic period lengths
ASCT shall to ensure the health of side street service
respond more by altering the time between
quickly than coordinated movements.
normal
operation,
subject to user-

SERIAL 15058-RFP
specified
limits.
The system operator needs
to respond quickly to
sudden large shifts in
traffic conditions.
2.6.0-5 4 The ASCT 4.8.0-2 Yes In|Sync dynamically adjusts the period Demonstrated
shall select length (similar to cycle length) within
cycle length user-defined thresholds for a group of
from a list of intersections simultaneously. As traffic
user-defined demand increases, In|Sync shall increase
cycle lengths. (or decrease) period length by user-
specified increments within the user-
specified range.
The system operator needs
to constrain the selection
of cycle lengths to those
that provide acceptable
operations, such as when
resonant progression
solutions are desired.
3 3
External/Inter
nal Interfaces

SERIAL 15058-RFP
3.0-1 The ASCT
shall support
external
interfaces
according to
the referenced
interface
control
documents
and the
following
detailed
requirements.
(Insert
appropriate
requirements
that suit your
needs.
Interface data
flows should
be documented
in your ITS
architecture.
Interface
requirements
include:
5 · Information 4.3.0-1 Yes In|Sync meets this requirement. Demonstrated
layer protocol
The system operator needs
to adaptively control
signals operated by City
of Peoria, Maricopa
County, ADOT, and City

SERIAL 15058-RFP
of Glendale.
5 · Application 4.3.0-2 Yes In|Sync data is stored in a CSV Demonstrated
layer protocol database, and can be auto downloaded
to a computer or server. Additionally,
since In|Sync installs beside the
controller, any current system that uses
controller output data can still function
The adaptive system Yes In|Sync data is stored in a CSV Demonstrated
needs to send data to database, and can be auto downloaded
another system that would to a computer or server. Additionally,
allow the other system to since In|Sync installs beside the
coordinate with the ASCT controller, any current system that uses
system. controller output data can still function
5 · Lower layer 4.3.0-4
protocol
The adaptive system Yes In|Sync data is stored in a CSV Demonstrated
needs to receive data from database, and can be auto downloaded
another system that shall to a computer or server. Additionally,
allow the ASCT system to since In|Sync installs beside the
coordinate its operation controller, any current system that uses
with the adjacent system. controller output data can still function
5 · Data 4.11.0-5
aggregation
The adaptive system Yes In|Sync data is stored in a CSV Demonstrated
needs to report database, and can be auto downloaded
performance data in real to a computer or server. Additionally,
time to Regional Archive since In|Sync installs beside the
Data Server (RADS). controller, any current system that uses
controller output data can still function
5 · Frequency of 4.17.0-2
storage

SERIAL 15058-RFP
5 · Frequency of The adaptive system Yes Automatically switching into alternate Demonstrated
reporting needs to react to operations (i.e., event triggering) is an
commands issued by an important feature that is available in
external decision support In|Sync. In|Sync shall receive a binary
system or an Integrated (on/off) signal from a device or
Corridor Management controller, which shall trigger the
system, commanding the alternate configuration. This can
ASCT to initiate a flush alternate configuration be an adaptive or
plan. This flush plan shall non-adaptive configuration.
remain in operation until
the command from the
external source is
removed.
5 · Duration of
storage)
3.0- 4 The ASCT 4.3.0-2 Yes InSync sends operational data through Demonstrated
1.0-1 shall send its Web User Interface and Archiver
operational utilities. It also send status and alerts
data to through an SMTP server.
Regional The adaptive system
Archive Data needs to send data to
Server (RADS) another system that would
external allow the other system to
system. coordinate with the ASCT
system.
4.11.0-5
The adaptive system Yes In|Sync data is stored in a CSV Demonstrated
needs to report database, and can be auto downloaded
performance data in real to a computer or server. Additionally,
time to Regional Archive since In|Sync installs beside the
Data Server (RADS). controller, any current system that uses
controller output data can still function
3.0- 4 The ASCT 4.3.0-2

SERIAL 15058-RFP
1.0-2 shall send The adaptive system Yes In|Sync data is stored in a CSV Demonstrated
control data to needs to send data to database, and can be auto downloaded
the MaxView, another system that would to a computer or server. Additionally,
TranSuite, and allow the other system to since In|Sync installs beside the
KITS external coordinate with the ASCT controller, any current system that uses
systems. system. controller output data can still function
3.0- 4 The ASCT 4.11.0-1 Yes Each operator can be assigned Demonstrated
1.0-3 shall send credentials, limiting or extending their
monitoring access to monitoring data to any number
data to the of workstations.
MaxView, The agency needs
TranSuite, and MaxView, TranSuite, and
KITS external KITS to be able to
systems. monitor the ASCT system
automatically.
3.0- 4 The ASCT 4.3.0-2
1.0-4 shall send The adaptive system Yes In|Sync data is stored in a CSV Demonstrated
coordination needs to send data to database, and can be auto downloaded
data to the another system that would to a computer or server. Additionally,
MaxView, allow the other system to since In|Sync installs beside the
TranSuite, and coordinate with the ASCT controller, any current system that uses
KITS external system. controller output data can still function
systems.
3.0- 4 The ASCT 4.11.0-5 Yes Each operator can be assigned Demonstrated
1.0-5 shall send credentials, limiting or extending their
performance access to performance data to any
data to the number of workstations.
Regional The adaptive system
Archive Data needs to report
Server (RADS) performance data in real
external time to Regional Archive
system. Data Server (RADS).

SERIAL 15058-RFP
3.0- 4 The ASCT 4.17.0-2 Yes Automatically switching into alternate Demonstrated
1.0-6 shall receive operations (i.e., event triggering) is an
commands important feature that is available in
from the In|Sync. In|Sync shall receive a binary
MaxView, (on/off) signal from a device or
TranSuite, and controller, which shall trigger the
KITS external alternate configuration. This can
systems. alternate configuration be an adaptive or
non-adaptive configuration.
The adaptive system
needs to react to
commands issued by an
external decision support
system or future
Integrated Corridor
Management system,
commanding the ASCT to
initiate a flush plan. This
flush plan shall remain in
operation until the
command from the
external source is
removed.
3.0- 4 The ASCT 4.17.0-2 Yes Automatically switching into alternate Demonstrated
1.0-7 shall operations (i.e., event triggering) is an
implement the important feature that is available in
following In|Sync. In|Sync shall receive a binary
commands (on/off) signal from a device or
from the controller, which shall trigger the
MaxView, alternate configuration. This can
TranSuite, and alternate configuration be an adaptive or
KITS external non-adaptive configuration.
systems when

SERIAL 15058-RFP
commanded:
· Specified The adaptive system
cycle length needs to react to
· Specified commands issued by an
direction of external decision support
progression system or an Integrated
· Specified Corridor Management
adaptive system, commanding the
strategy ASCT to initiate a flush
plan. This flush plan shall
remain in operation until
the command from the
external source is
removed.
4 4 Crossing
Arterials and
Boundaries
4.0-1 4 The ASCT 4.3.0-4 Yes In|Sync can be configured with outside Demonstrated
shall conform data from an adjacent system. i.e.
its operation to Timing patterns can added into the
an external In|Sync processor from an adjacent
system's system for coordination purposes.
operation. The adaptive system
needs to receive data from
another system that shall
allow the ASCT system to
coordinate its operation

SERIAL 15058-RFP
with the adjacent system.
4.3.0-6
The adaptive system Yes The In|Sync system includes four Demonstrated
needs to detect traffic detection cameras per intersection.
approaching from a These cameras view the approach up to
neighboring system and 400 feet (i.e., 20 carlengths) back from
coordinate the ASCT the stop bar. The ability to actively
operation with the measure queues allows In|Sync to
adjacent system. schedule the right amount of time to
clear the actual queue at that moment,
and then change quickly to another
phase pair with active demand.
4.17.0-2
The adaptive system Yes Automatically switching into alternate Demonstrated
needs to react to operations (i.e., event triggering) is an
commands issued by an important feature that is available in
external decision support In|Sync. In|Sync shall receive a binary
system or an Integrated (on/off) signal from a device or
Corridor Management controller, which shall trigger the
system, commanding the alternate configuration. This can
ASCT to initiate a flush alternate configuration be an adaptive or
plan. This flush plan shall non-adaptive configuration.
remain in operation until
the command from the
external source is
removed.
4.0- 2 The ASCT 4.3.0-5 Yes Period lengths can be fixed in the Demonstrated
1.0-2 shall be based In|Sync system. Dynamic periods
on a fixed inherently provide better traffic
cycle length to operations, but In|Sync can be restricted
match an to operate this way.

SERIAL 15058-RFP
adjacent The system operator needs
system. to constrain the adaptive
system to operate a cycle
length compatible with the
crossing arterial.
5 5 Access and
Security
5.0-1 The ASCT 4.4.0-1 Yes In|Sync operates as a distributed Demonstrated
shall be network of intelligent traffic devices—
implemented typically through a Virtual Private
with a security Network, without a central server.
policy that Access to the system requires entry of
addresses the security credentials in the form of a
following username and password defined by the
selected ASCT administrator.
elements: The system operator needs
to have a security
management and
administrative system that
allows access and
operational privileges to
be assigned, monitored
and controlled by an
administrator, and
conform to the agency's
access and network
infrastructure security
policies.
5.0- 5 Local access to Yes Local access to the ASCT in the traffic Demonstrated
1.0-1 the ASCT. cabinet requires the entry of security
credentials in the form of a username
and password defined by the ASCT
administrator.

SERIAL 15058-RFP
5.0- 5 Remote access Yes Remote access to the ASCT requires Demonstrated
1.0-2 to the ASCT. security credentials to the VPN router,
or access to the VLAN. Additionally,
the adaptive device requires the entry of
security credentials in the form of a
username and password defined by the
ASCT administrator.
5.0- 5 System Yes System monitoring is conducted by Demonstrated
1.0-3 monitoring. entering the “Portal Page” URL into a
web browser, which provides a webpage
of the applicable intersections the user
wishes to monitor (see Remote access to
the ASCT for initial requirements). The
traffic engineer, technician, or TMC
staff can monitor traffic operations by
viewing each intersection individually,
the corridor in its entirety, or by viewing
a live map. Each intersection on the live
map can be clicked to access the
intersection’s video feed. The user can
then compare historical data—including
traffic counts, period lengths and phase
splits.

SERIAL 15058-RFP
5.0- 5 System manual Yes Manual overrides can be accomplished Demonstrated
1.0-4 override. by logging on to the In|Sync Processor
with the proper security credentials and
manually selecting the desired phases.
The user can also disable adaptive
operations at the intersection through
the same user interface. Lastly, the
intersection can be controlled by the
user’s central management software
when the user activates the controller’s
free-mode pin (which In|Sync monitors),
causing the controller to behave as
programed by the user (e.g., initiating a
controller’s user-programmed time-of-
day plan). Once In|Sync registers the
activated “free-pin,” In|Sync switches
into detector mode, passing all actuated
detector calls to the controller instead of
selectively passing adaptive calls.

SERIAL 15058-RFP
5.0- 5 Development Yes Development of the In|Sync Demonstrated
1.0-5 configurations is only possible with the
CentralSync configuration software,
which resides on the user’s PC.
Therefore, the security credentials for
the PC must be entered to gain access to
the PC and subsequently to change the
adaptive configuration. The user is
prompted for the adaptive network’s
user credentials upon sending the newly
developed adaptive configuration out to
each intersection. Overall system
development is managed by Rhythm
Engineering and the user is notified of
new software or firmware releases; only
upon response with a notice to proceed
from the user shall Rhythm Engineering
distribute the new software to each
respective intersection. The same
network security credentials are utilized
to accomplish the deployment of newly
developed In|Sync software or firmware.
5.0- 5 Operations Yes The systems administrator is responsible Demonstrated
1.0-6 for designating who is allowed to view,
monitor, receive system alerts and
manipulate the In|Sync system. The
system administrator shall be provided
with instructions to define operational
responsibility. Rhythm Engineering
shall ask for a predetermined list of
users to preconfigure the system with
the proper credentials prior to shipping
the system.

SERIAL 15058-RFP
5.0- 5 User login Yes The system administrator is responsible Demonstrated
1.0-7 for determining the user login and
respective passwords for the system.
Rhythm Engineering can make
suggestions on the nature and
complexity of these criteria, but the
system administrator can ensure the
security credentials meet the proper
conventions of the overall security
policy. The security credentials can also
be configured without Rhythm
Engineering’s involvement, if desired.
5.0- 5 User password Yes The system administrator is responsible Demonstrated
1.0-8 for determining the user login and
respective passwords for the system.
Rhythm Engineering can make
suggestions on the nature and
complexity of these criteria, but the
system administrator can ensure the
security credentials meet the proper
conventions of the overall security
policy. The security credentials can also
be configured without Rhythm
Engineering’s involvement, if desired.

SERIAL 15058-RFP
5.0- 5 Administration Yes System administration security is Demonstrated
1.0-9 of the system accomplished through overall network
administration. In|Sync establishes
connectivity with the user, typically
through a VPN connection using a VPN
router and managed Ethernet switches
that manage the security access of
In|Sync’s network. Network security is
maintained by the security policy’s
selected technology to prevent
unauthorized attempts at access to the
system or network. Access to each
adaptive processor is further controlled
by the previously mentioned required
In|Sync security credentials.
5.0- 5 Signal Yes In|Sync shall not interfere with existing Demonstrated
1.0-10 controller communications and security measures
group access for signal controller group access. The
In|Sync processors are accessed through
VPN, and different groups of processors
can be accessed by users with proper
credentials. Multiple users can be set up,
each user having access only to the
group of processors assigned.
5.0- 5 Access to Yes In|Sync does not interact with any Demonstrated
1.0-11 classes of equipment electrically downstream of
equipment the detector calls In|Sync submits to the
controller. The access to this equipment
is controlled by the network
administrator beyond In|Sync’s means
of interaction.

SERIAL 15058-RFP
5.0- 5 Access to Yes The In|Sync processors are accessed Demonstrated
1.0-12 equipment by through VPN, and different groups of
jurisdiction processors can be accessed by users
with proper credentials. Multiple users
can be set up, each user having access
only to the group of processors
assigned.
5.0- 5 Output Yes Output activation is governed by the Demonstrated
1.0-13 activation level of access given to the user by the
network administrator in conjunction
with the system administrator. I.e., the
user must have network access to gain
system access, which in turn provides
visibility to output activation. Output
activation may also be viewed by the
central management system without
compromising the adaptive system.
5.0- 5 System Yes Please see the “Development” and Demonstrated
1.0-14 parameters “Operations” responses of this section.
5.0- 5 Report Yes Please see the “System Monitoring” Demonstrated
1.0-15 generation response of this section.
5.0- 5 Configuration Yes Please see the “Development” response Demonstrated
1.0-16 of this section.
5.0- 5 Security alerts Yes Please see the “User login”, “User Demonstrated
1.0-17 password” and “Administration of the
system” responses of these sections.
5.0- 5 Security Yes Please see the “User login”, “User Demonstrated
1.0-18 logging password” and “Administration of the
system” responses of these sections.

SERIAL 15058-RFP
5.0- 5 Security Yes Security reporting regarding In|Sync is Demonstrated
1.0-19 reporting determined by monitoring the network
access. Please see the “Administration
of the system” response in this section.
5.0- 5 Database Yes Database management of security Demonstrated
1.0-20 regarding network access is determined
by the network management software.
Please see the “Administration of the
system” response in this section.
5.0- 5 Signal Yes In|Sync is an electrically passive device, Demonstrated
1.0-21 controller only submitting calls to the controller
after receiving them from the detection
source. This is the only form of
electrical connection to the controller,
limiting In|Sync’s interaction with the
controller to submitting “holds” and
“force-offs.”
5.0-2 The ASCT Yes In|Sync meets this requirement. Demonstrated
shall provide Processors can be monitored and
monitoring and controlled via web browser with correct
control access login credentials and appropriate
at the network access using any laptop or
following tablet with an internet connection.
locations:
5.0- 5 Agency TMC 4.10.0-1.0-1 Yes In|Sync meets this requirement. Demonstrated
2.0-1 at City of Processors can be monitored and
Peoria, controlled via web browser with correct
Maricopa login credentials and appropriate
County, network access using any laptop or
ADOT, and tablet with an internet connection.
City of Agency TMC at City of
Glendale Peoria, Maricopa County,
ADOT, and City of

SERIAL 15058-RFP
Glendale
5.0- 5 Maintenance 4.10.0-1.0-2 Yes In|Sync meets this requirement. Demonstrated
2.0-2 facilitiy Processors can be monitored and
controlled via web browser with correct
login credentials and appropriate
network access using any laptop or
tablet with an internet connection.
Maintenance facility
5.0- 5 Agency LAN 4.10.0-1.0-3 Yes In|Sync meets this requirement. Demonstrated
2.0-3 or WAN Processors can be monitored and
controlled via web browser with correct
login credentials and appropriate
network access using any laptop or
tablet with an internet connection.
Workstations on agency
LAN or WAN
5.0- 5 Other agency 4.10.0-1.0-4 Yes In|Sync meets this requirement. Demonstrated
2.0-4 TMC Processors can be monitored and
controlled via web browser with correct
login credentials and appropriate
network access using any laptop or
tablet with an internet connection.
Other agency's TMC (at
City of Peoria, Maricopa
County, ADOT, and City
of Glendale)

SERIAL 15058-RFP
5.0- 5 Local 4.10.0-1.0-5 Yes The equipment panel, included with the Demonstrated
2.0-5 controller In|Sync system, includes a network
cabinets switch which is connected to the In|Sync
processor. Technicians can connect
directly to the In|Sync processor at the
cabinet location by simply plugging and
Ethernet cable from their laptop into the
network switch on the equipment panel.
Local controller cabinets
5.0- 5 Maintenance 4.10.0-1.0-6 Yes In|Sync meets this requirement. Demonstrated
2.0-6 vehicles Processors can be monitored and
controlled via web browser with correct
login credentials and appropriate
network access using any laptop or
tablet with an internet connection.
Maintenance vehicles
5.0- 5 Remote 4.10.0-1.0-7 Yes In|Sync meets this requirement. Demonstrated
2.0-7 location via Processors can be monitored and
internet controlled via web browser with correct
login credentials and appropriate
network access using any laptop or
tablet with an internet connection.
Remote locations
5.0-3 5 The ASCT 4.4.0-1 Yes Rhythm Engineering works with the Demonstrated
shall comply agency IT department to setup a Virtual
with the Private Network (VPN) that Rhythm
agency's Engineering shall use to access system
security policy. hardware. This includes all security
measures built into the agency network,
including firewalls, authentication and
authorization.

SERIAL 15058-RFP
The system operator needs
to have a security
management and
administrative system that
allows access and
operational privileges to
be assigned, monitored
and controlled by an
administrator, and
conform to the agency's
access and network
infrastructure security
policies.
5.0-4 5 The ASCT 4.10.0-2 Yes In|Sync does not interfere with Demonstrated
shall not communications into our out of the
prevent access controller, nor any databases generated
to the local by the controller.
signal The operator needs to
controller access to the database
database, management, monitoring
monitoring or and reporting features and
reporting functions of the signal
functions by controllers and any related
any installed signal management
signal system from the access
management points defined for those
system. system components.
6 6 Data Log
6.0-1 The ASCT 4.11.0-6 Yes Each local In|Sync processor stores all Demonstrated
shall log the such data in local csv files for each of
following the past 30 days. This data can be auto-
events: archived to a computer or server to keep
a running database as far back as

SERIAL 15058-RFP
desired.
The system operator needs
6.0- 5 Time-stamped to be able to report the Yes In|Sync supports this capability. Demonstrated
1.0-1 vehicle phase exact state of signal
calls timing and input data for a
6.0- 5 Time-stamped specified period, to allow Yes In|Sync supports this capability. Demonstrated
1.0-2 pedestrian historical analysis of the
phase calls system operation.
6.0- 5 Time-stamped Yes In|Sync would report this event as a Demonstrated
1.0-3 emergency general vehicle pre-emption.
vehicle
preemption
calls
6.0- 3 Time-stamped Yes In|Sync would report this event as a Demonstrated
1.0-4 transit priority general vehicle pre-emption.
calls
6.0- 3 Time-stamped Yes In|Sync would report this event as a Demonstrated
1.0-5 railroad general vehicle pre-emption unless the
preemption rail preemption was triggered by a
calls specific rail preemption controller pin.
6.0- 5 Time-stamped Yes In|Sync supports this capability. In|Sync Demonstrated
1.0-6 start and end of time-stamps all start and end times by
each phase monitoring the green status of the lights.
6.0- 5 Time-stamped Yes In|Sync supports this capability. In|Sync Demonstrated
1.0-7 controller time-stamps all changes in period length
interval and the start and end times of each
changes phase.

SERIAL 15058-RFP
6.0- 5 Time-stamped Yes In|Sync eliminates transition, through its Demonstrated
1.0-8 start and end of improved methodology of non ring-
each transition based operations. Groups of In|Sync
to a new processors change from one
timing plan configuration to the next using a time-
of-day schedule with no transition.
6.0-2 5 The ASCT 4.11.0-4 Yes Each local In|Sync processor stores data Demonstrated
shall export its for the intersection locally. This data
systems log in can be downloaded remotely and
the following opened in MS Excel, any text viewer, or
formats: a csv reader software.
* MS Excel The system operator needs
* Text to store all operational
* CSV data and signal timing
parameters calculated by
* Open source
the adaptive system, and
SQL database
export selected data to a
networked drive on the
signal system.
6.0-3 5 The ASCT 4.11.0-4 Yes Each local In|Sync processor stores Demonstrated
shall store the configurations, traffic volume counts
event log for a and queue and first-vehicle delay data
minimum of 10 for each phase for the past 30 days. This
days. data can be auto-archived to a computer
or server to keep a running database as
far back as desired.
The system operator needs
to store all operational
data and signal timing
parameters calculated by
the adaptive system, and
export selected data to a
networked drive on the

SERIAL 15058-RFP
signal system.
6.0-4 5 The ASCT 4.11.0-2 Yes In|Sync stores 30 days of data on the Demonstrated
shall store processor for each intersection;
results of all however, data can be archived on a
signal timing regular basis, providing event data for as
parameter long as desired. In|Sync constantly
calculations for measures and logs queue and first-
a minimum of vehicle delay for all movements. This
10 days. allows In|Sync to report MEASURED
performance, not just estimated
performance. Using tools such as Data
Visualization, delay, stops, and volumes
can be reviewed for any intersection in
the system at any time.
The system operator needs
to store and report data
used to calculate signal
timing and have the data
available for subsequent
analysis.
4.11.0-3
The system operator needs Yes In|Sync constantly measures and logs Demonstrated
to store and report data queue and first-vehicle delay for all
that can be used to movements. This allows In|Sync to
measure traffic report MEASURED performance, not
performance under just estimated performance. Using tools
adaptive control. such as Data Visualization, delay, stops,
and volumes can be reviewed for any
intersection in the system at any time.

SERIAL 15058-RFP
6.0-5 4 The system 4.11.0-2 Yes Each local In|Sync processor stores all Demonstrated
shall store the such data in local csv files for each of
following the past 30 days. This data can be auto-
measured data archived to a computer or server to keep
in user- a running database as far back as
specified desired. Arrivals on green and green
increments in band efficiency are not logged.
the form used
as input to
calculations for
a minimum of
6 months.
* Volume The adaptive system
* Occupancy needs to automatically
store and report data used
to calculate signal timing
and have the data
available for subsequent
analysis.
* Queue length 4.11.0-3
* Percent The adaptive system Yes In|Sync constantly measures and logs Demonstrated
arrival on needs to automatically queue and first-vehicle delay for all
green store and report data that movements. This allows In|Sync to
* Percent time can be used to measure report MEASURED performance, not
running traffic performance under just estimated performance. Using tools
adaptive adaptive control. such as Data Visualization, delay, stops,
and volumes can be reviewed for any
intersection in the system at any time.
* Average 4.11.0-7
Cycle Length
per intersection

SERIAL 15058-RFP
The adaptive system Yes In|Sync constantly measures and logs Demonstrated
needs to have the ability queue and first-vehicle delay for all
to generate historic and movements. This allows In|Sync to
real-time reports that report MEASURED performance, not
effectively support just estimated performance. Using tools
operation, maintenance such as Data Visualization, delay, stops,
and reporting of system and volumes can be reviewed for any
performance and traffic intersection in the system at any time.
conditions.
6.0-7 4 The ASCT 4.11.0-4 Yes Each In|Sync processor stores Demonstrated
shall provide configuration files and performance data
data storage for for the intersection it controls. There is
a system size no limit on the number of intersections,
of 50 signal and data can be auto-archived from each
controllers. In|Sync processor to a computer or
The data to be server at any frequency desired.
stored shall
include the
following:
* Controller The system operator needs
state data to store all operational
* Reports data and signal timing
* Log data parameters calculated by
* Security data the adaptive system, and
export selected data to a
* ASCT networked drive on the
parameters signal system.
6.0-8 4 The ASCT 4.11.0-7 Yes In the event that detector failure occurs, Demonstrated
shall calculate In|Sync issues email or SMS alarms to
and report user-specified recipients and stores the
relative data failure notification in a searchable,
quality achievable and exportable log.
including:

SERIAL 15058-RFP
* The extent Have the ability to
data is affected generate historic and real-
by detector time reports that
faults effectively support
* Other operation, maintenance
applicable and reporting of system
items performance and traffic
conditions.
6.0-9 3 The ASCT 4.11.0-7 Yes Any time period can be entered into Demonstrated
shall report In|Sync’s WebUI and a report shall be
comparisons of created for that time period. To compare
logged data any period to any other period, the user
when would simply open up a second window
requested by in their web browser and select the
the user: desired comparison period.
* Day to day Have the ability to
* Hour to hour generate historic and real-
* Hour of day time reports that
to hour of day effectively support
* Hour of operation, maintenance
week to hour and reporting of system
of week performance and traffic
* day of week conditions.
to day week
* Day of year
to day of year
6.0-10 3 The ASCT 4.11.0-4 Yes In|Sync's free external software Demonstrated
shall store data application can be used to accommodate
logs in this requirement with user-defined data
standard retrieval.
databases The system operator needs
to store all operational
data and signal timing

SERIAL 15058-RFP
parameters calculated by
the adaptive system, and
export selected data to a
networked drive on the
signal system.
6.0-11 3 The ASCT 4.11.0-7 Yes In|Sync's web-based user interface can Demonstrated
shall report output current graphs of traffic data and
stored data in a historical movements in real-time and
form suitable compare against live video feeds of
to provide traffic which depict In|Sync's adaptive
explanations of processes.
system Have the ability to
behavior to generate historic and real-
public and time reports that
politicians and effectively support
to troubleshoot operation, maintenance
the system. and reporting of system
performance and traffic
conditions.
7 7 Advanced
Controller
Operation
7.0-1 4 When 4.9.0-1.0-1 Yes In|Sync can be configured to meet this Demonstrated
specified by requirement.
the user, the Service a phase more than
ASCT shall once per cycle, such as
display a running a left turn phase
vehicle phase before and after its
more than once opposing through
for each time movement
the coordinated
phase is
served.

SERIAL 15058-RFP
7.0-2 4 The ASCT 4.9.0-1.0-2 Yes The controller is responsible for Demonstrated
shall provide a instituting overlaps. In|Sync must have
minimum of 8 at least eight detector phases in which to
phase overlaps. submit adaptive detector calls.
Operate at least 8 overlap
phases
7.0-3 5 The ASCT 4.9.0-1.0-3 Yes In|Sync can accommodate eight detector Demonstrated
shall phases to submit adaptive vehicle
accommodate detector calls, while the remaining
a minimum of phases can be used as dummy phases
8 phases at within the controller, which provide
each signal system detection information to the
central management or ATMS systems.
Operate four rings, 8
7.0-4 5 The ASCT phases and up to 4 phases Yes In|Sync does not operate using rings. Demonstrated
shall per ring. In|Sync dynamically chooses the next
accommodate phase to receive green based on live
a minimum of demand.
4 rings at each
signal.
7.0-5 5 The ASCT Yes In|Sync does not operate rings so Demonstrated
shall In|Sync can accommodate any number
accommodate of phases. In|Sync dynamically chooses
a minimum of the next phase to receive green based on
4 phases per live demand.
ring
7.0-6 4 The ASCT 4.1.0-6 Yes In|Sync chooses from 16 user-defined Demonstrated
shall provide a sequences for each signal.

SERIAL 15058-RFP
minimum of 16 The system operator needs
different user- to modify the sequence of
defined phase phases to support the
sequences for various operational
each signal. strategies. For example,
the ability to omit or skip
a phase under some traffic
conditions or based on
external input to allow a
shorter cycle length to
operate, or to provide
additional time to other
phases; the ability to
maintain coordination
with external movements
by preventing phases from
being skipped, or by
omitting phases, based on
time-of-day, external
input or when certain
phase sequences are in
operation.
4.9.0-1.0-4
The ability to operate
7.0- 4 Each different phase sequences Yes In|Sync chooses from 16 user-defined Demonstrated
6.0-1 permissible based on different traffic sequences for each signal.
phase sequence conditions or by time-of-
shall be user- day
assignable to
any signal
timing plan.

SERIAL 15058-RFP
7.0- 4 Each Yes In|Sync chooses from 16 user-defined Demonstrated
6.0-2 permissible sequences for each signal and may
phase sequence executable by a time of day schedule.
shall be
executable by a
time of day
schedule.
7.0- 4 Each Yes In|Sync dynamically chooses the next Demonstrated
6.0-3 permissible phase to receive green based on live
phase sequence queue and first-vehicle delay
shall be measurements.
executable
based on
measured
traffic
conditions
7.0-7 4 The ASCT 4.1.0-6 Yes The controller is responsible for Demonstrated
shall not instituting overlaps. In|Sync must have
prevent a at least eight detector phases in which to
phase/overlap submit adaptive detector calls.
output by time- The system operator needs
of-day. to modify the sequence of
phases to support the
various operational
strategies. For example,
the ability to omit or skip
a phase under some traffic
conditions or based on
external input to allow a
shorter cycle length to
operate, or to provide
additional time to other
phases; the ability to

SERIAL 15058-RFP
maintain coordination
with external movements
by preventing phases from
being skipped, or by
omitting phases, based on
time-of-day, external
input or when certain
phase sequences are in
operation.
7.0-8 4 The ASCT 4.1.0-6 Yes Automatically switching into alternate Demonstrated
shall not operations (i.e., event triggering) is an
prevent a important feature that is available with
phase/overlap In|Sync. In|Sync shall receive a binary
output based (on/off) signal from a device or
on an external controller, which shall trigger the
input. alternate configuration.
The system operator needs
to modify the sequence of
phases to support the
various operational
strategies. For example,
the ability to omit or skip
a phase under some traffic
conditions or based on
external input to allow a
shorter cycle length to
operate, or to provide
additional time to other
phases; the ability to
maintain coordination
with external movements
by preventing phases from
being skipped, or by

SERIAL 15058-RFP
omitting phases, based on
time-of-day, external
input or when certain
phase sequences are in
operation.
4.17.0-2
The system needs to react Yes Automatically switching into alternate Demonstrated
to commands issued by an operations (i.e., event triggering) is an
external decision support important feature that is available in
system or an Integrated In|Sync. In|Sync shall receive a binary
Corridor Management (on/off) signal from a device or
system, commanding the controller, which shall trigger the
ASCT to initiate a flush alternate configuration. This can
plan. This flush plan shall alternate configuration be an adaptive or
remain in operation until non-adaptive configuration.
the command from the
external source is
removed.
7.0-9 5 The ASCT 4.1.0-6 Yes Any phase can be utilized as a Demonstrated
shall not coordinated phase with In|Sync.
prevent user- The system operator needs
specified to modify the sequence of
phases to be phases to support the
designated as various operational
coordinated strategies. For example,
phases. the ability to omit or skip
a phase under some traffic
conditions or based on
external input to allow a
shorter cycle length to
operate, or to provide
additional time to other

SERIAL 15058-RFP
phases; the ability to
maintain coordination
with external movements
by preventing phases from
being skipped, or by
omitting phases, based on
time-of-day, external
input or when certain
phase sequences are in
operation.
4.9.0-1.0-9
The ability to designate
certain phases as
coordinated phases
7.0-10 The ASCT 4.9.0-1.0-12 Yes In|Sync evaluates early service based on Demonstrated
shall have the real-time queue measurement. If
option for a determined optimal by the adaptive
coordinated algorithm, In|Sync shall release the
phase to be coordinated movement early.
4 released early Allow the coordinated
based on a phase to terminate early if
user-definable the coordinated platoon is
point in the short.
phase or cycle.
7.0-11 5 The ASCT 4.9.0-1.0-15 Yes In|Sync is compatable with flashing Demonstrated
shall not yellow arrow left-turn signals.
prevent the Use flashing yellow arrow
controller from to control permissive left
displaying turns.
flashing yellow
arrow left turn.

SERIAL 15058-RFP
7.0-12 4 The ASCT 4.9.0-1.0-11 Yes In|Sync’s video detection actively Demonstrated
shall not optimizes passage time for all phases.
prevent the This is accomplished in the In|Sync
local signal processor and not in the controller so
controller from In|Sync can impact its dynamic
performing sequencing in real-time and not be
actuated phase relegated to traffic responsive
control using sequencing operations.
20 The ability to separately
extension/pass monitor each lane on an
age timers as approach and take
assigned to different action depending
user-specified on the conditions
vehicle measured in each lane.
detector input This may be implemented
channels in the in the signal controller
local using 20
controller. extension/passage timers,
7.0- 4 The ASCT which may be assignable Yes In|Sync meets this requirement. Demonstrated
12.0-1 shall operate to each vehicle detector
adaptively input channel. This may
using user- allow the adaptive
specified operation to be based on
detector data from a specific
channels. detector, or by excluding
specific detectors.
8 8 Pedestrians

SERIAL 15058-RFP
8.0-2 5 When the 4.6.0-2 Yes Unlike ring-based controllers and ring- Demonstrated
pedestrian based adaptive systems, which can be
phase is called, thrown into transition by a pedestrian
the ASCT shall call, In|Sync incorporates pedestrian
accommodate service into its coordinated operations.
pedestrian In|Sync shall serve pedestrian phases at
crossing times a time when required the pedestrian
during crossing time can be given without
adaptive interfering with the coordinated
operations. movement.
The system operator needs
to accommodate
infrequent pedestrian
operation while
maintaining adaptive
operation. Pedestrian
phases are rarely called in
the study area.
Intersections with the
most pedestrian activity
include 99th, 91st, and
84th Avenue. During early
mornings, evenings and
parts of the weekends
when traffic is light, a
lower cycle length may be
applicable. If there is a
cycle length that would
provide good two-way
progression and
accommodate all
movements at all
intersections equitably,

SERIAL 15058-RFP
but cannot accommodate
all pedestrian movements
on all phases and stay in
coordination, the system
shall allow the lower cycle
length through the
following actions. The
maximum green time may
be set lower than the sum
of pedestrian walk and
clearance times, and still
allow the pedestrian phase
to operate by extending
the green time when
necessary without
throwing the system out of
coordination.
8.0-6 2 When 4.9.0-1.0-13 Yes In|Sync constantly reviews the existing Demonstrated
specified by demand for all phases and schedules out
the user, the time and the best sequence to minimize
ASCT shall delay. Planning and scheduling is done
execute second-by-second. The start time of a
pedestrian non-coordinated phase is adjusted in
recall on real-time based on the demand present
pedestrian at that moment.
phase adjacent Allow flexible timing of
to coordinated non-coordinated phases
phases. (such as late start of a
phase) while maintaining
coordination.
9 9 Special
Functions

SERIAL 15058-RFP
9.0-1 2 The ASCT 4.9.0-1.0-11 Yes In|Sync does not preschedule time; Demonstrated
shall set a rather, it continuously analyzes how
specific state much time is left before the subsequent
for each coordinated movement and calculates
special sequences and phase lengths using real-
function output time data. This evaluation is done live,
based on the with current queued traffic, by lane.
occupancy on a The ability to separately
user-specified monitor each lane on an
detector. approach and take
different action depending
on the conditions
measured in each lane.
This may be implemented
in the signal controller
using 20
extension/passage timers,
which may be assignable
to each vehicle detector
input channel. This may
allow the adaptive
operation to be based on
data from a specific
detector, or by excluding
specific detectors.
4.17.0-1
The system operator needs Yes In|Sync meets this requirement. Demonstrated
to be able to turn on signs Processors can be monitored and
that control traffic or controlled via web browser with correct
provide driver information login credentials and appropriate
when specific traffic network access using any laptop or
conditions occur, when tablet with an internet connection.
needed to support the

SERIAL 15058-RFP
adaptive operation, when
congestion is detected at
critical locations or
according to a time-of-day
schedule
9.0-3 2 The ASCT 4.17.0-1 Yes This functionality could be Demonstrated
shall set a accomplished by quereing data from
specific state specifed In|Sync processors, and
for each incorporating the data into the driver
special information system.
function output The system operator needs
based on a to be able to turn on signs
time-of-day that control traffic or
schedule. provide driver information
when specific traffic
conditions occur, when
needed to support the
adaptive operation, when
congestion is detected at
critical locations or
according to a time-of-day
schedule.
10 10 Detection
10.0-1 5 The ASCT Yes In|Sync works with traditional detector Demonstrated
shall be calls and can receive them from any
compatible technology submitting vehicle presence
with the calls to the controller, including loops,
following video, and many others.
detector
technologies:
* Existing
standard loop
detectors

SERIAL 15058-RFP
* Existing
video detection
* Furnished
Detection
11 11 Railroad
and EV Pre-
emption
11.0-2 5 The ASCT 4.13.0-2 Yes In|Sync maintains adaptive operation at Demonstrated
shall maintain non-preempted intersections during
adaptive emergency vehicle preemption.
operation at The system operator needs
non-preempted to accommodate
intersections emergency vehicle
during preemption. When an
emergency intersection responds to an
vehicle EV preemption, other
preemption. signals within the
11.0-4 5 The ASCT coordinated group Yes In|Sync releases control to the controller Demonstrated
shall operate continue to operate during preemptive events while still
normally at adaptively. The preempted utilizing adaptive algorithms in the
non-preempted signal returns to adaptive background. As soon as the preemption
signal control once the releases, the adaptive algorithm then
controllers preemption is released. takes control. There is no transition.
when special
functions are
engaged by a
preemption
event. (An
example of
such a special
functions is a
phase omit, a
phase

SERIAL 15058-RFP
maximum
recall or a fire
route.)
11.0-6 5 The ASCT Yes In|Sync releases control to the controller Demonstrated
shall return to during preemptive events and resumes
normal adaptive control when preemptions are
adaptive released. And operates normally at non-
operation when preempted signals.
preemption of
a signal
controller is
released.
12 12 Transit Not Used
Priority
13 13 Failure
Events and
Fallback
13.1 13.1 Detector
Failure
13.1.0- 3 The ASCT 4.14.0-1 Yes In|Sync processors communicate via a Demonstrated
1.0-1 shall release distributed network. Using CentralSync
control to or the WebUI web-based software,
central system changes can be made to In|Sync
control. configuration files. When a
configuration is updated on one
processor, all other processors receive
the update. In|Sync can control
significantly more than 50 signals
concurrently.
The system operator needs

SERIAL 15058-RFP
13.1.0- 3 The ASCT to have a fallback state Yes In|Sync accounts for multiple levels of Demonstrated
1.0-2 shall release that allows coordination detector failure, using historical green
control to local using a common cycle split service information before falling
operations to length for all signals back to non-adaptive operations if
operate under within a coordinated prompted by the controller.
its own time- group, without causing
of-day disruption to traffic flow,
schedule. in the event of equipment,
13.1.0- 4 The ASCT communications and Yes In|Sync handles detector failure Demonstrated
2 shall use the software failure. For automatically and utilizes historical data
following example, if the for failed detectors.
alternate data communications link to
sources for the Peoria TMC fails, a
operations in defined boundary of the
the absence of ASCT could continue to
the real-time operate adaptively.
data from a Alternatively, if the
detector: communications link to
* Data from a the Glendale TMC fails, a
user-specified defined boundary of the
alternate ASCT could operate non-
detector. adaptively based on
* Historical system operator
data gathered preference. The system
by the adaptive shall recognize a detector
system prior failure and take
to the detector appropriate action to
failure. accommodate the missing
13.1.0- 4 The ASCT data. For a local detector Yes When using In|Sync’s product option set Demonstrated
2.0-1 shall switch to failure, the local controller In|Sync: Fusion (combining In|Sync’s
the alternate shall place a soft recall or video detection with WSDOT’s existing
source in real maximum recall (to be stop-bar detection). In|Sync can use the
time without user-specified) on the specified detector if In|Sync’s video

SERIAL 15058-RFP
operator appropriate phase, and detection camera is not functioning.
intervention. issue an alarm. For a Otherwise In|Sync shall fall back to
detector that influences using historical green durations to serve
the adaptive operation the intersection.
(e.g., a system detector),
the system shall use data
from an alternate (user-
specified) detector, such
as in an adjacent lane or at
an appropriate upstream
or downstream location. If
the number of detector
failures within a specified
group exceeds a user-
specified threshold, the
system shall cease
adaptive operation and go
to a fallback operation
specified by the user (such
as time-of-day operation
or free operation). The
fallback operation shall be
specified by the user
based on location and time
of day.
13.1.0- 4 In the event of 4.12.0-1 Yes In|Sync system can be configured to Demonstrated
3 a detector send email/text message alerts at the
failure, the frequencies desired.
ASCT shall The system operator needs
issue an alarm to immediately notify
to user- maintenance and
specified operations staff of alarms
recipients. To and alerts.

SERIAL 15058-RFP
issue an alarm, 4.12.0-2
the ASCT shall The system operator needs
send an email, to immediately and
text message, automatically pass alarms
etc. to and alerts to the respective
recipients MaxView, TranSuite, or
authorized to KITS systems.
receive each
alarm.
13.1.0- 5 In the event of 4.12.0-3 Yes In|Sync logs all operations including Demonstrated
4 a failure, the failure into a csv file stored on the local
ASCT shall log In|Sync processor. This file is kept for
details of the 30 days, and can be auto-archived to a
failure in a computer or server.
permanent log. The system operator needs
to maintain a complete log
of alarms and failure
events.
13.1.0- 5 The permanent 4.12.0-3 Yes In|Sync exports searchable, achievable Demonstrated
5 failure log and exportable csv data files.
shall be The system operator needs
searchable, to maintain a complete log
archivable, and of alarms and failure
exportable. events.
13.2 13.2
Communicati
ons Failure

SERIAL 15058-RFP
13.2-1 5 The ASCT 4.14.0-1 Yes During loss of communication, In|Sync Demonstrated
shall execute relies on historical tunnel data to keep
user-specified coordination between intersections and
actions when maintains a form of time-based adaptive
communication coordination. Each intersection is
s to one or notified that a communication failure
more signal has occurred at some point along the
controllers corridor and reacts by using the
fails within a historical tunnel and period length data.
group. All local adaptive functions continue to
work including the dynamic split
allocations.
The system operator needs
to have a fallback state
13.2- 2 In the event of that allows coordination Yes In|Sync is the ONLY adaptive system Demonstrated
1.0-1 loss of using a common cycle with effective mitigation for
communication length for all signals communication failure. The In|Sync
to a user- within a coordinated architecture is distributed and therefore,
specified group, without causing the intelligence resides locally at the
signal disruption to traffic flow, intersection.
controller, the in the event of equipment,
ASCT shall communications and
release control software failure. For
of all signal example, if the
controllers communications link to
within a user- the Peoria TMC fails, a
specified group defined boundary of the
to local ASCT could continue to
control. operate adaptively.
Alternatively, if the
13.2- 5 The ASCT Yes In the event of detector failure, In|Sync Demonstrated
communications link to
1.0-2 shall switch to automatically switches to alternate
the Glendale TMC fails, a
the alternate operation relying on historical data until
defined boundary of the
operation in detection is restored.

SERIAL 15058-RFP
real time ASCT could operate non-
without adaptively based on
operator system operator
intervention. preference. If a
communication failure
prevents the adaptive
system from continuing to
control one or more
intersections within a
defined group, the signals
within the group shall
revert to an appropriate,
user-specified fallback
mode of operation, either
time-of-day operation or
free operation. The
fallback mode shall be
specified by the user
based on location and time
of day.
13.2-2 5 In the event of 4.12.0-1 Yes In|Sync system can be configured to Demonstrated
a detector send email/text message alerts at the
failure, the frequencies desired.
ASCT shall The system operator needs
issue an alarm to immediately notify
to user- maintenance and
specified operations staff of alarms
recipients. To and alerts.
issue an alarm, 4.12.0-2
the ASCT shall The system operator needs
send an email, to immediately and
text message, automatically pass alarms
etc. to and alerts to the respective

SERIAL 15058-RFP
recipients MaxView, TranSuite, or
authorized to KITS systems.
receive each
alarm.
13.2-3 5 The ASCT 4.12.0-1 Yes In|Sync system can be configured to Demonstrated
shall issue an send email/text message alerts at the
alarm within 1 frequencies desired.
minute of The system operator needs
detection of a to immediately notify
failure. maintenance and
operations staff of alarms
and alerts.
4.12.0-2
The system operator needs
to immediately and
automatically pass alarms
and alerts to the respective
MaxView, TranSuite, or
KITS systems.
13.2-4 5 In the event of 4.12.0-3 Yes In|Sync logs all operations including Demonstrated
a failure into a csv file stored on the local
communication In|Sync processor. This file is kept for
s failures, the 30 days, and can be auto-archived to a
ASCT shall log computer or server.
details of the The system operator needs
failure in a to maintain a complete log
permanent log. of alarms and failure
events.

SERIAL 15058-RFP
13.2-5 5 The permanent 4.12.0-3 Yes In the event that detector failuer occurs, Demonstrated
failure log In|Sync issues email or SMS alarms to
shall be user-specified recipients and stores the
searchable, failure notification in a searchable,
archivable, and achievable and exportable log.
exportable. Communication link failures between
individual intersections are discernible
to the In|Sync system and In|Sync is
capable of issuing an alarm to users via
email and SMS text message, as long as
the communications path from at least
one In|Sync intersection and the TMC is
capable of propagating the message. The
network administrator’s hosting
hardware supporting the
communications shall detect the lack of
communications with each
intersection’s Ethernet switching device.
In turn, the network’s hosting hardware
should issue an alarm to a user-specified
list of recipients.
The system operator needs
to maintain a complete log
of alarms and failure
events.
13.3 13.3 Adaptive
Processor
Failure
13.3-1 5 The ASCT 4.14.0-1 Yes The controller must have a free Demonstrated
shall execute configurable pin to relate the need to fall
user-specified back to the controller's operation.
actions when The system operator needs
adaptive to have a fallback state

SERIAL 15058-RFP
control fails: that allows coordination
13.3- 5 The ASCT using a common cycle Yes The controller must have a free Demonstrated
1.0-1 shall release length for all signals configurable pin to relate the need to fall
control to within a coordinated back to the controller's operation.
central traffic group, without causing
signal system disruption to traffic flow,
control. in the event of equipment,
13.3- 5 The ASCT communications and Yes Controllers may be programmed to Demonstrated
1.0-2 shall release software failure. For activate a user-configured free-mode pin
control to local example, if the to respond to the absence of ground-
operations to communications link to logic inputs from the detection sources.
operate under the Peoria TMC fails, a This activation directs the controller to
its own time- defined boundary of the transition from adaptive operations to
of-day ASCT could continue to the user’s preferred timing plan or max
schedule. operate adaptively. recall functionality.
Alternatively, if the
communications link to
the Glendale TMC fails, a
defined boundary of the
ASCT could operate non-
adaptively based on
system operator
preference. There are two
types of adaptive system
failures: failure of the
server or equipment that
operates the adaptive
algorithms; and inability
of the adaptive algorithms
to accommodate current
traffic conditions. If the
equipment that operates
the adaptive algorithms

SERIAL 15058-RFP
fails, the system shall
recognize the failure and
place the operation in an
appropriate, user-specified
fallback mode, either
time-of-day operation or
actuated free operation.
The fallback mode shall
be specified by the user
based on location and time
of day. The presence of
the adaptive processor
shall not inhibit the
normal operation of the
signal controller when it is
in fallback operation. The
adaptive system makes its
decisions based largely on
detector information.
Occasionally, as the result
of an incident or other
event outside the control
of the system and outside
the area covered by the
system, congestion shall
propagate back into the
adaptive control area and
the measured traffic
conditions shall be outside
the range of data that can
be processed by the
system. In locations where
this is likely to occur, the

SERIAL 15058-RFP
intersection detectors, or
queue detectors installed
specifically for this
purpose, shall measure
increased occupancy. In
such cases, when user-
specified signal timing
and detector occupancy
conditions are met, the
system shall recognize
that its response to the
input data may not be
appropriate, and it shall
revert to an appropriate,
user-specified fallback
mode, either time-of-day
operation or free
operation. The fallback
mode shall be specified by
the user based on location
and time of day.
13.3-2 4 In the event of 4.12.0-1 Yes Extensive failure notification via SMS Demonstrated
adaptive or email is available including failed
processor detection and pedestrian actuation
failure, the hardware. Notification can be sent to
ASCT shall different technicians by TOD and TOW.
issue an alarm The system operator needs
to user- to immediately notify
specified maintenance and
recipients. operations staff of alarms
(This and alerts.
requirement 4.12.0-2

SERIAL 15058-RFP
may be The system operator needs
fulfilled by to immediately and
sending the automatically pass alarms
alarm to a and alerts to the respective
designated list MaxView, TranSuite, or
of recipients by KITS systems.
a designated
means, or by
using an
external
maintenance
management
system.
13.3-3 4 The permanent 4.12.0-3 Yes In|Sync exports searchable, achievable Demonstrated
failure log and exportable csv data files.
shall be The system operator needs
searchable, to maintain a complete log
archivable, and of alarms and failure
exportable. events.
13.3-4 4 During 4.14.0-1 Yes In the case of a CPU failure, detection Demonstrated
adaptive actuations are passed through to the
processor controller by a redundant circuit.
failure, the The system operator needs
ASCT shall to have a fallback state
provide all that allows coordination
local detector using a common cycle
inputs to the length for all signals
local within a coordinated
controller. group, without causing
disruption to traffic flow,
in the event of equipment,
communications and
software failure. For

SERIAL 15058-RFP
example, if the
communications link to
the Peoria TMC fails, a
defined boundary of the
ASCT could continue to
operate adaptively.
Alternatively, if the
communications link to
the Glendale TMC fails, a
defined boundary of the
ASCT could operate non-
adaptively based on
system operator
preference.
14 14 Software
14.0-1 5 The vendor's 4.15.0-2 Yes In|Sync meets this requirement. Demonstrated
adaptive Processors can be monitored and
software shall controlled via web browser with correct
be fully login credentials using any laptop or
operational tablet with an internet connection.
within the
following
platform:
* Linux The system operator needs
* Windows-PC to use equipment and
software acceptable under
current agency IT policies
and procedures.
14.0-2 5 The system 4.15.0-1.0-2 Yes In|Sync is compatible with all detector Demonstrated
shall interface technologies that submit detector calls
with detectors into the controller.
from all Preferred detector type:
manufacturers. video and loop detection.

SERIAL 15058-RFP
14.0-3 5 The system 4.15.0-1.0-1 Yes In|Sync is fully-compatible with any Demonstrated
shall interface controller/cabinet/detection type on the
with TS-2 market.
NTCIP and Preferred controller type:
Econolite TS-2 NTCIP, Econolite
ASC/3 ASC/3
controllers
controllers.
15 15 Training
15.0-1 The vendor 4.16.0-1 Yes Rhythm Engineering provides full Demonstrated
shall provide comprehensive training on installation,
the following monitoring and operation of In|Sync.
training. The agency needs all staff
15.0- 5 The vendor involved in operation and Yes Rhythm Engineering provides full Demonstrated
1.0-1 shall provide maintenance to receive comprehensive training on integration,
training on the appropriate training. The configuration, troubleshooting,
operations of operators shall already be monitoring and operation of In|Sync.
the adaptive experienced in setting up Extensive video training library (and
system. and fine tuning traditional user manuals) is also available to
coordinated signal augment in-person training.
15.0- 5 The vendor systems. They shall Yes Rhythm Engineering shall Meet this Demonstrated
1.0-2 shall provide require training specific to Requirement. Two years of technical
training on the adaptive system, support and additional training are
troubleshootin sufficient to allow them to provided with the purchase of In|Sync.
g the system. set up, adjust and fine tune

SERIAL 15058-RFP
15.0- 5 The vendor all aspects of the system. Yes Rhythm Engineering shall Meet this Demonstrated
1.0-3 shall provide Requirement. Rhythm Engineering
training on provides the training and course
preventive materials (Printed & Electronic
maintenance Installation and Maintenance, Web
and repair of User-Interface and CentralSync
equipment. software guides) throughout the
hardware installation and adaptive turn-
on processes. The user may invite as
many individuals as they deem
necessary to properly address this
requirement as well as hold the training
where the user desires. Additional
training beyond what is initially
provided covering all of the mentioned
topics.
15.0- 5 The vendor Yes Rhythm Engineering shall Meet this Demonstrated
1.0-4 shall provide Requirement. See response to
training on Requirement 15.0-1.0-3
system
configuration.
15.0- 5 The vendor Yes Rhythm Engineering shall Meet this Demonstrated
1.0-5 shall provide Requirement. See response to
training on Requirement 15.0-1.0-3
administration
of the system.
15.0- 5 The vendor Yes Rhythm Engineering shall Meet this Demonstrated
1.0-6 shall provide Requirement. See response to
training on Requirement 15.0-1.0-3
system
calibration.

SERIAL 15058-RFP
15.0- 5 The vendor's Yes All material including an extensive Demonstrated
1.0-7 training video training library shall be provided.
delivery shall
include:
printed course
materials and
references,
electronic
copies of
presentations
and references.
15.0- 4 The vendor's Yes Rhythm Engineering shall Meet this Demonstrated
1.0-8 training shall Requirement. Training locations are on
be delivered at site at the client's location and at the
each agency's project's traffic cabinet.
Traffic
Management
Center
15.0- 5 The vendor Yes Rhythm Engineering shall Meet this Demonstrated
1.0-9 shall provide a Requirement. Installation training
minimum of 3 includes four hours of in class training
day training to and four hours field training.
a minimum of Configuration training includes a one
10 staff for hour goal meeting, a one to two hour
each agency. CentralSync preliminary configuration
session and one day of driving the
corridor after the adaptive turn-on. Upon
project completion, an additional hour
of CentralSync training is provided
upon the explanation of the adaptive
corridor's final configuration.

SERIAL 15058-RFP
15.0- 5 The vendor Yes Rhythm Engineering shall provided the Demonstrated
1.0-10 shall provide a requested training onsite and/or
minimum of 2 remotely through training resources.
training
sessions over 6
months to each
agency.
16 16
Maintenance,
Support and
Warranty
16.0-1 5 The 4.16.0-2 Yes Standard InSync hardware warranty is Demonstrated
Maintenance guaranteed for two years. Extended
Vendor shall warranty for years 3-5 are available.
provide Rhythm shall repair or replace
maintenance malfunctioning equipment. All other
according to a maintenance is the responsibility of the
separate client.
maintenance The agency needs the
contract. That system to fulfill all
contract should requirements for the life
identify repairs of the system. The agency
necessary to therefore needs the system
preserve to be maintained to repair
requirements faults that are not defects
fulfillment, in materials and
responsiveness workmanship.
in effecting
those repairs,
and all
requirements
on the
maintenance

SERIAL 15058-RFP
provider while
performing the
repairs.
16.0-2 5 The Vendor 4.16.0-4 Yes Standard In|Sync software warranty is Demonstrated
shall provide guaranteed for two years including all
routine updates updates to the latest software releases.
to the software Extended warranty for years 3-5 are
and software available and also include the latest
environment updates.
necessary to The agency needs the
preserve the system to fulfill all
fulfillment of requirements for the life
requirements of the system. The agency
while the therefore needs support to
maintenance keep software and
contract is software environment
active. updated as necessary to
Preservation of prevent requirements no
requirements longer being fulfilled. The
fulfillment agency expects
especially maintenance of all
includes all IT adaptive system software
management for a period of 10 years
requirements shall be included in the
as previously purchase price. The
identified. The agency expects to operate
vendor shall this system using the latest
respond to software for a period of 10
requests for years. The agency shall
software seek technical support
maintenance from the vendor for

SERIAL 15058-RFP
within a 24- assistance in using the
hour period. adaptive software for the
life of the system.
16.0-3 5 The Vendor 4.16.0-3 Yes Rhythm warrants that all In|Sync Demonstrated
shall warrant hardware components shall be free of
the system to defects for a period of two (2) years
be free of from date of receipt by buyer, and all
defects in software or firmware furnished shall
materials and operate as designed and defined in user
workmanship manuals for two (2) years. Extended
for a period of warranties are available.
5 years. The agency needs the
Warranty is system to fulfill all
defined as requirements for the life
correcting of the system. The agency
defects in therefore needs the system
materials and to remain free of defects
workmanship in materials and
(subject to workmanship that result in
other language requirements no longer
included in the being fulfilled.
purchase Maintenance of all field
documents). equipment shall be
Defect is performed by contract
defined as any staff. Maintenance of the
circumstance following field equipment
in which the shall be performed by in-
material does house staff: controller
not perform cabinet assembly and all
according to its typical signal field

SERIAL 15058-RFP
specification. equipment.
The vendor
shall respond
to request for
hardware
maintenance
within a 24-
hour period.
16.0-4 5 The vendor Yes Configuration of the In|Sync system is Demonstrated
shall set up and included at no additonal charge. Rhythm
fine tune the Engineers are available 24 hours a day,
operation of 7 days per week to assist in continued
the ASCT prior refinements and updates to
to handover to configuration files.
the agency. The set up and fine tuning
of the system shall be
contracted out. A review
of the system's operation
shall be performed
quarterly. Complaints or
requests for changes in
operation shall be handled
by the in-house operators
on an as-needed basis.
17 17 Schedule
17.0-1 4 The ASCT 4.17.0-1 Yes In|Sync signals are organized into Demonstrated
shall set the groups. Each group of signals is
state of governed by a configuration file which
external is copied to every processor in that
input/output group. The configuration running at a
states given time of the day is defined by the
according to a time of day schedule defined within that
time-of-day configuration file.

SERIAL 15058-RFP
schedule. The system operator needs
17.0-2 4 The ASCT to be able to turn on signs Yes In|Sync signals are organized into Demonstrated
output states that control traffic or groups. Each group of signals is
shall be provide driver information governed by a configuration file which
settable when specific traffic is copied to every processor in that
according to a conditions occur, when group. The configuration running at a
time-of-day needed to support the given time of the day is defined by the
schedule adaptive operation, when time of day schedule defined within that
congestion is detected at configuration file.
critical locations or
17.0-3 4 The ASCT according to a time-of-day Yes In|Sync signals are organized into Demonstrated
operational schedule groups. Each group of signals is
parameters governed by a configuration file which
shall be is copied to every processor in that
settable group. The configuration running at a
according to a given time of the day is defined by the
Time of Day time of day schedule defined within that
schedule configuration file.
18 18
Performance
Measurement,
Monitoring
and Reporting
18.0-1 4 The ASCT 4.11.0-2 Yes All traffic conditions used to base signal Demonstrated
shall report state alterations are reported in a history
measures of log that can be viewed live on screen as
current traffic the adaptive processor makes the
conditions on decision, in a graphical format or
which it bases archived and exported to CSV format.
signal state The agency needs to
alterations.

SERIAL 15058-RFP
18.0-2 3 The ASCT maintain a complete Yes In|Sync calculates intermediate values, Demonstrated
shall report all record of the actions and which may be observed via the WebUI.
intermediate performance of the The result of those values is reported
calculated adaptive system. This and logged.
values that are shall allow staff to
affected by monitor the effectiveness
calibration of the system, and also
parameters. respond to requests for
18.0-3 4 The ASCT information and review Yes The In|Sync History Viewer maintains Demonstrated
shall maintain the operation when and displays such a log. Historical data
a log of all complaints are received. can also be downloaded as csv files, or
signal state The system shall maintain archived automatically to an agency
alterations a complete record of all its computer or server.
directed by the calculations, changes of
ASCT. output state, inputs
received from other
systems and commands to
local signal controllers.
All calculations that are
affected by calibration
parameters (including the
results of intermediate
calculations that are inputs
to optimization routines
and selection tables) shall
be reported, to facilitate
set-up, fine tuning and
trouble-shooting. The log
shall include a record of
all inputs received from
external sources, and all
external outputs generated
by the system. It shall also

SERIAL 15058-RFP
record the actual values of
all parameters that are
subject to a user-specified
maximum, minimum or
range.
4.11.0-7
Have the ability to
18.0- 4 The ASCT log generate historic and real- Yes Events that cause the controller to exit Demonstrated
3.0-1 shall include time reports that the free mode state of operation shall be
all events effectively support recorded and logged by the operation of
directed by the operation, maintenance the system.
external inputs. and reporting of system
18.0- 4 The ASCT log performance and traffic Yes InSync logs all external output changes Demonstrated
3.0-2 shall include conditions. The log shall from its processor.
all external be maintained on-line in a
output state format able to be queried
changes. by a user, for a user
18.0- 4 The ASCT log specified period. The log Yes Each In|Sync processor stores Demonstrated
3.0-3 shall include shall be able to be configuration files which define and
all actual exported in .csv or other track all parameters, including user-
parameter user-defined format for specified values.
values that are further analysis. The log
subject to user- shall be able to be
specified archived in .csv or other
values. user-defined format.
18.0- 4 The ASCT Yes In|Sync maintains records of operations Demonstrated
3.0-4 shall maintain for 30 days and can be archived for
the records in perpetuity.
this ASCT log
for a user-
defined period.

SERIAL 15058-RFP
18.0- 4 The ASCT Yes All history viewer logs can be archived Demonstrated
3.0-5 shall archive at any frequency and shall be stored for
the ASCT log 30 days on the local processor in CSV
in a user- format, which can be converted to SQL.
defined
manner.

SERIAL 15058-RFP
EXHIBIT C
“CLICK THROUGH” AGREEMENT
FOR TRAFFIC MANAGEMENT SOFTWARE
Below are terms and conditions applicable to the Traffic Management software (the “Software”) and related
services (all of the foregoing are collectively referred to herein as the “Services”) furnished by Rhythm Engineering,
LLC (“RHYTHM”), as well as the licensing terms for downloading, installing, accessing and using the Software made
available by RHYTHM in connection with the Services furnished pursuant to any agreement, purchase order and/or
license between RHYTHM and Customer (collectively, such terms and conditions and licensing terms are referred to
hereinafter as the “Terms & Conditions”). Please read the Terms & Conditions carefully before accessing or using the
Services or the Software. BY YOUR “CLICK” ON THE “AGREE AND CONTINUE” ICON AT THE END OF THE
TERMS & CONDITIONS AND BY ACCESSING OR USING THE SERVICES OR THE SOFTWARE, YOU
AND/OR THE ENTITY THAT YOU REPRESENT (REFERRED TO HEREIN AS THE “CUSTOMER” OR “YOU”)
AGREE AND ACKNOWLEDGE THAT YOU ARE AUTHORIZED TO AGREE TO AND BIND CUSTOMER TO
THESE TERMS & CONDITIONS AND ARE AGREEING TO BE LEGALLY BOUND BY ALL OF THE
PROVISIONS SET FORTH IN THESE TERMS & CONDITIONS. If You do not agree to (or cannot comply with) all
of the provisions of these Terms & Conditions, You do not have the right to download, install, access or use the
Services or the Software and must not download, install, access or use the Services or the Software. Notwithstanding
any provision of these Terms & Conditions to the contrary, if RHYTHM and Customer have entered into a
separate written agreement concerning the Services and/or the Software, the provisions of such separate written
agreement will prevail over any conflicting provisions of these Terms & Conditions.
1. DEFINITIONS: Certain capitalized terms used in these Terms & Conditions have the meanings set forth
below.
“Confidential Information” means any information relating to or disclosed in the course of the provision of
Services hereunder that is or should be reasonably understood to be confidential or proprietary to the disclosing
party including, without limitation, technical or non-technical data, product or service plans, developments,
processes, designs, techniques, devices, formulae, software (whether owned by, licensed by or sublicensed by a
party hereto and including both source and object code), business plans, and agreements with third parties.
“Confidential Information” shall not include information (1) already lawfully known to the receiving party at
the time of disclosure by the disclosing party, (2) generally known to the public through no act or fault of the
receiving party, or (3) lawfully obtained from any third party that, to the knowledge of the receiving party, has
no duty or obligation of confidentiality to the disclosing party with respect to such information.
“Software” means only the Software program made available by RHYTHM, and corresponding
documentation, associated media, printed materials, electronic documentation, and all updates, upgrades,
modifications, patches and the like made to or in connection with said Software program to the extent that such
items are not accompanied by a separate license agreement or terms and conditions of use. The Software is
proprietary to RHYTHM and is protected by intellectual property laws and treaties.
2. LICENSE:
(a) With respect to the Software, subject to Customer’s payment in full of all applicable fees, costs and
expenses required to be paid by Customer to RHYTHM in connection therewith, RHYTHM grants to
Customer a non-revocable, non-exclusive, assignable, limited license to the Software, in machine-
readable object code form only, to download, install, access and use the Software in connection with
the Services. The Software is licensed for use by Customer and may not be used for processing of
third-party data as a service bureau, application service provider or otherwise. Customer shall not
make any use of the Software in any manner not expressly permitted by these Terms & Conditions.
(b) Customer agrees: (1) not to remove any RHYTHM notices in the Software; (2) not to sell, transfer,
rent, lease or sub-license the Software or documentation to any third party (Cities and governmental
organizations identified in (c) below excluded); (3) not to alter or modify the Software; and (4) not to
reverse engineer, disassemble, decompile or attempt to derive source code from the Software, or
prepare derivative works therefrom.

SERIAL 15058-RFP
(c) Customer may not assign, transfer or sublicense all or part of these Terms & Conditions or the
Software without the prior written consent of RHYTHM, with the exception of Cities and
governmental organizations identified as having an interest in the Adaptive Signal Control
Technology deployment scope of work (see Exhibit B of agreement).
3. OWNERSHIP OF SOFTWARE/DATA: RHYTHM owns, and Customer acknowledges and agrees that
RHYTHM owns, the Software, including, without limitation, any and all worldwide copyrights, patents, trade secrets,
trademarks and proprietary and confidential information rights in or associated with the Software and upgrades,
updates, modifications, patches and the like related thereto. The Software is protected by copyright laws and
international copyright treaties, as well as other intellectual property laws and treaties. No ownership rights in the
Software are transferred to Customer. Customer agrees that nothing in these Terms & Conditions or associated
documents gives Customer any right, title or interest in the Software, except for the limited express rights granted in
Section 2 of these Terms & Conditions. All rights not specifically granted in these Terms & Conditions, including
Federal and International Copyrights, are reserved by RHYTHM. Additionally, RHYTHM owns, and Customer
acknowledges and agrees that RHYTHM owns, any and all data generated, collected, used and/or developed by the
Software. Customer agrees to reasonably cooperate with RHYTHM to make any and all data available to RHYTHM.
4. CUSTOMER’S OBLIGATIONS AND RESPONSIBILITIES - OTHER REQUIRED SOFTWARE,
HARDWARE, ETC.: Customer shall be solely responsible for obtaining and maintaining, at its own expense, all
software, hardware (including without limitation network systems), telephonic or other communications circuits, and
Internet Service Provider relationships that are necessary or appropriate for Customer to properly access and use any
Services or the Software. RHYTHM shall have no responsibility or liability for any unavailability or failure of, or
nonconformity or defect in, any Services or the Software that is caused by or related in any manner to any failure of
Customer to obtain and maintain all such software, hardware, equipment, circuits and relationships.
5. CONFIDENTIALITY: Customer and RHYTHM each agree that, with respect to the Confidential
Information of the other party, during the term of the provision of the Services by RHYTHM to Customer, and for a
period of five (5) years (or in the case of any Confidential Information of a disclosing party that is a “trade secret,” for a
period of the longer of five (5) years or so long as such information remains a “trade secret” under applicable law)
thereafter, such recipient party shall at all times maintain the confidentiality of the other party’s Confidential
Information, using the same degree of care that such party uses to protect its own confidential information, but in any
event not less than reasonable care; and shall not use or disclose to any third party any such Confidential Information
(except in performance of the Services), except as may be required by law or court order. Each party shall be liable and
responsible for any breach of this Section committed by any of such party’s employees, agents, consultants, contractors,
representatives or anyone else who has gained access to such Confidential Information through the recipient party.
6. ACCEPTABLE USE OBLIGATIONS:
(a) Customer is responsible for any misuse of the Services and the Software. Therefore, Customer must
take all reasonable precautions to protect access and use of the Services and the Software.
(b) Customer shall not use the Services or the Software in any manner in violation of applicable law
including, but not limited to, by infringing or misappropriating intellectual property rights, including
copyrights, trademarks, service marks, software, patents and trade secrets.
(c) Customer shall not use the Services or the Software to engage in any of the following:
(i) Interfering with, gaining unauthorized access to or otherwise violating the security of
RHYTHM’s or another party’s server, network, personal computer, network access or
control devices, software or data, or other system, or to attempt to do any of the foregoing,
including, but not limited to, use in the development, distribution or execution of Internet
viruses, worms, denial of service attacks, network flooding or other malicious activities
intended to disrupt computer services or destroy data;
(ii) Interfering with RHYTHM’s network or the use and enjoyment of the Services or the
Software received by other authorized customers of RHYTHM;

SERIAL 15058-RFP
(iii) Violating personal privacy rights;
(iv) Engaging in any activities that RHYTHM believes, might be harmful to RHYTHM’s
operations, public image or reputation. Rhythm shall give Customer notice of its belief of
improper activities, and Customer shall have three (3) days from its receipt of the notice to
respond, and offer remedy if appropriate.
7. SERVICE SUSPENSION FOR VIOLATIONS: In the event of any default by Customer in the payment of
any amounts when due to RHYTHM as specified on the applicable invoice(s) from RHYTHM, which default continues
unremedied for at least five (5) business days following notice from RHYTHM of such default, RHYTHM shall have
the right to immediately suspend or terminate Customer’s right of use of the Services or the Software or block access
thereto (each such circumstance, a “Service Suspension”) unless and until such default, and any and all other defaults
by Customer under these Terms & Conditions, shall have been cured. RHYTHM may institute a Service Suspension
upon at least seven (7) calendar days’ prior written notice to Customer in the case of any other violation of these Terms
& Conditions, and may do so without notice for any of the following reasons: (a) in response to a court order or
government notice that certain conduct must be stopped or (b) when RHYTHM reasonably determines: (1) that it may
be exposed to sanction, civil liability or prosecution; (2) that such violation may cause harm to or interfere with the
integrity or normal operations or security of RHYTHM’s network or networks with which RHYTHM is interconnected
or interfere with another of RHYTHM’s customer’s use of RHYTHM services or software products; or (3) that such
violation otherwise presents imminent risk of harm to RHYTHM or other of RHYTHM’s customers or their respective
systems or employees. Any such Service Suspension shall continue unless and until such violation, and any and all
other defaults by Customer, shall have been cured to the satisfaction of RHYTHM. Customer is responsible for all
charges or fees due to RHYTHM through the date the Service Suspension begins.
8. CUSTOMER CONTROLS THE TRAFFIC PLAN: Customer is in control of any and all traffic plans
and/or uses of the RHYTHM Software. Customer agrees it has reviewed and tested the Software before its use.
Customer takes full responsibility for the implementation, use and associated output from said use of the Software.
Warranty
Rhythm Engineering’s skilled technicians and engineers are available 24 hours a day, 7 days a week, 365 days a year.
During the five-year warranty period requested and recommended for this project, our team is available to assist with
any support needs you may have.
Rhythm Engineering manages In|Sync software updates approximately four times per year for partner agencies. Rhythm
Engineering shall schedule software updates on a client-preferred schedule basis.
Hardware
All In|Sync hardware components are guaranteed to be free of defects in materials or workmanship for two years from
the date of receipt by the buyer. If any failure to conform to the warranty appears within this period, Rhythm
Engineering shall repair or replace any defective parts at our option, upon notification at no cost to the buyer. (No
equipment shall be returned during the warranty period without Rhythm Engineering’s consent, which consent shall not
be unreasonably withheld.)
Services
All recommendations, guidance and performance of Rhythm staff shall reflect competent, professional knowledge and
judgment.
Software & Firmware
Rhythm Engineering warrants that all software or firmware furnished shall operate as
designed under regular uses defined in our user manuals for two years from the date of
receipt of system hardware by the buyer.
Claim Process
If any fault is found in any In|Sync component, agency staff should contact Technical
Support at (913) 227-0603. A service representative shall help diagnose and isolate the
issue immediately.
We stand by the quality &
effectiveness
of each In|Sync
component.

SERIAL 15058-RFP
Warranty Exclusions
This Warranty covers all Rhythm Engineering provided traffic cabinet components as well as video cameras and
camera enclosures sold as part of the system that fail for any reason except:
 Acts of God – Including, but not limited to – damage by lightning strikes, tornados, hurricanes, floods, etc.
 Errors or damage during installation or transportation
 Improperly maintained equipment
 Irregular power supplies – including but not limited to power surges
 Maliciousness or vandalism
 Accidents, incidents or collisions – including, but not limited to vehicular
For the best possible coverage, Rhythm Engineering strongly recommends the purchase of spare hardware at a 10%
level (i.e., one spare system for a purchase of ten, two spares for a purchase of 11-20, etc.)
Limitation of Warranty
Warranties are exclusive and in lieu of all other warranties, whether statutory, express or implied. Remedies provided
above are the buyer’s sole remedies for any failure by Rhythm Engineering to comply with its warranty obligations.
Correction of non-conformities in the manner and for the period of time provided herein shall constitute complete
fulfillment of all the liabilities of Rhythm Engineering for defective equipment, materials, services or
software/firmware, whether the claims by the buyer are based in contract, in tort (including negligence or strict liability)
or otherwise.
Limitation of Liability
Neither Rhythm Engineering nor its sub-contractors or suppliers of any tier shall be liable to the buyer for any special,
indirect, liquidated, incidental or consequential damage or loss, or for damage or loss of property or equipment not
furnished under a purchase order resulting therefrom on which the liability or claims of buyers are based. The remedies
set forth herein are exclusive; for each item of equipment, material, services or software/firmware, the total cumulative
liability of Rhythm Engineering under any purchase order accepted by Rhythm Engineering, or anything done in
connection therewith, shall be limited to the price of the item of equipment, material, services or software/firmware. In
all cases where buyer’s claim, whether based in contract, in tort (including negligence and strict liability), under any
warranty, or otherwise arises out of or in connection with the sale, delivery or use of defective equipment, material,
software/firmware or services supplied hereunder or damage resulting therefrom, buyer’s exclusive remedies and
Rhythm Engineering’s sole liability shall be limited to those specifically outlined in the warranty provision. The
provisions of this section, Limitation of Liability, shall also protect Rhythm Engineering suppliers and sub-contractors
and shall apply to the full extent permitted by law and regardless of fault and shall survive termination, cancellation or
expiration of the order.
The provisions of this section, Limitation of Liability, shall apply notwithstanding any other provision of the purchase
order.
The equipment, material and software/firmware are intended for use only for the purpose for which they were expressly
provided. With respect to any other use, Rhythm Engineering makes no representation or warranty and assumes no
liability of any kind where in contract or tort (including negligence and strict liability)
Replacement Parts
In|Sync’s hardware requires little maintenance and has similar needs to the maintenance needs of existing hardware
found in the traffic cabinet. Rhythm Engineering has found that partner agencies maintain the In|Sync video detection
cameras at the same frequency as traditional video detection systems. However, In|Sync’s cameras require less power
cycling field visits because of the user’s ability to remotely interact with the cameras using the In|Sync WebUI.
In the event of equipment failure covered under warranty, the responsible agency can contact Rhythm customer support
to begin a Return Merchandise Authorization (RMA) process wherein Rhythm’s quality control team shall receive and
test potentially damaged or defective equipment and provide replacement parts in an expeditious manner that meets the
agency’s expectation as defined in the requirements.

SERIAL 15058-RFP
Extended Support Options
Rhythm Engineering provides a two-year warranty and technical support with every purchase of In|Sync adaptive traffic
control (see In|Sync Warranty PDF). Deployment partners of Rhythm Engineering can extend the coverage using one of
the following plans. Support Plans are offered on a per-corridor basis.
Option #1: Software & Support Plan
This tier of support includes all software upgrades and fixes released during the plan period and a fixed amount of
Rhythm Engineering staff support time. The staff support time includes a retainer of two (2) hours of remote technical
or engineering support per intersection purchased per year. Hours are aggregated per corridor, and cannot be used to
support other corridors. This plan is available for $250 per intersection per year, payable in advance.
Option #2: Comprehensive Coverage Plan
This level of support includes everything in the Software and Support Plan plus unlimited remote technical and
engineering support time and hardware replacement for failed equipment. Defective or failed equipment must be
returned to Rhythm Engineering. Equipment may be replaced with new or refurbished equipment of equal or greater
functionality or repaired, at the discretion of Rhythm Engineering. This plan does not cover damage from incidents (e.g.
traffic collisions or power surges) or “acts of God” (e.g. lightning strikes). This plan is available to cover equipment up
to five years from the original date of shipping. The Comprehensive Coverage Plan is available for $750 per
intersection per year, payable in advance.
Standard Software & Comprehensive
Service & Equipment Offered Two-Year Support Plan Coverage Plan
Warranty $250/int/yr $750/int/year
In|Sync hardware & software guaranteed
X X
to operate as designed & purchased
Updates provided to maintain original
X X X
functionality as designed
Upgrades to provide new functionality, as
X X X
& when developed
Two hours per intersection of remote
X
technical & engineering support
Unlimited remote technical & engineering
X X
support
Hardware replacement (see above) X X
NOTE: Table is for informational purposes.

SERIAL 15058-RFP
Exhibit D
Office of Procurement Services Contractor Travel and Per Diem Policy
 All contract-related travel plans and arrangements shall be prior-approved by the County Contract
Administrator.
 Lodging, per diem and incidental expenses incurred in performance of Maricopa County/Special District
(County) contracts shall be reimbursed based on current U.S. General Services Administration (GSA) domestic
per diem rates for Phoenix, Arizona. Contractors must access the following internet site to determine rates (no
exceptions): www.gsa.gov
• Additional incidental expenses (i.e., telephone, fax, internet and copying charges) shall not be
reimbursed. They should be included in the contractor’s hourly rate as an overhead charge.
• The County will not (under no circumstances) reimburse for Contractor guest lodging, per diem or
incidentals.
 Commercial air travel shall be reimbursed as follows:
• Coach airfare will be reimbursed by the County. Business class airfare may be allowed only when
preapproved in writing by the County Contract Administrator as a result of the business need of the
County when there is no lower fare available.
• The lowest direct flight airfare rate from the Contractors assigned duty post (pre-defined at the time of
contract signing) will be reimbursed. Under no circumstances will the County reimburse for airfares
related to transportation to or from an alternate site.
• The County will not (under no circumstances) reimburse for Contractor guest commercial air travel.
 Rental vehicles may only be used if such use would result in an overall reduction in the total cost of the trip,
not for the personal convenience of the traveler. Multiple vehicles for the same set of travelers for the same
travel period will not be permitted without prior written approval by the County Contract Administrator.
• Purchase of comprehensive and collision liability insurance shall be at the expense of the contractor.
The County will not reimburse contractor if the contractor chooses to purchase these coverage.
• Rental vehicles are restricted to sub-compact, compact or mid-size sedans unless a larger vehicle is
necessary for cost efficiency due to the number of travelers. (NOTE: contractors shall obtain pre-
approval in writing from the County Contract Administrator prior to rental of a larger vehicle.)
• County will reimburse for parking expenses if free, public parking is not available within a reasonable
distance of the place of County business. All opportunities must be exhausted prior to securing
parking that incurs costs for the County. Opportunities to be reviewed are the DASH; shuttles, etc.
that can transport the contractor to and from County buildings with minimal costs.
• County will reimburse for the lowest rate, long-term uncovered (e.g. covered or enclosed parking will
not be reimbursed) airport parking only if it is less expensive than shuttle service to and from the
airport.
• The County will not (under no circumstances) reimburse the Contractor for guest vehicle rental(s) or
other any transportation costs.
 Contractor is responsible for all costs not directly related to the travel except those that have been pre-approved
by the County Contract Administrator. These costs include (but not limited to) the following: in-room movies,
valet service, valet parking, laundry service, costs associated with storing luggage at a hotel, fuel costs

SERIAL 15058-RFP
associated with non-County activities, tips that exceed the per diem allowance, health club fees, and
entertainment costs. Claims for unauthorized travel expenses will not be honored and are not reimbursable.
 Travel and per diem expenses shall be capped at 15% of project price unless otherwise specified in individual
contracts.
 Contractor shall provide, (upon request) with their invoice(s), copies of receipts supporting travel and per diem
expenses, and if applicable with a copy of the written consent issued by the Contract Administrator. No travel
and per diem expenses shall be paid by County without copies of the written consent as described in this policy
and copies of all receipts.

SERIAL 15058-RFP
Exhibit E
Special Federal Terms, Conditions and Documents
Maricopa County Small Business Enterprise Program
Participation Reporting Form
This form is to be submitted with each pay application or invoice. Any pay application or invoice without this form
attached is subject to rejection as not being a completed pay application or invoice pursuant to the terms of the
contract.
Name of Prime Consultant Contractor Contract No.
Contact Person Project No.
Street Address Amount of this Pay Application/ Invoice
City, State ZIP
Complete below with information on the SBE firms utilized as sub consultants/ subcontractors for this pay
application/ invoice. If work was self-performed and your firm, as the prime, is an SBE firm pursuant to
ARS.§ 41-1001, et seq then you may list your firm as the SBE firm.
Type Of Work $ Paid to SBE App./
SBE Firm Name SBE Firm Address
Performed Invoice
$
$
$
$
$
$
￿ A mark in this box certifies that no SBE firms were utilized as the prime, subconsultant or subcontractor with
respect to this pay application/ invoice.
Date: Signature:
Printed Name & Telephone Number

SERIAL 15058-RFP
**FOR USE ON FEDERAL AID PROJECTS WITHOUT GOALS**
(EPRISENGL, 03/15/11)
DISADVANTAGED BUSINESS ENTERPRISES:
1.0 Policy:
The Arizona Department of Transportation (hereinafter the Department) has established a Disadvantaged
Business Enterprise (DBE) program in accordance with the regulations of the U.S. Department of
Transportation (USDOT ), 49 CFR Part 26. The Department has received Federal financial assistance from
the U.S. Department of Transportation and as a condition of receiving this assistance, the Department has
signed an assurance that it will comply with 49 CFR Part 26.
It is the policy of the Department to ensure that DBEs, as defined in Part 26, have an equal opportunity to
receive and participate in USDOT-assisted contracts. It is also the policy of the Department:
1. To ensure nondiscrimination in the award and administration of USDOT-assisted contracts;
2. To create a level playing field on which DBEs can compete fairly for USDOT-assisted contracts
3. To ensure that the DBE program is narrowly tailored in accordance with applicable law;
4. To ensure that only firms that fully meet 49 CFR Part 26 eligibility standards are counted as DBEs;
5. To help remove barriers to the participation of DBEs in USDOT-assisted contracts; and
6. To assist in the development of firms that can compete successfully in the market place outside
the DBE program.
Local Public Agencies (LPA) and or sub-recipients of Federal financial assistance will administer and
manage the contracts from advertising, consultant selection, negotiation, contract execution, processing
payment reports and contract modifications, audits, DBE compliance (e.g., reporting and monitoring)
through contract closeout.
2.0 Assurances of Non-Discrimination:
The contractor, sub-recipient, or subcontractor shall not discriminate on the basis of race, color, sex or
national origin in the performance of this contract. The contractor shall carry out applicable requirements
of 49 CFR Part 26 in the award and administration of contracts. Failure by the contractor to carry out these
requirements is a material b r e a c h of this contract, which may result in the termination of this contract
or such other remedy as the state deems appropriate. The contractor, sub-recipient, or subcontractor shall
ensure that all subcontract agreements contain this non-discrimination assurance.
3.0 Definitions:
A. Disadvantaged Business Enterprise (DBE): a for-profit small business concern which meets both of
the following requirements:
1. Is at least 51 percent owned by one or more socially and economically disadvantaged individuals
or, in the case of any publicly owned business, at least 51 percent of the stock is owned by one or
more such individuals; and,
2. Whose management and daily business operations are controlled by one or more of the socially
and economically disadvantaged individuals who own it.
B. Socially and Economically Disadvantaged Individuals: any individual who is a citizen (or lawfully
admitted permanent resident) of the United States and who is:

SERIAL 15058-RFP
1.0 Any individual who is found to be a socially and economically disadvantaged individual on a
case-by-case basis.
2.0 Any individual in the following groups, members of which are rebuttably presumed to be socially
and economically disadvantaged:
i. Black Americans," which includes persons having origins in any of the Black racial groups of
Africa;
ii. "Hispanic Americans," which includespersons of Mexican, Puerto Rican, Cuban, Central or
South American, or other Spanish or Portuguese culture or origin, regardless of race;
iii. "Native Americans," which includespersons who are American Indians, Eskimos, Aleuts, or
Native Hawaiians;
iv. "Asian-Pacific Americans," which includes persons whose origins are from Japan, China,
Taiwan, Korea, Burma (Myanmar), Vietnam, Laos, Cambodia (Kampuchea), Thailand, Mala-
ysia, Indonesia, the Philippines, Brunei, Samoa, Guam, the U.S. Trust Territories of the Pacific
Islands (Republic of Palau), the Commonwealth of the Northern Marianas Islands, Macao,
Fiji, Tonga, Kiribati, Tuvalu, Nauru, Federated States of Micronesia, or Hong Kong;
v. "Subcontinent Asian Americans," which includes persons whose origins are from India,
Pakistan, Bangladesh, Bhutan, the Maldives Islands, Nepal or Sri Lanka;
vi. "Women;"
vii. Any additional groups whose members are designated as socially and economically
disadvantaged by the Small Business Administration (SBA), at such time as the SBA
designation becomes effective.
C. Joint Venture: an association of a DBE firm and one or more other firms to carry out a single, for-
profit business enterprise, for which parties combine their property, capital, efforts, skills and
knowledge, and in which the DBE is responsible for a distinct, clearly defined portion of the work of
the contract and whose share in the capital contribution, control, management, risks, and profits of the
joint venture are commensurate with its ownership interest.
D. Non-DBE: any firm that is not a DBE.
E. RACE-CONSCIOUS: a measure or program is one that is focused specifically on assisting only
DBEs, including women-owned DBEs.
F. RACE-NEUTRAL: a measure or program is one that is, or can be, used to assist all small
businesses. For the purposes ofthis part, race-neutral includes gender- neutrality.
4.0 Working with DBEs:
The Department works with DBEs and assists them in their efforts to participate in the highway construction
program. All bidders should contact the Business Engagement and Compliance Office at the address shown
below for assistance in their efforts to use DBEs in the construction program of the Department:
Arizona Department of Transportation
Business Engagement and Compliance Office
1135 N. 22nd Avenue (second floor), Mail Drop 154A
Phoenix, AZ. 85009
Phone: (602) 712-7761
FAX:(602) 712-8429

SERIAL 15058-RFP
5.0 Applicability:
The Department has established an overall annual goal for DBE participation on Federal-aid contracts. The
Department intends for the goal to be met with a combination of race conscious efforts and race neutral
efforts. Race conscious participation occurs where the contractor uses a percentage of DBEs, as defined
herein, to meet the contract-specified goal. Race neutral efforts are those that are, or can be, used to assist
all small businesses or increase opportunities for all small businesses. The regulation, 49 CFR 26, defines
race neutral as when a DBE wins a prime contract, is awarded a subcontract on a project without DBE
goals, and is awarded a subcontract from a prime contractor that did not consider the firm's DBE status.
The provisions are applicable to all bidders including DBE bidders.
6.0 Certification:
Certification as a DBE shall be predicated on:
1. The completion and execution of an application for certification as a "Disadvantaged Business
Enterprise".
2. The submission of documents pertaining to the firm(s) as stated in the application(s), including but not
limited to a statement of social disadvantage and a personal financial statement.
3. The submission of any additional information which the Department may require to determine the
firm's eligibility to participate in the DBE program.
4. The information obtained during the on-site visits to the offices of the firm and to active job-sites.
Applications for certification may be filed with the Department at any time. Both hardcopy submission and
online submission is available.
For hardcopy submissions, applications for certification are available at the Business Engagement and
Compliance Office, 1135 N. 22nd Avenue (second floor), mail drop 154A, Phoenix, Arizona 85009, phone
(602) 712-7761. Hardcopy applications may also be obtained through the internet at www.azdbe.org.
Hardcopy applications must be filed t h r o u g h the Business Engagement and Compliance Office at the
above address.
For online submissions, the online application process may be accessed through the internet at
www.azdbe.org.
DBE firms and firms seeking DBE certification shall cooperate fully with requests for information relevant
to the certification process. Failure or refusal to provide such information is a ground for denial or removal
of certification.
Arizona is a member of the AZ Unified Certification Program (AZUCP). Only DBE firms that are certified
by the AZUCP are eligible for credit on ADOT projects. A list of DBE firms certified by AZUCP is available
on the internet at www.azdbe.org. The list will indicate contact information and specialty for each DBE firm,
and may be sorted in a variety of ways.
However, ADOT does not guarantee the accuracy and/or completeness of this information, nor does ADOT
represent that any licenses or registrations are appropriate for the work to be done.
The Department's certification is not a representation of qualifications and/or abilities. The contractor bears
all risks that the firm may not be able to perform its work for any reason.

SERIAL 15058-RFP
7.0 General:
Each contractor shall establish a program that will ensure nondiscrimination in the award and administration
of contracts and subcontracts.
Each contractor shall also designate a full time employee who shall be responsible for the administration of
the contractor's DBE program.
Agreements between the bidder and a DBE in which the DBE promises not to provide subcontracting
quotations to other bidders are prohibited.
8.0 DBE Subcontractor Payment Reporting:
The Department is required to collect data on DBE and non-DBE participation to report to Department Of
Transportation on Federal-aid projects. Maricopa County Transport will notify the contractor that such
record keeping is required by the Department for tracking DBE participation.
The contractor shall submit a report on a monthly basis indicating the amounts earned by and paid to all
DBEs and non-DBEs working on the project. In addition, the contractor shall require that all DBE and non-
DBE subcontractors verify receipt of payment.
The contractor shall provide all such required information for the current month by the 5th of the
following month. The required information shall be submitted electronically through the Department's web-
based payment tracking system (https://arizonalpa.dbesystem.com).
9.0 Goals:
The Department has not established contract goals for DBE participation in this contract. Contractors are
still encouraged to employ reasonable means to obtain DBE participation. Contractors must retain records
in accordance with these DBE specifications. The contractor is notified that this record keeping is important
to the Department so that it can track DBE participation where only race neutral efforts are employed.
10.0 Crediting DBE Participation:
10.01 General Requirements:
Only the value of the work actually performed by the DBE can be credited toward DBE
participation. Credit is given only after the DBE has been paid for the work performed.
The contractor bears the responsibility to determine whether the DBE possesses the proper
contractor's license(s) to perform the work.
The Department's certification is not a representation of qualifications and/or abilities. The
contractor bears all risks that the DBE may not be able to perform its work for any reason.
A DBE may participate as a prime contractor, subcontractor, joint venture partner with either a prime
contractor or a subcontractor, or as a vendor of materials or supplies. A DBE joint venture partner
shall be responsible for a clearly defined portion of the work to be performed, in addition to meeting
the requirements for ownership and control.
The dollar amount of work to be accomplished by DBEs, including partial amount of a lump sum or
other similar item, shall be on the basis of subcontract, purchase order, hourly rate, rate per ton, etc.,
as agreed to between parties.
With the exception of bond premiums, all work must be attributed to specific bid items. Where
work applies to several items, the DBE contracting arrangement must specify unit price and
amount attributable to each bid item. DBE credit for any individual item of work performed by the
DBE shall be the lesser of the amount to be paid to the DBE or the prime contractor's bid price. If

SERIAL 15058-RFP
the amount bid by the DBE on any item exceeds the prime contractor's bid amount, the prime
contractor may not obtain credit by attributing the excess to other items.
Where more than one DBE is engaged to perform parts of an item (for example, supply and
installation), the total amount payable to the DBEs will not be considered in excess of the prime
contractor's bid amount for that item.
Bond premiums may be stated separately, so long as the arrangement between the prime
contractor and the DBE provides for separate payment not to exceed the price charged by the
bonding company.
DBE credit may be obtained only for specific work done for the project, supply of equipment
specifically for physical work on the project, or supply of materials to be incorporated in the work.
DBE credit will not be allowed for costs, such as overhead items, capital expenditures (for example,
purchase of equipment), and office items.
If a DBE performs part of an item (for example, installation of materials purchased by a Non-DBE),
the DBE credit shall not exceed the lesser of (1) the DBE's contract or (2) the prime contractor's bid
for the item, less a reasonable deduction for the portion performed by the Non-DBE.
When a DBE performs as a partner in a joint venture, only that portion of the total dollar value of
the contract which is clearly and distinctly performed by the DBE's own forces can be credited.
The contractor may credit second-tier subcontracts issued to DBEs by non-DBE subcontractors. Any
second-tier subcontract to a DBE must meet the requirements of a first-tier DBE subcontract.
All DBE and non-DBE subcontracting activity must be reported by the contractor. This includes
lower-tier subcontracting regardless of whether or not the DBE is under contract with another DBE.
A prime contractor may credit the entire amount of that portion of a construction contract that is
performed by the DBE's own forces. The cost of supplies and materials obtained by the DBE for
the work of the contract can be included so long as that cost is reasonable. Leased equipment may
also be included. No credit is permitted for supplies purchased or equipment leased from the prime
contractor or its affiliate(s).
When a DBE subcontracts a part of the work of its contract to another firm, the value of the
subcontract may be credited towards DBE participation only if the DBE's subcontractor is itself a
DBE and performs the work with its own forces. Work that a DBE subcontracts to a non-DBE firm
does not count towards DBE participation.
A prime contractor may credit the entire amount of fees or commissions charged by a DBE firm
for providing a bona fide service, such as professional, technical, consultant, or managerial
services, or for providing bonds or insurance specifically required for the performance of a
USDOT-assisted contract, provided the fees are reasonable and not excessive as compared with fees
customarily allowed for similar services.
10.02 Police Officers:
DBE credit will not be permitted for procuring DPS officers. For projects on which officers from
other agencies are supplied, DBE credit will be given only for the broker fees charged, and will
not include amounts paid to the officers. The broker fees must be reasonable.
10.03 Commercially Useful Function:
As a prime contractor, a DBE shall perform a significant portion of the contract work with its own
work force in accordance with normal industry practices and Subsection 108.01 - Subletting of
Contract of the Standard Specifications.

SERIAL 15058-RFP
A prime contractor can credit expenditures to a DBE subcontractor only if the DBE performs a
commercially useful function on the contract. A DBE performs a commercially useful function
when it is responsible for execution of the work of a contract and is carrying out its
responsibilities by actually performing, managing, and supervising the work involved. To perform
a commercially useful function, the DBE must also be responsible, with respect to materials and
supplies on the contract, for negotiating price, determining quality and quantity, ordering the
material, and installing (where applicable) and paying for the material itself. To determine
whether a DBE is performing a commercially useful function, the Department will evaluate the
amount of work subcontracted, industry practices, whether the amount the firm is to be paid under
the contract is commensurate with the work it is actually performing and the DBE credit claimed
for its performance of the work, and other relevant factors.
A DBE will not be considered to perform a commercially useful function if its role is limited to
that of an extra participant in a transaction contract, or project through which funds are passed in
order to obtain the appearance of DBE participation. In determining whether a DBE is such an
extra participant, the Department will examine similar transactions, particularly those in which
DBEs do not participate.
If a DBE does not perform or exercise responsibility for at least 30 percent of the total cost of
its contract with its own work force, or if the DBE subcontracts a greater portion of the work of a
contract than would be expected on the basis of normal industry practice for the type of work
involved, the Department will presume that the DBE is not performing a commercially useful
function.
When a DBE is presumed not to be performing a commercially useful function as provided above,
the DBE may present evidence to rebut this presumption. Decisions on commercially useful
function matters are subject to review by DOT, but are not administratively appealable to U.S.
DOT.
10.04 Trucking:
The Department will use the following factors in determining whether a DBE trucking company is
performing a commercially useful function. The DBE must be responsible for the management
and supervision of the entire trucking operation for which it is responsible on a particular
contract, and there cannot be a contrived arrangement for the purpose of meeting DBE goals.
The DBE must itself own and operate at least one fully licensed, insured, and operational truck
used on the contract on every day that credit is to be given for trucking.
The contractor will receive credit for the total value of transportation services provided by the
DBE using trucks it owns, insures and operates, and using drivers it employs.
The DBE may lease trucks from another DBE firm, including an owner-operator who is certified
as a DBE. The DBE who leases trucks from another DBE receives credit for the total value of the
transportation services.
The DBE may also lease trucks from a non-DBE firm, including an owner-operator. The DBE
who leases trucks from a non-DBE is entitled to credit for the total value of the transportation
services provided by non-DBE lessees not to exceed the value of transportation services provided by
DBE-owned trucks on the contract. Additional participation by non-DBE lessees results in credit
only for the fee or commission paid to the DBE as a result of the lease agreement.
Example: DBE Firm X uses two of its own trucks on contract. It leases two trucks from DBE
Firm Y and six trucks from non-DBE firm Z. DBE credit would only be awarded for the total
value of transportation services provided by Firm X and Firm Y, and may also be awarded for
the total value of transportation services provided by four of the six trucks provided by Firm Z. In
all, full credit would be allowed for the participation of eight trucks. With respect to the other two
trucks provided by Firm Z, D BE credit could be awarded only for the fees or commissions
pertaining to those trucks Firm X receives as a result of the lease with Firm Z.

SERIAL 15058-RFP
10.05 Materials and Supplies:
The Department will credit expenditures with DBEs for material and supplies as follows. If the
materials or supplies are obtained from a DBE manufacturer, 100 percent of the cost of the
materials or supplies is credited. A manufacturer is defined as a firm that operates or maintains a
factory or establishment that produces, on the premises, the materials, supplies, articles, or
equipment required under the contract, and of the general character described by the
specifications.
If the materials or supplies are purchased from a DBE regular dealer, 60 percent of the cost of
the materials or supplies is credited. A DBE regular dealer is defined as a firm that owns,
operates, or maintains a store or warehouse or other establishment in which the materials,
supplies, articles, or equipment of the general character described by the specifications and
required under the contract are bought, kept in stock, and regularly sold or leased to the public in
the usual course of business. To be a regular dealer, the firm must be an established, regular
business that engages, as its principal business and under its own name, in the purchase and sale
or lease of the products in question. A firm may be a DBE regular dealer in such bulk items as
petroleum products, steel, cement, stone or asphalt without owning, operating, or maintaining a
place of business, as provided above, if the person both owns and operates distribution
equipment for the products. Any supplementing of regular dealers' own distribution equipment
shall be by a long-term lease agreement, and not on an ad-hoc or contract-by-contract basis.
Packagers, brokers, manufacturers' representatives, or other persons who arrange or expedite
transactions are not regular dealers within the meaning of this paragraph and the paragraph
above.
With respect to materials or supplies purchased from a DBE which is neither a manufacturer nor
a regular dealer, the Department will credit the entire amount of the fees or commissions charged
by the DBE for assistance in the procurement of the materials and supplies, or fees or
transportation charges for the delivery of materials or supplies required on a job site, toward DBE
goals, provided the fees are determined to be reasonable and not excessive as compared with
fees customarily allowed for similar services. The cost of the materials and supplies themselves
may not be counted toward the DBE goal.
DBE credit for supplying paving grade asphalt and other asphalt products will only be permitted
for standard industry hauling costs, and only if the DBE is owner or lessee of the equipment and
trucks. Leases for trucks must be long term (extending for a fixed time period and not related to
time for contract performance) and must include all attendant responsibilities such as insurance,
titling, hazardous waste requirements, and payment of drivers.
11.0 Joint Checks:
11.01 Requirements:
A DBE subcontractor and a material supplier (or equipment supplier) may request permission for
the use of joint checks for payments from the prime contractor to the DBE subcontractor and the
supplier. Joint checks may be issued only if all the conditions in this subsection are met.
1. The DBE subcontractor must be independent from the prime contractor and the supplier, and
must perform a commercially useful function. The DBE subcontractor must be responsible
for negotiating the price of the material, determining quality and quantity, ordering the
materials, installing (where applicable), and paying for the material. The DBE subcontractor
may not be utilized as an extra participant in a transaction, contract, or project in order to
obtain the appearance of DBE participation.
2. The use of joint checks will be allowed only if the prime contractor, DBE subcontractor, and
material supplier establish that the use of joint checks in similar transactions is a commonly
recognized business practice in the industry, particularly with respect to similar transactions

SERIAL 15058-RFP
in which DBE's do not participate.
3. A material or supply contract may not bear an excessive ratio relative to the DBE
subcontractor's normal capacity.
4. There may not be any exclusive arrangement between one prime and one DBE in the use of
joint checks that may bring into question whether the DBE is independent of the prime
contractor.
5. Any arrangement for joint checks must be in writing, and for a specific term (for example,
one year, or a specified number of months) that does not exceed a reasonable time to
establish a suitable credit line with the supplier.
6. The prime contractor may act solely as the payer of the joint check, and may not have
responsibility for establishing the terms of the agreement between the DBE subcontractor
and the supplier.
7. The DBE must be responsible for receiving the check from the prime contractor and
delivering the check to the supplier.
8. The prime contractor cannot require the DBE subcontractor to use a specific supplier, and
the prime contractor may not participate in the negotiation of unit prices between the DBE
subcontractor and the supplier.
11.02 Procedure and Compliance:
1. Maricopa County Dept. Transportation Procurement Office must approve the agreement for
the use of joint checks in writing.
2. After obtaining authorization for the use of joint checks, the prime contractor, the DBE, and
the supplier must retain documentation to allow for efficient monitoring of the agreement.
3. Copies of canceled checks must be submitted period in which the joint check was issued.
whether or not joint checks were used. with the payment information for the Certificates of
payment must indicate
4. The prime contractor, DBE, and supplier each have an independent duty to report to the
Maricopa County Dept. Transportation Procurement Office in the case of any change from the
approved joint check arrangement.
5. Any failure to comply will be considered by the Maricopa County Dept. Transportation
Procurement Office to be a material breach of this contract and will subject the prime
contractor, DBE, and supplier to contract remedies and, in the case of serious violations, a
potential for termination of the contract, reduction or loss of prequalification, debarment, or
other remedies which may prevent future participation by the offending party.

SERIAL 15058-RFP
MARICOPA COUNTY DEPARTMENT
OF TRANSPORTATION PROJECT
SPECIFIC CONSULTANT PAYMENT
REQUEST
SUBMIT THIS PAYMENT REQUEST TO: Maricopa County Department of Transportation, Attention: Financial Branch
Services, 2901 West Durango Street, Phoenix, Arizona 85009-6357.
CONSULTANT’S NAME: DATE:
CONSULTANT’S ADDRESS:
PROJECT NAME: PAYMENT REQUEST NO.:
CONTRACT NO.: TIME PERIOD: TO
WORK ORDER NO.:
MCDOT PROJECT MANAGER (not procurement contact):
1. CONSULTANT’S CONTRACTS FEES
1. Contract Amount (Basic/ Lump Sum Fee)
$
2. Contract Additions (Approved Change Orders and Contract Amendments,
Allowance, Work Authorizations, and Not-to-Exceed Work or Expenses)
A. 3. 5.
B. 4. 6.
3. Total Contract Additions:
$
4. Total Current Contract Amount (A1 plns A3)
$
2. CONSULTANT’S FEE EARNED TO DATE
1 Value of Basic Fee Work Completed % x =
$
2 Requested Payment for: Allowanced, NTE Work or Expenses, Work,
Authorizations, Change Orders, Contract Amendments, etc. (attach backup
Documents for allowances, NTE work and expenses, work authorizations)
1. 3. 5.
2. 4. 6.
3 Total Contract Additions:
$
4 Total Fee Earned To Date (B1 plus B3)
$
5 Percentage Total Contract Work Completed
3. PAYMENT REQUEST DATA
A. Less Prior Net Payments $
B. Less Prior Retainage $
C. Total Payment Request (B4 minus C1 minus C2) $
D. Less Tetainage this Payment Request $
E. Total Retainage to Date (C2 plus C4) $
F. Net Payment Request (C3 minus C4) $
If this is a full and final payment request be certain to include the required Certificate of Performance (COP).
Submitted by:
Consultant Date
Payment Request Verification:

SERIAL 15058-RFP
MCDOT Project Manager Date
Approval to Pay:
MCDOT Division Head Date
*If substitute security accounts have been approved by MCDOT, write “ESCROW”.
A Design and Progress Report MUST accompany this payment request, when applicable. Requests for release/ reduction of
retention must include a separate memo & invoice justifying release/ reduction, dated with MCDOT’s Project Manager’s
concurrence.
Rev. 6/1/07

SERIAL 15058-RFP
FHWA-1273 -- Revised May 1, 2012
REQUIRED CONTRACT PROVISIONS
FEDERAL-AID CONSTRUCTION CONTRACT

SERIAL 15058-RFP

SERIAL 15058-RFP

SERIAL 15058-RFP

SERIAL 15058-RFP

SERIAL 15058-RFP

SERIAL 15058-RFP

SERIAL 15058-RFP

SERIAL 15058-RFP

SERIAL 15058-RFP

SERIAL 15058-RFP

SERIAL 15058-RFP

SERIAL 15058-RFP

SERIAL 15058-RFP

SERIAL 15058-RFP

SERIAL 15058-RFP
MARICOPA COUNTY DEPARTMENT OF TRANSPORTATION
Certificate of Performance and Payment of ALL Claims
PROJECT NAME:
hereby certifies to the Maricopa County Department of Transportation
(Name of Signer)
(MCDOT) that all lawful claims for labor, rental of equipment, material used, and any other
claims by or its subconsultants in connection with the project described in
MCDOT Contract No , have been paid.
understands that with receipt of payment for any previously invoiced
amounts, plus any retained monies, that this is a settlement of all claims of every nature and kind against
MCDOT arising out of the performance of MCDOT’S Contract No .
relating to the material, equipment and work covered in and required by the contract.
The undersigned hereby certifies that to his/her knowledge, no contractual disputes exist in regard to this
contract and that he/she has no knowledge of any pending or potential claims in regard to this contract.
Upon submission of this document and a separate invoice for any retained funds to MCDOT, invoice
processing will be completed within sixty (60) calendar days.
State of Arizona )
§
County of Maricopa )
Signed this day of , 20 .
Signature
Subscribed and Sworn to before me this day of , 20
Notary Public
My Commission Expires: _

SERIAL 15058-RFP
Title VI Assurances
Maricopa County Department of Transportation
Title VI Assurances
The Maricopa County Department of Transportation The Civil Rights Restoration Act of 1987 clarified the
(herein referred to as the "Recipient"), HEREBY original intent of Congress, with respect to Title VI and
AGREES THAT, as a condition to receiving other Non-discrimination requirements (The Age
any Federal financial assistance from the U.S. Department Discrimination Act of 1975, and Section 504 of the
of Transportation (DOT}, through Federal Highway Rehabilitation Act of 1973}, by restoring the broad,
Administration and Arizona Department of Transportation, institutional-wide scope and coverage of these non-
is subject to and will comply with discrimination statutes and requirements to include all
the following: programs and activities of the Recipient, so long as any
portion of the program is Federally assisted.
Statutory/Regulatory Authorities
• Title VI of the Civil Rights Act of 1964 Specific Assurances
(42 U.S.C.§ 2000d et seq., 78 stat. 252}, (prohibits More specifically, and without limiting the above
discrimination on the basis of race, color, national general Assurance, the Recipient agrees with and gives
origin); the following Assurances with respect to its Federal Aid
• 49 C.F.R. Part 21 (entitled Non-discrimination In Highway Program.
Federally-Assisted Programs of the Department of
Transportation-Effectuation of Title VI of the Civil 1. The Recipient agrees that each "activity," "facility,"
Rights Act of 1964}; or "program," as defined in §§ 21.23 (b) and 21.23 (e)
of 49 C.F.R. § 21 will be
• 28 C.F.R. section 50.3 (U.S. Department of Justice
(with regard to an "activity") facilitated, or will
Guidelines for Enforcement of Title VI of the
be (with regard to a "facility") operated, or will be
Civil Rights Act of 1964};
(with regard to a "program") conducted in
• 23 C.F.R. Part 200 Subchapter C-Civil Rights compliance with all requirements imposed by, or
(Title VI program implementation and pursuant to the Acts and the Regulations.
related statues)
2. The Recipient will insert the following notification
The preceding statutory and regulatory cites in all solicitations for bids, Requests For Proposals
hereinafter are referred to as the ':O.cts" and for work, or material subject
"Regulations," respectively. to the Acts and the Regulations made in connection
with all Federal Aid Highway Program and, in
General Assurances adapted form, in all proposals for negotiated
In accordance with the Acts, the Regulations, and other agreements regardless of funding source:
pertinent directives, circulars, policy, memoranda and/or
guidance, the Recipient hereby gives assurances that it "The Maricopa County Department of
will promptly take any measures necessary to ensure Transportation, in accordance with the
that: provisions of Title VI of the Civil Rights Act of
"No person in the United States shall, on the 1964 (78 Stat. 252.42 U.S.C.§§ 2000d-
grounds of race, color, or national origin, be 4} and the Regulations, hereby notifies all
excluded from participation in, be denied advertisement, disadvantaged business
the benefits of, or be otherwise subjected to enterprises will be afforded full and fair
discrimination under any program or activity," for opportunity to submit bids in response to this
which the Recipient receives Federal financial invitation and will not be discriminated against
assistance from DOT, including the Federal Highway on the grounds of race, color, or
Administration. national origin in consideration for an award."

SERIAL 15058-RFP
3. The Recipient will insert the clauses of Appendix b. the period during which the Recipient retains
A and E of this Assurance in every contract or ownership or possession of the property.
agreement subject to the Acts and the Regulations. 9. The Recipient will provide for such methods of
4. The Recipient will insert the clauses of Appendix B administration for the program as are found by
of this Assurance, as a covenant running with the the Secretary of Transportation or the official
land, in any deed from the United States effecting or whom he/she delegates specific
recording a transfer of real property, structures, use, authority to give reasonable guarantee that it,
or improvements thereon or interest therein to a other recipients, sub-recipients, sub-grantees,
Recipient. contractors, subcontractors, consultants, transferees,
5. That where the Recipient receives Federal successors in interest, and other participants of
financial assistance to construct a facility or part Federal financial assistance under such program
of a facility, the Assurance will extend will comply with all requirements imposed or
to the entire facility and facilities operated in pursuant to the Acts, the Regulations, and this
connection therewith. Assurance.
6. That where the Recipient receives Federal financial 10. The Recipient agrees that the United States has a
assistance in the form, or for the acquisition of real right to seek judicial enforcement with regard to any
property or an interest in real property, the Assurance matter arising under the Acts, the Regulations, and
will extend to rights to space on, over, or under such this Assurance.
property.
7. That the Recipient will include the clauses set forth
in Appendix C and Appendix D of this Assurance, as
a covenant running with the land, in any future deeds,
leases, licenses, permits,
or similar instruments entered into by the
Recipient with other parties:
a. for the subsequent transfer of real property
acquired or improved under the applicable
activity, project, or program; and
b. for the construction or use of, or access to,
space on, over, or under real property acquired
or improved under the applicable activity,
project or program.
8. That this Assurance obligates the Recipient for the
period during which Federal financial assistance is
extended to the program, except where the Federal
financial assistance is to provide, or is in the form
of, personal property,
or real property, or interest therein, or structures
or improvements thereon, in which case the
Assurance obligates the Recipient, or any
transference for the longer of the following
periods:
a. the period during which the property is used for a
purpose for which the Federal financial assistance
is extended, or for another purpose involving the
provision of similar services or benefits; or

SERIAL 15058-RFP
By signing this ASSURANCE, Maricopa County Department of Transportation also agrees to comply (and require any
sub-recipients, sub-grantees, contractors, successors, transferees, and/or assignees to comply) with all applicable provisions
governing Federal Highway Administration or Arizona Department of Transportation access to records, accounts,
documents, information, facilities, and staff. You also recognize that you must comply with any program or compliance
reviews, and/or complaint investigations conducted by the Federal Highway Administration or Arizona Department of
Transportation. You must keep records, reports, and submit the material for review upon request to Federal Highway
Administration, Arizona Department of Transportation, or its designee in timely, complete, and accurate way. Additionally,
you must comply with all other reporting, data collection, and evaluation requirements, as prescribed by law or detailed
in program guidance.
Maricopa County Department of Transportation gives this ASSURANCE in consideration of and for obtaining any
Federal grants, loans, contracts, agreements, property, and/or discounts, or other Federal-aid and Federal financial
assistance extended after the date hereof to the recipients by the U.S. Department of Transportation under the Federal
Highway Administration and Arizona Department of Transportation. This ASSURANCE is binding on Arizona, other
recipients, subrecipients, sub-grantees, contractors, subcontractors and their subcontractors, transferees, successors in
interest, and any other participants in the Federal Aid Highway Program the person(s) signing below is authorized to sign
this ASSURANCE on behalf of the Recipient.

SERIAL 15058-RFP
APPENDIX A
During the performance of this contract, the contractor, for itself, its assignees and successors in interest
(hereinafter referred to as the "contractor") agrees as follows:
1. Compliance with Regulations: The contractor instructions. Where any information required of a
(hereinafter includes consultants) will comply contractor is in the exclusive possession of another
with the Acts and the Regulations relative to Non- who fails or refuses to furnish the information, the
discrimination in Federally- assisted programs of contractor will so certify to the Recipient, the
the U.S. Department of Transportation, Federal Federal Highway Administration, or Arizona
Highway Administration or the Arizona Department of Transportation, as appropriate, and
Department of Transportation, as they may be will set forth what efforts it has made to obtain
amended from time to time, which are herein the information.
incorporated by reference and made a part of this 5. Sanctions for Noncompliance: In the event of a
contract. contractor's noncompliance with the Non-
2. Nondiscrimination: The contractor, with discrimination provisions of this contract, the
regard to the work performance by it during the Recipient will impose such contract sanctions as it
contract, will not discriminate on the grounds of or the Federal Highway Administration or Arizona
race, color, or national origin in the selection and Department of Transportation, may determine to be
retention of subcontractors, including procurements appropriate, including, but not limited to:
of materials and leases of equipment. The contractor a. withholding payments to the contractor under the
will not participate directly or indirectly in the contract until the contractor complies; and/or
discrimination prohibited by the Acts and the
Regulations, including employment practices when b. cancelling, terminating, or suspending a
the contract covers any activity, project, or program contract, in whole or in part.
set forth in Appendix B of 49 CFR Part 21. 6. Incorporation of Provisions: The contractor will
3. Solicitations for Subcontractors, Including include the provisions of paragraphs one through
Procurements of Materials and Equipment: In all six in every subcontract, including procurements
solicitations, either by competitive bidding, or of materials and leases of equipment, unless
negotiation made by the contractor for work to be exempt by the Acts, the Regulations and directives
performed under a subcontract, including issued pursuant thereto. The contractor will take
procurements of materials, or leases of equipment, action with request to any subcontract or
each potential subcontractor or supplier will be procurement as the Recipient, the Federal
notified by the contractor of the contractor's Highway Administration, or Arizona Department of
obligations under this contract and the Acts and Transportation may direct as a means of enforcing
Regulations relative to Non- discrimination on the such provisions including sanctions for
grounds of race, color, or national origin. noncompliance. Provided, that if the contractor
4. Information and Reports: The contractor will becomes involved in, or is threatened with
provide all information and reports required by the litigation by a subcontractor or supplier because of
Acts, the Regulations, and directives issued such direction, the contractor may request the
pursuant thereto and will permit access to its books, Recipient to enter into any litigation to protect the
records, accounts, other sources of information, and interests of the Recipient. In addition, the
its facilities as may be determined by the Recipient, contractor may request the United States to enter
the Federal Highway Administration or Arizona into the litigation to protect the interests of the
Department of Transportation to be pertinent to United States.
ascertain compliance with such Acts, Regulations,
and

SERIAL 15058-RFP
APPENDIX E
During the performance of this contract, the contractor, for itself, its assignees, and successors in interest
(hereinafter referred to as the "contractor") agrees to comply with the following nondiscrimination
statutes and authorities; including but not limited to:
Pertinent Non-Discrimination Authorities:
• Title VI of the Civil Rights Act of 1964 (42 U.S.C. § 2000d et seq., 78 stat. 252), (prohibits discrimination
on the basis of race, color, national origin): and 49 CFR Part 21.
• The Uniform Relocation Assistance and Real Property Acquisition Policies Act of 1970, (42 U.S.C. §
4601), (prohibits unfair treatment of persons displaced or whose property has been acquired because of
Federal or Federal-aid programs and projects);
• Federal-Aid Highway Act of 1973, (23 U.S.C. § 324 et seq.), (prohibits discrimination on the basis of
sex);
• Section 504 of the Rehabilitation Act of 1973, (29 U.S.C.§ 794 et seq.), as amended, (prohibits
discrimination on the basis of disability); and 49 CFR Part 27;
• The Age Discrimination Act of 1975, as amended, (42 U.S.C. § 6101 et seq.), (prohibits discrimination on
the basis of age);
• Airport and Airway Improvement Act of 1982, (49 USC§ 471, Section 47123), as amended, (prohibits
discrimination based on race, creed, color, national origin, or sex);
• The Civil Rights Restoration Act of 1987, (PL 100-209), (Broadened the scope, coverage and applicability
of Title VI of the Civil Rights Act of 1964, The Age Discrimination Act of 1975 and Section 504 of the
Rehabilitation Act of 1973, by expanding the definition of the terms "programs or activities" to
include all of the programs or activities of the Federal-aid recipients, sub- recipients and contractors,
whether such programs or activities are Federally funded or not);
• Titles II and Ill of the Americans with Disabilities Act, which prohibit discrimination on the basis of
disability in the operation of public entities, public and private transportation systems, places of public
accommodation, and certain testing entities (42 U.S.C. §§ 12131-12189) as implemented by
Department of Transportation regulations at 49 C.F.R. parts 37 and 38;
• The Federal Aviation Administration's Non- discrimination statute (49 U.S.C. § 47123) (prohibits
discrimination on the basis of race, color, national origin, and sex);
• Executive Order 12898, which ensures discrimination against minority populations by discouraging
programs, policies, and activities with disproportionately high and adverse human health or
environmental effects on minority and low-income populations;
• Executive Order 13166, Improving Access to Services for Persons with Limited English Proficiency, and
resulting agency guidance, national origin discrimination includes discrimination because of limited
English proficiency (LEP). To ensure compliance with Title VI, you must take reasonable steps to ensure
that LEP persons have meaningful access to your programs (70 Fed. Reg. at 74087 to 74100);
• Title IX of the Education Amendments of 1972, as amended, which prohibits you from
discriminating because of sex in education programs or activities (20 U.S.C. 1687 et seq).

SERIAL 15058-RFP
RHYTHM ENGINEERING, 11228 THOMPSON AVENUE, LENEXA, KS 66219
PRICING SHEET: NIGP CODE 91842
Terms: NET 30
Vendor Number: VS0000000382
Certificates of Insurance Required
Contract Period: To cover the period ending August 31, 2021.