Exhibit_B_-_DAB_Parking_Access_and_Revenue_Control_System_Specifications.pdf

5/7/26 11 12 11 - PARCS

EXHIBIT B

DAB PARKING ACCESS AND REVENUE CONTROL SYSTEM SPECIFICATIONS

PART 1 - GENERAL

1.1 OVERVIEW

1.2 PARKING FACILITIES

1.3 RELATED DOCUMENTS

1.4 RELATED REQUIREMENTS

1.5 ABBREVIATIONS

1.6 FUTURE SYSTEM EXPANSION

1.7 SYSTEM REQUIREMENTS

1.8 SUBMITTALS

1.9 ITEMS PROVIDED BY THE COUNTY

1.10 MAINTENANCE MATERIALS AND CONSUMABLES

1.11 ENVIRONMENTAL REQUIREMENTS

1.12 WARRANTY

1.13 POST-WARRANTY SOFTWARE SUPPORT SERVICES

1.14 POST-WARRANTY HARDWARE SUPPORT SERVICES

1.15 SPARE PARTS

PART 2 - PRODUCTS

2.1 SOFTWARE

2.2 EQUIPMENT AND SUBSYSTEMS

2.3 PRODUCT CERTIFICATION

PART 3 - EXECUTION

3.1 EXAMINATION

3.2 DELIVERY, HANDLING, AND STORAGE

3.3 DEMOLITION

3.4 INSTALLATION

3.5 FIELD QUALITY CONTROL

3.6 ACCEPTANCE TESTING

3.7 INSTRUCTION AND TRAINING

PART 1 - GENERAL

1.1 OVERVIEW

A. This section includes requirements for Parking Access and Revenue Control System (“PARCS”) for the Daytona Beach International Airport (“DAB”, “Airport”, or “County”).

B. Complete and submit Exhibit E – PARCS Functional Requirements Matrix to demonstrate compliance with, clarification of, and deviations from these specifications.

11 12 11 - PARCS 5/7/26

C. Key PARCS objectives.

1. Provide a PARCS leveraging technologies to enhance the DAB passengers’ parking experience.

2. The County seeks a PARCS partner who will provide the most current and proven PARCS solutions, with an emphasis on open and dynamic integrations that provide an efficient and effective management system, robust databases that provide rich information for decision-making, and partnerships that support and strengthen modern parking management practices.

3. Durability and reliability are paramount. The County seeks a PARCS that is comprised of best-in-class hardware and software such that down-time, maintenance, and repair is minimized. The desired solution should be proven to be engineered and manufactured to operate reliably in the adverse weather conditions experienced in the Daytona Beach, FL, area.

4. Accurately document the required financial and statistical data for the parking operation by producing reports for revenue and other activities as defined herein.

5. Provide complete audit, accountability and traceability of all parking activity and revenues.

6. Provide a post-installation warranty, maintenance, and service support plan.

7. It is the County’s preference to implement a fully cloud-based PARCS solution with full redundancy.

a. A locally hosted PARCS server solution or hybrid solution will be considered, if proposed.

8. Provide an API-based solution that will facilitate PARCS integration with future third party systems.

D. Data ownership

1. All data processed through the PARCS is considered the property of the County.

2. The PARCS must be able to support multiple integrations and interfaces with other PARCS modules, County applications, and third-party sales channels.

E. References in this section to the “Contractor” refers to the PARCS manufacturer.

1.2 PARKING FACILITIES

A. The PARCS will include the following DAB facilities:

1. Short Term Parking Lot

2. Long Term Parking Lot

3. VIP Parking Lot

4. East Employee Parking Lot

5. West Employee Parking Lot

1.3 RELATED DOCUMENTS

A. The number of lanes and equipment per lane are detailed in Exhibit I- PARCS Equipment Matrix.

B. The entry/exit lane locations of the existing parking facilities are detailed in Exhibit A – Scope of Services.

1.4 RELATED REQUIREMENTS

A. The provisions of the Contract Documents apply to the work of this section.

B. The design and operation of the new PARCS shall conform to the following reference codes, regulations, and standards as applicable:

1. National Electrical Code (NEC)

2. American National Standards Institute (ANSI)

3. National Electrical Manufacturers Association (NEMA)

4. Underwriters Laboratories (UL)

5. National Fire Safety Association (CFSA)

6. Federal Communications Commission (FCC)

7. Payment Card Industry Data Security Standard (PCI DSS), latest version

8. Payment Card Industry Software Security Framework (PCI SSF), latest version

9. Applicable Federal, Province, and Local Laws, Regulation, and Codes

10. Americans with Disabilities Act (ADA)

C. Identify and notify the County of any changes to the standards that are instituted between the time of NTP and PARCS implementation and certify that the software meets these requirements.

1.5 ABBREVIATIONS

A. ACMS: Access Credential Management System

B. ADA: Americans with Disabilities Act

C. ANSI: American National Standards Institute

D. API: Application Programming Interface

E. AWG: American Wire Gauge

F. BG: Barrier Gate

G. BI: Business Intelligence

H. DAB: Daytona Beach International Airport

I. EMV: Europay, MasterCard, and Visa

J. ES: Entry Station

K. EX: Exit Station

L. FAT: Factory Acceptance Test

M. FDR: Final Design Review

N. GUI: Graphical User Interface

O. IRW: Image Review Workstation

P. IT: Information Technology

Q. LAN: Local Area Network

R. LAT: Lane Acceptance Test

S. LED: Light Emitting Diode

T. LPN: License Plate Number

U. LPR: License Plate Recognition

V. MOR: Merchant of Record

W. MS: Microsoft

X. NEMA: National Electrical Manufacturers Association

Y. NFC: Near Field Communications

Z. NTP: Notice to Proceed

AA. ODBC: Open Database Connectivity

BB. OS: Operating System

CC. PARCS: Parking Access and Revenue Control System

DD. PCI: Payment Card Industry

EE. PCI DSS: Payment Card Industry Data Security Standard

FF. PCI SSF: Payment Card Industry Software Security Framework

GG. PDR: Preliminary Design Review

HH. QR: Quick Response

II. SAT: System Acceptance Test

JJ. SOC: System and Organization Controls

KK. UL: Underwriters Laboratories, Inc.

LL. VM: Virtual Machine

MM. VoIP: Voice Over Internet Protocol

1.6 FUTURE SYSTEM EXPANSION

A. Support the expansion of additional parking facilities and products for the next ten (10) years.

B. Readily upgradable, scalable, and modular in design to accommodate existing and additional parking equipment, parking facilities, features and functionalities including the following:

1. Additional parking facilities and products

2. Open APIs to interface with third-party applications

3. Additional functionalities

4. Firmware or software upgrades without the need to replace field devices

C. The County may procure a parking reservations system in the future that will require an interface and seamless functionality with the PARCS.

D. The County may procure a parking loyalty system in the future that will require an interface and seamless functionality with the PARCS.

1.7 SYSTEM REQUIREMENTS

A. Provide a complete operational PARCS, as described herein, with all necessary components.

Furnish all task/subsystem controllers, software, and other accessories.

B. Primary components/features shall include:

1. Automated public entry lanes, barcode/QR code tickets

2. Automated public exit lanes, no cashiers

3. Roving ambassadors with handhelds, providing assistance with exception transactions in the automated lanes and accept cash and credit card payments

4. Command center

5. Mobile device ticket scan-to-pay payment

6. Pinhole cameras in devices

7. VoIP intercom

8. EMV/NFC credit card payments

9. Pre-capture LPR as a credential

10. Online and physical validations

11. ACMS, for County employees, tenants, and contract parkers

12. Barcode/QR code

13. Proximity card

14. AVI

15. Cloud, onsite VM hosted, or hybrid server solution

16. Dynamic variable message signage, all public exit lanes

17. Browser-based application software

18. Offline functionality

19. Uninterrupted power supplies

20. Test bed

1.8 ADMINSTRATIVE REQUIREMENTS

A. PARCS Project Kickoff Meeting: a PARCS project kickoff meeting will take place onsite within thirty (30) calendar days of issuance of the Contract’s NTP to review the project scope, project schedule, and the forthcoming PDR meeting requirements.

B. Preliminary Design Review: an onsite PDR meeting within thirty (30) calendar days of attendance of the project kickoff meeting will take place to review the Contractor’s proposed System Design Document.

1. During the PDR meeting, the Contractor will provide a detailed review of the SDD to obtain information needed from the Airport team to complete the system design and configuration documents for the PARCS installation.

2. The PDR meeting is intended to provide the Contractor with all information needed to set up, configure, and install the PARCS in the test bed, lanes, pay stations, and parking office.

3. The SDD shall be compiled and submitted by the Contractor one (1) week prior to the PDR meeting for County review.

4. The SDD will include the following:

a. Product data submittals for all proposed equipment to be installed.

b. Infrastructure improvement design drawings and specifications.

c. Network and single-line diagrams for the PARCS.

d. Description of logic for each use case scenario described in the specification documents.

e. Outline of all third-party technology, APIs, and integrations.

5. Shop Drawings to include the following:

a. All drawings must be submitted in the most recent version of AutoCAD and PDF software.

b. Mounting details for PARCS equipment, per manufacturer recommendations.

c. Drawings will clearly outline all dimensions (feet and inches) between lanes, islands, and equipment.

d. Wiring diagrams detailing requirements for power and communication.

e. Clearly indicate any work that is “not in contract.”

6. A detailed Project Schedule using Microsoft (MS) Project, or other County-approved scheduling application, clearly outlining all tasks, task durations, owner of each task, percent completed, and inter-related dependencies as well as providing the project’s critical path. Each version of the schedule will be submitted in both MS and .PDF formats.

7. A list of each device, by device ID and location, requiring an Internet Protocol address.

8. A list of all PARCS applications, operating systems, and versions to be installed.

9. A narrative of the process to retrieve archived data, format of retrieved data, and any limitations of retrieved data.

10. A PARCS Configuration Workbook:

1) The Configuration Workbook is the official document of the County’s decisions for all PARCS settings and configurations.

2) The Configuration Workbook is a comprehensive document that includes all configuration information that is needed from the County to set up and install the PARCS such as rates, validations, time out periods, ticket / receipt layout and content, screen messaging, hardware configurations by device, software configurations by module, etc.

3) The Contractor will complete the Configuration Workbook prior to the PDR meeting and will be reviewed during the PDR meeting.

4) The Contractor will update the Configuration Workbook as part of the Change Management process throughout the project installation, Warranty, and Post- Warranty periods.

11. Interface and data transfer questions to complete the design for the FDR.

12. Detailed Revenue and Activity Report Samples.

13. Ticket Samples

14. Receipt Samples

15. Training Plan

16. Testing Plan for each phase of testing

17. Maintenance and Repairs tracking system and process.

18. Maintenance and Repairs report samples

19. Submittal Register – a list of all submittals

C. Final Design Review: The County will schedule the FDR meeting remotely within twenty-one

(21) calendar days following the PDR. The purpose of the FDR meeting is to:

1. Review all the SDD revisions made since the PDR meeting.

2. Provide a revised schedule with milestone dates clearly identified, task start and completion dates, lane-by-lane installation dates, training dates, and testing dates.

3. Identify any outstanding information needed for the Contractor to design, set up, and configure the PARCS.

D. Using the information from the FDR meeting, submit revised final SDD within fourteen (14) calendar days after the FDR meeting for the County’s approval.

1.9 ITEMS PROVIDED BY THE COUNTY

A. County shall make available an existing 120V AC power conduit, cabling, and source circuits for PARCS equipment that is installed where existing devices are installed. Contractor shall test and accept any re-used power components.

B. County shall make available existing Ethernet communication connectivity conduit, cabling, and source switches for PARCS equipment that is installed where existing devices are installed.

Cabling will be either CAT 6A or fiber optic based on distance requirements.

1. The existing PARCS communication network is centralized in the toll plaza parking office and is a completely stand-alone network from the County network.

1.10 MAINTENANCE MATERIALS AND CONSUMABLES

A. Stock: Furnish a twenty-four (24) month supply of County-approved operating stock items prior to commencement of the lane testing. Estimated quantities are:

Stock Quantity

Entry parking tickets 250,000

Exit station receipt paper/tickets 250,000

Proximity Cards 200

AVI transponders (bumper-mount) 20

AVI transponders (windshield decal) 200

B. Equipment keys

1. Provide two (2) keys per lane device prior to the lanes being put into production.

2. Keys shall be unique to this project; other equipment supplied by the same manufacturer in other projects will use different keys.

3. If a special tool is required to perform any function on the PARCS during the normal course of business and/or maintenance, provide one (1) of these tools per device.

1.11 ENVIRONMENTAL REQUIREMENTS

A. Environmental conditions shall not inhibit the PARCS from performing in accordance with the contract documents. Provide a system such that environmental conditions in any cabinet or inside any device do not cause failure of the installed electronics.

B. Components located in IT data/communication rooms shall be capable of normal performance in a business environment.

C. Exterior equipment shall be capable of operating in temperature, humidity, and wind conditions of the geographic area.

D. Lightning protection shall be provided on all conductors.

E. The equipment shall be designed to prevent entry of condensing and dripping moisture as well as windblown dust, foreign objects, rain, snow, and ice.

F. All exterior equipment shall be rated for a wet environment.

G. The Contractor will be responsible for advising the County if there are any special environmental factors to which its equipment may be sensitive that are not listed in the contract documents.

H. All devices and component enclosures shall be NEMA type IV weather resistant or equivalent.

Metal enclosures shall be finished in acrylic enamel to match other equipment. The Contractor shall submit color samples and finishes to the County for approval.

I. All lane equipment shall be equipped with heaters and cooling fan units.

J. PARCS components shall operate dependably in the environmental conditions indigenous to Daytona Beach, Florida. In addition, operation of the equipment shall not be affected in any way by the conditions listed below:

1. Ambient temperatures: -30ºF to 130ºF (with addition of solar loading).

2. Humidity: 0% to 99%.

3. Condensation: Condensation on the interior or exterior of equipment or the surrounding structure that may be caused by rapid increases in the dew point temperature.

4. Precipitation: Blowing rain and other nature borne events.

5. Wind: Comply with local building code.

6. Dust: Accumulating and blowing dust and fine sand.

7. Insects and Rodents: Prevent intrusion from insects and rodents.

K. Electrostatic and electromagnetic forces within the environment, e.g., non-direct lightning strikes, or other types of power interference shall have no effect upon the integrity or operation of the

PARCS.

1.12 WARRANTY

A. The Warranty period on the PARCS will only start upon formal notification from the County of substantial completion.

B. Warrant all parts, materials, and workmanship beginning upon substantial completion for a minimum period of twenty-four (24) months. All-inclusive costs (parts, labor, preventative maintenance, emergency service, software support, warranty repairs, Contractor travel time, Contractor expenses, etc.) incurred during the warranty period to be provided with no added cost to the County.

C. Costs (time and material) for repair or parts replacement, components, etc., damaged or rendered unserviceable due to provable misuse, abuse, vandalism or negligence by County or the using public are excluded as a warranty item. Also excluded from the warranty are damages due to Acts of God.

1. Any Contractor costs related to these non-warranty repairs can be invoiced to the County on a time and materials basis using the component costs and hourly labor rates submitted on Exhibit G – PARCS – Cost Proposal Form.

D. Maintain all systems that are operating prior to starting the warranty period. Maintenance services are defined within the manufacturer's recommended maintenance procedures manual submitted with the proposal as accepted by the County.

E. Participate in monthly project review meetings throughout the warranty period, at no cost to the County. Meeting dates and times shall be mutually coordinated between the County and the Contractor to ensure the participation of all necessary stakeholders.

F. Preventative maintenance during the warranty period:

1. Provide all manufacturer-recommended preventative maintenance services for the PARCS hardware and any associated subsystem hardware.

G. Emergency service during the warranty period:

1. Provide emergency repair service in accordance with Table 1.

2. Emergency service includes both on-site service and remote service support.

3. Provide three methods of notification to be used for emergency contact information (ex:

telephone, email, SMS text message).

4. All warranty requirements defined in this document are also requirements for all systems and hardware that are operating prior to starting the warranty period.

5. Factors beyond the control of the Contractor, such as unexpected delays in parts, accidents, severe weather, and unusual traffic, to be thoroughly documented and reported to the County the next business day. The County may grant relief for the service hour requirement after reviewing these factors.

H. Software support during the warranty period:

1. Provide readily available software support in accordance with Table 1.

2. Provide readily available on-site and remote software support for PARCS software and all third-party software applications.

3. Provide all PARCS software version upgrades, software patches, service packs and updates free of charge during the installation, warranty, and post-warranty periods; however, the County reserves the option of implementing the updates or not. Provide documentation/release notes seven (7) calendar days prior to all PARCS software modifications, patches, updates, and upgrades, which describes:

a. Patch/update/upgrade release designation.

b. Proposed date and time of implementation.

c. Detailed description of what the patch/update accomplishes.

d. Disaster recovery procedures as defined herein.

4. All changes should be fully installed, tested, and verified by the Contractor in the test bed prior to being applied to the production system.

5. Provide patches, hotfixes and upgrades required to maintain PCI compliance.

6. Submit to the County a monthly or quarterly software / hardware patch update list.

7. For a non-cloud-based solution, support software upgrades to the PARCS application based on operating system patch and upgrade requirements. For example, if the PARCS runs on a MS operating system, patch the PARCS software according to the MS patch and upgrade schedule without breaking any application.

a. If MS decommissions an operating system, the Contractor must be capable of releasing code compatible with the next operating system upgrade prior to MS ending support for current operating system.

b. The Contractor shall contact the County with a plan at least six (6 months) in advance of operating system patch and upgrade requirements being executed.

c. The County retains the option to purchase and install OS licenses in the PARCS devices.

8. The Contractor shall provide corrective patches and upgrades in the event security vulnerability or system availability issues are discovered.

I. Scheduled Maintenance Windows

1. Coordinate all planned maintenance activities, including software updates, security patches, and hardware service with the County. Scheduled maintenance shall be conducted during designated maintenance windows to minimize operational impact.

a. Scheduled maintenance shall generally occur between 12:00 AM and 4:00 AM local time, or no earlier than thirty (30) minutes after the last scheduled flight arrival of the day, whichever is later.

b. Submit a maintenance request to the County at least three (3) business days in advance of any scheduled maintenance, including:

1) Description of the maintenance activity.

2) Anticipated impact to system availability.

3) Estimated start and end time.

c. No performance penalties shall apply during County-approved maintenance windows.

2. The County reserves the right to approve, modify, or deny proposed maintenance windows based on operational needs.

J. Service level performance requirements

1. Preventative maintenance

a. Create an annual preventative maintenance schedule listing each device and the preventative maintenance type and dates to be completed for the year. Submit seven (7) calendar days prior to installation of the first lane.

b. Each month submit the preventative maintenance performed for the month by updating the annual preventative maintenance schedule with the dates the maintenance was performed on each device.

2. Emergency Repair Service & Software Support

a. Prior to the first lane going into production, provide three (3) methods of notification to be used for emergency contact information. The methods of notification shall provide a means of tracking the date and time the message was delivered.

b. Definitions:

1) Acknowledgement time - Elapsed time beginning when the County gives the Contractor initial notification via phone call or email until Contractor's real-time, human communication with the County regarding the issue and receipt of an email containing a service ticket number.

2) Final resolution time - Elapsed time from acknowledgement until final resolution of the issue including receipt of an email with ticket number closure notification.

c. Emergency service and software support notifications will be placed only by designated County staff. County staff will assign a priority level (1-4) for all emergency service maintenance notifications as defined in Table 1. For each priority level, adhere to the service levels as defined in Table 1.

d. Failure to meet the service level times defined in Table 1 due to the unavailability of parts is not an acceptable reason. For each occurrence where the service request was not achieved at the performance level in Table 1, one percent (1%) of the monthly warranty and post-warranty payment will be deducted per occurrence.

Table 1: Emergency Repair Service Levels

3. Installation and warranty documentation and reporting

a. Provide a service tracking system to monitor and record all scheduled, requested, and performed maintenance/repair services during installation, warranty, and post-warranty periods. The service tracking system shall record the time of notification, acknowledgement, onsite/remote support, and resolution/workaround that shall be used to compute compliance with the service levels in Table 1.

b. All system changes must be tracked through the service tracking system.

c. The Contractor shall fill in all required fields, completely, for all preventative maintenance and repair services scheduled and performed. At a minimum, the service tracking system inputs shall include:

1) Unique work order number

2) Device ID or component to be serviced

3) Identification of the problem/service to be performed

4) Date/time failure reported

5) Reporting party

6) Assigned technician

7) Corrective action code

8) Description of corrective action

9) Identification of all replaced modules, parts, software patches or any upgrades made

10) Date/time corrective action was tested and verified to be operational

d. The service tracking system database shall be kept on a component-by-component basis according to equipment number or component type. A component shall be defined as the major items within the PARCS, e.g., BG, ES, EX, LPR camera, lane controller, validation scanner, etc.

e. The service tracking system shall also record all software and hardware updates.

f. The service tracking system shall be accessible by the County at any time during the installation, warranty and post-warranty periods.

4. Maintenance Service Reporting:

a. All reporting requirements shall be reviewed and finalized at the PDR.

b. The Contractor shall provide, by email, the following electronic reports:

1) A weekly out-of-service report, indicating how long any lane or component was out of order for the preceding week.

2) A monthly repair service report summarizing the number of repairs made by problem and the number of repairs made by lane ID for the preceding month.

3) A monthly PM report of all preventative maintenance performed by lane, along with an updated spreadsheet showing each lane and the dates preventative maintenance was performed for the preceding month.

K. The Contractor shall reimburse the County for any quantifiable lost revenue directly related to Contractor errors and/or the Contractor’s actions, for example, the Contractor incorrectly updating a proposed rate change.

L. The County shall notify the Contractor in writing of performance problems with respect to the service standards within twenty (20) calendar days after the end of each month based on the performance reports from the service tracking system.

M. The Contractor shall be given thirty (30) calendar days from receipt of notification to take corrective actions with respect to the problem identified by the County or request relief.

1.13 POST-WARRANTY SOFTWARE SUPPORT SERVICES

A. Post-warranty software support services shall conform to the software support warranty service requirements described above for the warranty period.

1.14 POST-WARRANTY HARDWARE SUPPORT SERVICES

A. Factory train and certify County staff to perform Level 1 and 2 hardware service, including manufacturer-recommended preventative maintenance.

B. Perform semi-annual site inspections and equipment preventative maintenance overhauls for the PARCS hardware and any associated subsystem hardware.

C. Provide on-call 24/7 hardware support for hardware service for issues beyond the expertise of County staff.

1.15 SPARE PARTS

A. Propose a list of spare parts (type and quantity) recommended to be maintained on site. Identify and include the list of all spare parts required to maintain the system.

B. Submit a price list for the proposed spare parts inventory detailing the cost of each part on the spare parts inventory.

C. Provide guaranteed component pricing for three years following final system acceptance. Prices will be valid for the County to purchase the spare parts.

D. The County reserves the right to order additional parts and manage the PARCS spare parts inventory as required to support the system.

E. The proposed spare parts list is subject to the approval of the County, and the County reserves the right to modify the spare parts inventory throughout the term of the contract.

F. The County will provide a storage location for the spare parts, exact location to be identified by the County after contract award. The Contractor shall have access to the spare parts inventory while performing on-site service calls and shall be responsible for ordering replacement components or parts as components or parts are used throughout the installation, warranty and post-warranty service periods.

1. The Contractor shall be responsible for ordering replacement spare parts within 72 hours of use.

G. Provide newly manufactured equipment and parts that have never been installed in any other operational system other than for factory test purposes. Refurbished parts are not acceptable as spares.

H. Provide an itemized list of manufacturer's part numbers, model numbers, pricing, supplier's address, supplier's telephone numbers, and any single source components when parts are delivered to the site.

I. Provide the County with the ability to order subcomponent parts that facilitate the repair of an assembly without having to order an entire replacement assembly. Example: if a spring or belt fails resulting in a disabled ticket transport assembly, the County shall be able to order only the failed spring or belt to repair the assembly as opposed to having to order an entire new assembly.

PART 2 - PRODUCTS

2.1 PARCS approved manufacturers::

A. DESIGNA Verkehrsleittechnik GmbH

B. IP Parking International Ltd.

C. SKIDATA GmbH

D. Contractors may submit proposals for equivalent equipment for approval at the sole discretion of the County no later than fourteen (14) days prior to the closing of this solicitation. Final proposals that include non-County-approved equivalent equipment will not be accepted and may result in the respondent being deemed non-responsive.

PARCS equipment must be able to be purchased and maintained by any Contractor.

2.2 SOFTWARE

A. Provide all software and software licensing required by the system.

B. Provide any necessary perpetual licenses and/or authorization for all software used by the County.

C. All software, associated licenses, and user credentials provided under this contract shall be issued to and registered to the County.

D. Provide a site license to the County, meaning usage of the license is unrestricted, regardless of the physical locations where the software may be used as part of this contract.

1. No limitations on the number of simultaneously logged in users.

E. Database Management System

1. Provide application software consisting of software to provide complete operation of the PARCS and include the database management system.

2. Maintain data recorded by the PARCS in files that are in ODBC compatible formats.

F. Operating System Platform

1. Provide operating system software consisting of software to support system setup, system operation, routine system backups, diagnostics, and other maintenance routines.

2. For a local/onsite server, the operating system shall be Windows Server 2022 or the latest available version.

3. For a non-URL based solution, the workstation operating system shall be Windows 11 or the latest available version.

G. PARCS application software

1. Provide complete operation of the PARCS including the database management system.

2. PA-DSS validated for new deployments according to PCI. Maintain a valid PCI report of compliance and submit annually to the County throughout the installation, warranty, and post-warranty maintenance periods.

3. The PARCS solution shall utilize a P2PE architecture that is listed on the PCI-approved website and operates in line with PCI SSF requirements. The PARCS solution shall not retain any sensitive cardholder data.

4. The PARCS will not store or transmit unencrypted credit card data.

5. Provide the relevant SOC II report for IT security standards to submit annually.

6. Upgradeable to maintain PCI standards throughout the life of the system.

7. Browser-based such that the PARCS application software is accessible from any workstation or mobile device web browser.

8. Operates on an independent, Contractor-provided LAN accessible with the County-approved user ID and password protocols, on all workstations authorized to access the PARCS software modules.

9. Allow multiple groups and roles that govern individual access to the system. The assignment of a group/role will control access to the various modules of the PARCS, and if the access allows the user to edit configurations or is read-only.

10. Access rights to the system for the various groups and roles will be defined prior to the

FDR.

11. PARCS application software to provide the following:

a. Manage, display, and report all PARCS-related activity.

b. Automatic detection and reporting of fault conditions and equipment failures.

Categorize fault condition by severity and display alarm notification on the system Graphical User Interface (GUI) as well as generate messages back to the County’s management system for any individual fault condition, category of fault, or County-selected group of faults.

c. Support network performance monitoring tools for monitoring all PARCS devices.

d. Reporting as outlined in the Reporting section.

e. Command center functionality as defined herein with the ability to view the status of all equipment in a single screen.

f. Audit trail for the use of central controls within the PARCS database by user ID, time, device-controlled, and action taken.

g. Configurable parking rates (including special rates for events), grace periods, and time increment changes from system workstations. Configuration access to be restricted to County-designated users with proper authorization.

h. Audit trail for all parking rate, grace period, and time increment changes.

i. Remote communication with all devices in real-time for a general broadcast of information (e.g., rate changes or time increment changes) or software update and an ability to communicate to a single device to upload information or software. It shall be possible to remotely upload updates and remotely reboot the field device.

j. Correct calculation and processing of parking fees during a transition:

1) From daylight savings time to standard time, and vice versa.

2) At the beginning of March during leap years (e.g., when there is a February 29th).

3) From one rate to another (e.g., rate has an effective date so that customers are charged a parking fee based upon the parking fee that was current at the entry date and time, not the exit date and time, allow the new rate to be either less than or greater than the new rate).

12. Programmable rate structure to establish variable rates based upon the time of day, day of week, season of year, and special events.

a. Programmable rate structure to establish hourly fee progression, daily/weekly/monthly maximum fees, special event rates, grace times, and complimentary periods.

b. Programmable rate structure to allow configuration of the tax rate applied to parking fees.

c. Ability to reconcile credit card revenue collected through the PARCS to the clearinghouse bank deposits.

d. Ability to audit remote transaction processing activity by user to confirm manual inputs that impact the fee charged to the customer. This includes a detailed transaction report of remote transactions.

e. Create system generated alarms – generation of alarms for user selectable event type.

Alarm hierarchy shall be completely configurable so the County can adjust priority of alarms, audible tones, where the alarms are sent, etc. Initial alarm hierarchy shall be coordinated with the County during implementation.

f. Ability to export all query results and reports to multiple formats including .PDF, .CSV, .XLS, etc.

H. Reports

1. Available online and on demand for County personnel who have proper password access.

2. Viewable, printable, and exportable from the GUI.

3. Data compiled in an ODBC compliant database with the ability to prepare custom reports using the PARCS data including MS Excel, at a minimum, via a .CSV file format.

4. Coordinate with the County as required during the system design to address the specific reporting needs of the County. At a minimum, reports provided shall include:

a. Detailed revenue and non-revenue transactions reports – Reports of transactions processed through the PARCS by user selectable parameters including user type, date/time range, and by device.

b. Detailed and summary revenue reports for daily, weekly, and monthly PARCS activity.

c. Credit card reports – Reports of credit card transactions by user selectable parameters including date/time range, credit card terminal ID, credit card type, transactions type (transaction amount, approved transactions, declined transactions, offline-approved transactions, last-four digits of credit card, zip code associated with each credit card, etc.)

d. Validation reports – Detailed and summary reports of validations issued, validation amount, validation time, and validation issuer (user ID), by user selectable parameters.

e. System event reports – Reports for system generated events by user selectable parameters including PARCS device and date/time range.

f. Manual gate vend report – Report showing each manual gate vend, the lane ID, date/time, user ID, and sum total for a date/time range by lane ID and user ID.

g. Occupancy, duration of stay, and turnover reports.

h. Access credential reports – Detailed and summary reports of credential activity for individual credentials or by account number that include the credential type (team member, contractor/vendor, hotel guest, etc.), credential number, account number, entry/exit date/time, and lane ID.

5. Prepare up to five (5) custom reports as defined by County. County and Contractor to coordinate report design and finalize custom reports prior to the expiration of the warranty period. Custom report requests shall be limited to data contained within the PARCS database and third-party solutions provided by the Contractor as part of the PARCS.

I. Financial Accounting System Scheduled Data Exports

1. The PARCS solution shall provide the ability to export all revenue and financial transaction data in formats compatible with standard financial accounting system. At a minimum, the system shall:

a. Export financial and transaction reports in structured file formats such as .CSV, .XLSX, JSON, and XML.

b. Allow scheduled or on-demand exports to designated County directories or secure FTP locations.

c. Include necessary fields to support automated reconciliation with the County’s financial accounting system, such as:

1) Unique transaction ID

2) Date/time

3) Payment type

4) Amounts (gross, net, tax, validation/discount)

5) Terminal or lane ID

6) User ID

7) Detailed and summary revenue reports for daily, weekly, and monthly

PARCS activity

2. Provide audit trails to track and verify exported data batches.

3. The Contractor shall coordinate with the County’s Accounting and IT departments to format reports or exports as needed for direct import into the County’s financial system.

2.3 ELECTRICAL

A. All new 120V electrical infrastructure required to support the PARCS shall be designed, permitted, and installed by Contractor to all PARCS devices where existing electrical service either does not exist or is insufficient to support the new PARCS.

B. All electrical work shall be designed and installed in accordance with County standards.

C. Terminate and test all electrical cables to the end field devices.

D. Provide PARCS components that are powered via hardwired connections. Solar power or batteries are not acceptable as primary power sources.

2.4 COMMUNICATION

A. The PARCS shall reside on an independent, Contractor-provided communications network completely separate from the County’s network.

B. All new Transmission Control Protocol/Internet Protocol (TCP/IP) communication infrastructure required to support the PARCS shall be designed, permitted, and installed by Contractor to all PARCS devices where is existing communication infrastructure either does not exist or is insufficient to support the new PARCS.

C. Provide a new hardwired, high-speed Internet Service Protection (ISP) connection to the toll plaza parking office.

D. Provide wireless (cellular) or satellite back-up communication functionality to support the PARCS network in the event that the primary ISP connection fails.

E. Terminate and test all communication cables to the end field devices.

F. Configure all field component communications such that no single point of failure of a device causes an operational failure of surrounding devices.

G. Provide PARCS components that utilize hardwired communication.

H. Network:

1. To improve reliability and manageability, the PARCS shall network all equipment via low voltage copper and fiber optic cabling per County standards.

2. All nodes on the network, including workstations, servers, and field concentrators, shall use Ethernet as the Open Systems Intercommunication (OSI) layer 2 transport and unicast TCP/IP as the layer 3 protocol.

3. All networkable devices shall be IP addressable and accessible for management.

I. Direct connection:

1. All PARCS equipment shall communicate directly with the PARCS server (on-premise or cloud-hosted).

2. Any on-premise servers will be located in the toll plaza parking office or other location to be determined by County unless a cloud solution is utilized.

2.5 EQUIPMENT AND SUBSYSTEMS

A. All equipment performing a like function and of the same part number to be fully interchangeable without the requirement for physical modifications.

B. Provide device autonomy such that no single point of failure of a device causes an operational failure of surrounding devices.

C. Application and data servers

1. The Contractor will provide all relevant servers and configuration, whether physical, virtual, or cloud-based.

2. Provide centralized management of the PARCS.

PARCS servers shall contain all PARCS application and database software that is associated with PARCS operation, data storage, and reports.

D. Cloud-based database requirements (if applicable). If the proposed PARCS utilizes a cloud-based database for any component of system operation, transaction processing, credential management, validation, reporting, integrations, or data storage (including “cloud-first,” “cloud-hosted,” or “hybrid” architectures), meet all requirements in this section:

1. Data ownership, access, and portability

a. The County shall retain full ownership of all data generated by or stored within the system, including but not limited to transactions, audit logs, device events, credential records, rate tables, validations, and user/account records.

b. The County shall have the right to export all data at any time, without Contractor intervention, in non-proprietary formats (e.g., CSV, JSON, XML) and/or via documented APIs.

c. Upon contract termination or non-renewal, the Contractor shall provide a complete export of all County data and metadata within ten (10) business days, and shall certify deletion of County data from the Contractor’s systems within five (5) business days thereafter, except as required by law.

2. Security and encryption

a. All data shall be encrypted in transit using TLS 1.2 or higher (TLS 1.3 preferred) and at rest using industry-standard encryption (e.g., AES-256 or equivalent).

b. Encryption keys shall be managed using a secure key management process. If Contractor-managed, the Contractor shall describe key management controls, rotation policies, and access restrictions.

c. The system shall support role-based access control (RBAC) and enforce least-privilege access for all users and administrators.

3. Compliance and security attestation

a. The Contractor shall provide current third-party security documentation applicable to the cloud service, such as SOC 2 Type II (preferred) or equivalent independent audit reports.

b. The Contractor shall disclose any material security incidents impacting the proposed service within the last 36 months, including scope, remediation, and preventive controls implemented.

c. The Contractor shall maintain a documented vulnerability management program and apply critical security patches within published timelines.

4. Availability, reliability, and disaster recovery

a. The cloud database/service shall be designed for high availability and provide an uptime service level of ≥ 99.9% (excluding scheduled maintenance announced in advance).

b. The Contractor shall provide a documented Disaster Recovery (DR) and Business Continuity plan.

c. Backups shall be performed at least daily and retained in accordance with the County’s data retention policy.

5. Data residency and hosting transparency

a. The Contractor shall identify the cloud hosting environment/provider and the primary and secondary (DR) data center regions where County data is stored and processed.

b. The Contractor shall specify whether County data may be stored or accessed outside the United States (or other required jurisdiction) and shall comply with County data residency requirements.

6. Performance and offline/degraded mode operations

a. The PARCS shall continue to support core field operations during internet outages or cloud service interruptions via a documented offline/degraded mode, including at minimum: lane operation, credential recognition/validation, and transaction queuing for later synchronization.

b. The Contractor shall describe how data conflicts are resolved upon reconnection and how time synchronization, audit integrity, and transaction sequencing are maintained.

7. Integration and API requirements

a. The Contractor shall provide documented, supported APIs for accessing transactional and operational data and for integrations with third-party systems (e.g., accounting, enforcement, permits, validations).

b. APIs shall support secure authentication (e.g., OAuth 2.0 or equivalent), logging, and rate limiting.

8. Auditability and logging

a. The system shall maintain immutable audit logs for all financial transactions, rate/parameter changes, user administration actions, and device events.

b. Logs shall be exportable and retained in accordance with County requirements.

9. Subcontractors and third-party dependencies

a. The Contractor shall disclose any subcontractors or third parties that store, process, or access County data, and shall remain fully responsible for their performance and compliance.

b. No material change to hosting provider or data-processing subcontractors shall occur without prior written notice to the County.

10. Support, maintenance, and change management

a. The Contractor shall provide a change management process for cloud updates, including advance notice for releases that impact functionality, integrations, reporting, or user workflows.

11. Approved hosting providers: If the PARCS utilizes a cloud-based database, the Contractor shall host all system data in Microsoft Azure or Amazon Web Services (AWS), unless the Contractor requests and receives written approval from the County for an equivalent commercial cloud environment. The Contractor shall disclose the hosting provider and the primary hosting region(s).

12. No commingling; restricted access: All County data (“DAB data”) stored in the cloud database shall be stored in a secure, logically dedicated (separate tenant/account with isolation controls) environment that stores only DAB data, with controls preventing commingling with any other customers’ data. Access to the environment shall be restricted to authorized personnel and governed by role-based access controls and audit logging.

13. Data use restrictions; County-controlled access: DAB data shall not be sold, licensed, monetized, shared, disclosed, mined, aggregated, or combined with any other customers’ data for any purpose, including analytics, benchmarking, product improvement, or marketing, except as expressly authorized in writing by the County or as required by law.

Access to DAB data shall be secure and controlled by the County, including County-defined user roles/permissions, least-privilege access, and the ability for the County to grant, modify, and revoke access at any time. The Contractor shall not provide third parties access to DAB data without the County’s prior written approval.

E. Command center functionality

This section defines equipment monitoring, system alarms, equipment management functionality, customer intercom call response, event log (which records all system events), and remote transaction processing.

1. General Requirements

a. The PARCS shall provide an online, real-time monitoring and control platform that performs the following five (5) primary functions at a minimum:

1) Equipment monitoring - provides the status for each device and PARCS component.

2) System alarms - notifies via selected alarms of device equipment status either online or offline and problem reporting.

3) Equipment management functionality - used to operate devices remotely from a workstation.

4) Customer intercom call response – Two-way communication with a customer in the lane to assist in remote transaction processing and remote problem resolution.

5) Event log - records all PARCS activity and assigns each event a unique code, allowing event occurrences and frequencies can be queried.

6) Remote transaction processing as defined in the Remote transaction processing requirements section herein.

2. Equipment monitoring requirements

a. The command center shall be a network of computers and servers that provide on-line monitoring and control of all PARCS equipment and parking events.

b. The command center shall also use singular and/or multiple software packages (e.g., PARCS application, intercom application, pinhole camera application, credit card gateway application, or one overlay software application that combines all subsystems under one dashboard.)

c. All workstations shall have command center software and shall have a GUI for ease of use.

1) The command center shall provide a view of all parking facilities on one screen to view alarm notification, allowing high-level monitoring of the entire parking system.

2) The command center shall provide the ability to drill down from the global view to the device with alarm details.

d. At a minimum, the command center shall monitor the operational status of each of the following entry lane and display:

1) Lane status: open or closed

2) Device status: online and offline

3) Mirrored image of what is currently being displayed on the device screen

4) Ticket jams

5) Gate failure

6) Gate stuck up

7) Low ticket supply

8) Ticket out of stock

9) Illegal exit - reverse direction through lane

10) Backout

e. At a minimum, the command center shall monitor operational status of each exit lane and display:

1) Lane status: open or closed

2) Device status: online/offline

3) Mirrored image of what is currently being displayed on the device screen

4) Receipt jams

5) Gate failure

6) Gate stuck up

7) Illegal entrance - reverse direction through lane

8) Backout (stolen ticket)

9) Backout (ticket left in…