Parking integration
Parking Management Integration
Parking management integration for buildings: occupancy, barrier status, guidance and cross-system links, without supplying barriers or parking hardware.
Scope: integration, not parking hardware
Parking management in this context means connecting an existing or third-party parking system to the building platform. We do not supply barriers, ticket machines, payment terminals, ANPR cameras or space sensors. The parking vendor remains responsible for its equipment, transactions and warranty. Our role is to bring occupancy, barrier status, entry and exit events and equipment faults into the building operating picture, then link them to lighting, ventilation, access and reporting. That boundary keeps responsibility clear and lets the client keep the parking system it has already procured. Where a new system is being specified, we can define the interface requirements. The interface list is agreed before the parking vendor and the building team start work. A written interface list is also the clearest protection against a late claim that integration was included in someone else's package. That clarity is what makes a future change of parking vendor survivable, and it should be reflected in the drawings, the point list and the maintenance contract.
- We integrate existing or third-party parking systems
- Barriers, ticket machines and cameras stay with the parking vendor
- Interface requirements can be defined before procurement
- Responsibility boundaries written into the scope
Data and interfaces
Parking systems expose data in different ways. Older installations provide volt-free contacts for barrier open, full signs or alarm. Newer systems offer a software API, a database export or a Modbus or BACnet gateway. The integration should start from a data list: what is needed, at what frequency, and who owns each point. Occupancy counts, level counts, entry and exit events, payment status and fault codes are common. Time synchronisation matters more than it appears: an entry event that is two minutes out of step with CCTV makes incident review harder. Every point needs a name, a unit, a quality flag and a documented source. The data list should distinguish live status from historical records, because the two usually arrive by different routes, with different latency and different retention rules. Where a vendor will not document its interface, the negotiation belongs before the contract, not after the first fault.
- Data list agreed before interface work starts
- API, database export, Modbus, BACnet or volt-free contacts
- Time synchronisation with CCTV and access records
- Each point has a name, unit, quality flag and source
Occupancy counting and guidance
Once counts are reliable, the platform can drive guidance: available-space signs, level indicators, zone displays and app views. Guidance logic should include hysteresis so a sign does not flicker between full and available at the threshold, and a fallback when counts become stale. EV bay status can be shown where the charge points report it. Historical utilisation supports decisions about allocation, pricing policy and after-hours access. The platform can compare weekday and weekend patterns, identify persistently full zones and show how long vehicles stay. These are operational insights, not a substitute for the parking operator's own revenue system. A guidance display that promises a space it cannot verify is worse than no display at all, because drivers stop trusting the system after the second wrong turn. Stale counts should be replaced by a neutral message, not by the last known number. Counts should be calibrated against a manual survey on the first day of operation and again after any sensor works.
- Available-space signs and level indicators
- Hysteresis to prevent flicker at thresholds
- EV bay status where charge points report it
- Utilisation trends by zone and time band
Lighting, ventilation and CO control
Parking events become useful when they connect to the rest of the building. A vehicle entering an underground level can trigger the lighting scene and ventilation stage for that zone. A barrier fault can raise a facilities alarm and point the operator to the nearest camera. An exit event can release the associated access record. Ventilation should follow CO and occupancy data rather than a fixed timer, with staged fan speeds and a defined purge period. Typical staged control uses CO thresholds in the range of 20 to 30 ppm for the first stage and a higher alarm level above 50 ppm, but the actual values must come from the car park ventilation design and local requirements. Fire and smoke control remain with the fire system; the parking integration must not delay or override a life-safety sequence.
- Entry events trigger zone lighting and ventilation
- Barrier faults route to facilities and CCTV
- CO and occupancy drive ventilation stages
- Fire and smoke control stay outside the BAS sequence
Access, EV charging and payment boundaries
Access and payment are boundaries that need to be drawn early. The parking system owns tickets, tariffs, validations and payment; the building platform may receive status and events for correlation, but it should not become the transaction system. Where the same credential opens a lobby door and a parking barrier, the access system and the parking system need a defined relationship, including what happens when one is offline. EV charging adds a second commercial relationship: the charge point operator owns sessions and billing, while the building platform may cap site demand or shift charging toward generation. Each boundary should name the system of record, the direction of data and the fallback behaviour. Ambiguity at these boundaries is usually discovered by a driver at the barrier, which is the least convenient place to resolve it.
- Parking system remains the transaction system
- Credential relationship defined across access and parking
- EV sessions and billing stay with the charge point operator
- System of record and fallback named for each boundary
Reporting and operations
Parking reports should answer operational questions: how full did each zone get, when, for how long, and how often was guidance wrong? The platform can trend occupancy, entry and exit counts, barrier faults and equipment downtime. It can reconcile counts against the parking operator's transaction totals where the interface allows, but reconciliation is a check, not a billing system. Alarms should be grouped by equipment and location, with a clear route to the parking vendor for faults outside the integration scope. A monthly review of utilisation and faults is usually more valuable than a live dashboard nobody watches. The review should also test the guidance logic against actual arrivals, because a count that is accurate at midnight can still be wrong at the morning peak. Trends should be retained long enough to compare seasons, not only weeks.
- Occupancy and dwell trends by zone
- Barrier faults and equipment downtime logged
- Reconciliation only where the interface allows
- Faults outside scope routed to the parking vendor
Delivery, testing and vendor boundaries
Delivery starts with an interface survey and a test plan. Each point is proved against the parking system, including normal values, disconnection, restart and stale data. Guidance signs are checked at the threshold, not only at mid-range. The ventilation link is tested with simulated CO signals and with the fire mode, because those two conditions must not conflict. Handover includes the data list, the point map, the API or register documentation, the alarm routing and the escalation contacts for both vendors. A joint test with the parking vendor is worth scheduling, since most integration problems are ownership problems rather than protocol problems. The support agreement should say who responds first when a barrier, a counter or a gateway fails, and what the building team does while the vendor is on the way.
- Interface survey and joint test plan agreed
- Every point proved, including disconnect and stale data
- Ventilation tested against CO and fire mode
- Escalation contacts and first response named
Parking integration functions and failure checks
14 rows| Function | Source system | Typical interface | Platform role | Failure to check |
|---|---|---|---|---|
| Space and zone occupancy | Parking sensors or counters | API, Modbus, dry contact | Trend, guidance and reporting | Counter drift after a restart |
| Barrier status | Barrier controller | Dry contact or API | Monitor and raise fault alarms | Status stuck open or closed |
| Entry and exit events | Parking system | API or database export | Cross-reference CCTV and access | Event time out of step with video |
| Payment and ticket status | Parking system | API | Status only; no transactions | Platform assumed to handle payment |
| Availability signs | Sign controller | API or relay | Drive guidance logic | Sign flicker at the threshold |
| EV bay status | Charge point system | API or Modbus | Display availability | Occupied bay reported as free |
| Equipment faults | Parking vendor system | API or dry contact | Route alarms to the responsible vendor | Alarm with no owner |
| ANPR events | Parking system | API | Correlation and record only | Plate data retained without a rule |
| Lighting link | BAS | Local I/O or field bus | Zone scenes on entry and exit | Lights left on after the last exit |
| Ventilation and CO link | CO sensors and BAS | Local I/O or Modbus | Staged fans and purge | Stage stuck or purge disabled |
| Access correlation | Access control system | API or event export | Link vehicle and credential events | Credential valid after the barrier fails |
| Utilisation reporting | All parking sources | Platform data model | Trend by zone and time band | Report built on stale counts |
| Time synchronisation | Parking system and BAS | Network time or protocol | Consistent event reconstruction | Clock drift after a vendor update |
| Vendor escalation | Both vendors | Support agreement | Route faults to the right team | Both parties decline the call |
Project images
3 images
Frequently asked
01Do you supply barriers or ticket machines?
No. We integrate and monitor. Barriers, ticket machines, payment terminals and ANPR cameras are supplied and supported by the parking specialist, which keeps equipment responsibility and warranty with one party. This also means the client can change parking vendors later without replacing the building platform, provided the interface remains available.
02Can you integrate our existing parking system?
It depends on the interface it exposes. Systems with an API, database export, Modbus or dry contacts are usually feasible. Start with an interface survey and a data list before committing to scope. Older systems may need a gateway or a small hardware interface, and that cost should be known before the proposal is fixed.
03Can the platform take payments?
No. Payment and transactions stay with the parking system or its payment provider. The platform reads status for monitoring and reconciliation only. Keeping transactions out of the building platform also reduces the security and audit scope, which is an advantage rather than a limitation.
04Can parking drive lighting and ventilation?
Yes. Vehicle entry, zone occupancy or CO concentration can trigger lighting scenes and ventilation stages. The logic must be agreed with the electrical design and the car park ventilation requirements. The fire mode takes precedence over every normal sequence, and the two should be tested together rather than separately.
05Can the app show free spaces?
Yes, where the parking system provides reliable zone counts. Guidance needs hysteresis and a defined fallback when counts become stale, so the display does not promise a space it cannot verify. A neutral message is better than a confident wrong number, and the operator should be able to see when the count was last updated.
06Is ANPR included?
We do not supply cameras. Where the parking system exposes recognition events through an API, the platform can receive them for entry and exit correlation and record keeping. Retention, access and privacy rules for plate data belong to the parking operator and the building's data policy, not to the integration alone.
07Can several sites be managed together?
Yes. Each site keeps its local parking system and local control, while the platform provides central monitoring, reporting and alarm routing. The data model should be consistent across sites from the start. Central reporting is only useful if the same point means the same thing everywhere, so naming and counting rules belong in the first phase.
Next step
Bring us the building.
Tell us the building type, systems in scope and the outcome you need. We will map the shortest path to a working system.