Mobile Data Terminals for Transit DepartmentMasterpiece on the Mississippi
TO: The Honorable Mayor and City Council Members
FROM: Michael C. Van Milligen, City Manager
SUBJECT: Mobile Data Terminals for Transit
DATE: April 28, 2010
Transit Manager Jon Rodocker recommends City Council approval to issue a Request
for Proposal for procurement of Mobile Data Terminals in KeyLine mini - buses. The
terminals will offer real -time dispatching capabilities for the mini -bus operation.
I concur with the recommendation and respectfully request Mayor and City Council
approval.
el C. V
MCVM:jh
Attachment
cc: Barry Lindahl, City Attorney
Cindy Steinhauser, Assistant City Manager
Dave Heiar, Economic Development Director
Jon Rodocker, Transit Manager
Mich an Milligen
Dubuque
kiltd
AN- America Clty
11111,
2007
041310bal
CITY OF DUBUQUE
REQUEST FOR PROPOSALS
RFP No. 03.10
TRANSIT AVUMDT PROJECT
RFP #03.10 Transit AVUMDT Project
CITY OF DUBUQUE, IOWA
REQUEST FOR PROPOSALS
TRANSIT AVUMDT PROJECT
NOTICE TO PROPOSERS
Notice is hereby given that the City of Dubuque, Iowa will receive proposals from
qualified and responsible firms for the purchase of AVUMDT systems for the City
of Dubuque KeyLine buses.
Proposals must be submitted in an envelope clearly marked "Transit AVUMDT
Project" to the City Clerk, City Hall, 50 West 13 Street, Dubuque IA 52001.
Proposals will be received until 4:00 PM, June 4, 2010 according to the City
Clerk's time -stamp clock. Any proposals received after that time and date will
not be considered but will not be returned to the proposer.
This Request for Proposals and any resulting contract will be administered in
accordance with the Federal Transit Administration "Third Party Contracting
Guidelines, FTA Circular 4220.1D", and all other applicable federal, state and
local laws and regulations. All proposers must certify that they are not an
ineligible contractor listed on the U.S. Comptroller General's Debarred Bidders
list. The successful proposer will be required to comply with all applicable Equal
Employment Opportunity laws and regulations. The City of Dubuque hereby
notifies all proposers that it will affirmatively ensure that Disadvantaged and
Women's Business Enterprises will be afforded full opportunity to submit
proposals in response to this invitation and will not be discriminated against on
the grounds of gender, race, color, sexual orientation, gender identity, or national
origin in consideration for an award.
The City of Dubuque reserves the right to postpone, accept or reject any and all
proposals and to waive any informality in the Request for Proposals process as
the City deems to be in its best interest.
Copies of the Request for Proposals may be obtained from Jon Rodocker,
KeyLine Transit Manager, 563.589.4341 or proposers may access the Request
for Proposals, amendments and addenda at http: / /www.cityofdubuque.orq /.
2
RFP #03.10 Transit AVUMDT Project
1.0. PURPOSE.
The City of Dubuque is soliciting Proposals from qualified firms or individuals
who meet the conditions set forth herein to provide turnkey installation services
to furnish goods and services for the purchase of AVUMDT systems for City of
Dubuque, hereinafter described in accordance with the provisions hereof.
Except as otherwise approved by the City of Dubuque, the contractor shall
supply standard, service- proven products of computer, communication, and
peripheral equipment manufacturers, established third -party hardware and
software suppliers, and their own baseline product offering that meet or exceed
the functional requirements of this specification. Proposers shall describe their
offerings which satisfy the City specifications and highlight those proposed
features which exceed specification requirements.
All equipment shall be designed for use in the public transit industry, with specific
attention to ergonomics, reliability, efficiency, safety, and vehicle compatibility.
Equipment furnished under these specifications shall be the latest model in
current production, as offered to commercial trade, and shall conform to quality
workmanship standards and use materials with transit industry requirements.
1.1. PROPOSAL SUBMISSION.
City Clerk
City Hall
50 West 13 Street
Dubuque IA, 52001
PART I
SOLICITATION
One original and five copies of the proposal must be submitted in an envelope
clearly marked "Transit AVL /MDT Project" and addressed to:
Proposals will be received until 4:00 PM, June 4, 2010. Proposals received after
that time and date will not be considered.
1.2. PROPOSAL OPENING. Proposals submitted to the City in accordance
with the requirements hereof shall be publicly opened and examined on the
Proposal Opening Date June 4, 2010 @ 4:OOpm CST. PLEASE BE ADVISED
that the contents of each Proposal, including documents marked proprietary,
shall be made public.
3
RFP #03.10 Transit AVL /MDT Project
1.3. REQUEST FOR CLARIFICATIONS. Any request for clarifications must
be in writing and submitted by the Proposed to the City by May 19, 2010.
Responses will be made by the City on or before May 26, 2010. All
clarifications /responses will be posted on the City's website at
http: / /www.citvofdubuque.orq/ .
1.4. PROPOSAL INQUIRIES. The point of contact for any questions
regarding the specifics of this RFP is:
Mr. Jon Rodocker, Transit Manager
2401 Central Ave
Dubuque IA, 52001
Tel. #563.589.4341
Fax. #563.589.4340
jrodocke(a�citvofdubuque.org
1.5. PRE - PROPOSAL TOUR. No Pre - Proposal Tour will be conducted for this
project. However, interested proposers are encouraged to schedule times for
either an in- person meeting, and /or conference phone call to discuss the
specifications pertaining to this project.
IF YOU HAVE FURTHERS QUESTIONS RELATED TO SPECIFICATIONS OR
DESIGNS, PLEASE CONTACT JON RODOCKER AT 563.589.4341
MONDAY - FRIDAY, 8:00 A.M. — 5:00 P.M. C.S.T.
PART II
OVERVIEW
2.0. OVERVIEW OF THE TRANSIT SYSTEM. Keyline transit is a public
transit system, located in Dubuque Iowa, servicing the City of Dubuque and East
Dubuque, IL. Keyline transit service is a combination of fixed routes along with
Para - transit/demand response.
2.1. SERVICE AREA. The service area is approximately twenty -six (26)
square miles with an estimate population by 2010 of 58,000 residents. The
proposed software must be capable of expansion to allow for growth of the
system in the future.
2.2. GOALS & OBJECTIVES. As a fixed route and Para - transit provider, the
City is seeking to improve the operational efficiency, cost - effectiveness, control
and security of its transit operations.
Some of the goals are but not limited to the following:
(1) Increase the availability of transit information and dissemination;
4
RFP #03.10 Transit AVL /MDT Project
(2) Improve overall dispatching, operational efficiency, and cost
effectiveness;
(3) To provide mapping services for ease of driver /passenger location;
(4) Increase driver and passenger safety and security;
The City intends to procure and implement a proven solution that easily
integrates with existing systems and services and represents current state -of-
the -art in transit technology solutions.
2.3. CURRENT VEHICLE FLEET. The City's current Paratransit fleet is
comprised of thirteen (13) 2000 -2004 Ford E-450 Cutaways.
*The City has an ongoing vehicle replacement schedule. During the installation
process the Contractor will be required to work with the City in scheduling
equipment installations on new vehicles before they are placed in service and
preventing equipment installations in vehicles that are to be removed from
service. The Contractor will be required to submit an installation plan showing
the timeline to complete vehicles. This plan shall include the dates and duration
of each installation. Proposers are required to provide option pricing for the
purchase of additional on -board subsystems for installation of future vehicle
purchases by the City.
PART III
TECHNICAL SPECIFICATIONS
3.0 GENERAL OVERVIEW. The City seeks to improve the efficiency and
effectiveness of its transit operations with the objectives established in this RFP.
3.1. PARA - TRANSIT REQUIREMENTS
(1) The City currently utilizes Route Match Software to assist with
scheduling, booking, client tracking, and manifest printing for Para -
transit/demand response service. The City is open to the consideration of
other software providers for Para - transit/demand response scheduling
and can be included in the proposal.
(2) However, the City will make a final determination whether to use
the existing Route Match software or to change scheduling systems.
Proposers shall develop a plan of action to integrate the current operating
system, if it is in the City's best interest to continue using the current
Route Match Software.
3.2. PARA - TRANSIT SCHEDULING AND DISPATCHING SOFTWARE.
5
RFP #03.10 Transit AVUMDT Project
The following specifications describe the minimum for Para - transit and
dispatching software:
(1) Service Area.
a) GIS (Geographical Information System) and mapping
functions shall be provided as part of the software system
proposed by the vendor. At a minimum, the service area maps
shall encompass Dubuque, East Dubuque, IL and Grant County,
Wisconsin. Additional maps for the contiguous counties may be
necessary for the out of county transportation. However, it may be
possible, given the software capabilities, to manually schedule out
of county trips without the use of GIS.
b) The City considers mapping capabilities and the dispatcher's
abilities to identify approximate current locations, based on last
known point in the schedule, essential.
c) Within the Keyline service area.
(2) GIS Functionality.
a) The software must incorporate GIS capabilities and allow
user access to the service area through a map view. The GIS map
view must be capable of displaying individual routes or runs, and /or
bus stops; specific street address; or other specified user - defined
physical features.
b) In addition to providing support to the software's primary
scheduling and customer information functions, the GIS
functionality of the proposed software must support other GIS
analyses. The City desires that the software be capable of:
1. printing /producing camera ready printed output
2. providing geographically based query functions
c) System shall be capable of importing and exporting data and
graphic images from and to other software platforms. If the
software is limited to basic mapping functions, then data shall be
exportable to a standard GIS software format (Arc View) thus
enabling external GIS analyses. System shall be capable of printing
maps to a wide range of printers /plotter devices.
6
RFP #03.10 Transit AVL /MDT Project
(3)
Map Features And Attributes.
a) Access to maps shall be seamless from within the
scheduling software (e.g., user shall be able to generate needed
maps with single mouse click or menu selection).
b) Base maps shall contain current attributes on street
segments, addressing, speed limits, etc. Vendor shall be
responsible for supplying a fully up -to -date map complete with all
attributes necessary for point -to -point scheduling using coordinate
geography (not zones). Street network shall permit definition of
segment characteristics, such as speed limits, one -way direction,
etc. Vendor shall outline in its proposal how the City should expect
to receive updates on maps.
c) The City defines various fares. GIS functionality shall include
ability to define service -based fares, such as set fares, contract
fares, varying fares, etc. This functionality is in addition to
consideration of client codes such as elderly, disabled, child, etc.
d) System shall be capable of defining and displaying point
files, indicating system time - points, major intersections, possible
future major transfer points, and major destinations of travel, or
other points of interest.
(4) Geo- Coding
a) Service area map shall contain definitions of street segment
name and address ranges. System shall have full geo- coding
capability allowing the City to enter an address and locate the
address on the map. System shall be capable of handling various
abbreviations and spellings of names (e.g., St. for Street, etc) in the
geo- coding process. System shall permit manual assignment of x-
and y- coordinates in the event an address cannot be geo -coded
based on existing map address range attributes.
b) Systems shall have the capability of allowing user to
calculate distance between points or along a specified portion of
the street or route network.
(5) Client Database
a) Client database shall be capable of providing a full range of
data elements for each client in the system. Information shall
include full identification (including social security number (as
needed)), birth date, address, contact, third party /emergency
7
RFP #03.10 Transit AVUMDT Project
contacts, disability status, mobility aides used, program affiliation,
and third party contract payee options.
b) System shall be capable of producing reports based upon
client, sponsoring agency, transportation provider, origins or
destinations, cities, or zip code.
(6) Trip Reservations.
a) System shall permit trip booking while City personnel are on
the telephone with the client/customer. System must be capable of
processing both subscription (standing- order) and demand
response trips in this manner. System shall be capable of
processing same day trip orders.
b) System shall permit City staff to access client records by
entering client last name, telephone number, address, or other
identification. Current protocols involve booking trips using client
last name. However, due to common proper names, additional
details must be available to the user in order to distinguish between
customers with the same first and last name.
c) Pop -up windows or list boxes shall be used to display lists of
clients for easy access and selection. Once selected, pertinent data
from the client database file shall be accessible to the call center
representative, either through on- screen display or pop -up window.
d) System shall default to the client's home address as the
pick -up location. System shall provide ability to enter alternative
addresses through keystroke entry or through use of list boxes of
alternative pick -up addresses associated with that client (e.g.,
common travel destinations of that customer).
e) System shall be capable of displaying, through pop -up
window, list box, or similar alternative, a list of most frequent client
travel destinations and /or recent destinations of travel for easy
insertion into the destination field. User should be able to select
destination from these fields and populate trip destination fields
through this selection process.
f) Systems shall be capable of incorporating a user - specified
policy on pick -up time negotiation with the client. System must be
capable of incorporating multiple policies.
g) System shall be capable of accepting trip reservations for a
period of at least up to 365 days in advance of the requested trip
date. Most trips entered will only be up to 7 days in advance.
8
RFP #03.10 Transit AVL /MDT Project
h) System shall be capable of accepting standing orders.
i) System shall be capable of setting finite limits on the length
of subscription orders.
j) System shall be capable of scheduling both go and return
trips with ease. The current system allows the user to input the "go"
trip, click on a "return trip" button to then enter only the time of pick
up for the return trip. All information on the client's origin and
destination are reversed for the return trip. This process saves the
user time in re- entering addresses for each trip.
k) System shall provide means for the City's customer service
representatives to easily and quickly access existing trip
reservations for the client in order to edit travel destination, trip
dates, and /or travel times.
I) System shall permit cancellation of any trip in the system in
advance consistent with City policies on trip cancellations. System
shall maintain a cancellation record, by client, to facilitate
management of cancellation policies.
m) System shall be capable of temporarily suspending a client's
eligibility for service on transit vehicles. System shall permit entry of
both a start date and end date of the time period when the client's
ridership privileges are suspended. During this period, system shall
not permit trip booking, providing a pop -up alarm for the customer
service representative.
n) System, at the conclusion of trip booking, shall provide a
confirmation of the booking with fare(s), if applicable, to be paid by
the user(s), or companion.
(7) Scheduling.
a) System shall be capable of scheduling, in batch mode on a
next -day basis, or as trips are added (up to one -hour prior to
requested pick -up time) all reservations for a designated travel day.
Scheduling shall be based on the actual street network in the City's
service area (e.g., actual x- and y- coordinates, not zones),
parameters associated with network segments as established in
the GIS system, physical barriers, speed parameters, time of day,
and appropriate dwell times for the boarding and alighting of
passengers.
b) System shall permit the establishment of base runs or
subscription templates based on existing standing orders. System
9
RFP #03.10 Transit AVL /MDT Project
shall be capable of evaluating base runs in order to optimize run in
terms of least distance and travel time, based on network factors.
c) System shall permit trips to be placed in the system
schedule but remain unassigned to a specific run. This can be
accomplished through a manual setting of the trip to "unassigned"
or "will- call" category or similar means.
d) System shall be capable of taking trip orders on a same day
basis and dynamically scheduling the trip into existing schedules.
System shall consider existing path of route travel, existing
customer assigned trips, system policies on travel and pick up time
windows in making the scheduling assignment. If system is capable
of producing multiple solutions to the trip assignment, priorities,
expressed on some type of score or other method, shall show the
best possible choice of assignment.
e) System shall be capable of producing schedules, by run, in
chronological order, indicating projected arrival time of City vehicles
at each origin and destination.
f) Once generated, system shall be able to display all
schedules for all runs on a given day. Display shall contain all
pertinent run data and contain necessary menu and edit tools to
provide manual adjustments, as necessary, to the scheduled runs.
g) System shall have internal validation controls to ensure that
schedules do not violate schedule and work rules.
h) System should be capable of generating or identifying trips
that violate system parameters so that staff can attempt to remedy
the violation.
i) System shall provide the capability of City scheduling staff to
manually move trips after schedule development.
j) In assigning passengers to vehicles and /or vehicles to
system runs, system shall be capable of recognizing the need for
accessible vehicles, vehicle capacity, etc. in making said
assignments.
k) System shall be capable of adding trips to a previously
generated schedule or re- assigning trips from one run to another in
dynamic fashion. The system shall be capable of dynamically
updating the remaining scheduled pick -ups and drop -offs on the
run's schedule.
I) System shall be capable of evaluating individual trip
parameters and select runs that best satisfy the requirements of
10
RFP #03.10 Transit AVL /MDT Project
the reservation and maintaining the integrity of existing reservations
on the same run. If system generates a range of alternatives,
system shall present alternatives in rank order with the highest
ranked alternative indicating the "best" selection.
m) The system shall be capable of updating the schedules of all
other impacted trips after the system updates a trip so all
previously scheduled trips must remain on time, not violate travel
time rules, etc.
n) If the system cannot schedule all orders for the day of travel
being scheduled, then the system shall be capable of displaying all
such trips in its own dataset so that staff may consider manual
overrides to the schedule and /or assignment of the trip.
(8) Dispatching.
a) System shall be capable of allowing dispatchers to process
cancellations (cancellations received prior to system policy time),
no show /late calls (cancellations received after the system policy
time) and no- shows. System shall maintain a cancellation record
and a no show record, by client, to facilitate management of
cancellation and no show policies.
b) System shall be capable of automatically displaying to the
dispatcher /scheduler cancellations, same day reservations, and
will -call return trips waiting for vehicle assignment (e.g., trips
reservations made but not yet assigned /scheduled).
c) System shall be capable of identifying runs when a vehicle is
pulled from service due to an emergency or vehicle breakdown.
Dispatcher shall have the capability to dynamically re- schedule all
trips impacted by this service emergency.
(9) Reports.
a) Software shall be capable of generating a range of
management and service reports necessary to permit sufficient
oversight of the para- transit service.
b) Please describe your systems standard reporting
capabilities. It is desired that all standard reports can be imported
and exported from the system. Please describe this functionality.
c) The system must provide tools and wizards that allow users
to easily create, edit, and save reports. Please describe your
systems report generation capabilities.
11
RFP #03.10 Transit AVUMDT Project
d) The system must interface with the reporting requirements
of the National Transportation Database.
e) The system must provide the capability for our Information
Technology staff to create custom reports utilizing an industry-
standard reporting product. Please explain how this requirement
can be met. The City also requires the system to integrate into an
ODB C- compliant database which provides additional third party
tools to access the database to query and view the database tables
and the database model.
f) The proposed system shall be a client/server application
based on an ODBC compliant relational database engine with the
potential for import/export to a other systems. The client platform
shall be Windows, 32 -bit design, incorporating a common graphical
interface. DOS based applications will not be evaluated. Solutions
with proprietary databases and /or middleware are not preferred.
The system must provide tools and utilities to import and export
data from its database to other databases and systems. Please
describe your systems capability to import and export data into
other systems and formats.
g) System shall be capable of permitting the user to create,
format, and print user - defined reports based on any data element
contained in the database.
3.3. AVUMDT HARDWARE SPECIFICATIONS. The wireless network to be
used will be a public cellular data network operating on the most current cellular
network in operation. Wireless Gateway software will be provided that will have
the following functionality:
(1) Support a minimum of 8 wireless network communication channels,
allowing for the simultaneous use of different types of wireless networks
should the need arise.
(2) Support multiple, simultaneous, Host -end communication channels,
allowing multiple Host software applications (e.g. Para - transit software
and Fixed Route software), to communicate to the in- vehicle hardware.
(3) Diagnostic features available via remote connection for ongoing
system maintenance and troubleshooting support.
(4) Can provide confirmation of message delivery to in- vehicle
hardware.
(5) Ability to queue data messages and re -send automatically if no
acknowledgment is received.
12
RFP #03.10 Transit AVL/MDT Project
(6) For private radio networks, the Wireless Gateway will provide a
radio system- testing module for system "auto exercise" and coverage
testing.
(7) Will perform on -line real time diagnostic information and reports
maintenance functions.
(8) Reporting capability for Message Transmission Performance
(success and volume), Vehicles on the System, Data Logs, and System
Errors.
(9) Able to display system events in user - configurable colors based on
type: information, minor alarm, and major alarm.
(10) Displays connection status to Host -end software.
(11) Displays wireless network connection status.
(12) Stores and maintains all transaction data on a database.
(13) User Documentation to be supplied for Wireless Gateway in
electronic format.
3.4. OVER THE AIR PROGRAMMING.
(1) The Vendor will provide software that can perform over - the -air
remote programming and software updates of the in- vehicle MDT
device(s).
(2) The over - the -air programming software will have the following
functionality:
(3) The software and firmware (operating system) of the in- vehicle
MDT must be updateable over a cellular network.
(4)
(5) The software update function must allow files to be transferred over
the wireless network and be automatically installed on the MDT without
operator assistance at the vehicle.
(6) Types of software that can be updated over the wireless network
must include:
a) MDT Operating system
b) MDT Application software (In- Vehicle Software)
c) Configuration or setup files
13
RFP #03.10 Transit AVL /MDT Project
d) Mapping files (to allow for map data updates)
e) All MDTs in the fleet will automatically register with the
software.
f) MDT data /activity logs will be able to be downloaded.
g) The software update function will allow the System
Administrator to specify updates to all or select portions of the fleet.
h) The software update function will allow the System
Administrator to perform updates immediately, or schedule them for
an automatic update at a later date.
i) For updates at times when vehicles are normally out of
service and the MDT is powered down, the update function will
have the feature of being able to program the MDT Device to
automatically `wake -up' at the scheduled time to enable the
transfer.
j) The software will allow the System Administrator to track
MDT type, the version of each major software type installed on the
deployed MDT devices, and provide a historical record of the
updates provided to each.
k) To minimize the amount of data sent over the wireless
network, the software update function will utilize a file compression
algorithm.
I) If a software update data transfer is interrupted due to an
MDT losing power or going out of wireless coverage, the transfer
will resume once the MDT is available again at the point it left off
with no need to restart the transfer.
m) The diagnostic and fault logging features of the ITS Device
must be accessible through the cellular network.
n) The software will be capable of displaying the progress of
the software transfer.
o) The software will provide an `Update Wizard' windows
interface to aid the creation of software updates.
p) Software is compatible with the following operating systems
- Windows XP. Please explain what operating system will be
recommended for MDT units.
3.5. MOBILE DATA COMPUTER FUNCTIONALITY REQUIREMENTS
14
RFP #03.10 Transit AVL/MDT Project
(1) Log On Functions.
a) Once the MDT /AVL unit is powered up, it will automatically
display a driver log -on form screen requesting the driver's
identification number and the vehicle's odometer reading.
b) The MDT /AVL unit will display the vehicle's current
odometer reading as calculated by the vendor supplied odometer
interface.
c) The MDT /AVL unit will allow the driver to manually correct
the calculated vehicle odometer value.
d) Drivers must be able to log -on to the MDT /AVL unit by
entering their employee identification number and the vehicle's
odometer reading into the MDT /AVL unit.
e) The MDT /AVL unit will validate the log -on information with
the Para - transit Dispatch Software.
(2) Display Functions: All driver screens should always display the
following information.
a) Current system time, the time should be able to be depicted
by a twenty -four (24) hour clock, or alternatively an AM /PM
designation.
b) Radio /wireless network status
c) New message indicator
(3) Through the use of a soft key on the display, the software will also
provide users with the ability to:
a) Switch between a `day' mode graphics display and a 'night'
mode graphics display that have been optimized for the ambient
lighting expected under those conditions.
b) Adjust volume
c) Adjust backlighting intensity of display
15
RFP #03.10 Transit AVL /MDT Project
(4) Communications Functionality.
a) Capable of visual and audible alerts to indicate incoming
messages.
(5)
b) The driver must be able to acknowledge incoming messages
(as deemed necessary by the importance level of the message).
c) After the driver acknowledges an incoming message it shall
be displayed on the MDT /AVL unit.
d) The MDT /AVL unit shall also be capable of allowing the
driver to respond to a message.
e) The MDT /AVL unit shall be capable of sending a message
and notifying the driver of the success or failure of the transaction.
The option will be given to the driver to resend the message should
the message not be delivered successfully. This sending method is
known as SEND and NOTIFY.
f) The MDT /AVL unit shall be capable of queuing messages in
a buffer and repeatedly attempting to deliver them to the host
application. Each message shall be configured to attempt delivery
indefinitely or to attempt delivery only for a fixed period of time after
which the message will be discarded. This sending method is
known as STORE and FORWARD.
g) The MDT /AVL unit should also be capable of sending
messages that are sent only once, regardless of whether they are
acknowledged. This sending method is known as SEND and
FORGET.
h) The MDT /AVL unit must be capable of receiving pre- defined
messages when a specific numeric code is sent from the host
application.
i) The nature of the canned messages will need to be defined
by the City in conjunction with the vendor.
Standard Para - Transit Functionality.
a) The MDT /AVL unit shall provide the para- transit operator
with the option of downloading and storing up to one hundred (100)
rider /trip stops in the MDT /AVL unit.
16
RFP #03.10 Transit AVL /MDT Project
b) The MDT /AVL unit shall allow the driver to scroll through the
manifest up to the maximum number of transmitted trips as
determined by the para- transit operator.
c) Should the driver turn off the ignition during the course of his
shift, he /she should not need to logon again as the trip list will be
retained in the MDT /AVL unit.
d) The MDT /AVL unit must be capable of adding, updating, and
saving new Para - transit trip data without Driver intervention.
e) The MDT /AVL unit must provide drivers with a Job List, Job
Detail and Job Perform Screens.
f) The MDT /AVL unit Job List Screen must provide drivers with
an overview of their job list.
g) The MDT /AVL unit should be able to display eight lines of 40
characters each at one time.
h) Additional trip message lines must be available by scrolling.
i) The MDT /AVL unit should display a single line entry for each
trip /stop.
j) All trips must be shown on the display in ascending order of
scheduled stop times.
k) The current trip must be located at the top of the job list
screen.
I) When the driver completes the current trip, the MDT /AVL
unit should automatically delete it from the job list screen.
m) The Job list Screen must display multiple rider pick -ups and
drop -offs from the same address.
n) At any time after the driver has logged on to the system and
received a job list, the MDT /AVL unit should update the job list by
inserting additional trips sent to it by the dispatch system. The
MDT /AVL unit must insert trips in the order of their scheduled pick
up or drop off times.
o) At any time after the driver has logged on to the system and
received a job list, the MDT /AVL unit should update the job list by
deleting trips that have been canceled.
17
RFP #03.10 Transit AVL /MDT Project
p) The driver must be able to access the Job Perform Screens
from the Job List Screen by a single keystroke.
q) The driver must also be able to access the Job Detail
Screen from the Job List Screen by a single keystroke, using a
keypad key.
r) The Job Detail Screen should provide the driver with
detailed information about each stop.
s) Additional lines of trip information should be viewable by
scrolling.
t) The driver must be able to access the Job List Screen from
the Job Detail
Screen by a single keystroke, using an MDT /AVL unit keypad key.
u) The driver must be able to access the Job Perform Screen
from the Job Detail Screen by a single keystroke, using the keypad.
v) Job Perform Screens should display a list of information
requests to be completed by the driver and transmitted to the Para -
transit Dispatch Software, that are necessary to complete each
Para - transit trip (each Pickup and Drop -off assignment).
w) After the driver has used the MDT /AVL unit to record a
rider's boarding, prompts should be popped up that need to be
filled in by the driver and transmitted to the ITS host, before the
driver can return to any other screen.
x) If a Job Perform Screen requires the vehicle's odometer
reading, the MDT /AVL unit must automatically read and fill in the
odometer reading.
y) If the rider and trip numbers, number of riders, attendants
and companions, and fare amounts and types were in the original
trip message that was transmitted to the MDT /AVL unit, the
MDT /AVL unit must automatically place that information in the
appropriate Form Screen fields. The driver should be able to edit
this information once it is displayed on the MDT /AVL unit.
(6) Data Messaging. The following section describes the types of
messages that the para- transit operator will likely be transmitting between
the in- vehicle MDT /AVL devices (mobile data terminals) and the Para -
transit. The vendor should be able to comply with the following
messaging requirements:
18
RFP #03.10 Transit AVL /MDT Project
• Trip Messages
• Driver Log On
• Driver Log Off
• Pick Up Site Arrival
• Pick Up Site Departure
• Drop Off Site Arrival
• Drop Off Site Departure
• Rider Boarding
• Rider Alighting
• Rider Call Out (Flag Stop)
• Rider No Show
• Rider Door Cancellation
• Rider Not Ready — Will Call
• Coded Messages
• Emergency Message
a) Each message should contain data appropriate to that
message (i.e. the vehicle odometer reading, GPS latitude and
longitude, and time /date stamp).
b) to be included with each message.
(7) Navigation Functions.
a) The MDT must be capable of displaying in- vehicle maps.
b) The MDT must be capable of providing navigation
directions including voice annunciation and visual display of trip
route and turn directions.
c) Driver will not have to enter destination address
to use the map navigation, as the software will do this
automatically.
d) Drivers will not have to start the map navigation as a
separate software application. The Navigation functionality will
be integrated into the in- vehicle software application.
3.6. AVUMDT TECHNICAL REQUIREMENTS. The MDT In- Vehicle
Hardware will include the following:
(1) Mobile Data Terminal (MDT): user interface with color display and
touch screen for driver input.
19
RFP #03.10 Transit AVL /MDT Project
(2) Vehicle Logic Unit (VLU): computer processing and operating
system for In- Vehicle Software.
(3) GPS Antenna: reception of GPS signals.
(4) GPS Receiver: GPS signal processing.
(5) AVL Reporting: control of GPS Reporting.
(6) Wireless Network Communications - Wireless Modem and RF
Antenna: for communication with Host -end Application Software
(7) The GPS Antenna and RF Antenna shall be combined into one
Dual -Mode Antenna if possible
(8) All necessary mounting equipment, cables, and fuses.
Excluding the antennas, cables, and mount equipment, the MDT In- Vehicle
Hardware may consist of one integrated device, or 2 separate physical devices
(such as an MDT and a separate wireless modem /GPS device).
The In- Vehicle Hardware shall meet the following specifications:
(1) Minimum 400 MHz or higher processor
(2) Windows CE 5.0 or higher operating system
(3) Maximum Size of MDT: 9" x 6" x 2"
(4) 6 programmable soft keys, including power button
(5) Built -in smartcard reader (optional)
(6) Built -in Magnetic card reader (optional)
(7) Microphone, stereo speakers, audio out
(8) Type II Compact Flash Socket
(9) 1 Host USB Port
(10) 1 Slave (Device) USB Port
(11) 1 RS -232 COM port
(12) Storage temperature range: —22° F to +155° F
20
RFP #03.10 Transit AVL /MDT Project
(13) Operating temperature range: —22° F to +145 F
(14) Vibration tested as per MIL - STD -810F
(15) Shock tested as per MIL - STD -810F Shock
(16) Humidity: 5% to 95% relative humidity non - condensing
(17) Able to handle power supply voltage from 10VDC to 30VDC
(18) FCC Class A Part 15 compliance
(19) Touch Screen
(20) Minimum display size of 6" on the diagonal
(21) Color display
(22) Adjustable back - lighting for visibility in low -light environments
(23) Backlighting minimum brightness of 300 NIT
(24) Adjustable volume
(25) LCD Display Heater option available to ensure the display is
readable at temperatures below 32 F (0 C) temperatures
(26) Dust and water resistant
(27) Allows software applications to be able to switch from `day' mode
to`night' mode graphics display through use of a soft key.
(28) Minimum 64 MB or higher of SDRAM
(29) Minimum 64 MB or higher of FLASH memory
(30) Internal memory expandable with internal compact flash card
(optional)
The MDT's GPS Receiver must meet the following specifications:
(1) 16- channel GPS receiver
(2) GPS Accuracy: 15 meters (RMS) uncorrected
(3) GPS Position Update Rate: 1 Hz (once a second)
21
RFP #03.10 Transit AVL /MDT Project
(4) Time to acquire GPS lock: 2 minutes or less on cold start, 45
seconds or less on warm start, 3 seconds or less on hot start
Odometer Input and Monitoring: The device will have a built -in pulse accumulator
input and pulse conditioner to facilitate the conversion of input data from the
vehicle's odometer circuit to distance traveled in miles. In order to account for
any variances in vehicle travel mileage; the odometer reader must be
configurable to allow the settings to be calibrated from one vehicle to the next.
(1) Minimum 5 discrete inputs
(2) Minimum 5 discrete outputs
(3) J1708 interface
(4) Ability to accept an audio input
(5) Built -in covert microphone (optional, for use with radio systems
only)
(6) Ability to route input audio to up to 2 audio outputs
(7) Vehicle Ignition sense input: the vehicle ignition switch will
control the
(8) In- Vehicle Hardware power.
(9) Power connections for In- Vehicle Hardware to vehicle Battery.
The vendor shall provide the following installation hardware:
(1) Adjustable mount hardware for the MDT. The mount hardware
will allow drivers to reposition the angle and tilt of the display.
(2) Cabling for connections to the applicable on -board equipment,
antennas, power, and ignition switch.
(3) Any additional antennas required for data modems or the GPS
receiver.
The vendor shall supply, as part of this proposal, the cost to pre -wire vehicles in
order to incorporate the future additions of on -board video surveillance systems.
Proposer shall identify how their system will be incorporated into the video
surveillance system.
22
RFP #03.10 Transit AVL /MDT Project
PART IV
PROJECT PROPOSAL UNDERSTANDING
At a minimum, each proposal should contain the following elements:
4.0. UNDERSTANDING OF THE PROJECT
(1) Based on information contained in this RFP, as well as information
obtained in subsequent addenda, responses to questions submitted by
vendors, and other materials available from the City, the proposer shall
indicate, in written narrative, how the proposed software will facilitate the
system's goals for providing cost efficient, customer responsive, demand
response /Para- transit transportation to the general public and clients.
(2) Proposers shall demonstrate a thorough understanding of FTA
requirements as well as those of other major client transportation
programs.
(3) Proposers should indicate how their software system could work to
improve the transit system's handling of various tasks associated with
para- transit and fixed route service delivery.
4.1. SOFTWARE SYSTEM DESCRIPTION
(1) Proposers shall fully describe the software scheduling system
being offered as part of this submission. Capabilities and features should
be described in the context of the application to the provision of demand
responsive transportation and fixed route transportation to the general
public.
(2) Benefits gained from installing and using the vendor's product
should be described in full. Proposers must list all software components or
modules necessary to fully implement the project, including third party
software necessary to complete the total installation (e.g., report
generation software, RDBMS, back -up software, remote access software,
etc.).
4.2. AVL /MDT HARDWARE DESCRIPTION
(1) Proposers shall fully describe the hardware being offered as part
of this submission. Capabilities and features should be described in the
context of the application to the provision of demand responsive /fixed
route transportation to the general public.
(2) Benefits gained from installing and using the vendor's product
should be described in full. Proposers must list all hardware /software
components or modules necessary to fully implement the project,
including third party systems necessary to complete the total installation.
23
RFP #03.10 Transit AVL /MDT Project
4.3. IMPLEMENTATION PLAN. Proposers shall fully describe the
proposed implementation plan, detailing all major milestones in the process. A
proposed timeframe from notice -to- proceed through "go- live" should be
developed as an integral part of this proposal.
4.4. QUALITY ASSURANCE PLAN. Proposers shall describe in detail their
management strategies for overall quality assurance in the installation, start-up,
and operation of the scheduling and dispatching system software. At a minimum,
proposers should address:
(1) Project Management and Staffing — Describe the proposed
individuals and team approach used to successfully communicate
with City staff throughout the project. If contractors are used for any part
of the installation, customization, or maintenance of the proposed
software system, this element of your overall approach must be identified
here.
(2) Quality Control — Describe steps and techniques employed by the
proposer to ensure the integrity of databases (e.g., street networks, client
databases, etc.) that may be required to be imported and /or converted for
use in the proposed scheduling system.
(3) Maintenance, Support, and Upgrades — Describe the proposer's
network of technical support during the project, focusing both on the
critical initial implementation period as well as long -term operation.
(4) Describe procedures for rendering support, including the
availability of technicians to provide on -site repairs and ability to
remotely access, diagnose, and make necessary repairs. Technical
support policies and pricing must be explained in detail. Proposers shall
also describe their most recent three -year history in terms of system
upgrades offered and pricing. Future system upgrade policies must be
described and will be a factor in the award.
(5) Long -Term Maintenance and Support — The City relies heavily
on its database to provide transportation services and cannot tolerate
deficiencies in the selected software and hardware. Technical support
for program issues faced after initial installation should be addressed.
Items to be included are, but are not limited to, response time, hours
technical support is available, length of time for correction, etc.
4.5. TRAINING.
(1) Proposers shall provide a detailed schedule and course outline
for the necessary training of the designated individuals on the proposed
software and hardware. This training shall be held at the City transit
facility. Vendors should assume that up to Six (6) system individuals will
24
RFP #03.10 Transit AVUMDT Project
participate in software training. This section of the proposal should
identify the training course content, the number of courses required, and
type of training (classroom, hands -on, etc.) that will be provided, the
length of the training session, etc.
(2) Proposers should indicate when the training should be provided
in the context of the overall implementation time schedule provided
above. Qualifications of the staff providing the training should be listed.
4.6. EXPERIENCE. Proposers shall provide a corporate profile indicating their
qualifications to provide the required software and support necessary to achieve
objectives for the project. Proposers must submit a list of other transit systems
where the proposed software application(s) have been installed. A separate list
of the proposer's last Five (5) installations (United States and Canada), along
with a project contact, address, telephone number, facsimile number, and e-mail
address must be provided.
5.0. PROJECT MANAGER
(1) The proposer shall name one (1) individual from the firm who shall
have complete authority and control over all aspects of customization,
data conversion, installation, testing, and training.
(2) This individual shall be named in the proposal and a resume' of the
individual's qualifications to oversee this project shall be detailed. A list of
other project installations directly under the control of this individual shall
be named in the proposal.
5.1. SINGLE POINT OF CONTACT.
PART V
QUALITY ASSURANCE PLAN
(1) The proposer's project manager shall be the sole point of contact
between the vendor and the City for all business matters concerning
the purchase, customization, installation, testing, and training phases
of this project.
(2) The City recognizes that other individuals will lead some phases of
work during the project. It is our intent, however, to have one
individual in an authoritative position to represent the proposer in all
aspects of the project.
5.2. PRODUCTS OFFERED.
(1) Use of Existing Market Products. The City does not desire to
purchase products that represent beta versions or products that have not
25
RFP #03.10 Transit AVL /MDT Project
been installed in other operational environments in another transit system
in the United States.
(2) Current Version. The City requires the proposer to offer the latest,
tested release version of each software product/module included in this
proposal. Proposer shall include the estimated date of the next update to
proposer's offered software.
(3)
Lists of Installed Sites.
a) For each product or module offered to fulfill the scope of
services under this RFP, the proposer shall provide a list of the
Five (5) most recent sites where the product is currently being
used. For each site, the proposer shall list:
b) Name of the transit system
c) Local project manager
d) Date of contract award
e) Status of the installation (awarded, under development,
testing, "live operation ")
f) Date in which the transit system began "live" operation
(4) Warranty. The City requires the successful proposer to warrant the
software product(s) offered to perform as described in the proposal
response for a period of five (5) years from date of "live" operation.
(5) Technical Support. The City requires that the proposer offer one
full year of full technical support as part of its price proposal. This
technical support shall include, but not necessarily be limited to:
a) Toll -free, telephone support with service technician /engineer
during all normal administrative business hours maintained by the
City
b) Provision of diagnostics/repairs via remote control access to system
hardware /software
c) On -site technical support when required
d) Product upgrades, new releases, patches, etc. when issued
by the vendor throughout the first three (3) years of
implementation.
26
RFP #03.10 Transit AVUMDT Project
(6) User Groups /Newsletters/Technical Bulletins.
a) Proposer shall immediately include the City, after notice of
award, in all mailing lists to receive product newsletters, e-mail
announcements, bulletins, or other technical matters concerning all
software products offered.
b) If the proposer operates a web -based program of support,
the City shall be given access rights upon notice of award.
c) If the proposer offers training classes, refresher courses, or
sponsors organized user groups, such support shall be listed in the
vendor's proposal.
(7) Installation, Testing, and Acceptance. Throughout the period of
software installation, the City shall designate a local project liaison to
coordinate the vendor's local installation efforts. All contact with the City
regarding project matters, site visits, project schedule, training, etc. shall
be coordinated through this project liaison.
(8) Installation.
b) The vendor may stage installation to best ensure
compatibility of all integrated software and hardware products.
(9) On -Site Representation. Proposer shall have the Project Manager
and /or a duly qualified software engineer on -site during the initial testing
of all software products.
(10) Acceptance. After final testing is completed to the satisfaction of
the City, the Transit Manager will issue a letter of acceptance to the
vendor.
5.3 TRAINING.
a) The proposer's implementation schedule shall document
major milestones during the development, customization, and
installation phases of the project. Upon completion of the
installation phase, the vendor shall notify the City, in writing, of the
readiness of the system installation for testing.
(1) Vendor shall be required to train designated individuals to
proficiency on all software and hardware products offered. All training
shall be conducted at the transit offices or any other office designated by
the City.
(2) All training schedules shall be coordinated with City Management.
27
RFP #03.10 Transit AVUMDT Project
(3) Vendor shall be required to provide a combination of classroom
and "hands -on" training for all software and hardware products offered.
Training content and duration shall be stated specifically in the proposer's
written offer in response to this procurement.
(4) Class Size. Vendor shall work with the City to assess the potential
number of individuals who will require vendor training on the various
software products.
(5) Manuals and Documentation. Vendor shall provide Six (6) copies
of the software manuals for each product offered as part of this
procurement along with driver manuals for MDT's.
PART VI
PROPOSAL EVALUATION
6.0. COST FACTORS USED IN PROPOSAL EVALUATION. The City is
requesting that proposers identify the following items as part of their base cost
proposal. Each item must be listed separately:
(1) Software Purchase Costs. The cost of the software and the
appropriate number of user licenses offered in the price must be stated
by the proposer. It is the responsibility of the proposer to understand the
City's operations in sufficient detail to determine the number of user
licenses required to run the scheduling system in our environment.
(2) Services. All costs associated with the full implementation of the
system. Supplemental costs associated with user assessment,
installation, database conversion, etc., must be detailed if separate and
not included in the software price above. Price proposals must
breakdown labor and travel costs.
(3) Data Acquisition and Conversion Costs. If the proposer must
acquire databases, street maps, or other items necessary to support
installation, these costs should be identified here.
(4) Related Third Party Software Costs. All other software necessary
to operate the scheduling system or to support maintenance of the
system recommended by the vendor should be identified. All such
products should be purchased by the proposer and licensed to the transit
system.
(5) Training Costs. If training costs are not included in the software
purchase or licensing costs, proposals must identify the labor, materials,
and travel costs associated with all required training.
(6) Five -Year Maintenance and Support. One year maintenance and
28
RFP #03.10 Transit AVL /MDT Project
technical support price shall be included.
(7) Other Costs. Any other costs not identified above that are integral
to the implementation of the proposed scheduling system should be
identified.
(8) Hardware Costs. Proposers are responsible for evaluating the
City's existing hardware computing environment to determine
compatibility with the hardware requirements necessary to operate the
proposed para- transit scheduling system software. If hardware
acquisition is recommended, the proposer should provide a full
breakdown of hardware requirements and costs. Servers should be
identified separately from workstations.
(9) Other Costs. Any other cost not identified above should be
identified and indicated by the vendor.
6.1. EVALUATION CRITERIA. Proposals will be evaluated as to their
responsiveness to the criteria specified in the contents of this RFP. Award will
be made to the lowest, responsive, responsible bidder meeting specifications,
who presents the product or service that is in the best interest of the City of
Dubuque.
6.2. RIGHT TO REJECT PROPOSALS.
(1) Submission of a proposal indicates acceptance by the Contractor
of the conditions contained in this RFP unless clearly and specifically
noted in the proposal submitted and confirmed in the contract between
the City of Dubuque and the firm selected. The award of this project is
subject to Federal Transit Administration (FTA) grant process approval.
No project shall be awarded without the express written consent of the
City of Dubuque.
(2) The City reserves the right without prejudice to reject any or all
proposals. All forms from following this page must be included in formal
proposal. Any omissions of forms or information will constitute a bid being
considered non - responsive.
a) The City is seeking a quality professional company, firm, or
individual to conduct the installation of the above mentioned
project. While cost is certainly a very important factor in this
procurement, it will not be the sole basis on which proposals are
evaluated.
29
RFP #03.10 Transit AVUMDT Project
b) Candidate proposals will be ranked in accordance with the
evaluation criteria. If necessary, negotiations may occur to modify
proposals to determine best and final offer prior to contract award.
c) The City's Transit Disadvantaged Business Enterprise (DBE)
goal for the contract to be awarded to the successful proposer is
two percent (2 %).
d) If DBE subcontractors are utilized, the successful proposer
will be required to submit certifications for these subcontractors
prior to contract award. Any proposer that is not a certified DBE
contractor or that does not intend to utilize the services of DBE
subcontractors must document its good faith efforts as required by
49 C.F.R. Part 26 to obtain the services of DBE subcontractors.
30
RFP #03.10 Transit AVL /MDT Project
RESPONSE TO RFP #03.10: TRANSIT AVLUMDT PROJECT
Insert Name of Proposer Here:
Insert the Business Address of
the Proposer:
Insert the Business Phone Number and Fax
Number of the Proposer: &
Insert the Name of the Person
completing this Proposal, who
will be treated as the contact
person for the Proposer
If the Proposer's Name inserted above is a trade name, an assumed name or
fictitious name, please give proper full name of individual or entity conducting
business under that name in the space provided immediately below:
If the Proposer is a general partnership or joint venture, please give the names
and personal and business addresses of each partner and /or joint venturer in the
space provided immediately below:
31
RFP #03.10 Transit AVUMDT Project
If the Proposer is a limited partnership, please give the names and addresses of
the General Partner(s) and the limited partner(s) in the space provided
immediately below (and attach to this Proposal that documentation evidencing
the General Partners authority to execute this Proposal and evidencing
Registration with the Secretary of State of the State of Iowa:
PLEASE NOTE IF MORE SPACE IS REQUIRED SIMPLY ATTACH SEPARATE
PAGE WITH THIS ADDITIONAL INFORMATION.
If the Proposer is a corporation or a limited liability company, please attach to
this Proposal (i) a certificate of good standing from the Secretary of State in the
state where the company operates in, (ii) a certified copy of the resolution
authorizing the execution of the Proposal in the name of the corporation or
limited liability company, and (iii) insure that the Proposal is executed by the duly
authorized officer of the corporation or limited liability company.
The Proposer named above proposes and offers to fully observe and perform all
of the obligations set forth in RFP #03.10 and to do and perform all of the
services described in RFP #03.10 in accordance with each and all of the
provisions of the RFP.
In compliance with the above, the undersigned offers and agrees to furnish any
or all items upon which prices are offered, at the price set opposite each item,
delivered to 2401 Central Avenue, Dubuque Iowa, 52002 within the time
specified.
Company: Authorized Proposer:
Address: Title /Signature:
Phone: Fax Number:
32
RFP #03.10 Transit AVL/MDT Project
CERTIFICATE NUMBER ONE
RECEIPT OF ADDENDA
CERTIFICATION
The Proposer warrants and represents that it has received all Addenda (if any)
issued by the City in connection with this Invitation for Bid.
33
PROPOSER NAME
BY:
TITLE:
RFP #03.10 Transit AVL /MDT Project
CERTIFICATE NUMBER TWO
NON - COLLUSION ASSURANCE AFFIDAVIT
The undersigned, having first been duly sworn, on and under oath state and
affirm as hereinafter stated:
1. That I am the person responsible for the final decision as to the price (s)
and amount of this Proposal or, if not, that I have written authorization, attached
to this certification, from that person to make the statements set forth below on
his or her behalf and on behalf of the Proposer.
2. I further attest that:
(a) The price(s) and amount of this Proposal have been arrived
at independently, without consultation, communication or
agreement for the purpose of restricting competition with any other
Contractor, Proposer or potential Proposer.
(b) Neither the price(s) nor the amount of this Proposal has
been disclosed to any other firm or person who is a Proposer or
potential Proposer on this project, and will not be so disclosed prior
to the Proposal Opening Date.
(c) No attempt has been made or will be made to solicit, cause
or induce any firm or person to refrain from submitting a proposal
on this project, or to submit a Proposal higher than the Proposal of
this firm, or any intentionally high or non - competitive Proposal or
other form of complementary Proposal.
(d) The Proposal of this Proposer is made in good faith and not
pursuant to any agreement or discussion with, or inducement from,
any firm or person to submit a complementary Proposal.
(e) This Proposer has not offered or entered into a subcontract
or agreement regarding the purchase of materials or services from
any firm or person, or offered, promised or paid cash or anything of
value to any firm or person, whether in connection with this or any
other project, in consideration for an agreement or promise by any
firm or person to refrain from proposing or to submit a
complementary Proposal on this project.
(f) This Proposer has not accepted or been promised any
subcontract or agreement regarding the sale of materials or
services to any firm or person, and has not been promised or paid
cash or anything of value by any firm or person, whether in
connection with this or any other project, in consideration for this
Proposer submitting a complementary Proposal, or agreeing to do
so, on this project.
(g) I have made a diligent inquiry of all members, officers,
employees, and agents of this Proposer with responsibilities
relating to the preparation, approval or submission of this
Proposer's Proposal on this project and have been advised by each
of them that he or she has not participated in any communication,
consultation, discussion, agreement, collusion, act or other conduct
34
RFP #03.10 Transit AVL /MDT Project
inconsistent with any of the statements and representations made
in this affidavit.
3. Further Affiant sayeth not.
Made and executed this
SUBSCRIBED AND SWORN to before me a Notary Public of and for the
County and State aforesaid on this day of
, 200
My Commission Expires:
35
day of , 200 .
Affiant's name
Notary Public
RFP #03.10 Transit AVL /MDT Project
CERTIFICATE NUMBER THREE
DISADVANTAGED/WOMEN BUSINESS ENTERPRISE
CERTIFICATION
The undersigned, having first been duly sworn, on and under oath state and
affirm as hereinafter stated:
1. That I am the Proposer or I have been duly authorized by the
Proposer to make the statements set forth below on behalf of the
Proposer.
2. I further attest that:
3. Further Affiant sayeth not.
Made and executed this
SUBSCRIBED AND SWORN to before me a Notary Public of and for the
County and State aforesaid on this day of
200
My Commission Expires:
(a) The Proposer is a Disadvantaged Business Enterprise and
meets the eligibility requirements detailed in 49 CFR Part 26.
(b) The Proposer is certified with the Arkansas Highway and
Transportation Department's DBE/WBE program or, if the
Proposer has not been not certified through the Arkansas
Highway and Transportation Department, the source of the
Proposer's DBE certification is : (Please Insert Source of
DBE Certification here):
day of , 200 .
Affiant's name
Notary Public
36
RFP #03.10 Transit AVL /MDT Project
CERTIFICATE NUMBER FOUR
EQUAL EMPLOYMENT OPPORTUNITY CERTIFICATION
The undersigned, having first been duly sworn, on and under oath state and
affirm as hereinafter stated:
1. That I am the Proposer or I have been duly authorized by the
Proposer to make the statements set forth below on behalf of the
Proposer.
2. I further attest that:
(a) the policy of the Proposer is to insure equal opportunity and
non - discrimination, and require that all employees and
applicants for employment be treated equally regardless of race,
color, sex, national origin, religion, age and physical handicap not
related to the ability to perform a particular job or occupation, and,
(b) that the Proposer agrees to treat each person fairly without regard
to race, color, sex, national origin, religion, age and physical handicap
not related to the ability to perform a particular job or occupation, with
respect to employment, upgrading, promotion, demotion, transfer,
layoffs, termination, rates of pay or other forms of compensation,
selection for training, and other terms and conditions of employment
and further agrees to include in all recruitment advertising the notation
that it is "An Equal Opportunity Employer, " and to register its
employment advertisements with such minority and female community
organizations as may be recommended by the Contract Compliance
Division of the City Attorney's Office.
3. Further Affiant sayeth not.
Made and executed this day of , 200
SUBSCRIBED AND SWORN to before me a Notary Public of and for the
County and State aforesaid on this day of
200 .
My Commission Expires:
37
Affiant's name
Notary Public
RFP #03.10 Transit AVUMDT Project
The Proposer warrants and represents that neither the Proposer, any of its
employees or its subcontractors:
(1) Are not presently debarred, suspended, proposed for debarment,
declared ineligible, or voluntarily excluded from covered transactions by any
Federal department or agency;
(2) Have not within a three -year period preceding thus Proposal 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 statutes or commission
of embezzlement, theft, forgery, bribery, falsification or destruction of records,
making false statements, or receiving stolen property;
(3) Are not presently indicted for or otherwise criminally or civilly charged by a
governmental entity (Federal, State or local) with commission of any of the
offenses enumerated in paragraph (2) of this certification; and
(4) Have not within a three -year period preceding this application /Proposal
had one or more public transactions (Federal, State or local) terminated
for cause or default.
The person executing this certification further represents, warrants and affirms
the truthfulness and accuracy of the contents of the statements submitted on or
with this Certification and understand that the provisions of 31 U.S.C. Sections
3801 Et Seq are applicable thereto.
My Commission Expires:
CERTIFICATE NUMBER FIVE
ELIGIBLE PROPOSER CERTIFICATION
PROPOSER NAME
BY:
TITLE:
SUBSCRIBED AND SWORN to before me a Notary Public of and for the County
and State aforesaid on this day of , 200_
38
Notary Public
RFP #03.10 Transit AVUMDT Project
CERTIFICATE NUMBER SIX
CERTIFICATION OF RESTRICTIONS ON LOBBYING
The undersigned, having first been duly sworn, on and under oath state and
affirm as hereinafter stated:
1. That I am the Proposer or I have been duly authorized by the
Proposer to make the statements set forth below on behalf of the
Proposer.
2. I further attest that:
(a) No Federal appropriated funds have been paid or will be paid, by or
on behalf of the Proposer, to any person for influencing or attempting to
influence an officer or employee of any agency, a Member of Congress in
connection with the awarding of any Federal contract, the making of any
Federal grant, the making of any Federal loan, the entering into of any
cooperative agreement, and the extension, continuation, renewal,
amendment, or modification of any Federal contract, grant, loan, or
cooperative agreement, and,
(b) If any funds other than Federal appropriated funds have been paid
or will be paid to any person for influencing or attempting to influence an
officer or employee of Congress, or an employee of a Member of
Congress in connection with this Federal contract, grant, loan, or
cooperative agreement, the Proposer shall complete and submit the
Standard Form -LLL, "Disclosure Form to Report Lobbying ", in
accordance with its instructions, and,
(c) that the Proposer shall require that the language of this certification
be included in the award documents for all sub awards at all tiers
(including subcontracts, sub grants, and contracts under grants, loans,
and cooperative agreements) and that all sub recipients shall certify and
disclose accordingly.
(d) The undersigned acknowledges that this certification is a material
representation of fact upon which reliance is placed when this transaction
is made or entered into. Submission of this certification is a prerequisite
for making or entering into this transaction imposed by section 1352, title
31, U.S. Code. Any person who fails to file the required certification shall
be subject to a civil penalty of not less than $10,000 and not more than
$100,000 for each such failure.
3. Further Affiant sayeth not.
39
RFP #03.10 Transit AVUMDT Project
Made and executed this
My Commission Expires:
day of , 200 .
Affiant's name
SUBSCRIBED AND SWORN to before me a Notary Public of and for the
County and State aforesaid on this day of
200 .
Notary Public
40
RFP #03.10 Transit AVL /MDT Project
INSTRUCTIONS FOR COMPLETION OF SF -LLL,
DISCLOSURE OF LOBBYING ACTIVITIES
This disclosure form shall be completed by the reporting entity, whether
subawardee or prime Federal recipient, at the initiation or receipt of a covered
Federal action, or a material change to a previous filing, pursuant to title 31
U.S.0 section 1352. The filing of a form is required for each payment or
agreement to make payment to any lobbying entity for influencing or attempting
to influence an officer or employee of any agency, a Member of Congress, an
officer or employee of Congress, or an employee of a Member of Congress in
connection with a covered Federal action. Use the SF -LLL -A Continuation Sheet
for additional information if the space on the form is inadequate. Complete all
items that apply for both the initial filing and material change report. Refer to the
implementing guidance published by the Office of Management and Budget for
additional information.
1. Identify the type of covered Federal action for which lobbying activity is
and /or has been secured to influence the outcome of a covered Federal
action.
2. Identify the status of the covered Federal action.
3. Identify the appropriate classification of this report. If this is a follow up
report caused by a material change to the information previously reported,
enter the year and quarter in which the change occurred. Enter the date
of the last previously submitted report by this reporting entity for this
covered Federal action.
4. Enter the full name, address, city, state and zip code of the reporting
entity. Include Congressional District, if known. Check the appropriate
classification of the reporting entity that designates if it is, or expects to
be, a prime or sub -award recipient. Identify the tier of the subawardee,
e.g., the first subawardee of the prime is the 1st tier. Subawards include
but are not limited to subcontracts, subgrants and contract awards under
grants.
5. If the organization filing the report in item 4 checks "Subawardee ",. then
enter the full name, address, city, state and zip code of the prime Federal
recipient. Include Congressional District, if known.
6. Enter the name of the Federal agency making the award or loan
commitment. Include at least one organizational level below agency
name, if known. For example, Department of Transportation, United
States Coast Guard.
41
RFP #03.10 Transit AVL /MDT Project
7. Enter the Federal program name or description for the covered Federal
action (item 1). If known, enter the full Catalog of Federal Domestic
Assistance (CFDA) number for grants, cooperative agreements, loans,
and loan commitments.
8. Enter the most appropriate Federal identifying number available for the
Federal action identified in item 1 (e.g., Request for Proposal (RFP)
number; Invitation for Proposal (RFP) number, grant announcement
number; the contract, grant, or loan award number; the
application /proposal control number assigned by the Federal agency).
Include prefixes, e.g., "RFP- DE- 90 -00I."
9. For a covered Federal action where there has been an award or loan
commitment by the Federal agency, enter the federal amount of the
award, loan commitment for the prime entity identified in item 4 or 5.
10. (a) Enter the full name, address, city, state and zip code of the
lobbying entity engaged by the reporting entity identified in item 4 to
influence the covered Federal action.
(b) Enter the full names of the individual(s) performing services, and
include full address if different from 10 (a). Enter Last Name, First Name,
and Middle Initial (MI).
11. Enter the amount of compensation paid or reasonably expected to be
paid by the reporting entity (item 4) to the lobbying entity (item 10).
Indicate whether the payment has been made (actual) or will be made
(planned). Check all boxes that apply. If this is a material change report,
enter the cumulative amount of payment made or planned to be made.
12. Check the appropriate box(es). Check all boxes that apply. If
payment is made through an in -kind contribution, specify the nature and
value of the in -kind payment.
13. Check the appropriate box(es). Check all boxes that apply. If other,
specify nature.
14. Provide a specific and detailed description of the services that the
lobbyist has performed, or will be expected to perform, and the date(s) of
any services rendered. Include all preparatory and related activity, not
just time spent in actual contact with Federal officials. Identify the Federal
official(s) or employee(s) contacted or the officer(s), employee(s), or
Member(s) of Congress that were contacted.
15. Check whether or not a SF -LLL -A Continuation Sheet(s) is attached.
16. The certifying official shall sign and date the form, print his /her name,
42
RFP #03.10 Transit AVL /MDT Project
title, and telephone number. Public reporting burden for this collection of
information is estimated to average 30 minutes per response, including
time for reviewing instructions, searching existing data sources, gathering
and maintaining the data needed, and completing and reviewing the
collection of information. Send comments regarding the burden estimate
or any other aspect of this collection of information, including suggestions
for reducing this burden, to the Office of Management and Budget,
Paperwork Reduction Project (0348 - 0046), Washington. D.C., 20503.
43
RFP #03.10 Transit AVUMDT Project
DISCLOSURE OF LOBBYING ACTIVITIES
Complete this form to disclose lobbying activities pursuant to
Substitute Form SF -LLL
44
31 U.S.C. 1352
(
)
1. Type of Federal Action:
_a. contract
_b. grant
_c. cooperative
agreement
d. loan
e. loan guarantee
f. loan insurance
4. Name & Address of Reporting Entity:
_Prime _ Subawardee
Tier , if known:
Congressional District,
if known:
6. Federal Department/Agency:
8. Federal Action Number
if known:
10. a. Name & Address of Lobbying
Entity (if individual, last name, first name,
MI)
(attach Continuation Sheet(s) if necessary)
11. Amount of Payment (check all that
apply):
$
actual planned
12. Form of Payment (check all that
2. Status of Federal Action:
a. Proposal /offer /application
b. initial award
c. post -award
3. Report Type:
a. initial filing
b. material change
For Material Change
Only:
year quarter
date of last report
5. If Reporting Entity in #4 is
Subawardee, Enter Name & Address of
Prime:
Congressional District,
if known:
7. Federal Program Name /Description:
9. Award Amount, if known:
$
b. Individuals Performing Services
(including address if different from #10a;
last name, first name, MI):
13. Type of Payment (check all that
apply):
a. retainer
b. one -time fee
c. commission
d. contingent fee
e. deferred
RFP #03.10 Transit AVUMDT Project
apply):
a. cash
b. in -kind; specify:
14. Brief description of Services Performed or to be Performed and Date(s) of
Service, including officer(s), employees(s), or Member(s) contacted for Payment
indicated in Item 11:
(attach continuation sheet(s) if necessary
15. Continuation Sheet(s) attached: Yes No
16.
Signature:
Print
Name:
Title:
Telephone No.:
Date:
nature:
value:
45
_ f. other, specify:
DISCLOSURE OF LOBBYING ACTIVITIES CONTINUATION SHEET
(Substitute Form SF- LLL -A)
Reporting Entity:
Page of
i
RFP #03.10 Transit AVL /MDT Project
CERTIFICATE NUMBER SEVEN
CERTIFICATION OF BUY AMERICA REQUIREMENTS
49 U.S.C. 5323(j)
49 CFR Part 661
46
RFP #03.10 Transit AVL /MDT Project
Buy America - The contractor agrees to comply with 49 U.S.C. 5323(j) and 49 C.F.R.
Part 661, which provide that Federal funds may not be obligated unless steel, iron, and
manufactured products used in FTA- funded projects are produced in the United States,
unless a waiver has been granted by FTA or the product is subject to a general waiver.
General waivers are listed in 49 C.F.R. 661.7, and include final assembly in the United
States for 15 passenger vans and 15 passenger wagons produced by Chrysler
Corporation, and microcomputer equipment and software. Separate requirements for
rolling stock are set out at 49 U.S.C. 5323(j)(2)(C) and 49 C.F.R. 661.11. Rolling stock
must be assembled in the United States and have a 60 percent domestic content.
A bidder or offeror must submit to Ozark Regional Transit the appropriate Buy America
certification (below) with all bids or offers on FTA- funded contracts, except those
subject to a general waiver. Bids or offers that are not accompanied by a completed
Buy America certification must be rejected as nonresponsive. This requirement does
not apply to lower tier subcontractors.
Certification requirement for procurement of steel, iron, or manufactured products.
Certificate of Compliance with 49 U.S.C. 5323(j)(1)
The bidder or offeror hereby certifies that it will meet the requirements of 49 U.S.C.
5323(j)(1) and the applicable regulations in 49 CFR Part 661.5.
Date
Signature
Company Name
Title
Certificate of Non - Compliance with 49 U.S.C. 5323(j)(1)
The bidder or offeror hereby certifies that it cannot comply with the requirements of 49
U.S.C. 5323(j)(1) and 49 C.F.R. 661.5, but it may qualify for an exception pursuant to
49 U.S.C. 5323(j)(2)(A), 5323(j)(2)(B), or 5323(j)(2)(D), and 49 C.F.R. 661.7.
Date
Signature
Company Name
Title
47