Overview
APX Data Specification for the APDS committee
Version 0.16.0 (draft)
Updated 2026-11-02
Proposed additions to the APDS data model · Draft for the APDS committee · based on APDS 4.1 (2026-01-14) · APX 0.16.0
APX Data Specification for the APDS committee
Version 0.16.0 (draft)
Updated 2026-11-02
Proposed additions to the APDS data model · Draft for the APDS committee · based on APDS 4.1 (2026-01-14) · APX 0.16.0
Parking and kerbside operations now run on many connected systems at once: access control and lane equipment, licence plate recognition, permits and credentials, payments, merchant validations, enforcement and the back offices that tie them together. APDS gives these systems a common language for places, rights, rates, quotes, occupancy, sessions and observations. In implementing APDS 4.1 end to end across these systems, we found a small number of things they need to exchange that the data model does not yet have a place for.
This document set proposes those additions to the APDS data model. It is offered to the Alliance for Parking Data Standards for consideration, with thanks for the work that has gone into APDS. Every item here is a request or a suggestion. None of it changes the meaning of anything APDS already defines.
To give the APDS working groups, in the same form as the APDS 4.1 documents, a complete and reviewable description of the data elements and enumerations APX needs so that parking systems can exchange this information in APDS terms rather than in private extensions.
APX (APDS Parking eXtensions) began as an open, additive companion to APDS 4.1. It reuses every APDS construct as published and adds only what APDS leaves out. APX has been shared with the APDS committee and, following discussion with the committee, the work is now split in two:
Every element proposed here is already exercised in the APX reference implementation and its published test scenarios.
The proposals follow the APDS guiding principles and these additional rules:
other, and
an external code list may extend it, as APDS already does for vehicle
types and occupancy levels.This document set mirrors the APDS 4.1 technical documentation:
The proposals are grouped in three tiers so the working groups can take them in steps:
Figure 1: The APDS data domains, with the two proposed new domains. Additions are also proposed within Place, Occupancy, Rates, Right, Session, Observation, Energy infrastructure and PkCommon.
Adds what an operator needs to describe how the equipment in a Place is working right now, which way the licence plate cameras on an access lane face, and what is posted on the signs at a Place. It also suggests four lane-equipment values for EquipmentTypeEnum. Equipment status is kept in its own record, apart from the static Place description, for the same reason APDS keeps Demand apart from Supply: it changes far more often. A second group describes the equipment itself, so that a Place can be understood from the data alone: what each item does (its role), where it stands, what it is and what runs on it, which cameras look at what, and how a parker at any point of the Place reaches help (a comms point).
The Place data specification already describes where a Place is, how it is organised, and the equipment and services it offers. These proposals add three things operators share every day but cannot yet express in APDS terms: whether the equipment is working, which way the licence plate cameras on a lane face, and what the signs at a Place say.
A parking operation runs on its equipment. When a barrier fails, a pay machine runs out of paper or a camera goes offline, the operator, its monitoring service, its customer-service centre and its enforcement partner all need to know, and they need to know in the same words. Today each pair of systems agrees its own list of states.
Licence plate cameras at a lane read the plates of vehicles travelling in one direction. A receiving system can only tell an entry from an exit if it knows which way each camera faces.
Signs set the terms of use of a Place. When a customer appeals a parking charge, the operator must be able to show what the sign said on that day, even if the sign has since been replaced.
An Equipment Status record:
Equipment status is kept in its own record rather than as an attribute of the equipment. This follows the approach APDS takes for occupancy, where Supply (which changes rarely) is kept apart from Demand (which changes often). The equipment description is sent once; its status is sent whenever it changes.
APDS 4.1 EquipmentTypeEnum already includes lprCamera, occupancySensor, paymentMachine and several door types. Four values would complete a typical off-street access lane: barrier, gate, ticketDispenser and intercom. We suggest adding them so that lane equipment need not be typed as 'other'.
A Lane Camera:
A system that joins a Place today learns its layout from three places at once: the parking vendor's portal for the lanes and devices, the call platform for which intercom rings where, and a spreadsheet for the cameras. A second group of additions lets the Place data say it all:
A Signage record:
A replaced sign is never edited. Its Validity is closed with end reason superseded, and a new record, or a new version, carries the new wording, so the history is kept.
APDS already models current occupancy fully through Supply and Demand, so nothing is proposed for the present moment. One small addition is suggested for discussion: letting a DemandType record summarise a period (its highest and average count, and how many readings it rests on), so that hourly or daily occupancy history can be exchanged in APDS terms.
The APDS Occupancy data specification divides occupancy into Supply (the spaces or area available) and Demand (how much of it is in use). APX reads and shares occupancy entirely through these classes and proposes nothing new for the present moment. One small addition is suggested for discussion: a way to summarise occupancy over a period.
Cities, landlords and operators increasingly ask for occupancy history: the busiest hour of each day, the average occupancy of a zone across a month, the effect of a price change. Today a Distributing Party must either send every individual DemandType reading, which can mean thousands of records a day for one Place, or agree a private summary format with each receiver.
A Demand Type record that summarises a period:
A receiver can then tell a period with no readings (no data) from a period with low occupancy, which matters when the figures are used for pricing or planning decisions.
APX also offers a "current occupancy" view and an hourly history view to its users. We considered whether either is a new data element and concluded they are not:
Counts of electric charging points by status are described in the Energy Infrastructure domain.
APDS models the rate deck completely: RateTables, RateLineCollections, RateLines, taxes, surcharges and discounts. APX asks for two small additions. First, a policy on a RateTable that says whether it may be offered as a negotiated rate, so a customer-service agent or a partner can only offer tables the operator has cleared for that. Second, a validation benefit that extends the existing RateDiscount with comped time and a plain-language description, so a merchant validation can say what it is worth in the same terms APDS already uses for discounts.
The Rate data specification already lets an operator publish every RateTable, RateLineCollection and RateLine for a Place, with taxes, surcharges and discounts. APX proposes two small additions that let a rate deck be used, not only published, by the people who sell parking on the operator's behalf.
Customer-service agents, call centres and partners regularly offer a customer a price other than the posted one: a flat rate for a lost ticket, a goodwill rate, a rate agreed with an event organiser. Today there is no way for an operator to say which of its RateTables may be offered this way, so each partner keeps its own list, which drifts from the published deck. A flag on the RateTable itself means everyone who receives the rate deck also receives the operator's answer.
Merchant validations are already recognised by APDS (a validation payment type, a validation reference on the Segment, and the RateDiscount class). What APDS cannot yet say is what a validation is worth when the merchant gives away time rather than money, which is the most common form ("first two hours free"). Extending RateDiscount with a duration closes that gap using the class APDS already has.
A RateTable (additions):
A ValidationBenefit:
APDS records who holds a right, which credentials prove it, and what was paid for it. APX asks for the lifecycle and context that operators exchange every day around those same classes: the status of an assigned credential and the physical medium it was issued on, a credential as it was actually presented at a reader, the state of a reservation and the renewal chain of a permit, the outcome of a payment and how it was taken, an account status and balance on the RightHolder, merchant validation programmes with their instrument stock, and lists of plates (watch, scofflaw, allow) that tell a site what to do when a plate is seen. Every addition is optional and attaches to an existing APDS class, so every APDS 4.1 instance stays valid.
The Right data specification defines how an owner or operator grants the use of a Place (the RightSpecification), to whom (the RightHolder), through which proof (the credentials), and what was paid (MonetaryValue and Payment). APX proposes optional additions that carry the lifecycle operators already manage around those same classes, so that a lane, an enforcement device, a booking platform and a back office can agree on the current state of a right without a bilateral agreement.
Access credentials change state constantly: a card is reported lost, a fob is suspended for non-payment, a replacement is issued with a new number. APDS lets a credential be attached to an AssignedRight, but not whether it is still usable or what replaced it, so every reader and enforcement system must be told separately. A small status list and a replacement link on the assigned credential fix that, and a medium (card, fob, transponder, hangtag) separates the item the customer holds from the read technology APDS already records.
Reservations and permits are already modelled as AssignedRights with PlannedUses, following the APDS use cases. What partners still exchange by other means is whether a booking is confirmed, used or lapsed, which permit a renewal replaces, and how many of a multi-vehicle permit's cars may be parked at once.
APDS Payment records money collected. Payment systems also produce declines, authorisations that are not yet captured, and partial refunds, and operators need to know where and how a customer paid. Optional attributes on Payment, reusing the APDS MeansOfPaymentEnum, cover these.
Merchant validations are already visible in APDS at the moment they are used. The programme behind them (who validates, what it is worth, the limits, the stock of codes) is not, so pay stations, merchant applications and sites keep separate copies. Finally, cities and operators share lists of plates (watch, scofflaw, allow, their own enforcement vehicles) with every system that screens arrivals; a list says what to do when a plate is seen, which is different from a right.
A CredentialAssigned (additions):
A PresentedCredential:
An AssignedRight (additions):
A RightHolder (additions):
A Payment (additions):
A ValidationProgram:
A PlateList:
APDS 4.1 records a Session with its start, end, Segments and credentials, but not what the Session rests on or how it ended. These additions let two parties exchange the observations a Session was built from, why and how it closed (including a close set by rule rather than observed), each access attempt at a lane whether granted or denied, which record a Session was matched to, each merchant validation applied to a stay, and the custody record of a valeted vehicle. Every addition is optional and compatible with APDS 4.1 (Level B): a receiver that does not know them still reads a valid APDS Session.
The Session data domain documents the actual use of an AssignedRight. APDS 4.1 records when a Session started and ended, its Segments, and the credentials and vehicle identified. The additions proposed here record what a Session rests on and what happened at the entry and exit points of a Place, including attempts that never became a Session.
Two parties that receive the same Sessions should be able to compute the same dwell times, the same occupancy and the same revenue. Today they cannot always do so, because a Session does not say whether its end was observed or set by a rule, or whether its entry was ever seen. A Session closed after 48 hours with no exit observation and a Session closed by an exit camera look the same.
Access control systems refuse credentials every day: a lost keycard, an expired permit, a vehicle already inside. A refusal opens no Session, so it leaves no trace in APDS today. The help desk that takes the call from the lane, the issuer of the credential and the operator all need the same record of what happened.
Merchant validations are already anticipated by APDS through
Segment.validationId, but there is no record that the identifier points
to. Adding one lets a merchant, an operator and an auditor see the same
redemption and the actual amount it removed.
Valet operations are mentioned in APDS only as an operating restriction. A valet ticket records custody of the vehicle, where it is parked, and how it was returned, while the stay and the money remain on the APDS Session.
Session (additions)
Access event
Validation redemption
Segment.validationId identifies.Valet ticket
APDS 4.1 records an observation with its method, credential, location, images and an overall and per-character confidence. Modern licence plate recognition knows more: a confidence for each recognised attribute (plate, issuing country and state, make, model, colour), the candidate plates that lost, which plate of the vehicle was read, which way the vehicle moved, which reads belong to one passage, and whether a person has reviewed the read. These additions carry that, add two image kinds, record the condition of a vehicle taken into valet custody, and add a toll transaction built from observations. All are optional and compatible with APDS 4.1 (Level B).
The Observation data domain documents the observation of an entity in a Place performing an action. APDS 4.1 already records the method, the credential observed, the location, images, an overall confidence and a confidence for each character. The additions proposed here carry what recognition systems now also report, record the condition of a vehicle, and tie observations at a toll point into a charge.
Enforcement, access control and analytics all act on plate reads, and each needs to know how far to trust them. A camera can be sure of the plate characters and unsure of the issuing state, or sure of the plate and wrong about the colour. One overall confidence cannot say which. A confidence for each recognised attribute lets every receiver apply its own thresholds.
When a read is wrong, the right answer is often one of the other candidates the engine considered. Keeping those alternates lets a reviewer or a matching system correct the read without a new capture.
On sites without barriers, whether a vehicle entered or left is decided by the direction it moved past the camera. Recording the movement and the plate face read tells a receiver which way the vehicle passed.
Some jurisdictions require a person to confirm a plate before a penalty is issued. Recording the review state and its reasons carries that evidence with the observation.
Valet operators record a vehicle's condition when they take it and when they return it; that report is the evidence a damage claim is answered with. Toll operators assemble a charge from one or more observations at a toll point and must handle disputes about it.
Observation element (additions)
Image (additions)
Condition report
Toll transaction
APDS 4.1 describes charging infrastructure as it is built: the SupplementalEquipment, its RefillPoints and ElectricChargingPoints, the Connectors, and a RefillPointStatusEnum for the point as a whole. APX adds only the live, parking-side view that operators exchange every day: the status of each connector, what is physically in the bay in front of a charging point, and one charge of one vehicle (a ChargingSession) linked to the parking Session it happened inside. Status values reuse RefillPointStatusEnum; nothing here restates the static description or the charging network's own protocols. All of it is in use in APX (Part 23). It is optional and offered for discussion, and nothing else in this package depends on it.
The Energy Infrastructure additions let parking operators and charging
networks share the live state of charging points and the charges that take
place inside a parking stay. APDS 4.1 already describes charging
infrastructure as it is built, through SupplementalEquipment, RefillPoint,
ElectricChargingPoint and Connector, and it provides RefillPointStatusEnum
for the status of a refill point. The additions build on these and do not
restate them.
A driver looking for a charger wants to know whether one is free now, not only that one exists. An operator wants to know when a bay is taken by a vehicle that is not charging, and wants to bill a charge together with the parking. Charging networks already exchange this information among themselves using their own protocols. What parking systems lack is a common, parking-side way to describe it alongside Places, Spaces, Sessions and AssignedRights.
All of these additions are in use in APX (Part 23). They are optional and offered for discussion rather than for immediate adoption, and nothing else in this package depends on them.
A ChargingPointStatus:
refillPointIndex of
the static RefillPoint it describes, the link APDS already provides
between static and dynamic publications.RefillPointStatusEnum.A ChargingSession:
One addition to RecordType: the system that first created a record, when the record reaches a receiver through another system. Open code lists need no new element, because APDS ReferencedCodeListEntry and UserDefinedCodeList already provide the pattern. Two shared enumerations are added: one for the channel through which an action was taken, and one for why a record is no longer in use. Two related gaps in APDS 4.1 common classes are offered in the separate list of suggested corrections and are not repeated here.
The PkCommon domain holds the classes, datatypes and code list mechanism shared by every other domain. APX needs little here: two shared enumerations that several domains use, and, for discussion, one attribute for RecordType. Everything else APX relies on is already in APDS.
Several proposals record the channel through which something was done:
a payment, a merchant validation, a valet retrieval request, a customer
contact. If each had its own list, the same channel would carry
different codes in different records, and a report across them would
need a mapping table. One shared InteractionChannelEnum gives a pay
station, a contact centre or a mobile app the same code wherever it
appears.
In the same way, signage, validation programmes, plate lists and
enforcement policies all have a period of use and an active, planned or
suspended state. APDS already models both with the Validity class. The
only thing Validity cannot say is why a record stopped being used, so a
single small RecordEndReasonEnum (superseded or retired) is shared by
all of them instead of a separate status list for each.
Parking data increasingly passes through more than one system before it reaches its user. A city may receive Place and Session data from a regional hub that collects it from several operators.
RecordType already says who created a record and when it was last updated. It cannot say which system first created it when that differs from the system now distributing it. Without that, a receiver that gets the same record by two routes cannot easily tell they are the same, or which source to ask when a record is wrong.
Several proposals in other domains add an attribute whose values come from a list that each region or operator may extend. APDS already has the right mechanism for this: UserDefinedCodeList, with ReferencedCodeListEntry used to cite one entry. These proposals use those classes as they are and add no new code list element.
Two related gaps in the APDS 4.1 common classes are offered in the separate list of suggested corrections and are not repeated here.
APDS 4.1 already carries everything an enforcement finding is built from: the Observation and its Images, the Session, the AssignedRight and the Payment. Use Case C.2.2 describes transaction exceptions becoming violation notices, but the model has no class for the violation or the notice itself. This new domain adds them: the Violation (a finding that a vehicle at a place was not covered by a valid right), how it was detected, the Notice issued for it, the Appeal against it, and the EnforcementPolicy that governs notices and penalties at a place. Every class reuses APDS types for places, credentials, vehicles, evidence, locations, money and payments.
The Enforcement domain is new. It gives a name and a structure to what happens after an operation finds that a vehicle is not covered by a valid right. APDS 4.1 already carries everything such a finding is built from: Observations and their Images, Sessions, AssignedRights and Payments. Use Case C.2.2 describes transaction exceptions being converted into violation notices that create fines or penalties. The data model, however, has no class for the violation or the notice. This domain adds them.
Enforcement usually involves several parties: the operator that owns the rights and sessions, an enforcement provider with cameras or officers, a processing agency that sends notices and collects payment, and someone who hears appeals. Today each keeps its own record of the same violation and reconciles by hand. A shared description of the violation, its notice and its outcome lets these parties hand a case from one to the next. It also lets reporting compare enforcement across places, and lets a driver's appeal be checked against the same evidence and rules the notice was issued under.
Every class in the domain reuses APDS types for places, credentials, vehicles, evidence images, locations, money and payments, so a violation refers to the same records the rest of the model already uses.
A Violation:
A Notice:
An EnforcementPolicy:
Use Case C.2.2 lists transaction exceptions and space statuses that an operation must act on, and APDS 4.1 describes the places, equipment, sessions and rights they concern, but it has no class for the operational condition itself. This new domain adds the Alert: a condition at a place or piece of equipment that needs attention, with its type, severity and lifecycle. It also offers, for discussion only, a SupportInteraction record of one customer-service contact, which may sit outside the scope APDS sets itself.
The Operations domain is new. It describes conditions in a running parking operation that need someone's attention. Use Case C.2.2 lists transaction exceptions and space statuses that an operation acts on, such as no check-out, a vehicle in the wrong space, or an ICE vehicle in an EV space. APDS 4.1 describes the places, equipment, sessions and rights these conditions concern, but has no class for the condition itself. This domain adds the Alert.
Parking sites are often monitored from many places: the equipment supplier's service desk, a remote monitoring centre, the operator's control room, and enforcement and charging partners. Each needs to know when a barrier faults, a lane is blocked, a charging bay is taken by a vehicle that is not charging, or a vehicle on a watch list arrives. Each also needs to know whether someone has already taken the condition in hand. A shared description of these conditions lets one party raise them and others act on them, without one integration per supplier.
An Alert:
APX also records customer-service contacts, so that an agent helping a driver can see earlier calls about the same session. This may lie outside the scope APDS sets itself in its guiding principles. It is included so the group can decide, and APX is equally happy to keep it within its own profile.
A SupportInteraction:
As with APDS, these proposals do not define security or permission rules. Access to data remains under the control of the Distributing Party, which decides what each Receiving Party may see.
Several proposed elements carry personal data: plate reads, access events, violations, notices, appeals and customer service records. Parties exchanging them should apply the data protection law of their jurisdiction, share only what the receiving purpose needs, and agree how long records are kept. The proposals keep personal attributes optional wherever the element still makes sense without them.
The APX API is the implementation specification that APX maintains on top of APDS. It defines how the data described here is requested, delivered, changed and secured: routes, change feeds, signed event delivery, discovery, scopes, and the workflow for commands such as opening a gate. It is not part of this proposal.
Until APDS adopts an element, the APX API carries it as an APDS extension under the generic extension mechanism introduced in APDS 4.1 (Use Case Document §C.2.5). When APDS adopts an element, the APX API moves to the APDS form in its next release and retires its own, so the two never disagree.
We would welcome the working groups' views on:
We are glad to prepare UML model changes, data dictionary entries or pull requests in whatever form the Alliance prefers.
Contact: rneubauer@umojo.com