RFP0000014_PARCS_Attachment_B_-_Compliance_Matrix.xlsx
XLSX spreadsheet 72 KB Posted
- Attached to
- Parking Access and Revenue Control System at MIA
- Solicitation number
- RFP0000014
- Issued by
- Florida
About this file
This is a Compliance Matrix attachment for a Parking Access and Revenue Control System (PARCS) solicitation issued by Miami-Dade County for Miami International Airport (MIA). The document serves as a mandatory evaluation tool requiring proposers to assess their solutions against 241 detailed requirements across multiple functional domains, including system architecture, entry and exit lane operations, payment processing, integrations with existing systems, customer channels, cybersecurity, hardware specifications, and reporting capabilities. The matrix is organized into 14 exhibit sections covering technical requirements ranging from core platform functionality and hybrid cloud/edge computing architecture to specific integrations with Florida Department of Transportation (FDOT) SunPass, Propel reservations platform, GateKeeper ground transportation system, and multiple MDAD systems including Microsoft Azure, Power BI, and Fiserv payment gateway. Of the 241 total requirements, 231 are designated as mandatory and 9 as desirable, with proposers required to indicate compliance status using codes C (Compliant), PC (Partially Compliant), NC (Non-Compliant), or N/A (Not Applicable), along with narrative explanations for any non-compliant or partial responses.
The matrix specifies extensive technical and operational performance targets for the PARCS solution, including 99.9% system availability over rolling twelve-month periods, 24-hour lane autonomy during wide-area network outages, recovery time objective of 15 minutes or less, and zero recovery point objective for paid-transaction ledger. Key performance requirements include entry-lane processing within 2.0 to 2.5 seconds median and 3.0 to 4.0 seconds at the 95th percentile, License Plate Recognition accuracy of 98% daytime and 95% nighttime, and 99% entry-to-exit pairing accuracy. The solution must support multiple entry and exit methods including paper tickets, credit-card-in/credit-card-out (CCI/CCO), SunPass, RFID credentials, app-driven ticketless, and cash payment at no fewer than one location per facility. All submissions must be provided as native, unsecured Excel files alongside proposal responses and are evaluated under technical criteria, with no modifications permitted to requirement IDs, section references, requirement statements, or row structure.
View the file
Other files
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
Instructions
| Attachment B - Compliance Matrix |
| Instructions |
| PURPOSE |
| This Compliance Matrix shall be completed by the Proposer for every requirement. It is a mandatory component of the proposal and shall be submitted as a native Excel file (.xlsx) alongside the proposal response (PDF). |
| RESPONSE CODES |
| Enter one of the following codes in the Proposer Response column (Column E) for every requirement row: |
| C — Compliant: The proposed solution meets the requirement as stated, without exception. |
| PC — Partially Compliant: The solution meets the requirement in part. Describe the gap or exception in Column F. |
| NC — Non-Compliant: The solution does not meet the requirement. An explanation is required in Column F. |
| N/A — Not Applicable: The requirement does not apply to the proposed configuration. Justification is required in Column F. Valid for both Mandatory and Desirable requirements. |
| COLUMN GUIDE |
| A — Req ID: Do not modify. |
| B — Section Reference: Do not modify. |
| C — Requirement Statement: Do not modify. |
| D — Requirement Type: M = Mandatory; D = Desirable. Do not modify. |
| E — Proposer Response: Enter C, PC, NC, or N/A. Every row must have a response. |
| F — Proposer Narrative / Exception: Required for PC, NC, and N/A. Optional for C (use to highlight value-adds or explain approach). |
| PROHIBITED ACTIONS |
| Do not delete rows. Do not insert rows. Do not alter Req IDs, Section References, or Requirement Statements. Do not lock or password-protect the workbook. Do not hide or delete sheets. |
| SUBMISSION |
| Submit this completed workbook as a native, unsecured .xlsx file together with the proposal response (PDF) and all Attachments. |
| EVALUATION NOTE |
| Compliance Matrix responses are evaluated under the Technical Criteria. |
Compliance Matrix
| Attachment B - Compliance Matrix | |||||
| Vendor Name: | Insert Vendor Name | ||||
| Req ID | Section Reference | Requirement Statement | Type | Proposer Response | |
| (C / PC / NC / N/A) | Proposer Narrative / Exception |
(Required for PC, NC, N/A)
| Exhibit A — §2.1 Technical Overview | |||
| Ex. A §2.1 | PARCS System Description (sub-sec 2.1.1) | ||
| 1 | The PARCS shall provide a state-of-the-art, recognition-capable, ticketless-capable, fully gated parking access and revenue control solution serving Miami International Airport (MIA). The system shall consolidate vehicle entry and exit processing, payment workflows, exception handling, reservations, validations, employee and VIP credentialed parking, and revenue assurance into a unified, MDAD-owned, Contractor-operated platform with auditable open data interfaces. | M | |
| 2 | The PARCS shall utilize a hybrid cloud and edge computing architecture. Lane equipment shall remain operational with autonomous decision-making capabilities for a minimum of twenty-four (24) hours during any wide-area network (WAN) outage, with deferred synchronization and reconciliation upon restoration of connectivity. The core platform shall achieve measured system availability of at least 99.9% over any rolling twelve-month period, with a recovery time objective (RTO) of fifteen (15) minutes or less and a recovery point objective (RPO) of zero (0) for the paid-transaction ledger. The Contractor shall meet these availability commitments without reliance on planned downtime windows for routine maintenance. | M | |
| 3 | The PARCS shall support multiple entry and exit methods, including traditional paper-ticket processing, credit-card-in / credit-card-out (CCI/CCO), SunPass, RFID employee/VIP credentials, and advance-reservation digital credentials, so that MDAD may determine the appropriate mix of methods for its customer base. App-driven ticketless entry/exit and LPR-driven ticketless entry/exit shall be available as optional, MDAD-activatable capabilities that MDAD may enable, expand, or restrict over the term as customer demographics, technology adoption, and operational needs evolve. License Plate Recognition (LPR) shall not serve as the primary authorization method for entry or exit; where used, LPR shall support and enhance vehicle identification, transaction matching, exception resolution, and revenue assurance. | M | |
| 4 | App-driven ticketless: (optional feature) Under the app-driven ticketless workflow, the customer shall pre-enroll their vehicle and payment method through the designated mobile or web-based application. At entry and exit, the vehicle's license plate shall be matched to the enrolled account and associated parking session, with LPR providing supplemental identification to ensure frictionless access. Gate operation shall be authorized upon successful validation of the customer account, parking session, and payment status. This workflow is an optional, MDAD-activatable feature; MDAD may enable, expand, disable, or restrict its availability at its discretion, and it is not a required or primary entry method. | M | |
| 5 | Credit-Card-In / Credit-Card-Out (CCI/CCO) ticketless: Under the CCI/CCO workflow, the customer shall present a contact or contactless EMV-enabled bankcard or supported digital wallet at entry. The same credential shall be presented at exit, allowing the PARCS to calculate and process the applicable parking fee. | M | |
| 6 | SunPass: For SunPass credentialed customers, the SunPass transponder shall be read at entry and exit. The PARCS shall validate the credential and facilitate parking fee settlement through the SunPass interface in accordance with applicable Florida Department of Transportation specifications. | M | |
| 7 | Radio-Frequency Identification (RFID) employee / VIP credential: For employee and VIP parking, the PARCS shall support Radio-Frequency Identification (RFID) credentials. These credentials shall be read at entry and exit, and the PARCS shall integrate with MDAD's ground transportation management system, currently GateKeeper, for credential validation, transaction processing, and billing. | M | |
| 8 | Advance reservation digital credential: For customers holding advance reservations, the PARCS shall validate reservation-based digital credentials such as QR codes, application-based credentials, or other authorized digital tokens at entry and exit. Reservation data shall be obtained through integration with MDAD's reservation platform, currently Propel. | M | |
| 9 | Fallback workflows for non-registered or unavailable preferred methods: The PARCS shall support multiple fallback workflows to ensure continuous operation and complete customer coverage whenever preferred ticketless methods are unavailable or the customer has not pre-enrolled. The system shall create temporary parking sessions for non-registered customers using LPR data, allowing payment at exit through pay-on-foot stations, exit payment terminals, or supported electronic payment workflows. The PARCS shall support mobile web-based payment without app enrollment by providing a QR code or similar digital mechanism, enabling customers to retrieve their parking session, review charges, and complete payment on a mobile browser. | M | |
| 10 | Cash payment at exit: (required) The PARCS shall accept cash as a required payment option, consistent with Miami-Dade County Commission policy, at no fewer than one exit booth, cash-enabled exit terminal, or attended cashier station per facility, allowing customers to complete their transaction using cash. Cash acceptance shall be fully integrated into the PARCS revenue-control, audit, reconciliation, and reporting workflows to provide complete transaction accountability and revenue assurance. | M | |
| 11 | Paper ticket: Paper ticket exception workflow: A paper ticket issuance workflow shall be supported strictly as a last-resort exception measure and shall be used only when all applicable preceding entry methods and fallback mechanisms identified in this Section have been attempted and are unavailable, have failed, or cannot establish a valid parking session. This includes, as applicable, the app-driven ticketless workflow, CCI/CCO, SunPass, RFID employee/VIP credentials, advance-reservation digital credentials, and temporary LPR-based session creation for non-registered customers. Standard ticket-based processing, including entry time capture and fee calculation, shall be supported solely as this final fallback and shall not be used as a routine or preferred entry method.A paper ticket issuance and processing workflow shall be supported as a standard entry method at all in-scope facilities, available to any customer alongside the credential-based and optional ticketless methods described in this Section. Paper-ticket processing shall support entry time capture and fee calculation at exit, and shall be fully integrated into the PARCS revenue-control, audit, and reconciliation workflows on the same basis as other entry methods. | M | |
| 12 | The Contractor's solution shall ensure seamless operational integration between all entry and exit methods described in this Section, whether standard, credential-based, or optional ticketless. Customers shall be able to complete parking transactions through any supported method without disruption, degradation of service quality, or increased operational burden on MDAD. | M | |
| 13 | The PARCS shall maintain barrier gates at every paid public entry and exit lane unless MDAD expressly approves, in writing, an alternate lane configuration for a specific lane. Gate decisions, entry and exit decisions, and payment authorizations shall be auditable end-to-end. Throughput targets shall meet the performance requirement set forth in Sections 2.4 and 2.5. | M | |
| Ex. A §2.1 | Design Approach (sub-section 2.1.3) | ||
| 14 | The PARCS shall use a configuration-driven design wherever feasible, so that common business rules (rate tables, validation rules, exception logic, threshold values, alert routing) can be modified by trained MDAD users through supervisor consoles without requiring vendor code changes. The Contractor shall document configurable parameters and provide a self-service configuration capability with approval workflow, version history, and rollback. Custom code shall be reserved for genuine business requirements that cannot be expressed in configuration and shall be documented as such. | M | |
| Ex. A §2.1 | Integration Requirements (sub-section 2.1.4) | ||
| 15 | The PARCS shall integrate, at a minimum, with the systems listed in the following table. Each integration shall use a documented application programming interface (API) or standards-based protocol, shall be versioned, shall handle errors and retries gracefully, and shall be exercised in non-production environments prior to go-live. | M | |
| 16 | SunPass (FDOT) | M | |
| 17 | Park Assist | M | |
| 18 | Propel (Reservations) | M | |
| 19 | GateKeeper (GTMS) | M | |
| 20 | MDAD Payment Gateway (Fiserv or successor) | M | |
| 21 | MDAD Identity Provider (Microsoft Entra ID or successor) | M | |
| 22 | MDAD Data Lake (Microsoft Azure Data Lake Storage (ADLS)) | M | |
| 23 | MDAD BI Platform (Microsoft Power BI and MDAD’s Integrated Financial Resource Management System (INFORMS)) | M | |
| 24 | Salesforce | M | |
| 25 | Florida Department of Law Enforcement (FDLE) | M | |
| 26 | MDAD Security Information and Event Management (SIEM) -Trellix Helix, Microsoft Sentinel, or successor SIEM | M | |
| 27 | MDAD ITSM (Ivanti or successor designated by MDAD) | M | |
| Exhibit A — §2.3 Core PARCS Platform and Central Data Management | |||
| Ex. A §2.3 | General (sub-section 2.3.1) | ||
| 28 | The core PARCS platform shall provide a deterministic transaction-handling engine, a configuration-driven rate engine, an exception workflow engine, an enterprise administration suite, an event store with immutable transaction identifiers, and documented APIs. The platform shall support segregated production, test, training, and disaster recovery environments. There shall be no direct production writes from test or training environments. | M | |
| Ex. A §2.3 | Functional Requirements (sub-section 2.3.2) | ||
| 29 | Hybrid cloud/edge architecture with lane autonomy of at least twenty-four (24) hours during WAN loss, including cached enrolled-account state, active session state, and current rate tables sufficient to maintain system flows during the autonomy window. The customer-facing mobile app and web experience shall implement graceful degradation during partial or complete backend outages: (a) the app shall display a clear, customer-friendly status message when real-time session data or entry confirmation cannot be retrieved, rather than displaying an error or blank screen; (b) any entry or payment action initiated during degraded connectivity shall be queued and retried automatically upon connectivity restoration, with the customer notified of the outcome via push notification or email within fifteen (15) minutes of resolution; (c) the app shall not permit a customer to be charged multiple times for the same session as a result of retry logic | M | |
| 30 | Resilient production hosting with RTO ≤ 15 minutes and RPO = 0 for the paid-transaction ledger (sub-sec.2.3.2.2) | M | |
| 31 | Immutable transaction identifiers for 100% of entry, exit, payment, refund, override, and gate events (sub-sec.2.3.2.3) | M | |
| 32 | Synchronized time across all components with clock drift ≤ ±1 second (sub-sec.2.3.2.4) | M | |
| 33 | Centralized configuration with version history and attribution for every change (sub-sec.2.3.2.5) | M | |
| 34 | Multiple parking products in one rule engine — transient, reservation, employee, VIP, valet, contract, fleet, and validation. The valet product type shall support valet ticket issuance at attended stations, a real-time valet manifest accessible to authorized MDAD supervisors, cashiering at exit with fee calculation against the valet rate structure, and revenue attribution separate from transient self-park revenue in all standard reports (sub-sec.2.3.2.6) | M | |
| 35 | Bulk import/export of master data (vehicles, accounts, permits, rates, watchlists) via comma-separated values (CSV) and API (sub-sec.2.3.2.7) | M | |
| 36 | Enterprise single sign on (SSO) via SAML 2.0 and/or OIDC, with delegated administration scoped by facility and function (sub-sec.2.3.2.8) | M | |
| 37 | Quarterly access reviews and just-in-time elevation for sensitive functions (sub-sec.2.3.2.9) | M | |
| Ex. A §2.3 | Database Requirements (sub-section 2.3.3) | ||
| 38 | The platform shall use a supported, industry-standard relational and/or distributed data store with documented backup, restore, and archival processes. Backups shall be encrypted at rest with advanced encryption standard (AES)-256 (or equivalent) and shall meet the Department's retention requirements. Transaction and financial records — including entry, exit, payment, refund, override, and gate events — shall be retained in a readily queryable state for a minimum of seven (7) years from the date of the transaction, or such longer period as MDAD specifies in writing, consistent with Florida public records law and the Department's financial audit obligations. Records required for open disputes, chargebacks, or legal holds shall be retained until the matter is resolved regardless of the standard retention period. At contract expiration or termination, the Contractor shall deliver a complete export of all Department transaction and configuration data in a documented, non-proprietary format within sixty (60) days. Schema documentation shall be maintained and provided to the Department on request. | M | |
| Ex. A §2.3 | System Performance (sub-section 2.3.4) | ||
| 39 | The core platform shall support the peak transaction volumes of MIA's parking facilities, with headroom of at least 50% above current peak. The Contractor shall demonstrate performance during SAT and during pre-go-live load testing using realistic production volumes. | M | |
| Ex. A §2.3 | Data Redundancy, Backup, and Disaster Recovery (sub-section 2.3.5) | ||
| 40 | The Contractor shall maintain redundant production hosting, automated backup, and a documented disaster recovery (DR) plan. The DR plan shall be exercised at least annually with MDAD participation. Backup integrity shall be verified by periodic restore tests. | M | |
| Exhibit A — §2.4 Entry Lane Equipment and Processing | |||
| Ex. A §2.4 | General (sub-section 2.4.1) | ||
| 41 | Entry lanes at all in-scope MIA facilities shall be gated, monitored, and capable of processing the entry methods listed in Section 2.1.1. Each entry lane shall include, at a minimum: | M | |
| 42 | - Industrial lane controller in NEMA 4 (or 4X where exposed) enclosure (sub-sec.2.4.1.1) | M | |
| 43 | - Barrier gate operator and arm (UL 325 compliant, with monitored entrapment protection) (sub-sec.2.4.1.2) | M | |
| 44 | - Vehicle loop detection and presence sensors (with backup detection technology where appropriate) (sub-sec.2.4.1.3) | M | |
| 45 | - LPR camera covering the plate-read zone, with a context camera covering the vehicle and driver area (sub-sec.2.4.1.4) | M | |
| 46 | - AVI antenna and reader compatible with the TransCore Encompass 5 (E5) baseline and with the SunPass transponder population (or successor technology approved by MDAD) (sub-sec.2.4.1.5) | M | |
| 47 | - EMV contact and contactless terminal supporting chip, tap, and mobile wallet (Apple Pay, Google Pay) (sub-sec.2.4.1.6) | M | |
| 48 | - Heads-Up Display (HUD) or equivalent customer-facing display (sub-sec. 2.4.1.7) | M | |
| 49 | - VoIP intercom with video, with customer-assistance routing to the parking office and 24×7 backup (sub-sec.2.4.1.8) | M | |
| 50 | - Surge protection on power and communication circuits (sub-sec.2.4.1.9) | M | |
| 51 | - Uninterruptible Power Supply (UPS) sufficient for fifteen (15) minutes of ride-through for the lane controller, network switch, cameras, gate logic, and intercom (sub-sec.2.4.1.10) | M | |
| Ex. A §2.4 | Performance Requirements (sub-section 2.4.2) | ||
| The Contractor shall meet the following entry performance targets, measured against a documented test set: | |||
| 52 | - Vehicle stop to entry decision: ≤ 2.0 seconds median, ≤ 3.0 seconds at the 95th percentile, for app-driven and SunPass flows (sub-sec.2.4.2.1) | M | |
| 53 | - Vehicle stop to entry decision: ≤ 2.5 seconds median, ≤ 4.0 seconds at the 95th percentile, for CCI/CCO and RFID credential flows (sub-sec. 2.4.2.2) | M | |
| 54 | - Gate raise: full cycle ≤ 1.5 seconds excluding hold-open time (sub-sec. 2.4.2.3) | M | |
| 55 | - LPR accuracy (entry): ≥ 98% daytime, ≥ 95% nighttime, ≥ 92% adverse weather (rain / wet night), measured against MDAD's witnessed test set (sub-sec.2.4.2.4) | M | |
| 56 | - Confidence score and image pair (plate + context) stored for every entry event (sub-sec.2.4.2.5) | M | |
| Ex. A §2.4 | Entry Methods and Fallbacks (sub-section 2.4.3) | ||
| 57 | Each entry lane shall support the standard and credential-based entry methods identified in Section 2.1.1, including paper ticket, CCI/CCO, SunPass, RFID employee/VIP credentials, and reservation-based digital credentials, as well as the optional app-driven and LPR-driven ticketless methods where activated by MDAD. For customers who are not enrolled in an optional ticketless method, the PARCS shall support issuance of a standard paper ticket or, where MDAD elects to enable it, creation of a temporary parking session using LPR data, with clear instructions for subsequent payment through pay-on-foot, exit payment, or mobile web-based workflows. All lane entry and fallback modes shall be documented, tested, accessible, and multilingual. | M | |
| Exhibit A — §2.5 Exit Lane Equipment and Processing | |||
| Ex. A §2.5 | General (sub-section 2.5.1) | ||
| 58 | Exit lanes shall mirror the equipment and capabilities of entry lanes (Section 2.4.1) and shall additionally support payment, validations, refunds (within supervisor controls), and exception handling. Exit lanes shall support cash payment through attended exit booths or cash-enabled exit terminals at no fewer than one location per facility, as a required payment option. Cashier stations, cash-handling equipment, and booth transaction panels shall be fully integrated with the PARCS transaction, audit, reconciliation, and reporting functions. | M | |
| 59 | At the Central Collection Plaza, cash payment acceptance and paper-ticket validation shall be limited to Exit Lane 1 (nearest the parking office). The remaining fifteen exit lanes at the Central Collection Plaza shall support CCI/CCO, SunPass, RFID, and reservation-based credential exit only, without cash-handling or paper-ticket-validation capability. Prior to finalizing this configuration, the Contractor shall validate that the designated Central Collection Plaza cash/ticket lane can support projected transaction volumes without degrading the throughput performance required under this Section, and shall report findings to MDAD for review. | M | |
| Ex. A §2.5 | Performance Requirements (sub-section 2.5.2) | ||
| 60 | - Vehicle stop to exit decision (gate open) for paid sessions: ≤ 2.5 seconds median, ≤ 4.0 seconds at the 95th percentile (sub-sec.2.5.2.1.) | M | |
| 61 | - Exit decision for sessions requiring payment at exit: ≤ 4.5 seconds median for EMV contactless, ≤ 7.0 seconds median for EMV contact (chip insert) (sub-sec.2.5.2.2) | M | |
| 62 | - LPR pairing accuracy (entry-to-exit): ≥ 99% for the deterministic pairing logic in normal operation (sub-sec. 2.5.2.3) | M | |
| 63 | - Override and supervisor-assisted exit shall be logged with attribution and reason code (sub-sec.2.5.2.4) | M | |
| Ex. A §2.5 | Unmatched Credential / Temporary Session Exit Handling (sub-section 2.5.3) | ||
| 64 | Where a primary entry credential or enrolled account cannot be matched at exit, the PARCS shall attempt to identify and retrieve the applicable parking session using available identifiers, including LPR data, reservation credentials, SunPass/RFID credentials, CCI/CCO payment tokens, or other MDAD-approved identifiers. Temporary LPR-based sessions created for non-registered customers shall be retrievable for payment at pay-on-foot stations, exit payment terminals, designated cash-enabled exit booths or terminals, or through the mobile web-based payment workflow. Where a paper ticket was issued under the exception workflow, the PARCS shall support ticket validation, fee calculation, payment, and exit processing. If no valid session can be established, the PARCS shall apply the MDAD-configurable exception or lost-session policy with supervisor controls. All unmatched, unread, temporary-session, paper-ticket, and supervisor-assisted exits shall be logged, attributable, and visible in the revenue-assurance dashboard. | M | |
| Exhibit A — §2.6 Rate Engine and Dynamic Pricing | |||
| Ex. A §2.6 | General (sub-section 2.6.1) | ||
| 65 | All parking rates at MIA shall be established by MDAD at its sole discretion and shall be subject to change upon five (5) calendar days written notice to the Contractor. The PARCS shall provide a configuration-driven rate engine that enables authorized MDAD users to define, test, activate, and retire rate structures across all public paid parking facilities without requiring vendor code changes or a contract amendment. The rate engine shall be a fully integrated component of the PARCS core platform and shall govern fee calculation for all transient and reservation-based transactions processed by the system. | M | |
| Ex. A §2.6 | Rate Structure Requirements (sub-section 2.6.2) | ||
| The rate engine shall support, at a minimum: | |||
| 66 | - A minimum of twenty (20) independently configurable fee structures, each supporting multiple rate increments, blocks, and segments, applicable across all public paid parking facilities (sub-sec. 2.6.2.1) | M | |
| 67 | - Fee structures differentiated by parking facility, area within a facility, product type, parking duration, time of day, and day of week (sub-sec.2.6.2.2) | M | |
| 68 | - Twenty-four (24) hour daily maximums, configurable per facility and product (sub-sec.2.6.2.3) | M | |
| 69 | - A configurable grace period with a zero-dollar charge for customers exiting within the grace period; grace period transactions shall be coded and reported separately (sub-sec.2.6.2.4) | M | |
| 70 | - Automatic adjustment for daylight savings time and leap year in all fee calculations (sub-sec.2.6.2.5) | M | |
| 71 | - Programmable rate effective dates, enabling MDAD to stage rate changes prior to the effective date (sub-sec.2.6.2.6) | M | |
| 72 | - A rate change revenue impact report that projects the revenue impact of a proposed rate change against historical transaction data for a user-specified date range, facility, and grace period setting (sub-sec.2.6.2.7) | M | |
| 73 | - Bulk import of rate structures from MDAD-approved file formats, including CSV and Excel (sub-sec.2.6.2.8) | M | |
| 74 | - Electric Vehicle (EV) charging fees, configurable per facility and charging station type, applicable to PARCS-integrated EV charging infrastructure (sub-sec.2.6.2.9) | D | |
| Ex. A §2.6 | Dynamic Pricing Requirements (sub-section 2.6.3) | ||
| 75 | The PARCS shall support MDAD-defined dynamic pricing models that allow parking rates to vary based on real-time and anticipated demand conditions. Dynamic pricing parameters shall be fully configurable by authorized MDAD users through the PARCS supervisor console. The dynamic pricing capability shall: | ||
| 76 | - Support rate variation based on occupancy thresholds, time of day, day of week, duration of stay, and scheduled events, as defined by MDAD (sub-sec.2.6.3.1) | M | |
| 77 | - Apply dynamic rate logic independently per facility and per parking product (sub-sec.2.6.3.2) | M | |
| 78 | - Allow MDAD to define minimum and maximum rate floors and ceilings for each dynamic pricing rule, ensuring rates do not fall below or exceed MDAD-approved bounds without explicit authorization (sub-sec.2.6.3.3) | M | |
| 79 | - Allow MDAD to activate, suspend, or retire any dynamic pricing rule in real time without system downtime or vendor intervention (sub-sec.2.6.3.4) | M | |
| 80 | - Support integration with a third-party variable rate engine designated by MDAD, via a documented and versioned API, to receive rate signals for transient and reservation parking products; the PARCS shall apply externally supplied rate signals subject to MDAD-configured floor and ceiling constraints (sub-sec.2.6.3.5) | D | |
| 81 | - Display the applicable rate to the customer at entry, at pay-on-foot kiosks, and through the customer mobile app and web experience, in real time and consistent with the rate in effect at the time of entry (sub-sec.2.6.3.6) | M | |
| 82 | - Log all rate changes, including the date and time of change, the user or system initiating the change, the prior rate, and the new rate, in an immutable audit trail accessible to MDAD (sub-sec.2.6.3.7) | M | |
| Ex. A §2.6 | Rate Testing (sub-section 2.6.4) | ||
| 83 | The PARCS shall provide a test mode that allows MDAD users to validate the accuracy of any new or modified fee structure or dynamic pricing rule against simulated transaction scenarios prior to activating the rule in the production environment. Test mode activity shall not generate revenue records or affect the production database. | M | |
| Ex. A §2.6 | 2.6.5 Validation Program Management | ||
| 84 | The PARCS shall provide a fully configurable validation program module, administered by authorized MDAD users without vendor intervention, that shall: | M | |
| 85 | - Support multiple validation types, including flat-rate discount (fixed dollar amount off the applicable parking fee), time-based reduction (specified number of complimentary minutes), and percentage discount, applicable individually or in combination as permitted by MDAD configuration (sub-sec.2.6.5.1) | M | |
| 86 | - Allow MDAD to create, modify, suspend, and retire validation issuer accounts, with each issuer assigned a unique identifier, a configurable daily and monthly issuance cap, and an expiry period for issued validations (sub-sec.2.6.5.2) | M | |
| 87 | - Require authorized MDAD or issuer user authentication for validation issuance; validation issuance shall be logged with issuer identity, validation type, timestamp, and associated transaction or vehicle where available (sub-sec.2.6.5.3) | M | |
| 88 | - Generate alerts when an issuer account approaches or exceeds its configured issuance cap, routed to designated MDAD staff (sub-sec.2.6.5.4) | M | |
| 89 | - Provide issuer-level financial impact reporting consistent with the standard report described in Section 2.17.2.6, including total validations issued, total validations redeemed, redemption rate, average discount value, and net revenue impact for any user-specified period (sub-sec.2.6.5.5) | M | |
| 90 | - Support bulk issuance of validation codes or QR codes for pre-authorized events, with each bulk batch assigned a unique batch identifier, an expiry date, and a use-limit per code (sub-sec.2.6.5.6) | M | |
| Exhibit A — §2.7 License Plate Recognition | |||
| 91 | LPR shall be used at entry and exit lanes as a recognition, audit, transaction-matching, exception-resolution, temporary-session, and revenue-assurance technology, supporting operations rather than serving as the primary means of authorizing entry or exit. LPR-driven ticketless entry/exit shall be available as an optional, MDAD-activatable capability that MDAD may enable, expand, or restrict over the term as customer demographics, technology adoption, and operational needs evolve; it shall not be required as the primary authorization method for normal entry or exit. Where enabled, and for non-registered customers or when an optional ticketless method is unavailable, LPR may be used to establish and retrieve a temporary parking session in accordance with Section 2.1.1. LPR shall also support plate evidence, swapped-credential detection, unmatched-session reconciliation, watchlist alerts (with FDLE integration), and revenue audit. | M | |
| 92 | - Capture a plate image and a context image for every entry and exit event (sub-sec.2.7.1 ) | M | |
| 93 | - OCR performed in real time, with the result available to lane logic within 500 milliseconds of image acquisition (sub-sec.2.7.2 ) | M | |
| 94 | - Daytime accuracy ≥ 98%, nighttime ≥ 95%, adverse weather ≥ 92% (sub-sec.2.7.3 ) | M | |
| 95 | - Confidence score stored with each plate read (sub-sec.2.7.4) | M | |
| 96 | - Low-confidence reads routed to exception handling per Department-configured threshold (sub-sec.2.7.5 ) | M | |
| 97 | - Support for U.S. jurisdictions including Florida, plus vanity, dealer, and temporary tags (sub-sec.2.7.6) | M | |
| 98 | - Deterministic entry-to-exit pairing logic with ≥ 99% pairing accuracy in normal operation (sub-sec.2.7.7 ) | M | |
| 99 | - Image review workstation (IRW) available to authorized operators, with the ability to correct plate data and search by plate, partial plate, time window, lane, or facility (sub-sec.2.7.8) | M | |
| 100 | - Cameras shall meet NEMA / IP ratings for exterior installation in South Florida conditions (sub-sec.2.7.9 ) | M | |
| Exhibit A — §2.8 Payment Processing | |||
| Ex. A §2.8 | 2.8.1 General | ||
| 101 | The PARCS shall accept payment at exit lanes, designated cash-enabled exit booths or terminals, pay-on-foot kiosks, in-app, through responsive mobile web and online workflows, and at attended cashier stations where retained. Cash transactions at designated exit locations shall be recorded in the same PARCS transaction ledger and revenue-control framework as electronic payments. Cash shall be accepted as a required payment option at no fewer than one designated location per facility, consistent with Miami-Dade County Commission policy. Mobile web-based payment shall not require app enrollment and shall allow a customer to retrieve a temporary or active parking session using a QR code or similar MDAD-approved digital access mechanism, review applicable charges, and complete payment using a supported electronic payment method. The payment architecture shall be PCI DSS v4.0.1 (or successor) compliant for cardholder-data functions, with EMV Level 1 and Level 2 certified terminal components. Plaintext primary account number (PAN) data shall not be visible to airport users or stored outside the approved payment scope; tokenized customer payment methods shall be supported for recurring users. | M | |
| Ex. A §2.8 | 2.8.2 Payment Methods | ||
| 102 | - EMV contact and contactless bankcards (Visa, MasterCard, Discover, American Express, JCB as supported by the MDAD merchant account) (sub-sec. 2.8.2.1) | M | |
| 103 | - Apple Pay and Google Pay on EMV-enabled devices (sub-sec. 2.8.2.2) | M | |
| 104 | - SunPass (FDOT) electronic toll/parking — see Section 2.9 (sub-sec. 2.8.2.3) | M | |
| 105 | - RFID employee/VIP credentials reconciled through GateKeeper (or successor) — see Section 2.12 (sub-sec. 2.8.2.4) | M | |
| 106 | - Reservation-based prepayments processed by Propel (or successor) — see Section 2.10 (sub-sec. 2.8.2.5) | M | |
| 107 | - Cash, as a required payment option, at no fewer than one attended exit booth, cash-enabled exit terminal, attended cashier station, or pay-on-foot kiosk per facility (sub-sec. 2.8.2.6) | M | |
| 108 | - Check at attended cashier stations only (during transition; subject to Department phase-out) (sub-sec. 2.8.2.7) | M | |
| Ex. A §2.8 | 2.8.3 Reversals and Refunds | ||
| 109 | The PARCS shall support reversals and refunds with supervisor controls, reason codes, attribution, and a documented audit trail. Refunds shall be processed through the MDAD payment gateway and shall be reflected in revenue reports within the same business day. | M | |
| Ex. A §2.8 | 2.8.4 Funds Settlement and Reconciliation | ||
| 110 | Funds from electronic payment transactions shall settle directly to the Department's designated merchant account in accordance with the MDAD-approved payment processor/acquirer agreement. The Contractor shall not receive, hold, or commingle electronic parking-revenue settlement funds except where expressly authorized in writing by MDAD. Cash payments collected at designated exit booths, cash-enabled exit terminals, attended cashier stations, or pay-on-foot kiosks shall be recorded by the PARCS with the applicable facility, lane or device, transaction identifier, date/time, amount due, amount tendered, change issued where applicable, and cashier/operator identification where applicable. Cash totals shall be included in daily revenue reconciliation and audit reporting, with overages, shortages, voids, refunds, and other cash exceptions separately identifiable. The Contractor shall provide daily settlement and revenue reconciliation reports that match issuer/acquirer settlement files and recorded cash collections to PARCS transaction records, with discrepancies flagged for investigation. Settlement and reconciliation files shall be delivered by 09:00 a.m. Eastern Time on the following business day in a format mutually agreed with MDAD Finance and compatible with MDAD's financial management system (currently INFORMS); at minimum, the format shall be either a documented flat file (CSV or fixed-width) or an API endpoint returning structured JSON or XML, with a published field dictionary. The Contractor shall begin investigation of any material reconciliation discrepancy within one (1) business day of identification and shall provide resolution or a documented escalation/status update within three (3) business days. The Contractor shall provide a sample reconciliation file format for MDAD Finance review no later than sixty (60) calendar days prior to go-live. | M | |
| Ex. A §2.8 | 2.8.5 Communications | ||
| 111 | Communications between EMV terminals, the PARCS, and the payment gateway shall be encrypted in transit using TLS 1.3 (minimum). Network segmentation shall isolate the cardholder data environment from non-payment PARCS components in accordance with PCI DSS guidance. | M | |
| Ex. A §2.8 | 2.8.6 Chargeback and Dispute Workflow | ||
| 112 | The PARCS shall support an end-to-end chargeback and dispute management workflow that enables MDAD and the Contractor to respond to payment card issuer chargebacks within required timeframes. At minimum, the PARCS shall: | M | |
| 113 | - Receive chargeback notifications from the payment gateway and automatically match each chargeback to the corresponding PARCS transaction record, including LPR image, entry timestamp, exit timestamp, payment amount, terminal identifier, and card token (sub-sec.2.8.6.1) | M | |
| 114 | - Provide an operator-accessible queue for open chargebacks, sortable by age, dispute amount, and facility, with configurable escalation alerts when a chargeback approaches the issuer response deadline (sub-sec.2.8.6.2) | M | |
| 115 | - Generate a response evidence package for each chargeback that includes the matched transaction record, LPR image(s), and any session-level audit log entries, exportable as a PDF or structured data file suitable for submission to the payment gateway (sub-sec.2.8.6.3) | M | |
| 116 | - Track chargeback outcomes (won, lost, pending) and financial impact, and reflect outcomes in the chargeback report described in Section 2.17.2.9 (sub-sec.2.8.6.4) | M | |
| 117 | - Support documented procedures for pre-arbitration and arbitration responses where the payment gateway and card network rules permit (sub-sec.2.8.6.5) | M | |
| Exhibit A — §2.9 SunPass Integration | |||
| Ex. A §2.9 | 2.9 SunPass Integration | ||
| 118 | The PARCS shall integrate with the Florida Department of Transportation (FDOT) SunPass M-Commerce Parking program in accordance with the current FDOT interface specification. The integration shall: | M | |
| 119 | - Read SunPass transponders at entry and exit lanes using compatible AVI readers (TransCore Encompass 5 / E5 or successor approved by MDAD and supported by FDOT) (sub-sec.2.9.1) | M | |
| 120 | - Reconcile parking transactions to SunPass accounts and remit fees in accordance with the FDOT program (sub-sec.2.9.2) | M | |
| 121 | - Maintain a local cache of transponder validity, so that SunPass entry decisions remain available during SunPass outage (sub-sec.2.9.3) | M | |
| 122 | - Reconcile offline SunPass transactions to the central system once the SunPass connection is restored (sub-sec.2.9.4) | M | |
| 123 | - Report SunPass transaction volumes, exceptions, and revenue separately within the standard revenue reports (sub-sec.2.9.5) | M | |
| 124 | - Maintain a SunPass read rate ≥ 99% in lanes where toll-tag acceptance is enabled (sub-sec.2.9.6) | M | |
| Exhibit A — §2.10 Reservation Integration (Propel and successor) | |||
| 125 | The PARCS shall integrate with the Department's parking reservation platform, currently Propel, to validate reservations at entry and exit. The integration shall: | M | |
| 126 | - Consume reservation bookings and inventory in near real time (sub-sec.2.10.1) | M | |
| 127 | - Validate reservation at entry by QR code, app token, plate, or credential, in accordance with the Department's chosen flow (sub-sec.2.10.2) | M | |
| 128 | - Apply the reservation-specific rate (sub-sec.2.10.3) | M | |
| 129 | - Honor cancellations, modifications, and no-show rules per Department policy (sub-sec.2.10.4) | M | |
| 130 | - Report reservation pickup, no-show, cancellation, and walk-up displacement (sub-sec.2.10.5) | M | |
| 131 | - Support migration to a successor reservation platform during the term (sub-sec.2.10.6) | M | |
| Exhibit A — §2.11 Park Assist (or Successor) Integration | |||
| 132 | The Department currently utilizes Park Assist as its parking guidance system in the Ibis, Dolphin Garage, and Flamingo Garages. The PARCS shall integrate with Park Assist, or a successor parking guidance system designated by MDAD, to: | M | |
| 133 | - Consume real-time occupancy and zone capacity to display 'available spaces' to entering customers (sub-sec.2.11.1) | M | |
| 134 | - Consume vehicle-location data to support customer self-service vehicle-finder and Department-initiated lost-vehicle response (sub-sec.2.11.2) | D | |
| 135 | - Publish PARCS lane events that meaningfully improve Park Assist signage and analytics (sub-sec.2.11.3) | D | |
| 136 | - Reconcile counts between PARCS lane events and Park Assist occupancy as part of routine revenue assurance (sub-sec.2.11.4) | M | |
| 137 | - Publish real-time facility-level occupancy status (available, limited, full, closed) to MDAD-designated variable message sign (VMS) controllers or sign management systems at roadway approach and facility entrance points, via a documented API or data feed; the feed shall update within sixty (60) seconds of an occupancy threshold change and shall support MDAD-configurable threshold values for each status level per facility (sub-sec.2.11.5) | M | |
| Exhibit A — §2.12 Ground Transportation and Employee Parking Integration | |||
| 138 | The Department currently uses GateKeeper as its ground transportation management system (GTMS). The PARCS shall integrate with GateKeeper to allow for employee and VIP parking access via RFID credentials. The PARCS shall: | M | |
| 139 | - Validate employee and VIP credentials at entry and exit lanes through GateKeeper or its successor (sub-sec.2.12.1) | M | |
| 140 | - Coordinate billing and account state for employee and VIP parkers (sub-sec.2.12.2) | M | |
| 141 | - Coexist with the GTMS in shared entry / exit plazas where public, employee, and VIP parkers share lanes (sub-sec.2.12.3) | M | |
| 142 | - Support migration to a successor GTMS during the term (sub-sec.2.12.4) | M | |
| 143 | - Generate automated overstay alerts when a vehicle in a permit-restricted, reservation-only, or time-limited zone exceeds its authorized duration, as configured by MDAD; alerts shall include the vehicle's license plate, entry time, authorized duration, current duration, zone, and facility, and shall be deliverable to designated MDAD enforcement staff via the supervisor console, email, and an API endpoint suitable for integration with a handheld enforcement device or mobile enforcement application; overstay events shall be logged and reportable separately from standard transaction records (sub-sec.2.12.5) | D | |
| Exhibit A — §2.13 Customer Channels - App, Web, Kiosk, and Lane | |||
| Ex. A §2.13 | Mobile App and Web (Optional Ticketless Channel) (section 2.13.1) | ||
| The Contractor shall provide a Department-branded (or co-branded as approved) mobile app and a responsive web experience as an optional, MDAD-activatable ticketless channel. The responsive web experience shall also support non-enrolled customers and temporary parking sessions without requiring installation of or enrollment in the mobile application. At a minimum, the customer channels shall: | |||
| 144 | - Support account creation, household accounts, multiple stored vehicles (at least 10 per account), and multiple stored payment methods (at least 5 per account) (sub-sec.2.13.1.1) | M | |
| 145 | - Support guest checkout for reservations where Department policy permits (sub-sec.2.13.1.2) | D | |
| 146 | - Provide entry / exit notifications, real-time session view, receipts, and dispute initiation (sub-sec.2.13.1.3) | M | |
| 147 | - Support contactless entry/exit via plate match against the enrolled account, with the gate raised against a confirmed paid session (sub-sec.2.13.1.4) | M | |
| 148 | - Conform to WCAG 2.2 AA (sub-sec.2.13.1.5) | M | |
| 149 | - Provide English and Spanish at minimum; the Contractor shall propose additional languages (e.g., Haitian Creole, Portuguese) appropriate to MIA's customer profile (sub-sec.2.13.1.6) | D | |
| 150 | - Provide short message service (SMS) and email notifications within five (5) minutes of triggering event (sub-sec.2.13.1.7) | M | |
| 151 | - Provide configurable customer communication templates for at least the events enumerated in the Compliance Matrix, editable by authorized MDAD users and deliverable via approved channels (sub-sec.2.13.1.8) | M | |
| 152 | - Support mobile web-based retrieval and payment of temporary or active parking sessions without app enrollment, using a QR code or similar digital access mechanism that allows the customer to review the session, charges, payment status, and receipt. (sub-sec. 2.13.1.9) | M | |
| Ex. A §2.13 | Pay-on-Foot Kiosks (section 2.13.2) | ||
| 153 | Pay-on-foot kiosks shall be provided in the Ibis Garage, Dolphin Garage, and Flamingo Garage, and at additional locations approved by MDAD. Kiosks shall support lookup and payment of temporary LPR-based and other active parking sessions and shall accept cash, EMV chip and contactless payments, mobile wallets, and validations, with cash transactions fully integrated into PARCS revenue-control, audit, and reconciliation reporting. Kiosks shall provide a receipt or digital receipt option and shall conform to ADA accessibility standards. Kiosk user interfaces and lane customer-facing displays (HUDs) shall support English and Spanish at minimum, consistent with the multilingual requirement in Section 2.13.1.6; the Contractor shall propose additional languages appropriate to MIA's customer profile. | M | |
| Ex. A §2.13 | Intercoms and Customer Assistance (section 2.13.3) | ||
| 154 | VoIP intercoms with video shall be installed at every entry and exit lane and at every pay-on-foot kiosk. Calls shall route to a 24×7 customer-assistance capability with documented escalation and resolution targets. | M | |
| Ex. A §2.13 | 2.13.4 Accessibility | ||
| 155 | All public-facing hardware and workflows shall support accessible use. Customer-facing web and mobile content shall conform to WCAG 2.2 AA. Physical equipment shall conform to the 2010 ADA Standards for Accessible Design and applicable Florida and Miami-Dade County accessibility requirements. | M | |
| Exhibit A — §2.14 Cybersecurity, Privacy and Network | |||
| 156 | The Contractor shall address three interdependent domains: cybersecurity, privacy, and network infrastructure. For cybersecurity, the Contractor shall align security controls to NIST CSF 2.0 outcomes (Govern, Identify, Protect, Detect, Respond, Recover) and shall maintain PCI DSS v4.0.1 (or successor) compliance for the cardholder data environment. For network infrastructure and communications, the Contractor shall design, document, and operate a resilient field network that supports continuous PARCS operations, meets MDAD monitoring and segmentation requirements, and is maintained in accordance with documented change-control procedures. At minimum: | M | |
| 157 | - Encrypt administrative and API communications in transit (TLS 1.3 minimum for externally routed communications unless MDAD approves an exception) (sub-sec.2.14.1) | M | |
| 158 | - Encrypt sensitive data at rest with AES-256 (or equivalent) for databases, backups, and log archives (sub-sec.2.14.2) | M | |
| 159 | - Multifactor authentication (MFA) for all privileged and remote administrative access, including vendor support access (sub-sec.2.14.3) | M | |
| 160 | - Least privilege and role segregation, with quarterly access reviews (sub-sec.2.14.4) | M | |
| 161 | - Forward immutable or tamper-evident security logs to the MDAD-approved store in near real time (sub-sec.2.14.5) | M | |
| 162 | - Centralized SIEM integration via syslog, API, or agent method, tested for every critical component (sub-sec.2.14.6) | M | |
| 163 | - Vulnerability management: critical vulnerabilities remediated within fifteen (15) calendar days; high within thirty (30) calendar days; unless MDAD approves an exception (sub-sec.2.14.7) | M | |
| 164 | - Annual independent penetration testing; report and remediation summary available on request, subject to reasonable redaction (sub-sec.2.14.8) | M | |
| 165 | - Secure software development practices: code review, dependency scanning, and release approval controls documented (sub-sec.2.14.9) | M | |
| 166 | - Privacy notice and terms disclosure during account creation; opt-in / opt-out controls for marketing communications (sub-sec.2.14.10) | M | |
| 167 | - LPR data governance compliant with applicable Florida law; access to LPR images and reads limited to authorized users; retention periods configurable and documented (sub-sec.2.14.11) | M | |
| 168 | - Tamper-evident alarms on field cabinet openings, with alerts forwarded to the SIEM and to the NOC (sub-sec.2.14.12) | M | |
| 169 | - Disclose and maintain documented data residency for all hosted Airport data; data shall be hosted within the continental United States unless MDAD approves an exception in writing (sub-sec.2.14.13) | M | |
| 170 | - Redundant fiber or independent network path from each field aggregation point to the central system; where the physical constraints of a specific location (e.g., space, structural limitations, or MDAD-imposed access restrictions beyond the IDF handoff) make full redundancy impracticable, the Contractor shall document the constraint and propose a compensating control for MDAD approval (sub-sec 2.14.14) | M | |
| 171 | - Managed switch port security configured on all field and core switches, including 802.1X port-based authentication or media access control (MAC) address filtering, with unused port disablement addressed separately under item 2.14.29 (sub-sec.2.14.15) | M | |
| 172 | - All new network switches supplied under this Contract shall be Cisco brand and shall be subject to MDAD approval prior to procurement; no substitute manufacturer shall be used without prior written approval from MDAD (sub-sec 2.14.16) | M | |
| 173 | - Quality of service (QoS) policies applied at all managed switches to prioritize voice, intercom, and help-point traffic over background data; QoS configuration shall be documented and provided to MDAD at project closeout (sub-sec.2.14.17) | M | |
| 174 | - Separate virtual local area network (VLAN) or network segment for remote and on-site maintenance access, logically isolated from the operational PARCS traffic path; access to the maintenance segment shall require MFA and shall be logged to the SIEM (sub-sec.2.14.18) | M | |
| 175 | - Network diagrams showing all VLAN assignments, IP address ranges, switch interconnects, uplink paths, and firewall zones, delivered as a project closeout submittal and updated within thirty (30) calendar days of any material network change (sub-sec.2.14.19) | M | |
| 176 | Wireless backhaul permitted only at locations where wired infrastructure is not feasible and MDAD has approved the wireless medium in writing; wireless links shall use WPA3 Enterprise (or WPA2 Enterprise with AES-CCMP where WPA3 is not supported) and shall be documented in the network diagrams required under item 2.14.18 (sub-sec.2.14.20) | M | |
| 177 | - Fallback communications path for each remote economy lot location; the fallback medium (cellular long term evolution (LTE)/ fifth-generation mobile network (5G), secondary fiber, or other) shall be documented, and automatic failover shall occur within sixty (60) seconds of primary path loss without requiring operator intervention (sub-sec. 2.14.21) | M | |
| 178 | - Continuous monitoring of packet loss and link-flap events on all lane-side and aggregation-switch uplinks; alerts shall be generated for packet loss exceeding one percent (1%) over any five (5)-minute interval or for more than three (3) link-flap events within any fifteen (15)-minute window, and forwarded to the NOC and SIEM (sub-sec. 2.14.22) | M | |
| 179 | - Documented bandwidth sizing model submitted at design review, specifying peak and average consumption per lane type (entry, exit, pay-on-foot) and per camera resolution profile; the model shall demonstrate no single uplink is sustained above eighty percent (80%) utilization under normal operating conditions (sub-sec.2.14.23) | M |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .