20250224_RO_Citation_Issuance_&_Mobile_LPR_TCM.xlsx

XLSX spreadsheet 51 KB Posted Feb 28, 2025

Attached to: Citation Issuance & Mobile LPR
Solicitation number: RFP-RO-2025-021
Issued by: Oakland County, Michigan

About this file

Written by GovTribe AI · May 11, 2025

The document is a Request for Proposal (RFP) from the City of Royal Oak, Michigan, for Citation Issuance Devices & Software and a Mobile License Plate Recognition (LPR) System. The City is seeking electronic proposals through their procurement portal, with submissions due by 1:00 pm on Wednesday, April 2, 2025. The comprehensive RFP covers two primary technology systems: citation issuance handheld devices with associated software and a mobile LPR system for parking enforcement. The RFP outlines detailed technical requirements, including specifications for hardware durability, software functionality, data management, integration capabilities, security protocols, and support services. The systems are expected to provide real-time enforcement capabilities, including digital tire chalking, time limit monitoring, and integration with various parking technologies.

The RFP includes extensive requirements for system performance, including 99.5% annual uptime, secure data hosting, and comprehensive integration with existing and future parking technologies. The contractor will be responsible for providing hardware, software, cloud-based servers, implementation, training, and ongoing technical support. Key technical requirements include the ability to read license plates with 98% accuracy, support for various plate types, real-time data sharing, and robust security measures. The City retains exclusive ownership of all generated data, and the contractor is prohibited from sharing personal information. The contract will include a minimum one-year hardware warranty, with options for extended warranties, and support services available seven days a week during specified hours. The RFP also outlines detailed liquidated damages provisions for system failures and performance issues.

View the file

Other files

File	Type	Posted
Citation_Issuance_&_Mobile_LPR_(Addendum_#1_Revision).pdf	PDF	Mar 27, 2025
RO_Attachment_B_UD-8_Supplemental_field_information.doc	DOC document	Feb 28, 2025
RO_Attachment_A_TKTDATAP-UD8_field_layout_positions.doc	DOC document	Feb 28, 2025
20250224_RO_Citation_Issuance_&_Mobile_LPR_SOW_FINAL.docx	DOCX document	Feb 28, 2025
20250224_RO_Citation_Issuance_&_Mobile_LPR_RFP_Items_FINAL.docx	DOCX document	Feb 28, 2025
20250224_RO_Citation_Issuance_&_Mobile_LPR_Pricing_Workbook.xlsx	XLSX spreadsheet	Feb 28, 2025

On GovTribe

Work with this file

Download the original file
Contacts named in this file
Similar government files
Ask GovTribe AI about this file

Try for free Login

Text version

The file's text, extracted by GovTribe without its formatting.

Instructions Proposer:

General

For submittal, save and submit the TCM as an Excel file.

Enter your company's name in the yellow highlighted section on each tab.

DO NOT add or remove rows or columns.

Minimum Qualifications/Requirements

Proposers shall select if they Comply or Do Not Comply with each Minimum Qualification/Requirement Column C (“Response”) for each of the following tabs.

Proposers may enter additional context in Column D (“Comments (Optional)”) for each tab.

Proposers shall not enter any comments in Column D ("Comments (Optional)") that contradict the Proposer’s response in Column C (“Response”). In cases where it is perceived that the comments contradicts the response in Column D, the line item will be scored as Cannot Meet.

DO NOT edit any content in columns A-B.

Technical Requirements
Tab Name	RFP Section	Number of Requirements
1 CitationIssuanceDevices&Softw	1 Citation Issuance Devices & Software	108
2 Mobile LPR	2 Mobile License Plate Recognition System (LPR)	93

Instructions

For submittal, save and submit the TCM as an Excel file.

Proposers shall select a response for each requirement Column D (“Response”) for each of the following tabs. A description of each response is below.

If the response for a requirement is "Future Release", the Proposer must include an estimated release date in the comments section.

Proposers may enter additional context in Column E (“Comments (Optional)”) for each tab.

Proposers shall not enter any comments in Column E ("Comments (Optional)") that contradict the Proposer’s response in Column D (“Response”). In cases where it is perceived that the comments contradicts the response in Column D, the line item will be scored as Cannot Meet.

Enter your company's name in the yellow highlighted section on each tab.

DO NOT add or remove rows or columns.

DO NOT edit any content in columns A-C.

Response Options
Response	Description
Comply	The system meets the requirement as is with no additional configuration or custom programming/coding.
With Configuration/Programming	The system will meet the requirement before the System is live by arranging the functional parameters that are already inherent in the product or by modifying the product’s source code (changing or adding new code) so that it functions in a way that meets the City’s specific business needs.
Future Release	The current version of the system cannot meet the requirement “Comply” or “With Configuration/Programming” but will be able to with a scheduled, future release of the product. Proposers must provide an estimated release date with this response.
Cannot Meet	The System cannot or does not meet the requirement.

MinQual CitationIssuance

Minimum Qualifications/Requirements Citation Issuance Devices & Software Proposers		Proposer:
Section Description	Requirement	Response	Comments (Optional)
Minimum Qualifications / Requirements	Proposer shall have five (5) years of experience providing hardware and software for the issuance of parking citations, with more than 10,000 citations processed annually.			Comply
Minimum Qualifications / Requirements	Proposer shall provide and support handheld issuance devices and printers.			Do Not Comply
Minimum Qualifications / Requirements	Proposer shall have the ability to configure daily batch reports (flat file) with Court-defined data fields as provided in Attachment A and B to a Court-defined location.

MinQuals Mobile LPR

Minimum Qualifications/Requirements Citation Issuance Devices & Software Proposers		Proposer:
Section Description	Requirement	Response	Comments (Optional)
Minimum Qualifications / Requirements	Proposer shall have five (5) years of experience providing hardware and software for Mobile LPR.			Comply
				Do Not Comply

1 CitationIssuanceDevices&Softw

1. Citation Issuance Devices & Software		Proposer:
Section Description	RFP Requirement #	Requirement	Response	Comments (Optional)
1.1 Enforcement Handhelds	1.1.1	The Contractor shall supply the City with handheld citation issuance devices and printers and manage and support the devices for the duration of the contract.
1.1 Enforcement Handhelds	1.1.2	The Contractor shall provide the data/cellular plan for the handheld citation issuance devices.
1.1 Enforcement Handhelds	1.1.3	The handheld and printer must include the protective infrastructure to ruggedize and protect equipment from working conditions and outdoor elements.
1.1 Enforcement Handhelds	1.1.4	The Contractor shall provide the necessary charging equipment for the handheld citation issuance devices and printers.
1.1 Enforcement Handhelds	1.1.5	The handheld and printer shall be able to withstand drops, be water resistant, and have appropriate screen protection and grip control.
1.1 Enforcement Handhelds	1.1.6	The life span of all devices shall be at least three years with proper use.
1.1 Enforcement Handhelds	1.1.7	Cellular communications on any handheld device provided to the City during the contract term shall last at least five years.
1.1 Enforcement Handhelds	1.1.8	The Contractor shall support all devices for the agreement term, including hardware, operation system software, and communication plans.
1.1 Enforcement Handhelds	1.1.9	Handheld and printer batteries shall last an entire shift (up to 11 hours); supplemental in-field replaced battery packs or mobile charging will be acceptable.
1.1 Enforcement Handhelds	1.1.10	Handheld devices shall include a camera with a minimum resolution of 8 megapixels, be able to take photos in all lighting conditions and geotag the images taken.
1.1 Enforcement Handhelds	1.1.11	Handheld and printer shall have an optional carrying case.
1.1 Enforcement Handhelds	1.1.12	Handheld devices shall include Wi-Fi, Bluetooth, and GPS capability.
1.1 Enforcement Handhelds	1.1.13	Should advancements in cellular technology or end-of-life require new devices, the Contractor will provide the City with at least one year's notice and reasonably priced upgrade options.
1.1 Enforcement Handhelds	1.1.14	In the case of separate components, printers shall include Bluetooth capability and shall not require a physical connection to the handheld for operations.
1.1 Enforcement Handhelds	1.1.15	All handheld devices shall be interchangeable when paired with all printers. However, a handheld shall not deviate from the current printer connection without the user prompting a new connection.
1.1 Enforcement Handhelds	1.1.16	Handheld devices shall include functionality that prevents device usage as a telephone or allows calling only to specific phone numbers, as directed by the City.
1.1 Enforcement Handhelds	1.1.17	Handheld devices shall include functionality that prevents SMS/text capability use unless limited to specific numbers, as the City directs.
1.1 Enforcement Handhelds	1.1.18	Handheld devices shall include functionality that restricts the device so that users in the field cannot add or remove apps/software unless directed by the City.
1.1 Enforcement Handhelds	1.1.19	The Contractor shall provide handheld device printer citation paper stock for the duration of the contract.
1.1 Enforcement Handhelds	1.1.19.1	The citation paper stock shall include a design and text provided by the City.
1.2 Citation Issuance Software	1.2.1	The following fields, at a minimum, must be captured during citation issuance by the Contractor’s enforcement software:

- Citation number

- Citation date and time

- Amount due

- Officer name

- Officer ID/Badge

- Location of violation, including City defined zones

- Meter Number field

- Violation code and description (up to three)

- License plate

- Where plate is not available, a field for up to 17-digit VIN shall be provided

- State

- Registration expiration (Year/Month), Body Type (DMV specific), Vehicle Make, Vehicle Color

- Last four digits of VIN

- Officer signature

- Notes to print on citation (known as external notes)

- Officer notes, not visible to the public (known as internal notes)

- Electronic marking

- Photos, videos, and audio

1.2 Citation Issuance Software	1.2.2	Software shall have the ability to support pay-by-plate, pay-by-space, permit status, and mobile payments.
1.2 Citation Issuance Software	1.2.3	Software shall provide a user-friendly interface for ease of use and durability.
1.2 Citation Issuance Software	1.2.4	Software shall require a password/security sign-in to prevent unauthorized use
1.2 Citation Issuance Software	1.2.5	Software shall allow the user to view and void any citation written by the user in the active session.
1.2 Citation Issuance Software	1.2.6	Software shall support voiding a previously issued citation requiring a City-defined reason/code and explanation input.
1.2 Citation Issuance Software	1.2.7	Software shall support reprinting an issued citation that is identical to the original.
1.2 Citation Issuance Software	1.2.8	Software shall automatically transfer and upload citations issued by the handheld to the Data Management System (DMS) in real time, including any audio and/or picture associated with the citation.
1.2 Citation Issuance Software	1.2.9	Software shall not allow an officer to attempt to issue a citation unless all required fields have been entered with valid information. For example, a citation cannot be created without a violation code, license plate, or VIN.
1.2 Citation Issuance Software	1.2.10	Upon entering a license plate during citation entry, the software shall automatically search necessary lists (scofflaw, permit, hotlist, stolen vehicle, etc.) for a match.
1.2 Citation Issuance Software	1.2.10.1	If a match is found, the appropriate information will be displayed on the handheld screen.
1.2 Citation Issuance Software	1.2.11	Software shall support monitoring vehicles in a fixed time limit zone across accessible to all handhelds simultaneously. This shall allow multiple Officers to enforce time limits at the location simultaneously.
1.2 Citation Issuance Software	1.2.12	Software shall accurately time and date stamp transactions by the system’s master clock.
1.2 Citation Issuance Software	1.2.13	Software shall support issuing and tracking warning notices and actual citations, including issuance history by license plate.
1.2 Citation Issuance Software	1.2.14	Software shall support standard location codes or block faces and descriptions. When necessary, locations shall also be manually generated.
1.2 Citation Issuance Software	1.2.15	Software shall support multiple citation number sequences and formats.
1.2 Citation Issuance Software	1.2.16	The software shall, at minimum, allow the selection of the previous location for a new citation; otherwise, it supports the geofencing capability to auto-populate locations.
1.2 Citation Issuance Software	1.2.17	Software shall include geolocation functionality, where the user's zones or location will be updated and the related field populated; however, the user may change the zone or location.
1.2 Citation Issuance Software	1.2.18	Software shall support real-time tracking of officer location based on GPS coordinates.
1.2 Citation Issuance Software	1.2.19	All prefilled selectable fields shall allow a user to view the entire field before selection. This may include scrolling across the field to view.
1.2 Citation Issuance Software	1.2.20	All prefilled selectable fields shall allow for alphanumeric keyboard entry, narrowing the available selectable fields to the entry.
1.2 Citation Issuance Software	1.2.21	Software shall support photos taken as part of the citation process. These photos shall be maintained within the citation “app” and uploaded to the DMS, not simply placed on the device’s “camera roll.”
1.2 Citation Issuance Software	1.2.21.1	The City shall be able to set a minimum number of photographs that must be taken for each citation.
1.2 Citation Issuance Software	1.2.21.2	If the Contractor has a maximum number of photographs per citation, it must be greater than 10.
1.2 Citation Issuance Software	1.2.22	Provide a set of pre-fixed text lines for the notes (both printed and internal); when the officer is completing the notes, they can pick from City-defined pre-established text lines or use free-from text entry.
1.2 Citation Issuance Software	1.2.23	The solution shall integrate with LPR systems so that any “hit” on the mobile LPR can be transferred seamlessly to the handheld, including associated LPR images.
1.2 Citation Issuance Software	1.2.24	Software shall allow a user to cancel a citation or warning that has not been completed (e.g., the citation has not been printed or marked as “drive-away”).
1.2 Citation Issuance Software	1.2.25	Software shall support an Officer activity log, allowing the Officer to record issues or notes in the field.
1.2 Citation Issuance Software	1.2.26	Print a complete citation or warning ticket, including the following fields on the front:

- Citation or warning number

- Date and time issued

- Badge number and name of issuing officer

- Location where citation issued

- Violation code for which the citation is being issued

- Violation description

- Violation amount

- Any State surcharge

- Total amount due

- Vehicle license plate or full VIN

- The Last 4 digits of the VIN

- Vehicle registration expiration date

- Vehicle make

- Vehicle color

- Vehicle type

- Public notes

1.3 Data Management System (DMS)	1.3.1.1	The DMS shall file and store citations in an easily retrievable format for the required timeframe by the City and State.
1.3 Data Management System (DMS)	1.3.1.2	The DMS shall provide a process and reporting for the City to review duplicate citations and correct dates, violation codes, and fine amounts.
1.3 Data Management System (DMS)	1.3.1.3	The DMS shall allow for assigning permissions to access certain features based on user ID, including limitations on the ability to correct dates, duplicate citations, violation codes, fine amounts, and void codes.
1.3 Data Management System (DMS)	1.3.1.4	The DMS shall allow customizable void codes/reasons. All codes shall have automation capabilities, allowing for their application and removal based on specific business rules dictated by the City.
1.3 Data Management System (DMS)	1.3.1.5	The DMS shall provide complete audit trail information for every action taken on a citation. This information must be captured and retained for each citation until the related citation is purged from the system per the policies established by the City. The city will also subject all activities to a detailed audit.
1.3 Data Management System (DMS)	1.3.2	The DMS shall allow for the City to perform the following functions:

Entry of manually issued citations.

1.3 Data Management System (DMS) 1.3.3 The DMS shall allow for the City to perform the following functions:

Query for citation data by any one or multiple input fields, including, but not limited to, date, citation number, license plate number, citation location, enforcement officer, and VIN.

1.3 Data Management System (DMS) 1.3.4 The DMS shall allow for the City to perform the following functions:

Add notes to citations and plates.

1.3 Data Management System (DMS) 1.3.5 The DMS shall allow for the City to perform the following functions:

Void citations with custom City void codes.

1.3 Data Management System (DMS) 1.3.6 The DMS shall allow for the City to perform the following functions:

View and print a copy of a citation and images/photos taken during citation issuance.

1.3 Data Management System (DMS) 1.3.7 The DMS shall allow for the City to perform the following functions:

The Contractor’s reporting shall be able to query reports by multiple filters such as date, channel, citation, permit, etc.

1.3 Data Management System (DMS) 1.3.8 The DMS shall allow for the City to perform the following functions:

Batch reporting shall be acceptable for large amounts of data only.

1.3 Data Management System (DMS) 1.3.9 The DMS shall allow for the City to perform the following functions:

The DMS reporting shall allow for the set up of automated reports

1.3 Data Management System (DMS) 1.3.10 The DMS shall allow for the City to perform the following functions:

Reports shall be exportable in PDF and Excel/CSV formats.

1.3 Data Management System (DMS) 1.3.11 The DMS shall allow for the City to perform the following functions:

Ability to schedule routine reports to run and auto-send to specified recipients via email

1.4 Court Integration	1.4.1	The Contractor shall be able to transfer daily batch reports (flat file) with Court-defined data fields as provided in Attachment A and B to a Court-defined location.
1.4 Court Integration	1.4.2	The Contractor shall be responsible for providing out-of-state registered owner information.
1.5 System and Security Requirements	1.5.1	The Contractor shall provide secure hosting and support for all functions, ensuring availability through the Internet for all devices, including desktop and mobile computers, phones, tablets, and other wireless devices. The City shall not be required to install or maintain software on servers owned or managed by the City.
1.5 System and Security Requirements	1.5.2	Computers shall not require special software packages or “client” software. Any computer shall access the DMS without plug-ins or other components through a standard web browser.
1.5 System and Security Requirements	1.5.3	The Contractor shall be responsible for taking every precaution to ensure the reliability of all systems, files, data, equipment, communications, and facilities.
1.5 System and Security Requirements	1.5.4	The Contractor shall be responsible for virus detection, prevention, control, and eradication for all servers and connected devices.
1.5 System and Security Requirements	1.5.5	The Contractor shall have security features designed to protect the security and confidentiality of all information contained in the database. The Contractor’s security for the DMS and all connections thereto shall conform to current industry best practices.
1.5 System and Security Requirements	1.5.6	The Contractor is expressly forbidden from selling, leasing, distributing, publishing, or otherwise sharing any personal information collected from the City, including, but not limited to, transaction history, address, email address, phone number, and credit card information. Notwithstanding the preceding restrictions, The Contractor shall be permitted to use such information to enable the services provided to the City as part of this agreement. At the City’s sole discretion, the City may direct the Contractor to share data securely with City-appointed parties.
1.5 System and Security Requirements	1.5.7	All information security incidents shall be reported immediately to the City. Security incidents include theft, loss, damage, or compromise to information systems and data, known vulnerabilities and exploits, website defacement or compromise, successful malware attacks, denial of services, and other security events as defined by the City’s Information Security Officer.
1.5 System and Security Requirements	1.5.8	The Contractor shall establish and maintain data storage, retention, and archive procedures to maintain all system performance.
1.5 System and Security Requirements	1.5.9	The System shall provide full system backup and recovery capabilities. The Contractor shall maintain the database, including backup and recovery procedures. The Contractor shall make sufficient backups to ensure that no data is lost in any circumstances.
1.5 System and Security Requirements	1.5.10	System uptime is critical. The Contractor will maintain a 99.5% or greater uptime annually for the system as a whole, including any essential subsystems in solution operation.
1.5 System and Security Requirements	1.5.11	Uptime will exclude scheduled maintenance. The Contractor will notify the City of any scheduled downtime at least seven days in advance. Scheduled maintenance shall be coordinated to have the least negligible impact on City operations.
1.6 Data Requirements	1.6.1	The City shall be the exclusive owner of all data and rights to the data generated from all systems, regardless of whether the data is direct, derived, calculated, or modeled.
1.6 Data Requirements	1.6.2	The Contractor shall store or archive (with the City’s approval) all transaction data generated during the term of the Agreement and retain it for at least five years after its termination.
1.6 Data Requirements	1.6.3	The Contractor shall deliver copies of all system data upon request of the City or its designee and upon the termination of the Agreement in a format mutually agreed upon by both parties.
1.6 Data Requirements	1.6.4	The Contractor shall be responsible for providing transaction data in a format that is readable by the City using commonly available commercial off-the-shelf software.
1.6 Data Requirements	1.6.5	If the successor contract is awarded to another firm after the termination of the contract for any reason resulting from this RFP, the Contractor must develop and implement a Data Conversion Plan with the City or its designee.
1.7 Integration Requirements	1.7.1	The Contractor shall utilize open-source APIs that allow for current and future integration with third parties.
1.7 Integration Requirements	1.7.2	The Contractor shall provide real-time integration with the City’s current, new, and future parking technology and data management contractors, including, but not limited to, citation issuance/enforcement handhelds, LPR, mobile payment, parking permits, and pay-by-plate pay stations. These types of integrations are considered standard in the industry.
1.7 Integration Requirements	1.7.3	The City recognizes that standard integrations have a certain amount of latency between systems. However, timely data exchanges are required for efficient and accurate parking operations. The latency between any two systems shall not exceed an average of 90 seconds for every 100 consecutive transactions. The latency measurement shall be defined as when a data request is made or data is sent and when the data is delivered and viewable to any end user.
1.7 Integration Requirements	1.7.4	If latency is observed in excess of 90 seconds, the Contractor will work with the City to measure it, identify the point of default, and correct the default.
1.7 Integration Requirements	1.7.5	The City may consider custom integration, which is nonstandard and not identified in this RFP. The Contractor agrees to provide the necessary development to achieve a custom integration for a mutually agreed-upon cost and schedule, which will be memorialized in an amendment to the resulting contract from this RFP.
1.7 Integration Requirements	1.7.6	Batch data transfer may be considered for specific integrations at the sole discretion of the City.
1.7 Integration Requirements	1.7.7	The Contractor shall provide all necessary parking-related data in a format compatible with standard industry integrations. If the data formats of the City Contractors do not match, the City may require either Contractor to make reasonable changes to their format at no additional cost to the City.
1.7 Integration Requirements	1.7.8	The Contractor shall operate in good faith with the City and the City’s designated Contractors to implement, troubleshoot, and complete necessary integration as defined by the City.
1.7 Integration Requirements	1.7.9	If two or more Contractors cannot agree on the methodology for any integration, the City will select the method that is most advantageous for the City.
1.7 Integration Requirements	1.7.10	The Contractor shall be able to transfer daily batch reports (flat file) with City-defined data fields to a City-defined location or system.
1.8 Required Integrations	1.8.1	The DMS and handhelds shall integrate with:

- Parking Meter or Pay Station System

- Parking Access Revenue Control System

- License Plate Recognition System

- Mobile or Text-to-Pay Payment System

- Permit Management System or any local databases necessary for permit processing

1.9 Warranty & Support Services	1.9.1	The Contractor shall include a minimum of a one-year hardware warranty for any hardware delivered to the City.
1.9 Warranty & Support Services	1.9.2	The Contractor shall provide extended hardware warranty options.
1.9 Warranty & Support Services	1.9.3	The Contractor shall provide a warranty on all software and system solutions for the contract term.
1.9 Warranty & Support Services	1.9.4	The Contractor shall provide ongoing support services through the contract term, including a toll-free phone number and online help (Help Desk). Support services shall be available from 8 a.m. to 5 p.m. Eastern Time Zone reasonable hours, seven days per week (excluding holidays).
1.9 Warranty & Support Services	1.9.5	The Contractor shall acknowledge any requests for support that cannot be handled immediately by the Help Desk within one business day and update them regularly.
1.9 Warranty & Support Services	1.9.6	A staff of experienced, well-trained technicians must provide the Contractor’s support services.
1.9 Warranty & Support Services	1.9.7	The Contractor shall utilize a ticket tracking system to open, track, and close support requests from the City.
1.9 Warranty & Support Services	1.9.8	The Contractor shall provide regular and ongoing technical bulletins that identify product notifications, technology updates, lessons learned, and system performance that detail issues, changes, improvements, and upgrades.
1.10 Training	1.10.1	The Contractor shall provide a training plan that includes but is not limited to all functionality of system operations, enforcement devices, DMS, LPR in-vehicle and back office, and reporting. The training plan shall include:

- Types of the training course with a target audience

- Description of the course

- Length of course

- Method of training (video conference, in person, etc.)

- Prerequisites for the training course

1.10 Training	1.10.2	The Contractor shall provide training in person or via video conference as is most appropriate for the topic. At a minimum, the Contractor will provide at least two days of onsite/in-person training.
1.10 Training	1.10.3	The City may request additional training sessions at reasonable intervals and lengths via video conference for no extra cost for the contract term.
1.10 Training	1.10.4	The Contractor will provide the necessary training to the City for any new, upgraded, or additional functionality provided during the contract term.
1.10 Training	1.10.5	The City may request additional in-person training sessions. The Contractor will provide a quote for services within one week and perform that training within four weeks of the City’s request.
1.10 Training	1.10.6	The Contractor shall supply and keep current digital copies of all operations, training, and user manuals, which include detailed instructions for operating the entire solution.
1.11 Liquidated Damages	1.11.1	Both parties will agree that the annual liquidated damages shall be limited to the amount paid or due to the Contractor by the City during a one-year period except in the initial 12-month period of this Agreement, where liquidated damages shall be limited to 30% of the amount paid or due to the Contractor by the City during the initial 12-month period of this Agreement. The Contractor agrees to pay (or provide invoice credit) these amounts to the City as set forth:

System Failure: The System shall not be unavailable during peak hours (8:00 AM and 5:30 PM, PDT/PST, Monday through Friday, excluding City holidays) for more than 30 minutes and/or for two or more incidents during these hours totaling more than 60 minutes within one business day. During non-peak hours, the System shall not be unavailable for more than four hours. Exceptions will be made if requested and approved in writing by the City. The Contractor shall not be responsible for unavailability caused by third-party providers. Any System unavailability that prevents the processing of bank cards and the collection of related revenue shall result in damages of $500 per incident, not to exceed $1,000 within a 24-hour period.

2 Mobile LPR

2 Mobile License Plate Recognition System (LPR)		Proposer:
Section Description	RFP Requirement #	Requirement	Response	Comments (Optional)
2.1 LPR System Requirements	2.1.1	The LPR system shall be capable of sharing data with the designated enforcement device(s) or handheld(s). This includes transferring the LPR-captured violation data, including license plate information, violation images, time stamps, and GPS locations, to the City’s enforcement device(s) for citation issuance.
2.1 LPR System Requirements	2.1.2	The LPR system should monitor time limits, permit status, pay-by-plate valid parking sessions, pay-by-text, and mobile payments in real-time, along with the various hotlists/databases as specified by the City. This includes the ability to seamlessly monitor multiple parking rights, or “permits,” during any particular enforcement route or session, including simultaneous enforcement of time limits and permit zones.
2.1 LPR System Requirements	2.1.3	LPR components on/in vehicles shall be weatherproof and capable of continuous, dependable operation under the range of weather conditions experienced in Royal Oak, Michigan.
2.1 LPR System Requirements	2.1.4	LPR cameras shall be capable of capturing license plates in various parking spaces (on—and off-street, including surface lots) configurations, including parallel, perpendicular, and angled spaces.
2.1 LPR System Requirements	2.1.5	LPR cameras must be capable of producing high-quality images of license plates regardless of weather or lighting conditions (e.g., dim or bright).
2.1 LPR System Requirements	2.1.6	The LPR cameras shall be capable of reading and interpreting non-reflective, specialty, digital, and Canadian license plates. For Michigan-issued license plate types, see https://www.michigan.gov/sos/vehicle/license-plates.
2.1 LPR System Requirements	2.1.7	All reads by the cameras shall have a context photo, a photo of the plate, and complete metadata, including the interpreted plate, GIS coordinates, date, time, ID of patroller/vehicle, ID of camera (left/right) capturing the image, Officer or User ID, and block face ID (if configured).
2.1 LPR System Requirements	2.1.8	LPR systems must be compatible to be installed on the City’s 2022 Ford Escape.
2.1 LPR System Requirements	2.1.9	The LPR system shall be capable of providing digital tire chalking for time limit monitoring; this includes the ability to monitor time limit violations by parking space, defined zone, or defined distance (e.g., a car must relocate at least 150 feet from the original parking location).
2.1 LPR System Requirements	2.1.10	The vehicles’ LPR units shall be able to connect with and share data between all other Contractor LPR units in the City in real time to maintain continuous operation and support of the same enforcement duties using multiple LPRs; i.e., LPR Unit #1 captures plates for vehicles parked on Street X; LPR Unit #2 shall be able to enforce Street X time limits for vehicles that were captured by Unit #1.
2.1 LPR System Requirements	2.1.11	The LPR system should be able to integrate with a third-party application and/or web-based system broadcasting real-time parking availability to customers.
2.1 LPR System Requirements	2.1.12	The LPR system shall have the ability to create routing plans and geofencing capabilities for zone-based enforcement.
2.1 LPR System Requirements	2.1.13	The LPR system shall include an integrated assisted GPS module.
2.1 LPR System Requirements	2.1.14	The LPR system shall function alongside other applications and systems in the enforcement vehicles.
2.2 Cloud-Based Server	2.2.1	The LPR system shall allow for the ability to define authorized users with varying levels of access (officer, supervisor, analyst, site administrator).
2.2 Cloud-Based Server	2.2.2	The LPR system shall allow authorized users to generate productivity reports.
2.2 Cloud-Based Server	2.2.3	The LPR system shall allow users to view dashboards of activity.
2.2 Cloud-Based Server	2.2.4	The LPR system shall generate hit location, date, and time reports.
2.2 Cloud-Based Server	2.2.5	The LPR system shall provide audit trails of user activity.
2.2 Cloud-Based Server	2.2.6	The LPR system shall collect, format and report daily occupancy by route(s) and location(s).
2.2 Cloud-Based Server	2.2.7	The LPR system shall allow users to identify license plate read accuracy.
2.2 Cloud-Based Server	2.2.8	The LPR system shall report trends in license plate number captures over time (e.g., what percent of plates are observed once per week versus five (5) times per week).
2.2 Cloud-Based Server	2.2.9	The LPR system shall integrate and create custom databases (e.g., vehicles of interest).
2.2 Cloud-Based Server	2.2.10	The LPR system shall allow for the City to set a time for data retention, with overrides for specific reads if the data need to be retained for investigative or adjudication purposes.
2.2 Cloud-Based Server	2.2.11	The LPR system shall adhere to the protocols dictated by The Department of Justice Cyber Security Program and the Criminal Justice Information Services (CJIS).
2.3 In-Vehicle LPR Units	2.3.1	The LPR system shall provide a live feed to the user of the license plates that were captured, including the plate photo and the interpretation of the plate after OCR
2.3 In-Vehicle LPR Units	2.3.2	The LPR system shall simultaneously monitor for all types of parking restrictions for the currently selected zone, including multiple types of license plate-based parking payments/permits (including detection of multiple vehicles sharing a permit), scofflaws, multiple hotlists, and other parking regulations (e.g., 72-hour rule).
2.3 In-Vehicle LPR Units	2.3.3	The LPR system shall raise an audible and visible indicator to the operator for any exception conditions, including:

- Vehicles not parked in compliance with the rule set currently chosen for enforcement (which may include a mixture of time zone restrictions, permits, and payments)

- Vehicles on hot lists designated by the City that may include, but are not limited to, local and State law enforcement

- Vehicles on allowlists provided by various sources

2.3 In-Vehicle LPR Units	2.3.4	The visible alert shall provide clear information to the operator and remain displayed until acknowledged/dismissed by the operator; while the alert is displayed, the LPR system shall continue reading and processing plates
2.3 In-Vehicle LPR Units	2.3.5	The LPR system shall allow manual entry of plates that were not interpreted accurately or not visible to the cameras; the LPR system shall flag the manual entry for reporting purposes
2.3 In-Vehicle LPR Units	2.3.6	The LPR system shall allow the operator to deactivate and reactivate either camera on the vehicle so that reads are done only on one side of the street. Left and right-side cameras must be positioned correctly, clearly delineated, and programmed to ensure accurate reporting and violation capture.
2.4 Implementation Requirements	2.4.1	The Contractor shall provide an initial purchase of one (1) complete LPR Systems that include the camera equipment, in-vehicle laptops or tablets (including mounting equipment for City vehicles), communications equipment including GPS technology, any software necessary to support the requested services, all associated mounting hardware, cables, installation, and training.
2.4 Implementation Requirements	2.4.2	The Contractor shall provide alternate leasing options for one and two LPR units.
2.4 Implementation Requirements	2.4.3	The Contractor shall allow for the purchase of additional LPR units in the future.
2.4 Implementation Requirements	2.4.4	The Contractor shall deploy, configure, and manager of one (1) cloud-based server.
2.4 Implementation Requirements	2.4.5	The Contractor shall provide application, GPS, and mapping capabilities.
2.4 Implementation Requirements	2.4.6	The Contractor shall purchase or license the Central LPR Software System.
2.4 Implementation Requirements	2.4.7	The City is soliciting various parking technologies, including Citation Issuance Devices & Software (this RFP), Paid Parking Technologies: Pay-by-Plate Pay Stations and Mobile Payment (not part of this RFP), and Parking Garage Paid Parking Equipment (not part of this RFP). The Contractor is expected to integrate these technologies in real-time.
2.4 Implementation Requirements	2.4.8	The Contractor shall provide real-time integration with third-party occupancy and data collection systems.
2.4 Implementation Requirements	2.4.9	The Contractor shall provide Desk Support Services, to include installation of any necessary software for all desktop users and routine updates to the software as required to keep the desktops operational
2.4 Implementation Requirements	2.4.10	The Contractor shall provide Maintenance Services, to include all routine software and hardware maintenance for all mobile units
2.4 Implementation Requirements	2.4.11	The Contractor shall provide Ongoing technical support to keep the LPR system fully functional and accommodate necessary modifications, such as recognition of new plate designs
2.4 Implementation Requirements	2.4.12	The Contractor shall submit operational manuals and training for City staff in various roles (enforcement officer, enforcement supervisor, analysts, etc.), including technical bulletins that identify product notifications, technology updates, lessons learned from other installations, and overall LPR system and performance details, including software and firmware upgrades with an explanation of features and improvements, with each software release, but at a minimum quarterly frequency.
2.4 Implementation Requirements	2.4.13	The Contractor shall conduct on-site testing of LPR, demonstrating the LPR system’s ability to read and store the license plate information with a minimum 98% read accuracy, including plates issued by all jurisdictions in North America.
2.4 Implementation Requirements	2.4.14	The Contractor shall conduct on-site testing of the LPR GPS capabilities and accuracy to demonstrate the LPR system’s ability to accurately enforce no-reparking ordinances at multiple distances and time limits.
2.5 Technical Requirements	2.5.1	The Contractor agrees that all data provided by users and staff is the property of the City, and shall prevent unauthorized parties from accessing, sharing, or using data without written consent from the Royal Oak Police Department. The Contractor is not granted the right to have and use the City’s data for private or public use.
2.5 Technical Requirements	2.5.2	If a new Contractor or LPR system is chosen, the Contractor will provide operational and data transfer support of records and data before the end of the agreement.
2.5 Technical Requirements	2.5.3	The Contractor shall include a copy of each manufacturer’s written warranty statement for any software and each piece of equipment furnished and installed before installation begins. The Contractor shall also provide the details of all warranties that are applicable to the services provided to the City.
2.5 Technical Requirements	2.5.4	The Contractor shall be responsible for ensuring that mobile components can communicate effectively on cellular networks throughout the contract term and any extensions.
2.6 Client Support Requirements	2.6.1	The Contractor shall be required to support all software and hardware for the term of the agreement, including all Contractor-provided software, hardware, communications, repair, maintenance, and the associated training, service updates, and equipment support.
2.6 Client Support Requirements	2.6.2	If available, the Contractor shall host up to two (2) City-designated personnel for the Mobile LPR certification training (times/dates to be mutually agreed upon).
2.7 System and Security Requirements	2.7.1	The Contractor shall provide secure hosting and support for all functions, ensuring availability through the Internet for all devices, including desktop and mobile computers, phones, tablets, and other wireless devices. The City shall not be required to install or maintain software on servers owned or managed by the City.
2.7 System and Security Requirements	2.7.2	Computers shall not require special software packages or “client” software. Any computer shall access the DMS without plug-ins or other components through a standard web browser.
2.7 System and Security Requirements	2.7.3	The Contractor shall be responsible for taking every precaution to ensure the reliability of all systems, files, data, equipment, communications, and facilities.
2.7 System and Security Requirements	2.7.4	The Contractor shall be responsible for virus detection, prevention, control, and eradication for all servers and connected devices.
2.7 System and Security Requirements	2.7.5	The Contractor shall have security features designed to protect the security and confidentiality of all information contained in the database. The Contractor’s security for the DMS and all connections thereto shall conform to current industry best practices.
2.7 System and Security Requirements	2.7.6	The Contractor is expressly forbidden from selling, leasing, distributing, publishing, or otherwise sharing any personal information collected from the City, including, but not limited to, transaction history, address, email address, phone number, and credit card information. Notwithstanding the preceding restrictions, The Contractor shall be permitted to use such information to enable the services provided to the City as part of this agreement. At the City’s sole discretion, the City may direct the Contractor to share data securely with City-appointed parties.
2.7 System and Security Requirements	2.7.7	All information security incidents shall be reported immediately to the City. Security incidents include theft, loss, damage, or compromise to information systems and data, known vulnerabilities and exploits, website defacement or compromise, successful malware attacks, denial of services, and other security events as defined by the City’s Information Security Officer.
2.7 System and Security Requirements	2.7.8	The Contractor shall establish and maintain data storage, retention, and archive procedures to maintain all system performance.
2.7 System and Security Requirements	2.7.9	The System shall provide full system backup and recovery capabilities. The Contractor shall maintain the database, including backup and recovery procedures. The Contractor shall make sufficient backups to ensure that no data is lost in any circumstances.
2.7 System and Security Requirements	2.7.10	System uptime is critical. The Contractor will maintain a 99.5% or greater uptime annually for the system as a whole, including any essential subsystems in solution operation.
2.7 System and Security Requirements	2.7.11	Uptime will exclude scheduled maintenance. The Contractor will notify the City of any scheduled downtime at least seven days in advance. Scheduled maintenance shall be coordinated to have the least negligible impact on City operations.
2.8 Data Requirements	2.8.1	The City shall be the exclusive owner of all data and rights to the data generated from all systems, regardless of whether the data is direct, derived, calculated, or modeled.
2.8 Data Requirements	2.8.2	The Contractor shall store or archive (with the City’s approval) all transaction data generated during the term of the Agreement and retain it for at least five years after its termination.
2.8 Data Requirements	2.8.3	The Contractor shall deliver copies of all system data upon request of the City or its designee and upon the termination of the Agreement in a format mutually agreed upon by both parties.
2.8 Data Requirements	2.8.4	The Contractor shall be responsible for providing transaction data in a format that is readable by the City using commonly available commercial off-the-shelf software.
2.8 Data Requirements	2.8.5	If the successor contract is awarded to another firm after the termination of the contract for any reason resulting from this RFP, the Contractor must develop and implement a Data Conversion Plan with the City or its designee.
2.9 Integration Requirements	2.9.1	The Contractor shall utilize open-source APIs that allow for current and future integration with third parties.
2.9 Integration Requirements	2.9.2	The Contractor shall provide real-time integration with the City’s current, new, and future parking technology and data management contractors, including, but not limited to, citation issuance/enforcement handhelds, LPR, mobile payment, parking permits, and pay-by-plate pay stations. These types of integrations are considered standard in the industry.
2.9 Integration Requirements	2.9.3	The City recognizes that standard integrations have a certain amount of latency between systems. However, timely data exchanges are required for efficient and accurate parking operations. The latency between any two systems shall not exceed an average of 90 seconds for every 100 consecutive transactions. The latency measurement shall be defined as when a data request is made or data is sent and when the data is delivered and viewable to any end user.
2.9 Integration Requirements	2.9.4	If latency is observed in excess of 90 seconds, the Contractor will work with the City to measure it, identify the point of default, and correct the default.
2.9 Integration Requirements	2.9.5	The City may consider custom integration, which is nonstandard and not identified in this RFP. The Contractor agrees to provide the necessary development to achieve a custom integration for a mutually agreed-upon cost and schedule, which will be memorialized in an amendment to the resulting contract from this RFP.
2.9 Integration Requirements	2.9.6	Batch data transfer may be considered for specific integrations at the sole discretion of the City.
2.9 Integration Requirements	2.9.7	The Contractor shall provide all necessary parking-related data in a format compatible with standard industry integrations. If the data formats of the City Contractors do not match, the City may require either Contractor to make reasonable changes to their format at no additional cost to the City.
2.9 Integration Requirements	2.9.8	The Contractor shall operate in good faith with the City and the City’s designated Contractors to implement, troubleshoot, and complete necessary integration as defined by the City.
2.9 Integration Requirements	2.9.9	If two or more Contractors cannot agree on the methodology for any integration, the City will select the method that is most advantageous for the City.
2.9 Integration Requirements	2.9.10	The Contractor shall be able to transfer daily batch reports (flat file) with City-defined data fields to a City-defined location or system.
2.10 Required Integrations	2.10.1	The LPR shall integrate with:

- Parking Meter or Pay Station System

- Parking citation DMS & handhelds